kimchi:beads
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.
Best use case
kimchi:beads is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
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.
Teams using kimchi:beads should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/beads/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How kimchi:beads Compares
| Feature / Agent | kimchi:beads | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
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.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Kimchi Beads
<command_purpose>
Convert plan tasks into self-contained bead YAML files with full context (using find: landmarks), deliverables, test specifications, and acceptance criteria. Each bead must be executable by an agent with ZERO external context.
</command_purpose>
## Input
Read in order of preference: `.kimchi/PLAN-SYNTHESIZED.md`, `.kimchi/PLAN-DRAFT.md`, `.kimchi/PLAN-REVIEWED.md`, or `.kimchi/PLAN.md`.
Also read `.kimchi/RESEARCH.md` for context references with landmarks.
Parse options:
- `--orchestration acfs|gastown` (default: acfs) — Determines the orchestration system that will consume and execute the beads. This affects manifest metadata and post-generation guidance.
## Process
### 1. Create .beads/ Directory
```bash
mkdir -p .beads
```
### 2. Convert Each Task to Bead YAML
For each task in the plan, create a bead file at `.beads/{id}-{slug}.yaml`:
```yaml
bead_id: "[ID]"
title: "[Task title]"
description: |
[Detailed description of what to implement.
Must be complete enough to execute without reading the plan.]
depends_on: ["[bead IDs]"]
context:
- file: "[path/to/file]"
find: "[search term to locate relevant code]"
scope: "[entire class|entire method|block|etc]"
purpose: "[Why this context is relevant]"
deliverables:
- type: "[file_create|file_modify|file_delete]"
path: "[full/path/to/file]"
find: "[anchor point for file_modify]"
action: "[add after|replace|add before — for file_modify]"
description: |
[What will be created or changed]
tests:
file: "[path/to/test/file]"
cases:
- "[Test case description 1]"
- "[Test case description 2]"
- "[Edge case description]"
run_command: "[command to run tests]"
acceptance_criteria:
- "[Verifiable criterion 1]"
- "[Verifiable criterion 2]"
estimated_complexity: "[S|M|L]"
requirements: ["[REQ-ID1]", "[REQ-ID2]"]
```
### 3. Context Rules (CRITICAL)
**Every file reference MUST use `find:` landmarks:**
```yaml
# GOOD
context:
- file: "app/services/storage/s3_client.rb"
find: "class S3Client"
purpose: "Existing S3 wrapper to use"
# BAD — never use line numbers
context:
- file: "app/services/storage/s3_client.rb"
lines: "12-34"
```
**Find terms must be:**
- Specific enough to be unique in the file
- Stable (survive refactoring — class names, method names, not comments)
- Appropriate scope for purpose
### 4. Test Case Minimums
| Complexity | Minimum Cases | Edge Cases Required |
|------------|--------------|-------------------|
| S | 2+ | 0 |
| M | 4+ | 1+ |
| L | 6+ | 2+ |
### 5. Create Manifest
Write `.beads/manifest.yaml`:
```yaml
version: "1.0"
plan_id: "[feature-slug]-[date]"
created_at: "[ISO 8601 timestamp]"
created_by: "kimchi:beads"
orchestration: "[acfs|gastown]" # Which system will execute these beads
source:
context: ".kimchi/CONTEXT.md"
requirements: ".kimchi/REQUIREMENTS.md"
plan: ".kimchi/PLAN-SYNTHESIZED.md" # or whichever plan file was used
beads:
- id: "[ID]"
file: "[filename].yaml"
status: "pending"
depends_on: []
- id: "[ID]"
file: "[filename].yaml"
status: "pending"
depends_on: ["[ID]"]
dependency_graph: |
[ASCII art showing dependency relationships]
```
### 6. Validate No Cycles
Check that the dependency graph has no circular dependencies. If cycles found, report them as errors and ask user to resolve.
Report: "Beads created. [N] bead files in .beads/"
Suggest: "Run `/kimchi:validate` to verify beads are standalone-executable."
### 7. Orchestration-Specific Guidance
After bead generation, provide guidance based on the `--orchestration` flag:
**If `acfs` (default):**
```
Beads are configured for ACFS orchestration.
Next: Run /kimchi:validate, then use /kimchi:bead-protocol for execution.
```
**If `gastown`:**
```
🏘️ These are GasTown-compatible beads.
The manifest is tagged with orchestration: gastown.
To execute these beads, use the GasTown mayor process:
1. The mayor reads .beads/manifest.yaml to understand the dependency graph
2. The mayor assigns beads to worker agents based on availability and dependencies
3. Workers execute beads and report completion back to the mayor
4. The mayor tracks progress and unblocks dependent beads as predecessors complete
Do NOT use /kimchi:bead-protocol (that's for ACFS). Let the mayor handle coordination.
Run /kimchi:validate first to ensure beads are standalone-executable.
```
## Key Principles
- **Self-contained**: An agent reads ONE bead and has everything it needs
- **No cross-references**: Don't say "use the service from bead 002". Point to the actual file.
- **Landmarks over coordinates**: `find:` always, line numbers never
- **Explicit over implicit**: If the agent might need to search for it, put it in the beadRelated Skills
kimchi:verification-before-completion
Use when about to claim work is complete, fixed, or passing — before committing or creating PRs. Evidence before assertions, always.
kimchi:validate
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.
kimchi:tdd
Use when implementing any feature, bugfix, or behavior change — before writing implementation code. Enforces RED-GREEN-REFACTOR cycle.
kimchi:systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior — before proposing fixes. Enforces 4-phase root cause analysis.
kimchi:status
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.
kimchi:simplicity-enforcement
Use when designing solutions, implementing features, or considering abstractions. Enforces YAGNI, minimal code, and preferring duplication over wrong abstraction.
kimchi:review
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.
kimchi:reset
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.
kimchi:research
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.
kimchi:requirements
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.
kimchi:refine
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.
kimchi:plan
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.