بنقرة واحدة
review-design
// Review design, implementation, and task documents produced by design. Evaluates document quality, internal consistency, and technical soundness. Use after design completes and before starting implement.
// Review design, implementation, and task documents produced by design. Evaluates document quality, internal consistency, and technical soundness. Use after design completes and before starting implement.
Code review of current git changes with an expert senior-engineer lens. Detects SOLID violations, security risks, and proposes actionable improvements. Use when performing code reviews.
Code review of current git changes with an expert senior-engineer lens. Detects SOLID violations, security risks, and proposes actionable improvements. Use when performing code reviews.
Review design, implementation, and task documents produced by design. Evaluates document quality, internal consistency, and technical soundness. Use after design completes and before starting implement.
TRIGGER when: user asks to implement, fix, build, or work on something — whether from a docs/wip plan OR a standalone task (bug fix, GitHub issue, one-off change). Examples: "work on task 1", "fix this bug", "implement feature X from the issue". Provides structured execution with profile detection, dependency handling, review checkpoints.
TRIGGER when: user asks to implement, fix, build, or work on something — whether from a docs/wip plan OR a standalone task (bug fix, GitHub issue, one-off change). Examples: "work on task 1", "fix this bug", "implement feature X from the issue". Provides structured execution with profile detection, dependency handling, review checkpoints.
After implementing a new feature or fixing a bug, make sure to document the changes. Use when writing documentation, after finishing the implementation phase for a feature or a bug-fix.
| name | review-design |
| description | Review design, implementation, and task documents produced by design. Evaluates document quality, internal consistency, and technical soundness. Use after design completes and before starting implement. |
Read capy knowledge base conventions at shared-capy-knowledge-protocol.md.
Pre-implementation review gate that evaluates design documents produced by /kk:design before code is written. Sits between /kk:design (creates docs) and /kk:implement (executes them). Reviews tree distinct dimensions
/kk:review-design)Reviews design documents in the main conversation context. Fast, single-pass review using the workflow below.
/kk:review-design:isolated)Delegates detection to independent reviewers that did not participate in the design, then annotates their findings with author context. Two parallel reviewers: a design-reviewer sub-agent and pal codereview (external model in native format). Produces a report organized by agreement level with corroborated findings highlighted.
See review-isolated.md for the isolated workflow.
| Type | Code | Description |
|---|---|---|
| Incomplete Spec | INCOMPLETE | Section lacks sufficient detail for implementation |
| Internal Inconsistency | INCONSISTENT | Two parts of the docs contradict each other |
| Technical Risk | TECH_RISK | Architecture choice has unaddressed failure modes, scalability concerns, or edge cases |
| Missing Concern | MISSING | Cross-cutting concern is absent (error handling, migration, backwards compatibility) |
| Ambiguity | AMBIGUOUS | Requirements can be interpreted multiple ways, likely to cause implementation divergence |
| Structure Issue | STRUCTURE | Document doesn't follow project conventions — missing sections, vague subtasks |
| Level | Name | Description | Action |
|---|---|---|---|
| P0 | Critical | Fundamental flaw — design will not work as described, or critical requirement is missing | Must fix before implementation |
| P1 | High | Significant gap — likely to cause rework or wrong implementation | Should fix before implementation |
| P2 | Medium | Moderate concern — ambiguity or missing detail that could cause confusion | Fix or create follow-up |
| P3 | Low | Minor — style, structure, or nitpick | Optional |
Mandatory order — methodology before evaluation. The flow below is strictly sequential. Do not evaluate document quality, assess technical soundness, or form findings until this SKILL.md and the process file are fully loaded. The design documents are both instruction context (they define what the feature is) and subject matter (they are what you evaluate) — but the review methodology and rubric must be loaded first.
Phases:
kk:arch-decisions and kk:review-findings for prior contextSee review-process.md for the detailed step-by-step process.
Post-design gate. This is the recommended review step after /kk:design completes and before /kk:implement begins. The default scope reviews all documents, including task-format checks.
Standard mode — reviews all documents by default:
/kk:review-design [feature-name]
Standard mode with scope — review specific documents:
/kk:review-design [feature-name] design
/kk:review-design [feature-name] implementation
/kk:review-design [feature-name] tasks
| Scope | Documents reviewed |
|---|---|
| (none) | design.md + implementation.md + tasks.md |
design | design.md only |
implementation | implementation.md only |
tasks | tasks.md only |
Isolated mode with independent sub-agents:
/kk:review-design:isolated [feature-name]
/kk:review-design:isolated [feature-name] tasks