Cm planning

Skill tody-agent/codymaster/.amp/skills/cm-planning

Vibe Coding Framework - Full SaaS Development Team from A-Z with Brain, Self Improvement, Auto Development

Install

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

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

What its author says it does

Copied from the file, not written here

You MUST use this before any creative work or multi-step task. Explores intent, requirements, and design before implementation. Then documents the plan before coding.

SKILL.md

3.4 KB, 840 tokens by cl100k_base, as published. Nobody here has run it

Planning — Brainstorm + Write Plans

TL;DR

Use before any feature, behavior change, or 3+ step task
Phase A (Brainstorm): clarify intent → 2-3 options → recommend → scope
Phase B (Write): emit openspec/changes/<name>/{design.md,tasks.md}
Handoff out: .cm/handoff/plan.json (goal, decisions, first 3 tasks)
Next: cm-tdd or cm-execution

When to Use

Creating features, components, or functionality
Modifying behavior; multi-step tasks; user-visible change
Skip only for trivial single-line edits or pure questions

Full Protocol

Phase A: Brainstorm

Intent — Ask clarifying questions. Don't assume scope. Surface hidden requirements.
Options — List 2-3 approaches with pros/cons. Recommend one with reasoning.
Scope — Must-have vs nice-to-have; edges to handle vs explicitly skip.
Design — Data flow, component boundaries, API contracts. UI work → cm-ui-preview.

Red flags (STOP): code before brainstorm; assuming intent; skipping scope; "it's simple."

Phase B: Write Plan (OpenSpec format)

Write to openspec/changes/<initiative-name>/:

design.md

# Design: [Goal]
## Context & Technical Approach
## Proposed Changes
### [Component/File]
## Verification

tasks.md

# Implementation Checklist
- [ ] 1.1 ...
- [ ] 1.2 ...
- [ ] Verification testing

Plan rules: small testable steps (15-30 min each), order by dependency, verification per step. No vague steps.

Step FINAL: Emit Handoff + Update Continuity

Write .cm/handoff/plan.json:

{
  "schema": "plan@1",
  "goal": "...",
  "decisions": ["..."],
  "first_tasks": ["1.1", "1.2", "1.3"],
  "openspec_path": "openspec/changes/<name>/"
}

Update .cm/CONTINUITY.md:

Active Goal → plan goal
Next Actions → first 3 tasks
Current Phase → "planning"
Working Context → key decisions

Token win: next session reads CONTINUITY (~200 tok) instead of full plan (2000+).

Integration

After planning...	Use skill
Complex initiative	`cm-brainstorm-idea` (run BEFORE)
Need isolated workspace	`cm-git-worktrees`
Execute the plan	`cm-execution`
Tests first	`cm-tdd`
UI/frontend	`cm-ui-preview`

Karpathy Discipline — Think Before Coding

Before writing the plan, surface what's uncertain instead of guessing:

State assumptions explicitly. List them in the plan; mark each as "verified" or "needs confirmation".
Multiple interpretations? Present them side-by-side with tradeoffs. Don't pick silently.
Simpler path exists? Say so. Push back on over-scoped requests.
Confused? Stop. Name the confusion. Ask. Cheaper than building the wrong thing.

Self-test: "Could a reviewer point to anything in this plan I'm guessing about?" If yes, mark it.

Anti-Patterns

❌ Coding before plan exists
❌ Skipping handoff JSON (downstream skills lose context)
❌ Vague tasks ("refactor the code")
❌ Hidden assumptions — pick one interpretation without telling the user

The Bottom Line

Think before you build. Document before you code. Emit handoff so the next skill picks up cold.

Gives 0 of the 12 instructions most plan spec skills give in 840 tokens

Counted across 1,099 of the 1,860 authors here whose files we hold, read 2026-08-07

ask one question at a timein 51 of 1099
Break plans into vertical slicesin 29 of 1099, across 11 files
Publish issues in dependency orderin 27 of 1099, across 9 files
Iterate until user approves the breakdownin 25 of 1099, across 7 files
Explore the repository to understand the codebase statein 24 of 1099, across 7 files
Use domain glossary vocabularyin 23 of 1099, across 5 files
Apply correct triage labels to published issuesin 23 of 1099, across 5 files
prefer AFK slices over HITLin 22 of 1099, across 7 files
write a specification before writing any codein 22 of 1099, across 14 files
Write failing tests before implementation codein 22 of 1099, across 20 files
ask clarifying questions until requirements are concretein 21 of 1099, across 13 files
Respect existing architecture decision recordsin 20 of 1099, across 5 files

Said here and by no other author read

define must-have versus nice-to-have scope
state assumptions explicitly in the plan
write design and tasks files
emit a handoff JSON file
update continuity file

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.