Menu
Use when you have a spec or requirements for a multi-step task, before touching code
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when you have a written implementation plan to execute
Spreadsheet toolkit. Reach for it whenever the artifact on either side of the conversation is a workbook file — .xlsx, .xlsm, .xltx, .csv, .tsv — and the user wants that artifact produced, changed, cleaned, or read. Typical triggers: 'build me a model', 'update this sheet', 'add a column', 'compute the totals as formulas', 'sanity-check this xlsx', 'export sheet 2 to CSV', 'render the workbook as PDF', 'the spreadsheet in ~/Downloads is a mess, fix it'. Applies equally to financial models, ops reports, data cleanups, and template fills. Skip it when the workbook is only source material and the real output is a Word doc, an HTML page, a Python script that runs standalone, a Google Sheets integration, or an ingestion pipeline into a database — in those cases the spreadsheet is a means, not the deliverable.
Perform a focused, evidence-based code review. Use when the user asks to review code, a diff, pull request, branch, commit, or implementation before merging.
Smart git commit message generator following Conventional Commits. Use when the user says 'commit', 'commit this', 'write a commit message', 'smart commit', or asks to create a git commit.
Use when the user asks what OpenZeroCode can do, how a feature works (memory, checkpoints, agents, subagents, tasks, compose, learn), how to configure it, where config/data lives, which config key controls a behavior, what CLI or slash commands exist, or how to enable/disable/tune something — the self-documenting reference for OpenZeroCode itself.
Use when executing implementation plans with independent tasks in the current session
| name | compose:plan |
| description | Use when you have a spec or requirements for a multi-step task, before touching code |
Write comprehensive implementation plans assuming the engineer has zero context for our codebase. Document everything they need to know: which files to touch for each task, code, testing, how to test it.
Each task should include:
# [Feature Name] Implementation Plan
**Goal:** [One sentence describing what this builds]
**Architecture:** [2-3 sentences about approach]
**Tech Stack:** [Key technologies/libraries]
---
### Task N: [Component Name]
**Files:**
- Create: `path/to/file.ts`
- Modify: `path/to/existing.ts:123-145`
**Steps:**
- [ ] Step 1: Write the failing test
- [ ] Step 2: Run test to verify it fails
- [ ] Step 3: Write minimal implementation
- [ ] Step 4: Run test to verify it passes
- [ ] Step 5: Commit
Save plans to docs/compose/plans/ directory.
Invoke compose:execute or compose:tdd to start implementation.