From plan-pipeline
Stage 4 of the planning pipeline — transforms the agreed task model into a concrete implementation design with change maps, technical decisions, and user approval points. Use this skill when: Stage 3 task synthesis is complete and you need to design how the task will be implemented in the system; the user has an agreed-task-model.md and wants to move to implementation design; you need to determine which files, modules, and interfaces to change, what technical decisions to make, and what to confirm with the user before coding begins. Triggers on: stage 4, solution design, design implementation, implementation design, design the solution, how to implement, plan the changes, map the changes, technical design, design review, проектирование решения, дизайн реализации, карта изменений.
How this skill is triggered — by the user, by Claude, or both
Slash command
/plan-pipeline:solution-designThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are executing Stage 4 of the planning pipeline. Your job is to transform the synthesized task model from Stage 3 into a concrete, actionable implementation design — and then present a **combined review** to the user covering both the task understanding and the design.
agents/design-architect.mdagents/design-critic.mdevals/evals.jsonevals/fixtures/dashboard-stage3-artifacts/agreed-task-model.mdevals/fixtures/dashboard-stage3-artifacts/agreement-package.mdevals/fixtures/dashboard-stage3-artifacts/stage-3-handoff.mdevals/fixtures/rejection-stage3-artifacts/analysis.mdevals/fixtures/rejection-stage3-artifacts/incomplete-handoff.mdevals/fixtures/sso-stage3-artifacts/agreed-task-model.mdevals/fixtures/sso-stage3-artifacts/agreement-package.mdevals/fixtures/sso-stage3-artifacts/stage-3-handoff.mdYou are executing Stage 4 of the planning pipeline. Your job is to transform the synthesized task model from Stage 3 into a concrete, actionable implementation design — and then present a combined review to the user covering both the task understanding and the design.
You do NOT write code or execute changes. You design the implementation and get user confirmation — nothing more. Stage 3 synthesized the understanding (but did not get user confirmation). Stage 4 designs the solution AND presents the combined review.
Think of it this way: Stage 3 produced a draft task model (validated by critic, but not yet confirmed by the user). Stage 4 takes that understanding, maps it onto the actual codebase, and then presents the user with one comprehensive review: "here's what we understood AND here's what we'll build." This combined review reduces user fatigue — one serious review instead of two fragmented ones.
This stage requires Stage 3 output with a synthesized task model (draft, pending user confirmation).
Before doing anything else, verify you have one of these input sets:
Preferred (Stage 3 format):
stage-3-handoff.md — self-contained handoff document with synthesized goal, scope, scenarios, constraints, and solution direction. This is the single entry point.Full context (recommended to also load):
agreed-task-model.md — the draft task model (status: draft — pending user confirmation in this stage's combined review)analysis.md — synthesized analysis from Stage 3agreement-package.md — Stage 3's agreement blocks (to include in the combined review)Supporting references (load if available):
product-analysis.md — detailed product/business analysis (Stage 2)system-analysis.md — detailed codebase/system analysis (Stage 2)constraints-risks-analysis.md — detailed constraints/risks analysis (Stage 2)If stage-3-handoff.md is missing or agreed-task-model.md doesn't exist, stop immediately and tell the user — send it back to Stage 3. If agreement-package.md is missing, warn the user that the combined review will not include the understanding blocks — the user will only review the design.
The stage runs in a cycle: design → critique → combined user review (understanding + design) → refine — repeating until both the task understanding and the design are confirmed.
Read all Stage 3 artifacts and supporting references. Build a comprehensive picture:
stage-3-handoff.md for the agreed modelagreed-task-model.md for the full confirmed understanding including user correctionsanalysis.md for the analytical depthPrepare a design brief (~300 words) for the subagents covering:
Spawn a Design Architect subagent to build the initial implementation design.
name: "design-architect"subagent_type: "Explore"prompt: the FULL content of the <design-architect> definition combined with the input data below — the agent definition IS the prompt, do not summarize or skip itThe architect must actually read the codebase to verify and extend the change map from Stage 2. Stage 2's system analysis provides a starting point, but the architect digs deeper — tracing data flows, checking interfaces, discovering implicit dependencies that surface only when you design the actual changes.
The architect returns:
Once the architect returns, spawn a Design Critic subagent.
name: "design-critic"subagent_type: "Explore"prompt: the FULL content of the <design-critic> definition combined with the input data below — the agent definition IS the prompt, do not summarize or skip itThe critic independently reviews the design for:
Save the critic's feedback.
If DESIGN_APPROVED:
If NEEDS_REVISION:
Assemble design-review-package.md — a combined review document that covers both the task understanding (from Stage 3) and the implementation design.
This is the user's first and primary review point — they haven't seen the synthesized understanding yet. The package must give them the full picture in one coherent document.
Part 1 — Task Understanding (from Stage 3's agreement-package.md):
Part 2 — Implementation Design:
Part 3 — Key Decisions (3-5 items max): Structure the combined review around key decisions — the most important choices that affect the outcome. Each decision should be self-contained: context, options (if any), recommendation, and a clear question.
Keep the total to 3-5 decision points. The goal is one focused review session, not a questionnaire. If a decision is obvious from context, don't make it an approval point — just include it in the summary.
Present the combined review package to the user.
This is a single, coherent review — not two separate reviews stitched together. The user should read it once and come back with all their feedback in one pass.
Show:
Ask: "Does this match your understanding? Do you agree with the approach and the key decisions? Anything to change before we proceed to decomposition?"
Do NOT split this into multiple rounds. Present everything, let the user respond once with all their feedback. If they want to discuss specific points, follow up — but don't force sequential block-by-block confirmation.
If the user rejects the understanding (Part 1): The synthesis is wrong — roll back to Stage 3. Re-run synthesis with the user's corrections as explicit input. Then re-design in Stage 4.
If the user rejects the design (Part 2) but accepts understanding: Re-run Steps 2-6 of this stage with the user's feedback. No need to re-do Stage 3.
If the user rejects the understanding AND the analysis seems wrong: Roll back to Stage 2. Re-run deep analysis with the user's corrections, then Stage 3, then Stage 4.
After all user feedback:
agreed-task-model.md with user corrections from the combined review. Change status from "draft" to "confirmed". Update the Agreed on date. Add user corrections to the User Corrections Log. This is now the agreed foundation — user-confirmed understanding.Build the four design artifacts using the Artifact Templates section below:
implementation-design.md — the main design artifactchange-map.md — detailed map of all changesdesign-decisions.md — journal of key decisions with reasoningstage-4-handoff.md — handoff for the next stageAlso finalize agreed-task-model.md (from Stage 3) with user confirmations.
Present a brief summary:
Then offer the user two options for continuing to Stage 5:
Option 1 — Continue in this session:
"Запустить Stage 5 (Implementation Decomposition) прямо сейчас в этой сессии?"
If the user agrees, invoke the /implementation-decomposition skill.
Option 2 — Continue in a new session: Provide a ready-to-paste block with actual paths filled in:
Запусти /implementation-decomposition
Task ID: {task-id}
Артефакты: .planpipe/{task-id}/ (stage-1/ через stage-4/)
This stage produces up to five files. Every artifact must follow its template exactly. These templates ensure consistency across tasks and enable the next stage to parse the output reliably.
implementation-design.mdWhen: Always created. The main design artifact — the complete implementation design.
# Implementation Design
> Task: [one-line summary]
> Solution direction: [minimal / safe / systematic — as agreed]
> Design status: [draft / user-reviewed / finalized]
## Implementation Approach
### Chosen Approach
[What approach was chosen and why. 2-3 paragraphs covering: the core idea, why this path over alternatives, and whether this is a minimal fix or a more systematic change.]
### Alternatives Considered
- **[Alternative A]:** [What it is, why it was rejected — specific trade-off that made it worse]
- **[Alternative B]:** [...]
### Approach Trade-offs
[Honest assessment: what this approach gives up, what risks it accepts, what it optimizes for]
## Solution Description
### Overview
[How the solution works end-to-end. Walk through the primary scenario showing how data flows through the changed system.]
### Data Flow
[How data moves through the system after changes. Include: entry point → processing → storage → output. Mark which parts are new vs. modified.]
### New Entities
[New types, classes, functions, services, or modules being added]
| Entity | Type | Location | Purpose |
|--------|------|----------|---------|
| [name] | class/function/service/type | `path/to/file` | [what it does] |
### Modified Entities
[Existing entities that change]
| Entity | Location | Current Behavior | New Behavior | Breaking? |
|--------|----------|-----------------|-------------|-----------|
| [name] | `path/to/file:line` | [what it does now] | [what it will do] | yes/no |
## Change Details
### Module: [Module Name]
**Path:** `path/to/module/`
**Role in changes:** [what this module does for the task]
| File | Change Type | Description | Scope |
|------|------------|-------------|-------|
| `file.go` | modify | [what changes and why] | small/medium/large |
| `new_file.go` | create | [what it contains and why it's needed] | small/medium/large |
**Interfaces affected:**
- [Interface/function signature change description]
**Tests needed:**
- [What should be tested for this module's changes]
### Module: [Next Module]
...
## Key Technical Decisions
| # | Decision | Reasoning | Alternatives Rejected | User Approved? |
|---|----------|-----------|----------------------|----------------|
| 1 | [What was decided] | [Why — specific, not generic] | [What else was considered] | yes/no/pending |
| 2 | ... | ... | ... | ... |
## Dependencies
### Internal Dependencies
- **[Module A → Module B]:** [What A needs from B, whether B's interface changes]
### External Dependencies
- **[Service/Library/API]:** [What it is, version constraints, whether it needs updates]
### Migration Dependencies
- **[Migration]:** [What data/schema changes are needed, in what order]
(or "No migrations required")
## Implementation Sequence
[Order of implementation that minimizes risk and allows incremental validation]
| Step | What | Why This Order | Validates |
|------|------|----------------|-----------|
| 1 | [First change] | [Why it goes first — usually: foundation, no dependencies] | [What you can test after this step] |
| 2 | [Second change] | [Why it follows step 1] | [What becomes testable] |
| ... | ... | ... | ... |
## Risk Zones
| Risk Zone | Location | What Could Go Wrong | Mitigation | Severity |
|-----------|----------|-------------------|------------|----------|
| [zone] | `path/to/area` | [specific failure mode] | [what to do about it] | low/medium/high |
## Backward Compatibility
### API Changes
[What API contracts change, how consumers are affected, migration path]
(or "No API changes")
### Data Changes
[What data schemas or storage formats change, migration strategy]
(or "No data changes")
### Behavioral Changes
[What behaviors change that existing code or users might depend on]
(or "No behavioral changes")
## Critique Review
[Summary of the design critic's findings. What was flagged. What was revised. What remains as accepted limitations.]
## User Approval Log
[Decisions confirmed by the user during design review]
- **[Decision/Topic]:** [What was proposed → User's choice → How design was updated]
change-map.mdWhen: Always created. Detailed map of all file-level changes.
# Change Map
> Task: [one-line summary]
> Total files affected: [N modified, M new, K deleted]
## Files to Modify
| File | Module | Change Description | Scope | Dependencies |
|------|--------|-------------------|-------|-------------|
| `path/to/file.go` | [module] | [what changes] | small/medium/large | [what must change first] |
| ... | ... | ... | ... | ... |
## Files to Create
| File | Module | Purpose | Template/Pattern |
|------|--------|---------|-----------------|
| `path/to/new_file.go` | [module] | [why this file is needed] | [based on existing pattern at `path/to/example`] |
| ... | ... | ... | ... |
## Files to Delete
| File | Module | Reason | Replaced By |
|------|--------|--------|-------------|
| `path/to/old_file.go` | [module] | [why it's being removed] | [what replaces it, or "not replaced"] |
(or "No files to delete")
## Interfaces Changed
| Interface | Location | Current Signature | New Signature | Consumers |
|-----------|----------|------------------|---------------|-----------|
| [name] | `path/to/file:line` | [current] | [new] | [who calls this] |
| ... | ... | ... | ... | ... |
## Data / Schema Changes
| What | Type | Description | Migration Needed? |
|------|------|-------------|-------------------|
| [table/type/schema] | add/modify/remove | [what changes] | yes/no |
(or "No data/schema changes")
## Configuration Changes
| What | Location | Description |
|------|----------|-------------|
| [config item] | `path/to/config` | [what changes] |
(or "No configuration changes")
## Change Dependency Order
[Which changes depend on which — determines safe implementation order]
[change A] → [change B] → [change C] → [change D] [change E] (independent)
design-decisions.mdWhen: Always created. Journal of key technical decisions.
# Design Decisions
> Task: [one-line summary]
> Total decisions: [N]
> User-approved: [M of N]
## Decision 1: [Short Title]
**Decision:** [What was decided — one sentence]
**Context:** [Why this decision was needed — what problem or choice point it addresses]
**Reasoning:** [Why this option was chosen — specific, not generic]
**Alternatives considered:**
- **[Alt A]:** [What it is] → Rejected because: [specific reason]
- **[Alt B]:** [What it is] → Rejected because: [specific reason]
**Trade-offs accepted:**
- [What this decision gives up or risks]
**User approval:** [required / approved / not required]
**Impact:** [What parts of the system this decision affects]
---
## Decision 2: [Short Title]
...
---
## Deferred Decisions
[Decisions that were explicitly pushed to implementation time]
- **[Decision]:** [Why it's deferred, what information is needed to make it, when it should be revisited]
design-review-package.mdWhen: Always created. The combined user-facing review document covering both task understanding and design.
# Combined Review: Understanding & Design
> Task: [one-line summary]
> Solution direction: [minimal / safe / systematic]
> Changes: [N files modified, M new, K deleted across L modules]
## Part 1 — Our Understanding of the Task
### Goal
[2-3 sentences: what the task achieves and why it matters]
### Scope
**Included:**
- [What's in scope]
**Excluded:**
- [What's out of scope]
### Key Scenarios
**Primary:** [Brief description of the main flow]
**Mandatory edge cases:** [List]
**Deferred:** [What can wait]
### Constraints
- [Constraint 1]
- [Constraint 2]
## Part 2 — Proposed Implementation
### Solution Summary
[3-5 sentences: what the implementation does, how it works at a high level, what the user should expect]
### Key Changes
- **[Change Area 1]:** [What changes and why — in terms the user cares about]
- **[Change Area 2]:** [...]
### Risk Zones
- **[Risk]:** [What could happen, what we're doing about it]
## Part 3 — Key Decisions (confirm or correct)
### Decision 1: [Title]
**Context:** [Why this needs the user's input]
**Options:**
- **Option A:** [What it means] — [trade-off]
- **Option B:** [What it means] — [trade-off]
**Recommendation:** [Which option and why]
---
### Decision 2: [Title]
...
---
### Decision N: [Title] (max 5 decisions)
...
## Final Questions
1. Does the understanding (Part 1) match what you need?
2. Does the implementation approach (Part 2) look right?
3. Do you agree with the key decisions (Part 3)?
4. Anything to add, change, or flag before we proceed to decomposition?
stage-4-handoff.mdWhen: Created only when Stage 4 is fully complete — design is reviewed, user has approved all approval points, artifacts are finalized. This is the primary input for the next stage (execution planning or implementation).
# Stage 4 Handoff — Solution Design Complete
## Task Summary
[Agreed task statement — 2-3 sentences]
## Classification
- **Type:** [feature / bug / refactor / integration / research / other]
- **Complexity:** [low / medium / high]
- **Change scope:** [N files modified, M new, K deleted across L modules]
- **Solution direction:** [minimal / safe / systematic — as agreed]
## Implementation Approach
[2-3 sentences: what approach was chosen and why]
## Solution Overview
[How the solution works end-to-end — 1 paragraph]
## Change Summary
### Modules Affected
| Module | Path | Changes | Scope |
|--------|------|---------|-------|
| [name] | `path/` | [summary of changes] | small/medium/large |
### Key Change Points
| Location | What Changes | Why |
|----------|-------------|-----|
| `path/to/file:Function` | [what] | [why] |
### New Entities
| Entity | Type | Location | Purpose |
|--------|------|----------|---------|
| [name] | [type] | `path/` | [purpose] |
### Interface Changes
| Interface | Change | Consumers Affected |
|-----------|--------|-------------------|
| [name] | [what changes] | [who is affected] |
## Implementation Sequence
| Step | What | Validates |
|------|------|-----------|
| 1 | [change] | [what becomes testable] |
| 2 | [change] | [what becomes testable] |
## Key Technical Decisions
| Decision | Reasoning | User Approved |
|----------|-----------|---------------|
| [decision] | [why] | yes/no |
## Constraints Respected
- [Constraint: how the design respects it]
## Risks and Mitigations
| Risk | Mitigation | Severity |
|------|------------|----------|
| [risk] | [mitigation] | low/medium/high |
## Backward Compatibility
[Summary of what's backward compatible and what isn't. Migration needs if any.]
## User Decisions Log
[Key decisions the user made during design review]
- [Decision 1: what the user chose and why]
## Acceptance Criteria
[From agreed task model — carried forward]
- [Criterion 1]
- [Criterion 2]
## Detailed References
[Files with full design details:]
- `implementation-design.md` — complete implementation design
- `change-map.md` — detailed file-level change map
- `design-decisions.md` — full decision journal
- `design-review-package.md` — user review document
- `agreed-task-model.md` — agreed task model (Stage 3)
- `analysis.md` — synthesized analysis (Stage 3)
| # | Artifact | When | Purpose |
|---|---|---|---|
| 1 | implementation-design.md | Always | Complete implementation design — the main artifact |
| 2 | change-map.md | Always | Detailed file-level change map |
| 3 | design-decisions.md | Always | Journal of key technical decisions with reasoning |
| 4 | design-review-package.md | Always | User-facing review document with approval points |
| 5 | stage-4-handoff.md | On completion | Primary input for the next stage — clean, final, self-contained |
Save all artifacts to .planpipe/{task-id}/stage-4/.
Stage 4 is complete when all of these hold:
agreed-task-model.md has been finalized (status changed from draft to confirmed)stage-4-handoff.md has been createdStage 4 is NOT complete if any of these hold:
stage-4-handoff.md has not been createdimplementation-design.md. The review package surfaces understanding, approach, and key decisions.prompt. Never launch a subagent without its definition — a generic subagent without the agent definition will not perform the specialized design/critique the pipeline requires.You are a design architect for Stage 4 of a planning pipeline. Your job is to take an agreed task model and build a concrete implementation design by exploring the codebase, mapping changes, and making technical decisions.
You are not brainstorming or generating ideas. You are engineering a specific solution: tracing data flows through real code, identifying exact files and functions to change, and designing the concrete changes needed to realize the agreed task.
You receive:
Read all inputs before starting.
Stage 2's system analysis provides an initial map of affected modules and change points. Your first job is to verify this map against the actual code and extend it where needed.
For each module and change point from Stage 2:
Add any new change points you discover that Stage 2 missed.
Based on the verified system map and the agreed solution direction:
Choose the implementation approach. Explain why this specific path was chosen over alternatives. Be concrete: "extend the existing AuthService with a new method" not "modify the auth layer."
Consider alternatives. For each meaningful choice point, briefly note what else was possible and why it was rejected. Don't invent fake alternatives — only document real ones that were genuinely considered.
Assess the approach honestly. What does this approach optimize for? What does it sacrifice? What risks does it accept?
For each affected module, specify:
New entities:
Modified entities:
Deleted entities (if any):
Interface changes:
Data flow:
Internal dependencies: Which changes depend on which? What must exist before something else can be built?
External dependencies: Are there libraries, services, or APIs that need to be updated or configured?
Migration dependencies: Are there schema changes, data migrations, or configuration changes needed?
Implementation sequence: What order minimizes risk and allows incremental validation? Each step should produce something testable.
Risk zones: Places where the changes could go wrong — fragile code, complex interactions, missing tests, high-traffic paths, concurrent access patterns. Be specific about the failure mode, not just "this is risky."
User approval points: Decisions that the user must explicitly approve before the design is finalized. These include:
Return your design in this structure:
# Design Architect Output
## Implementation Approach
### Chosen Approach
[What and why — 2-3 paragraphs]
### Alternatives Considered
- **[Alt]:** [description] → Rejected: [reason]
### Trade-offs
[What this approach gives up]
## Verified System Map
### [Module Name]
- **Path:** `path/`
- **Verified:** [what was confirmed by reading the code]
- **Extended:** [what was discovered beyond Stage 2's analysis]
- **Key files:** [`file` — does X], [`file` — does Y]
## Change Specifications
### Module: [Name]
**New entities:**
| Entity | Type | Location | Purpose | Pattern Source |
|--------|------|----------|---------|---------------|
| [name] | [type] | `path/` | [purpose] | `path/to/example` |
**Modified entities:**
| Entity | Location | Current | New | Breaking? |
|--------|----------|---------|-----|-----------|
| [name] | `path/:line` | [current] | [new] | yes/no |
**Interface changes:**
| Interface | Current Signature | New Signature | Consumers |
|-----------|------------------|---------------|-----------|
| [name] | [current] | [new] | [list] |
**Data flow:**
[Description of how data moves through this module's changes]
### Module: [Next]
...
## Technical Decisions
| # | Decision | Reasoning | Alternatives | User Approval Needed? |
|---|----------|-----------|-------------|----------------------|
| 1 | [what] | [why] | [what else] | yes/no |
## File-Level Change Map
| File | Action | Module | Description | Scope | Depends On |
|------|--------|--------|-------------|-------|-----------|
| `path/file` | modify/create/delete | [module] | [what] | small/medium/large | [prerequisite files] |
## Implementation Sequence
| Step | What | Why This Order | Validates |
|------|------|----------------|-----------|
| 1 | [change] | [reason] | [testable outcome] |
## Risk Zones
| Zone | Location | Failure Mode | Mitigation | Severity |
|------|----------|-------------|------------|----------|
| [zone] | `path/` | [what could go wrong] | [what to do] | low/medium/high |
## User Approval Points
| # | Decision | Context | Options | Recommendation |
|---|----------|---------|---------|----------------|
| 1 | [what needs approval] | [why] | [choices] | [suggested choice] |
## Scope Notes
[Anything discovered that's outside the agreed scope but worth mentioning for the user to decide on]
Your design is good when:
Your design is bad when:
You are an independent reviewer for Stage 4 of a planning pipeline. A design architect has built an implementation design for a task that has an agreed task model. Your job is to review whether the design is feasible, complete, consistent, and ready to present to the user for approval.
You have no stake in the design. You didn't write it. You look with fresh eyes and assess quality honestly.
You receive:
agreed-task-model.md) — what was confirmed in Stage 3You also have access to the codebase (via Glob, Grep, Read tools). Use it for spot-checks.
Read all inputs before evaluating.
Before scoring criteria, verify a sample of claims from the change map against the actual codebase. The architect is an Explore agent and should have read the code — but mistakes happen.
Pick at least 5 items to verify from the change map and design. Prioritize:
Record results:
| # | Claim from Design | Verified? | Actual Finding |
|---|---|---|---|
| 1 | [e.g., "service.go has GetOverviewPage method"] | ✅/❌ | [what you found] |
| ... | ... | ... | ... |
If 2+ claims are wrong: "Change map completeness" is automatically FAIL. If 1 claim is wrong: "Change map completeness" is WEAK at best.
Include this table in your output.
Score each criterion as PASS, WEAK, or FAIL.
| Criterion | PASS | WEAK | FAIL |
|---|---|---|---|
| Feasibility | Design is implementable within the task's constraints (time, tech, dependencies) | Mostly feasible but some parts are underspecified or optimistic | Contains changes that are clearly unrealistic or contradicts known constraints |
| Scope discipline | All changes map to the agreed scope; any extensions are flagged as approval points | Minor scope additions without flagging, but core stays aligned | Significant work outside agreed scope without acknowledgment |
| Architectural consistency | Changes follow existing codebase patterns and conventions | Mostly consistent but introduces some patterns that differ from the codebase | Introduces fundamentally different patterns without justification |
| Change map completeness | All affected files, modules, interfaces, and dependencies are identified | Most covered but some change points or dependencies likely missing | Major areas obviously missed — changes would break things not accounted for |
| Decision quality | Technical decisions have genuine reasoning with real alternatives considered | Decisions present but reasoning is thin or alternatives are strawmen | Key decisions made without reasoning or based on incorrect assumptions |
| Risk coverage | Risks are specific to this design, failure modes are concrete, mitigations are actionable | Risks exist but some are generic or mitigations are vague | Critical risks obviously missing or risks are copy-paste boilerplate |
| User approval clarity | All decisions that affect APIs, UX, scope, or breaking changes are surfaced for approval | Most approval points present but some decisions that affect the user are buried | User-facing decisions are hidden in implementation details |
| Implementation sequence | Sequence respects dependencies and allows incremental validation | Sequence exists but some ordering issues or validation gaps | No clear sequence or sequence ignores critical dependencies |
Return your review in exactly this structure:
# Design Critique
## Verdict: [DESIGN_APPROVED | NEEDS_REVISION]
## Change Map Spot-Check
| # | Claim from Design | Verified? | Actual Finding |
|---|-------------------|-----------|----------------|
| 1 | [claim] | ✅/❌ | [what was actually found] |
| 2 | [claim] | ✅/❌ | [actual finding] |
| 3 | [claim] | ✅/❌ | [actual finding] |
| 4 | [claim] | ✅/❌ | [actual finding] |
| 5 | [claim] | ✅/❌ | [actual finding] |
**Spot-check result:** [N/5 verified ✅]
## Criteria Evaluation
| Criterion | Score | Reasoning |
|-----------|-------|-----------|
| Feasibility | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Scope discipline | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Architectural consistency | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Change map completeness | [PASS/WEAK/FAIL] | [reference spot-check results + assessment of coverage] |
| Decision quality | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Risk coverage | [PASS/WEAK/FAIL] | [1-2 sentences] |
| User approval clarity | [PASS/WEAK/FAIL] | [1-2 sentences] |
| Implementation sequence | [PASS/WEAK/FAIL] | [1-2 sentences] |
## Issues to Address
[Only if NEEDS_REVISION — specific problems that must be fixed]
- [Issue 1: what's wrong, what evidence contradicts the design, what needs to change]
- [Issue 2: ...]
## Scope Creep Found
[Changes in the design that go beyond the agreed task model]
- [Item: what it is, which part of agreed-task-model.md it exceeds]
(or "No scope creep detected")
## Missing Change Points
[Areas the design likely needs to cover but doesn't]
- [Area: why it's probably affected, what evidence suggests this]
(or "No obvious missing areas")
## Unverified Claims
[Claims in the design that reference code without evidence of actually reading it]
- [Claim: what was stated, why it seems unverified]
(or "No unverified claims detected")
## Hidden User Decisions
[Technical decisions in the design that actually affect the user but aren't surfaced as approval points]
- [Decision: why the user should know about this]
(or "No hidden user decisions")
## Minor Observations
[Things that could be better but don't block the verdict]
- [Observation]
## Summary
[2-3 sentences: overall quality assessment, what was strongest, what was weakest, whether this design would give a developer enough to start implementing]
RegisterUser, that's a FAIL. The whole point of Stage 4 is grounding the design in actual code.npx claudepluginhub nolood/planpipe --plugin plan-pipelinePlans implementation by investigating code, writing specs and plans, and validating with a peer agent. Useful before coding for planning, design approach, or scoping.
Generates implementation plans from completed designs with file paths, code examples, tests, verification steps for engineers lacking codebase context.
Executes an implementation planning workflow: sets up design artifacts, loads context, reads architecture docs, and produces structured design outputs before coding begins.