Design Review

SkillDocs & knowledge

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.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Design Review skill

What this skill tells your AI

The instructions your AI receives, as published by serpro69/claude-toolbox in kodex-plugin/skills/review-design/SKILL.md and read by ahel’s review.

Conventions

Overview

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

  • document quality/structure (completeness, internal consistency, clarity, convention adherence)
  • technical soundness (architectural viability, edge cases, failure modes, trade-off analysis)
  • feature value (Does the feature improve things for end-users? Is it useful? Is it correct in how it tries to solve the problem?)

Review Modes

Standard Mode ($kk:review-design)

Reviews design documents in the main conversation context. Fast, single-pass review using the workflow below.

Isolated Mode ($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.

  • Cost: Higher (sub-agent + external model + annotation)
  • Isolation: True — reviewers have zero authorship bias or session context
  • Degradation: Graceful — if one reviewer fails, proceeds with the other; if both fail, suggests standard mode fallback
  • Best for: When extra rigor is worth the cost (before starting implementation of high-stakes features)

See review-isolated.md for the isolated workflow.

Finding Types

TypeCodeDescription
Incomplete SpecINCOMPLETESection lacks sufficient detail for implementation
Internal InconsistencyINCONSISTENTTwo parts of the docs contradict each other
Technical RiskTECH_RISKArchitecture choice has unaddressed failure modes, scalability concerns, or edge cases
Missing ConcernMISSINGCross-cutting concern is absent (error handling, migration, backwards compatibility)
AmbiguityAMBIGUOUSRequirements can be interpreted multiple ways, likely to cause implementation divergence
Structure IssueSTRUCTUREDocument doesn't follow project conventions — missing sections, vague subtasks

Severity Levels

LevelNameDescriptionAction
P0CriticalFundamental flaw — design will not work as described, or critical requirement is missingMust fix before implementation
P1HighSignificant gap — likely to cause rework or wrong implementationShould fix before implementation
P2MediumModerate concern — ambiguity or missing detail that could cause confusionFix or create follow-up
P3LowMinor — style, structure, or nitpickOptional

Workflow

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:

  1. Load documents — parse scope, locate feature directory, read in-scope docs
  2. Capy search — search kk:arch-decisions and kk:review-findings for prior context
  3. Document quality review — completeness, clarity, consistency, convention adherence
  4. Technical soundness review — viability, edge cases, trade-offs, scalability, testing strategy
  5. Self-check and confidence assessment — re-read, question assumptions, assign confidence
  6. Present findings with next steps

See review-process.md for the detailed step-by-step process.

Invocation

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
ScopeDocuments reviewed
(none)design.md + implementation.md + tasks.md
designdesign.md only
implementationimplementation.md only
taskstasks.md only

Isolated mode with independent sub-agents:

$kk:review-design:isolated [feature-name]
$kk:review-design:isolated [feature-name] tasks

Signals

GitHub stars
149
Forks
31
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
review-design-serpro69
Source
github.com/serpro69/claude-toolbox