npx claudepluginhub pcatattacks/solopreneur-plugin --plugin solopreneurWant just this skill?
Then install: npx claudepluginhub u/[userId]/[slug]
Review code, specifications, or designs for quality, bugs, security, and best practices. Use when the user wants feedback on recent work, a pull request, or any artifact.
This skill uses the workspace's default tool permissions.
eval.csvReview: $ARGUMENTS
You are conducting a quality review. Determine what type of artifact is being reviewed based on $ARGUMENTS:
- If it's a file path ending in code extensions (.ts, .js, .py, etc.) or a PR → Code Review
- If it's a path to a
.solopreneur/specs/file or mentions "spec" → Spec Review - If it's a path to a
.solopreneur/designs/directory or file, or mentions "design" → Design Review - If it's a path to a
.solopreneur/backlog/ticket file (e.g.,MVP-001.md) → Ticket Review - If
$ARGUMENTSmentions "sprint" or "batch" → Sprint Review (scans all backlog directories forstatus: builttickets) - If it's a path to a
.solopreneur/plans/file → Plan Validation (check completed steps against acceptance criteria)
Code Review
Delegate in parallel:
@engineer: Architecture review — code structure, patterns, maintainability, performance. Rate every finding using severity format (Critical/Warning/Suggestion/Positive).@qa: Bug hunting — security vulnerabilities, edge cases, error handling, test coverage. Rate every finding using severity format.
Spec Review
Delegate in parallel:
@bizops: Business viability — does this make commercial sense? Are requirements prioritized correctly? Provide a go/no-go per requirement.@engineer: Technical feasibility — can this be built as specified? Flag complexity risks, estimate effort, note missing requirements. Rate each requirement: feasible / complex / risky.
Design Review
If reviewing a design directory, read design-brief.md for flows and visual direction. If HTML mockups exist, open them in the browser (Chrome DevTools MCP if available) to inspect the actual layouts.
Delegate in parallel:
@designer: Usability review — is the flow intuitive? Accessibility issues? If HTML mockups exist, inspect for visual consistency and responsive behavior. Rate findings using severity format.@engineer: Implementability — can this be built as designed? Flag any technical constraints. Rate findings using severity format.
Ticket Review
Read the ticket file for acceptance criteria and the ## Files section for what was built. Delegate in parallel:
@engineer: Validate implementation against each acceptance criterion. Check code quality and architecture. Rate findings using severity format.@qa: Test edge cases, security, error handling specific to this ticket's scope. Rate findings using severity format.
Browser Validation (UI tickets)
If the ticket involves UI changes (references design mockups, creates HTML/CSS/frontend files, or has UI-related acceptance criteria):
- Follow the Claude Chrome Extension setup check (see Browser Tools in CLAUDE.md)
- Delegate browser validation to
@qa— visual walk-through, screenshots, console errors - Optionally spawn
@designerto compare against design mockups if they exist in.solopreneur/designs/
On pass, update the ticket's YAML frontmatter: status: tested.
If the ticket has a branch field in its YAML frontmatter, offer to merge:
This ticket passes review. Want me to merge branch
{branch}into main?
If yes:
- Merge:
git checkout main && git merge {branch} --no-ff -m "Merge ticket/{ID}: {title}" - Update ticket status to
done. - Delete the branch:
git branch -d {branch} - If the ticket has a
worktreefield, clean it up:git worktree remove {worktree} - If merge conflicts: adapt to technical level (check
.solopreneur/preferences.yaml) — technical users see conflicts; non-technical users get plain-language explanation.
On fail, list what needs fixing and suggest:
-> These issues need to be fixed before merging. Run:
/solopreneur:build .solopreneur/backlog/{date}-{slug}/{ID}.md
Sprint Review
Scan all .solopreneur/backlog/ directories for tickets with status: built that have a branch field in their YAML frontmatter.
If no built tickets found, report that and suggest:
No tickets ready for review. Build first:
/solopreneur:sprint
Phase 1 — Parallel Code Review
For each built ticket, spawn background review agents in parallel:
@engineer: Validate implementation against acceptance criteria, check architecture and code quality. Rate findings using severity format.@qa: Test edge cases, security, error handling for this ticket. Rate findings using severity format.
This means 2 agents per ticket (up to 6 agents for 3 tickets), all running simultaneously.
Phase 2 — Sequential CEO Review
As review results come in, present a consolidated report grouped by ticket using the standard Output Format (Critical / Warnings / Suggestions / Positives).
For UI tickets: run Browser Validation at this point (sequential — browser is shared state). Follow the Claude Chrome Extension setup check. Optionally spawn @designer to compare against design mockups if they exist.
The CEO reviews the product, flow, and findings with their own eyes.
Phase 3 — Merge Decisions
For each ticket, based on the CEO's decision:
- Pass: Merge the ticket's branch to main (same merge logic as Ticket Review). Clean up the worktree if present:
git worktree remove {worktree}. Update status todone. - Fail: List issues and suggest fixes. Keep the worktree alive so the CEO can fix in parallel:
-> Ticket {ID} needs fixes. The code is in its worktree — run: /solopreneur:build .solopreneur/backlog/{dir}/{ID}.md
After all merge decisions:
-> Next: Ready to ship?
/solopreneur:ship
More tickets to build?
/solopreneur:sprint
Plan Validation (after Cursor execution)
Read the plan file and check git diff or file state:
- For each step with acceptance criteria, delegate to
@qato validate - Update the plan file with checkboxes:
- [x] Step N: ... (validated)or- [ ] Step N: ... (FAILED: reason)
Output Format
Compile all findings into a structured review:
- Critical Issues: Must fix before proceeding
- Warnings: Should fix, but not blocking
- Suggestions: Nice-to-have improvements
- Positives: Things done well (always include at least one)
End with the next step prompt (adapt based on context):
If ticket(s) were just merged:
-> Next: Ready to ship what we've built?
/solopreneur:ship
More tickets to build?
/solopreneur:sprint
If review failed (no merge):
-> These issues need fixing first. Then re-review:
/solopreneur:build .solopreneur/backlog/{dir}/{ID}.md
Otherwise (general review, no ticket merge):
-> Next: Ready to ship? Run:
/solopreneur:ship
Or want a deeper adversarial discussion on the findings?
/solopreneur:kickoff code review
(assembles your team for collaborative debate — takes longer, deeper analysis)
Similar Skills
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.