sprint
Execute a batch of backlog tickets in parallel. Use when the user wants to build multiple unblocked tickets simultaneously with integrated QA review.
What this skill does
# Sprint: $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
1. Read the backlog directory (`.solopreneur/backlog/`) for the relevant project. If `$ARGUMENTS` names specific tickets (e.g., `MVP-001 MVP-003`), use those. Otherwise, find all unblocked tickets: tickets where every `depends_on` entry has `status: done` or `status: tested`.
2. If no backlog directory exists, stop and guide the CEO:
```
No backlog found. Let's create one first:
/solopreneur:backlog [your spec or feature]
```
3. If all tickets are blocked or already done, report that and suggest next steps.
4. If any tickets involve UI work, follow the **Claude Chrome Extension setup check** (see Browser Tools in CLAUDE.md) before proceeding.
5. Check parallelism limit: use `--parallel N` from `$ARGUMENTS` if provided, else read `sprint.max_parallel_tickets` from `.solopreneur/preferences.yaml`, else default to **3**. Cap at that limit. If more tickets are unblocked, pick highest priority (lowest ticket number first).
6. 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):
1. **Code QA** (always): Spawn `@qa` to 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)
2. **Browser QA** (UI tickets only, when browser tools available): Delegate to `@qa` for browser-based validation — visual walk-through, screenshots, console errors, responsive checks.
3. **Design review** (UI tickets with mockups): Spawn `@designer` to 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:
1. Update ticket YAML: set `status: built`, set `branch: <worktree-branch>`, set `worktree: <worktree-path>` (from the Task agent's result).
2. **Keep the worktree alive** — do NOT clean it up. The worktree is needed if `/review` finds 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
```
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.