# Cdev Planner

> Use when planning work inside a single CDev-conditioned repository — turning an objective into batches in the local SPRINTS.md with observable acceptance, or sweeping the repo for gaps (verification debt, stale blocks, coverage/parity holes, plan↔git divergence, contradictory docs) and proposing the next sprints. Also when the user invokes /cdev-planner or asks "plan this repo", "what's next here", "qué falta por hacer".

- Skill: `elmayii/cdev-planner` (Agent Skill)
- Install (CLI): `npx skillmds@latest add elmayii/cdev-planner`
- Raw SKILL.md: https://api.skillmd.com/api/skills/elmayii/cdev-planner/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: elmayii (https://skillmd.com/u/elmayii)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/elmayii/cdev-planner

---


# CDev Planner

Planning brain for **one** conditioned repository. **Never implements code.** The single-repo
counterpart of `cdev-monorepo-planner`: same two modes, scoped to this repo's own plan. Without
a clear argument, run both: gap analysis first, then materialize what is approved.

Requires a conditioned repo (`docs/develop/` with `SPRINTS.md`, `AGENT_PROGRESS.md`, protocol,
clarity map). Not conditioned → propose the right bootstrap skill and stop; do not improvise a plan.

## Mode 1 — Materialize an objective (objective → executable batches)

1. **Read the repo state first**: repo guide → local protocol → `SPRINTS.md` → last
   `AGENT_PROGRESS.md` entries → `git status` and recent commits. If plan and git disagree,
   flag and reconcile before planning on top — a plan built over a drifted state is poisoned.
2. **Locate the objective in the clarity map** (`PRODUCT.md`):
   - **DEFINED** → plan it fully;
   - **PARTIAL** → plan the clear part; record every assumption, dated, in `DECISIONS.md`;
   - **ABSENT** → do not plan it. Write the open question instead. Inventing an ABSENT area
     is forbidden.
3. **Place work respecting the local order**:
   - an existing batch already covers it → **adopt** it, don't duplicate;
   - fits the ACTIVE sprint's objective → append batches at the end of that sprint;
   - belongs to a later phase → next `PENDING` sprint, or a new sprint drafted as `PROPOSAL`
     (a human ratifies; the planner never activates it). Never a second ACTIVE sprint,
     never renumber.
4. **Write each batch executable as-is**: acceptance criteria observable and written before the
   work (not "endpoint implemented" but "this call returns this shape and this check proves
   it"); verification per the repo's real protocol; `depends_on` between batches where order
   matters; sized to be finishable and provable in one sitting.
5. **Declare gates**: any step whose blast radius exceeds the working branch (schema on a
   shared database, deploy, publishing) is marked prepare-don't-execute, naming the human
   decision required.
6. **Promote to `READY`** only when acceptance is observable, dependencies exist, and the plan
   still satisfies the invariants (exactly one ACTIVE sprint, no unresolved placeholders).
7. **Record planning decisions**, dated, in `DECISIONS.md`.

## Mode 2 — Gap analysis (find what to do, and what is silently missing)

Sweep the repo and produce actionable candidates, each with evidence:

1. **Verification debt, aggregated**: batches `DONE` with checks `not-run`, runtime evidence
   missing where the protocol demands it, blocked verifications never re-run. Sum it and show
   the total — individually honest entries add up to a plan that reads finished over work
   never fully verified.
2. **Stale state**: `BLOCKED` batches whose blocker may have cleared, `IN_PROGRESS` with no
   matching working tree, plan↔git divergence, registry-style claims no longer true.
3. **Coverage and parity**: untested areas the protocol gates on, parity gaps between targets
   (multi-target repos), marked debt (debt sections, deferred TODOs).
4. **Documentation consistency**: operational docs that contradict each other — the loop trusts
   instructions, so a contradiction is an incident waiting; clarity map stale against specs
   that have since arrived; leftover placeholders.
5. **Plan health**: no ACTIVE sprint (plan exhausted — natural next-sprint candidate),
   acceptance criteria not observable, blocked units missing their named human decision.

Output: table candidate → evidence (file/line/commit) → proposal (draft batch or open
question). Approved candidates enter `SPRINTS.md` via Mode 1 as `PROPOSAL`/`PENDING`.
**Findings not derivable from evidence are not invented** — open question in `DECISIONS.md`.

## Rules

- The repo is the source of truth; the planner reads, references and proposes — it never marks
  work `DONE`, never implements, never activates a `PROPOSAL` sprint.
- Self-directed planning stays inside DEFINED/PARTIAL areas of the clarity map.
- Every finding cites evidence (file/line/commit), never impressions.
- Invariant violations found while planning (two ACTIVE sprints, `DONE` without evidence) are
  reported as planning bugs with a proposed correction — not silently repaired.