kimchi

Convert the kimchi plugin into OpenCode and Codex compatible formats using the bundled converter CLI. Requires bun runtime.

This command should be used to run the Kimchi planning pipeline through refinement, transforming a vague idea into a draft plan ready for cross-model analysis. Orchestrates 6 stages: clarify, requirements, research, generate, review, refine. Use --full-auto to also run beads + validate after manual revise/synthesize.

Use when executing a bead task. Detects orchestration mode (ACFS or GasTown) from .beads/manifest.yaml and enforces the appropriate execution discipline.

This command should be used to convert the final plan into standalone bead YAML task specifications for multi-agent execution. Ninth stage of the Kimchi planning pipeline. Produces .beads/ directory. Supports both ACFS and GasTown orchestration modes.

This command should be used to run the Kimchi self-improvement system. Observes execution outcomes, proposes incremental improvements to skills/validators/personas, validates against history, and applies with versioning.

This command should be used to clear the Kimchi working directory (.kimchi/) and start fresh. Preserves .beads/ directory. Use when starting a new planning session or recovering from a bad state.

This command should be used to validate bead YAML files for standalone executability. Runs 4 validators (context completeness, deliverables clarity, test specification, isolation) and enriches failing beads. Eighth stage of the Kimchi planning pipeline.

This command should be used to extract and categorize requirements from CONTEXT.md into v1 (must have), v2 (next iteration), and out of scope. Second stage of the Kimchi planning pipeline. Produces .kimchi/REQUIREMENTS.md.

This command should be used to investigate codebase patterns, frameworks, and existing implementations before planning. Third stage of the Kimchi planning pipeline. Produces .kimchi/RESEARCH.md.

Use when designing solutions, implementing features, or considering abstractions. Enforces YAGNI, minimal code, and preferring duplication over wrong abstraction.

Use when encountering any bug, test failure, or unexpected behavior — before proposing fixes. Enforces 4-phase root cause analysis.

Use when implementing any feature, bugfix, or behavior change — before writing implementation code. Enforces RED-GREEN-REFACTOR cycle.

Use when about to claim work is complete, fixed, or passing — before committing or creating PRs. Evidence before assertions, always.

This command should be used to generate an implementation plan with task breakdown, dependencies, and complexity estimates. Fourth stage of the Kimchi planning pipeline. Produces .kimchi/PLAN.md.

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.

This command should be used to synthesize multiple cross-model plan revisions into a superior hybrid plan. Eighth stage of the Kimchi planning pipeline. Reads PLAN-REVISED-*.md files and outputs PLAN-SYNTHESIZED.md — the TRUE final plan.

This command should be used to iteratively improve the plan until quality threshold is reached or diminishing returns detected. Sixth stage of the Kimchi planning pipeline. Produces .kimchi/PLAN-DRAFT.md.

This command should be used to run multi-persona review of the implementation plan. Five specialized personas critique the plan for scope creep, complexity, premature optimization, and test coverage. Fifth stage of the Kimchi planning pipeline. Produces .kimchi/PLAN-REVIEWED.md.

This command should be used to check the current state of the Kimchi planning pipeline, including which stages have completed, what artifacts exist, and bead validation status.

This command should be used to extract complete understanding of a feature idea through structured clarification questions. First stage of the Kimchi planning pipeline. Produces .kimchi/CONTEXT.md.