Menu
Use when a Plan is complete and ready for review. Two-stage review -- spec contract compliance first, code quality second. Block on contract failure before reviewing code.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Use when carrying out the work a delivery document describes -- the build loop -- against its task breakdown and acceptance criteria.
Use as the entry point for any work, including reported bugs, defects, and unexpected behaviour. Reads the configured DAG and the user's position, then dispatches the right verb -- advancing within the current document automatically but stopping at type boundaries.
Use when moving a document to its next status along the type's lifecycle DAG, maintaining links and checking gates at the transition.
Use when drafting a document of a configured type collaboratively -- AI proposes a draft body, the human edits, iterate -- up to the type's authorship ceiling.
Use when adding a new custom document type to a lazyspec project. Interviews the user to co-author the type's methodology -- intent, authorship, lifecycle, gates, relations -- then writes its enriched template and `[[types]]` config via the config-write CLI. One type per run.
Use when running a criteria-based review (health check, security audit, accessibility review, pen test, bug bash, spec compliance). Creates an Audit document with findings and presents them to the user for triage.
| name | review-plan |
| description | Use when a Plan is complete and ready for review. Two-stage review -- spec contract compliance first, code quality second. Block on contract failure before reviewing code. |
NO APPROVAL WITHOUT FRESH VERIFICATION EVIDENCE
If you haven't run the tests in this session, you cannot claim they pass.
Do NOT approve without running verification commands in this session. Stage 1 (contract compliance) MUST pass before entering Stage 2 (code quality). If contracts fail during a `/build` per-task review, dispatch a fix subagent. If contracts fail during a standalone review, use `/create-plan` to re-plan.- Do NOT approve without running tests in the current session. Do NOT trust prior test reports.[!IMPORTANT] Read
_common.mdin the skills directory for CLI usage, forbidden actions, and subagent tiers.
lazy -> write-rfc -> create-spec -> resolve-context -> create-plan -> build -> review-plan
review-plan.style.fill: "#4A9EFF"
review-plan.style.font-color: "#FFFFFF"
lazy.style.opacity: 0.4
write-rfc.style.opacity: 0.4
create-spec.style.opacity: 0.4
resolve-context.style.opacity: 0.4
create-lazy.style.opacity: 0.4
build.style.opacity: 0.4
This skill operates in two modes:
Per-task review (dispatched as a reviewer subagent by /build after each task):
/build orchestrator, which dispatches a fix subagentFull review (dispatched by /build as final gate, or used standalone):
/build: targeted fix subagents for specific gapslazyspec context <plan-id> --json to see RFC -> Spec -> Planlazyspec show <plan-id> --jsonlazyspec show <spec-id> --jsonBEFORE claiming review passes:
1. IDENTIFY: Which Spec contracts does this plan cover?
2. RUN: Execute the FULL test suite (fresh, in this session)
3. READ: Full output, check exit code, count failures
4. VERIFY: Does each claimed contract have a passing test?
- If NO: State which contracts are unmet. Return to create-plan.
- If YES: Proceed to Stage 2 (code quality)
5. ONLY THEN: Approve
Skip any step = not a review
Read plan doc -> Read parent spec contracts -> Run full test suite -> All contracts satisfied?
All contracts satisfied?.shape: diamond
All contracts satisfied? -> Fix (see failure handling below): no
All contracts satisfied? -> Code quality review: yes
Code quality review -> Critical issues?
Critical issues?.shape: diamond
Critical issues? -> Fix (see failure handling below): yes
Critical issues? -> Approve: no
Approve.shape: double_circle
lazyspec context <plan-id> --json to see the full chain.lazyspec show <plan-id> --json to read the plan body.lazyspec show <spec-id> --json to read the Spec's contracts.Only enter this stage if all contracts are satisfied.
Review the code changes for correctness and clarity.
Verify no unnecessary complexity (YAGNI -- only what was asked for).
Check for real duplication worth extracting (DRY).
Check for security issues.
Evaluate test quality against these properties:
| Property | What to check |
|---|---|
| Behavioral | Tests assert on behavior, not implementation details |
| Structure-insensitive | A refactor preserving behavior shouldn't break tests |
| Isolated | No order dependence, no shared mutable state between tests |
| Deterministic | No flaky results from timing, randomness, or global state |
| Readable | Motivation for each test is obvious to the reader |
| Specific | When a test fails, the cause is obvious |
| Writable | Test complexity is proportional to code complexity |
These properties conflict. If a test trades one for another (e.g. an integration test that sacrifices Fast/Isolated for Predictive/Inspiring), the tradeoff should be noted. Flag unjustified tradeoffs to the collaborator.
The response to a failed review depends on context:
During /build per-task review: Report the specific failures back to the /build orchestrator. The build skill will dispatch a fresh implementer subagent with the failure details. Do NOT re-plan or use /create-plan.
During /build final review: If individual contracts are unmet, the build skill dispatches targeted fix subagents. If the failures indicate a fundamental planning problem (wrong approach, missing tasks), escalate to the user.
Standalone review (not during build): Report failures to the user. The user decides whether to use /create-plan to re-plan or fix directly.
| Red Flag | Reality |
|---|---|
| "The agent says tests pass" | Run them yourself. Trust is not evidence. |
| "I ran them earlier" | Earlier is stale. Run them now, in this session. |
| "The code looks right to me" | Code review before contract compliance is backwards. Check contracts first. |
| "It mostly works" | Mostly = some contracts aren't met. Return to implementation. |
Before claiming this review is approved:
lazyspec validate --json passesWhen a review passes (both stages), follow the status promotion steps in _common.md.