conventions
Scannednpx machina-cli add skill pcatattacks/solopreneur-plugin/conventions --openclawSolopreneur Conventions
These conventions are the single source of truth for shared formats across the solopreneur workflow.
Ticket Schema
Tickets are YAML-frontmatter markdown files in .solopreneur/backlog/{project}/:
---
id: MVP-001
title: Short descriptive title
priority: MVP | P1 | P2
type: eng | design | eng+design
status: pending | in-progress | built | tested | done
depends_on: []
blocks: []
design_ref: .solopreneur/designs/{dir}/{screen}.html
branch: ticket/{ID}
worktree: /path/to/worktree
---
## Description
What this ticket implements and why.
## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
## Technical Notes
Stack choices, approach, risks.
## Files
(Populated during build)
Status Transitions
pending → in-progress (build starts)
in-progress → built (build completes)
built → tested (QA passes in review)
tested → done (merged to main in review)
Where Transitions Happen
Skills contain the operational instructions for the orchestrator. If the state machine changes, update these locations:
pending → in-progress: build/SKILL.md (line 43), sprint delegates to buildin-progress → built: build/SKILL.md (line 150), sprint/SKILL.md (line 99)built → tested: review/SKILL.md (line 51)tested → done: review/SKILL.md (lines 58, 99)
Review Severity Format
When producing review findings, rate every issue:
- Critical: Breaks functionality, security vulnerability, data loss risk. Must fix before proceeding.
- Warning: Incorrect behavior in edge cases, missing validation. Should fix, not blocking.
- Suggestion: Code quality improvement, better patterns available. Nice-to-have.
- Positive: Things done well. Always include at least one.
Plan File Format
Implementation plans use this structure:
# Plan: [Feature Name]
## Context
[What we're building and why. Reference source spec/design if applicable.]
**Branch**: `ticket/{ID}` (if ticket build)
## Step N: [Short description]
**Files**: `path/to/file.ext` (create|modify)
**Do**: [Clear, specific instructions for what to write]
**Acceptance**: [Concrete criteria to verify this step is done]
Source
git clone https://github.com/pcatattacks/solopreneur-plugin/blob/main/skills/conventions/SKILL.mdView on GitHub Overview
Defines the single source of truth for shared formats across the solopreneur workflow. It standardizes ticket schemas, status transitions, review formats, and plan layouts to keep agents aligned.
How This Skill Works
Tickets are YAML frontmatter markdown files in .solopreneur/backlog/{project}/ with fields like id, title, priority, type, and status. The conventions also define status transitions (pending → in-progress → built → tested → done), review severity formats, and a uniform plan file format to guide implementation.
When to Use It
- Initiating a new project or ticket with a consistent schema
- Aligning design and engineering work with common fields like design_ref
- Enforcing predictable progress through the status transitions
- Preparing QA/review with standardized severity and acceptance criteria
- Documenting implementation plans with the Plan File Format
Quick Start
- Step 1: Create a new ticket in .solopreneur/backlog/{project}/ using the YAML frontmatter schema
- Step 2: Fill in Description, Acceptance Criteria, Technical Notes, and Files as needed
- Step 3: Define a Plan using the Plan File Format and push through the status transitions
Best Practices
- Always use the Ticket Schema frontmatter for new tickets
- Follow the defined status transitions to signal progress
- Populate Description, Acceptance Criteria, and Technical Notes
- Use the Review Severity Format for findings
- Reference the Plan File Format when outlining steps
Example Use Cases
- Ticket MVP-001 with YAML frontmatter fields including id, title, priority, type, status
- Status flow demonstrated: pending → in-progress → built → tested → done
- Plan file used: # Plan: [Feature Name] with Context and Step entries
- Review checklist utilized with - [ ] criteria under Acceptance Criteria
- design_ref and branch fields populated for artifact linkage
