Skip to content
Development
Skill

/cm-planning

You MUST use this before any creative work or multi-step task. Explores intent and writes execution-ready plans before coding.

From plugin
cm
5662 skills8 agents11 commands3 hooks
+1

Claude Code

$ npx -y skills add tody-agent/codymaster --skill cm-planning --agent claude-code

SKILL.md

cm-planning.SKILL.md
name: cm-planning
description: "You MUST use this before any creative work or multi-step task. Explores intent and writes execution-ready plans before coding."
token_budget: 1500
compressed: true
deprecated: false

Planning — Brainstorm + Execution-Ready Plans

TL;DR

  • **Use before** any feature, behavior change, or task needing 3+ actions.
  • **Brainstorm** intent, 2–3 approaches, recommendation, scope, and interfaces.
  • **Write** `openspec/changes/<name>/{design.md,tasks.md}`.
  • **Emit** `.cm/handoff/plan.json` with complete `task_specs`; `first_tasks`-only handoffs remain readable for backward compatibility.
  • **Next**: `cm-tdd` or `cm-execution`.

Phase A: Decide What to Build

1. Ask only questions that change scope or architecture. State assumptions and mark each `verified` or `needs confirmation`. 2. Present 2–3 approaches with concrete tradeoffs and recommend one. 3. Separate must-have, optional, handled edges, and explicit non-goals. 4. Map data flow, file responsibilities, public interfaces, and dependencies. UI work also uses `cm-design-system`.

Stop if intent, ownership, or an interface is ambiguous. Do not silently choose an interpretation.

Phase B: Write the Plan

Create `design.md` with context, chosen architecture, file map, interfaces, risks, and verification strategy. Create `tasks.md` using the template below.

Task boundary

A task is the smallest independently testable deliverable that a reviewer can approve or reject without deciding another task. Each task owns a complete red–green cycle and ends at a commit boundary. Fold setup, configuration, migrations, and documentation into the deliverable that needs them; never create empty setup-only or docs-only tasks.

Each step is exactly one 2–5 minute action: write one failing test, run it and observe the expected failure, add minimal implementation, run it and observe the pass, then commit. Never use 15–30 minute checklist items.

Required task template

### Task 1: Validate rich plan handoffs

**Goal:** Reject incomplete task specs while preserving legacy `plan@1` payloads.
**Deliverable:** A validator and focused tests that can pass review independently.
**Files:**
- Modify: `src/handoff/io.ts`
- Test: `test/handoff.test.ts`
**Dependencies:** Existing `validateHandoff(obj: unknown)` behavior.
**Interfaces:** Produces optional `PlanHandoff.data.task_specs`; consumes `PlanTaskSpec`.
**Acceptance criteria:** A complete rich handoff round-trips; a missing `deliverable` is rejected; a legacy handoff remains valid.

- [ ] **Step 1 — Write the failing validation test** in `test/handoff.test.ts` with `expect(() => validateHandoff(fixture)).toThrow(/missing key: deliverable/)`.
- [ ] **Step 2 — Prove RED.** Run `npx vitest run test/handoff.test.ts`. Expected: FAIL at `rejects incomplete rich plan task specs` because no error is thrown.
- [ ] **Step 3 — Implement the minimum validation** in `src/handoff/io.ts` for required rich-task fields without changing legacy required keys.
- [ ] **Step 4 — Prove GREEN.** Run `npx vitest run test/handoff.test.ts`. Expected: PASS, all handoff tests and zero failures.
- [ ] **Step 5 — Commit boundary.** Run `git add src/handoff/io.ts test/handoff.test.ts && git commit -m "feat: validate rich plan handoffs"`.
````

Every task must specify: goal, independently reviewable deliverable, exact create/modify/test paths, dependencies, consumed/produced interfaces with exact names and types, literal acceptance criteria, step-level test phase, exact command and expected result, and commit boundary. Repeat context needed by a fresh agent; never require it to reread the full plan.

## No Placeholders

Never write `TODO`, `TBD`, “add tests,” “handle edge cases,” “appropriate error handling,” “similar to Task N,” or an undefined type/function. Code steps include the concrete code or signature; verification steps include the exact command and observable evidence.

## Self-Review Before Handoff

1. **Coverage:** map every requirement and non-goal to a task; add any missing coverage.
2. **Placeholder scan:** search `tasks.md` for every banned phrase above and replace vague instructions.
3. **Interface/type consistency:** compare all produced and consumed names, signatures, field names, and task dependencies.
4. **Boundaries:** confirm every task has its own deliverable, test cycle, review decision, and commit; merge setup/docs fragments into their owning task.

Fix findings inline before emitting the handoff.

## Emit Handoff + Continuity

Write `.cm/handoff/plan.json`:

```json
{
  "schema": "plan@1",
  "emitted_at": "2026-08-04T00:00:00.000Z",
  "emitted_by": "cm-planning",
  "data": {
    "goal": "Validate execution-ready plan handoffs",
    "decisions": ["Keep task_specs optional for plan@1 compatibility"],
    "first_tasks": ["1.1"],
    "openspec_path": "openspec/changes/rich-plan-handoff/",
    "task_specs": [{
      "id": "1.1",
      "goal": "Validate complete task specifications",
      "deliverable": "A backward-compatible validator with focused coverage",
      "files": [
        { "path": "src/handoff/io.ts", "action": "modify" },
        { "path": "test/handoff.test.ts", "action": "modify" }
      ],
      "dependencies": ["validateHandoff(obj: unknown)"],
      "interfaces": {
        "consumes": ["PlanTaskSpec from src/handoff/contracts.ts"],
        "produces": ["PlanHandoff.data.task_specs?: PlanTaskSpec[]"]
      },
      "acceptance_criteria": ["Rich handoffs round-trip and legacy handoffs remain valid"],
      "steps": [
        {
          "id": "1.1.1",
          "action": "Add the failing incomplete-task validation test",
          "files": ["test/handoff.test.ts"],
          "test_cycle": {
            "phase": "red",
            "command": "npx vitest run test/handoff.test.ts",
            "expected_result": "FAIL because incomplete task_specs are accepted"
          }
        },
        {
          "id": "1.1.2",
          "action": "Impleme
Read more
@tody-agent
Ships withcm

"I can't write code. But in 6 months, I shipped 12 real products using AI. CodyMaster is everything I learned — so you don't have to repeat my mistakes." — Tody Le, Head of Product, Creator of CodyMaster 50+ skills. One install.

5662 skills8 agents1 MCP
Get the whole plugin

Stars on GitHub

Momentum

stars in total
56
Star history of tody-agent/codymaster on GitHub, a chart by star-history.com

Other skills on cm.

cm-autopilot

cm-autopilot

Easy-to-use conversational CLI (Claude Code style) for non-technical users to spawn parallel AI tasks supervised by a visual web…

@tody-agent@tody-agentInstall Skill
cm-brainstorm-idea

cm-brainstorm-idea

Strategic analysis gate for existing products — multi-dimensional evaluation (tech, product, design, business) using Design…

@tody-agent@tody-agentInstall Skill
cm-browse

cm-browse

Fallback local Playwright daemon for real-browser visual QA / screenshots / smoke. Use ONLY when the host platform has no native…

@tody-agent@tody-agentInstall Skill
cm-clean-code

cm-clean-code

Code hygiene gate — detect and eliminate dead code, duplicates, naming mess, and code smells. TRIZ-powered. Run after features,…

@tody-agent@tody-agentInstall Skill
cm-code-review

cm-code-review

Full review lifecycle — request reviews, handle feedback with technical rigor, and complete branch integration. Use when…

@tody-agent@tody-agentInstall Skill
cm-codeintell

cm-codeintell

Unified code intelligence — routes to Skeleton Index, CodeGraph, Architecture Diagram, or Smart Context Builder based on task…

@tody-agent@tody-agentInstall Skill

More skills from other plugins.

brainstorming
Auto-invoked

brainstorming

You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…

@obra@obraInstall Skill
ask-matt

ask-matt

Ask which skill or flow fits your situation. A router over the skills in this repo.

skills10d309k
@mattpocock@mattpocockInstall Skill
accessibility
Auto-invoked

accessibility

Design, implement, and audit accessible UI to WCAG 2.2 Level AA across Web, iOS, and Android — semantic ARIA roles and labels,…

ecc12d293k
@affaan-m@affaan-mInstall Skill
compiler-commit

compiler-commit

Use when you want to verify compiler changes and commit with the correct convention. Runs tests, lint, and format, then commits…

react1d252k
@facebook@facebookInstall Skill

Questions about cm-planning.

Which coding agents can use cm-planning?
cm-planning installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.