| name | kimchi:plan-revise |
| description | This command should be used to perform a fresh-eyes cross-model review of the draft plan. Seventh stage of the Kimchi planning pipeline. Reads PLAN-DRAFT.md and outputs PLAN-REVISED-{model}.md. Run once per model for cross-model analysis. |
Kimchi Plan Revise
<command_purpose>
Review the draft plan with "fresh eyes" from a different model's perspective. Find bugs, errors, logic problems, confusion, and missing pieces — then fix everything found. Each model writes its own revision file, enabling cross-model synthesis later.
</command_purpose>
Input
Read .kimchi/PLAN-DRAFT.md (required). If it doesn't exist, tell the user: "No PLAN-DRAFT.md found. Run /kimchi:refine first."
Also read for context:
.kimchi/REQUIREMENTS.md — v1 boundary and requirement IDs.kimchi/RESEARCH.md — codebase patterns and conventions
Process
1. Identify Model
Determine which model is running this review. Use one of:
- The
$MODEL environment variable if set
- Self-identification: state which model you are (e.g., "claude", "codex", "gemini", "grok", etc.)
- Normalize to lowercase, single-word slug (e.g., "claude", "codex", "gemini")
Store as {model} for the output filename.
2. Fresh-Eyes Review
Read the draft plan as if seeing it for the first time. Evaluate with intellectual honesty:
Correctness:
- Are there logical errors in the task ordering or dependencies?
- Do any tasks contradict each other?
- Are complexity estimates realistic?
Completeness:
- Are all v1 requirements covered? Cross-check against REQUIREMENTS.md.
- Are there missing integration points or edge cases?
- Are test specifications sufficient?
Clarity:
- Could an agent execute each task without ambiguity?
- Are deliverables specific enough?
- Is context sufficient for standalone execution?
Architecture:
- Do the proposed patterns match what RESEARCH.md found in the codebase?
- Are there simpler approaches that were overlooked?
- Is the dependency graph optimal for parallel execution?
Risks:
- What could go wrong during implementation?
- Are there hidden assumptions?
- What's the most likely failure mode?
3. Fix Everything Found
Don't just report problems — fix them. Produce a complete revised plan that addresses every issue found.
4. Write Output
Write .kimchi/PLAN-REVISED-{model}.md:
# Plan Revision: [Feature Name]
**Revised by:** {model}
**Date:** [today's date]
**Source:** .kimchi/PLAN-DRAFT.md
## Issues Found
| # | Category | Severity | Issue | Resolution |
|---|----------|----------|-------|------------|
| 1 | [Correctness/Completeness/Clarity/Architecture/Risk] | [High/Medium/Low] | [What's wrong] | [How it was fixed] |
| 2 | ... | ... | ... | ... |
## Summary of Changes
[Narrative description of what was changed and why. Be specific about trade-offs considered.]
## Revised Plan
[Complete revised plan with all fixes applied. This must be a full, standalone plan — not a diff.]
Report: "Fresh-eyes review complete ({model}). Found [N] issues ([H] high, [M] medium, [L] low). Saved to .kimchi/PLAN-REVISED-{model}.md"
Suggest: "Run /kimchi:plan-revise in other models for cross-model coverage, then /kimchi:plan-synthesize to blend all revisions."
Key Principles
- Fresh eyes: Pretend you've never seen this plan before. Question everything.
- Fix, don't just flag: Every issue found must have a resolution in the revised plan.
- Respect v1 scope: Don't add features. Only fix problems and improve clarity.
- Full plan output: The revised plan must be complete and standalone, not a patch.
- Honest assessment: If the plan is good, say so. Don't invent problems to justify your existence.
