kimchi:convert
Convert the kimchi plugin into OpenCode and Codex compatible formats using the bundled converter CLI. Requires bun runtime.
Best use case
kimchi:convert is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Convert the kimchi plugin into OpenCode and Codex compatible formats using the bundled converter CLI. Requires bun runtime.
Teams using kimchi:convert 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/convert/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How kimchi:convert Compares
| Feature / Agent | kimchi:convert | 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?
Convert the kimchi plugin into OpenCode and Codex compatible formats using the bundled converter CLI. Requires bun runtime.
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
# Plugin Format Converter Convert the kimchi Claude Code plugin into OpenCode and Codex compatible formats. ## How to Execute ### 1. Resolve paths Find these two absolute paths: - **Plugin root:** Walk up from the current working directory (or this skill's directory) until you find a directory containing `.claude-plugin/plugin.json`. This is the kimchi plugin root. - **CLI directory:** This skill's `cli/` subdirectory. It contains `src/index.ts` and `package.json`. Both paths MUST be absolute. CWD varies across invocations. ### 2. Check bun is available ```bash which bun ``` If missing, tell the user to install bun: `curl -fsSL https://bun.sh/install | bash` ### 3. Install dependencies (if needed) Check if `node_modules/` exists in the CLI directory. If not: ```bash cd <cli-dir> && bun install ``` ### 4. Run the converter Parse the user's arguments to determine the target format. Default is `both`. **OpenCode only:** ```bash bun run <cli-dir>/src/index.ts convert <plugin-root> --to opencode --output <output-path> ``` **Codex only:** ```bash bun run <cli-dir>/src/index.ts convert <plugin-root> --to codex --output <output-path> ``` **Both (default):** ```bash bun run <cli-dir>/src/index.ts convert <plugin-root> --to opencode --also codex --output <output-path> ``` ### 5. Output location Default output to `.converted/` in the **project root** (the git repository root or the directory containing the kimchi plugin), not the current working directory. If the user passes `--output <path>`, use that instead. ### 6. Report results After conversion, report: - What format(s) were generated - Where the output was written - List the key generated files (e.g., `opencode.json`, `config.toml`) ## Known Limitations - Kimchi has no `commands/` directory in the converter sense — only `skills/` and `agents/`. The `commands` array in output will be empty. This is expected; skills are kimchi's functional units. - The converter skill itself will appear in the conversion output. Harmless. - The `install` command in the CLI is compound-engineering specific and not useful for kimchi.
Related 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.