sprint
Scannednpx machina-cli add skill pcatattacks/solopreneur-plugin/sprint --openclawSprint: $ARGUMENTS
You are the sprint orchestrator. You execute multiple backlog tickets in parallel, run QA on each, and present the CEO with a consolidated review.
Process
Phase 0 — Load & Validate
-
Read the backlog directory (
.solopreneur/backlog/) for the relevant project. If$ARGUMENTSnames specific tickets (e.g.,MVP-001 MVP-003), use those. Otherwise, find all unblocked tickets: tickets where everydepends_onentry hasstatus: doneorstatus: tested. -
If no backlog directory exists, stop and guide the CEO:
No backlog found. Let's create one first: /solopreneur:backlog [your spec or feature] -
If all tickets are blocked or already done, report that and suggest next steps.
-
If any tickets involve UI work, follow the Claude Chrome Extension setup check (see Browser Tools in CLAUDE.md) before proceeding.
-
Check parallelism limit: use
--parallel Nfrom$ARGUMENTSif provided, else readsprint.max_parallel_ticketsfrom.solopreneur/preferences.yaml, else default to 3. Cap at that limit. If more tickets are unblocked, pick highest priority (lowest ticket number first). -
Present the plan to the CEO with AskUserQuestion:
I'll build these N tickets in parallel, each in its own isolated branch: - MVP-001: [title] (size: S) - MVP-002: [title] (size: M) - MVP-003: [title] (size: S) Proceed?
Phase 1 — Parallel Build
On CEO approval, spawn background Task agents (one per ticket, @engineer, isolation: "worktree"):
Each agent receives:
- The full ticket content (requirements, acceptance criteria, file list)
- Engineering guidance: "You are a senior engineer building this ticket. Start with the simplest solution. Write clean code with proper error handling. Run tests if a test suite exists (
npm test,pytest, etc.). Check each acceptance criterion before returning." - Instructions to return structured results:
## Results: [TICKET-ID] **Status**: pass | fail **Files changed**: [list] **Tests**: [pass count]/[total] or "no test suite" **Acceptance criteria**: - [criterion 1]: pass/fail - [criterion 2]: pass/fail **Notes**: [anything the CEO should know]
Cap agents at the parallelism limit from Phase 0. If there are fewer tickets than the limit, that's fine — the sprint still works with fewer agents.
Phase 2 — QA Review
As each build agent completes, run foreground subagent review (sequential, one ticket at a time):
-
Code QA (always): Spawn
@qato review the built code:- Code quality, security, edge cases
- Verify each acceptance criterion against the actual code
- Run tests if available
- Produce severity-rated findings (Critical / Warning / Suggestion / Positive)
-
Browser QA (UI tickets only, when browser tools available): Delegate to
@qafor browser-based validation — visual walk-through, screenshots, console errors, responsive checks. -
Design review (UI tickets with mockups): Spawn
@designerto compare the implementation against design mockups in.solopreneur/designs/:- Visual accuracy vs mockups
- Spacing, alignment, responsive behavior
- Flag any deviations
Phase 3 — Build Report
Compile all results into a consolidated sprint report:
Sprint Complete: N tickets built
MVP-001: Login Form ✓ BUILT
Tests pass (12/12)
QA: No critical issues
MVP-002: Dashboard ⚠ BUILT (with warnings)
Tests pass (8/8)
QA: Chart overflows on mobile
MVP-003: Settings Page ✓ BUILT
Tests pass (5/5)
QA: Clean
For each built ticket:
- Update ticket YAML: set
status: built, setbranch: <worktree-branch>, setworktree: <worktree-path>(from the Task agent's result). - Keep the worktree alive — do NOT clean it up. The worktree is needed if
/reviewfinds issues and the CEO needs to fix in parallel.
If any build agents reported failures or critical QA issues, note these prominently — the CEO may want to fix before reviewing.
Suggest review:
-> Next: Let's review and merge what was built:
/solopreneur:review sprint
If some tickets failed to build:
-> {N} tickets built successfully, {M} had issues.
Review the successful ones:
/solopreneur:review sprint
Fix the failed ones:
/solopreneur:build .solopreneur/backlog/{dir}/{ID}.md
Source
git clone https://github.com/pcatattacks/solopreneur-plugin/blob/main/skills/sprint/SKILL.mdView on GitHub Overview
Sprint orchestrates parallel work on backlog tickets, running integrated QA and delivering a consolidated report for leadership. It loads the backlog, selects unblocked tickets (or uses explicit IDs), and builds each ticket in isolation to keep changes separate and auditable.
How This Skill Works
Phase 0 loads and validates backlog from .solopreneur/backlog/, selecting specified tickets or all unblocked ones. It then determines the parallelism limit (via --parallel, then sprint.max_parallel_tickets in preferences.yaml, defaulting to 3) and caps the count. Phase 1 spawns one background task agent per ticket within the limit, each working on its own branch and meeting acceptance criteria. Phase 2 runs foreground QA—code QA for all builds, optional browser QA for UI tickets, and design review for UI against mocks—producing structured findings. Phase 3 compiles a Sprint Complete report and updates each ticket with status, branch, and worktree details.
When to Use It
- You want to build multiple ready backlog tickets at the same time.
- You require integrated QA review for every ticket in a single sprint.
- You need to enforce a parallelism limit to avoid resource contention.
- You want a consolidated sprint report summarizing build and QA results.
- You have resolved dependencies and want to ensure only unblocked tickets run.
Quick Start
- Step 1: Ensure backlog exists or specify the tickets you want to build (or rely on unblocked tickets).
- Step 2: Run the sprint command with an optional --parallel N to set concurrency.
- Step 3: Review the Sprint Complete report and address any QA findings.
Best Practices
- Explicitly specify ticket IDs when you want targeted parallel work.
- Define clear acceptance criteria in every ticket to enable objective QA.
- Keep backlog entries unblocked by ensuring dependencies are marked done or tested.
- Tune sprint.max_parallel_tickets and use --parallel to control concurrency.
- Review QA findings promptly and update tickets or backlog accordingly.
Example Use Cases
- MVP-001 and MVP-003 built in parallel, each in its own worktree, with consolidated QA results.
- Four UI-related tickets run in parallel, with code QA and browser QA validating UI behavior.
- Backend API tickets built concurrently; tests executed and results logged per ticket.
- Sprint invoked with --parallel 2 to prevent resource spikes during a heavy release window.
- Sprint Complete report lists status, tests, and QA notes for all built tickets.