git:20260919.a226148 to git:20260920.2c949ab

---

name: cdev-status

description: Use when the user asks where a CDev-conditioned repository stands — progress of the active sprint (or a named one) measured on three axes, functional requirements, non-functional requirements and user stories — after several batches have run, before deciding what to run next, or when coming back to a repo. Also when the user invokes /cdev-status or asks "status of the sprint", "where are we", "how far along is this", "status funcional", "por dónde vamos", "qué llevamos del sprint".

---

# CDev Status

A read-only reading of **one** conditioned repository: how far the sprint's intent has been

walked, on three axes. **It edits no file and marks no state.** The single-repo counterpart of

`cdev-monorepo-status`, which applies this skill's method by reference — this file is the

method's single home.

Requires a conditioned repo (`docs/develop/` with `SPRINTS.md`, `AGENT_PROGRESS.md`, protocol).

Not conditioned → propose the `bootstrap` skill and stop; do not improvise a status.

## The idea

The plan holds no list of requirements or user stories, on purpose: a formalized list has to be

kept current while a feature is still being discovered, and that maintenance is what drifts.

The intent lives in free form — the sprint's objective, each batch's text and acceptance, the

decisions, the handoff. This skill engineers the three axes **at read time** from that raw

chain, and says where each item came from.

## Scope

- **No argument** → the `ACTIVE` sprint. None `ACTIVE` → say so, and read the most recently

closed one.

- **A sprint named** → that sprint.

- **`all`** → one line per sprint (state, batches closed of N, the three percentages); full

detail only for the `ACTIVE` one.

- **`since <batch|date|commit>`** → adds the delta (§ Delta).

## Read, in this order

1. Repo guide → local protocol (what "verified" means here).

2. `SPRINTS.md` — the sprint's objective; every batch: text, acceptance, state, dependencies.

3. `DECISIONS.md` — the entries about this sprint.

4. `AGENT_PROGRESS.md` — the entries of this sprint's batches: what was done, verification per

check, blockers.

5. `git log` and `git status` — the commits carrying the sprint's units; work the plan does not

know about.

6. Whatever the sprint or its batches reference — contracts, reports, a testing document where

one exists.

Where a later record changes an earlier decision, the newest wins and is the one cited.

## Engineer the three axes, in this order

1. **Functional requirements** — what the sprint's objective and its batches commit the system

to *do*. One line each, in the plan's own terms.

2. **Non-functional requirements** — the qualities and constraints they commit the *system*

to, wherever the plan, the decisions or the referenced documents state them. The

repository's working rules — its verification sequence, branch convention, gates — are not

requirements of the system: they tell you what "verified" means, they are never items.

3. **User stories** — built last, over the first two, against the sprint's objective. First

person ("As a …, I …"), each marked **new** or **enriched** (a capability that already

existed and this sprint extends).

Every item cites its source: the sprint objective, a batch, a dated decision, a handoff entry,

a file path.

State per item:

- **met** — every batch carrying it is `DONE` and its handoff entry records the verification;

- **met, unverified** — the batches are `DONE` but a check that covers it is recorded `not-run`;

- **partial** — an estimated percentage, the reason, and the batch that owns the rest;

- **pending** — the owning batch.

Percentages are **estimates**: **one figure per axis** over the sprint's total, one per partial

item. "Met, unverified" items count toward the axis figure; the executive reading says how much

of it rests on them. Say in the method note that the numbers are estimates; never present them

as measured, never give an axis two figures.

## Report

1. **Title** — sprint, date, batches closed X of N.

2. **Method note** — one paragraph: the items were derived at read time from the files read

(name them); the percentages are estimates.

3. **§1 Functional requirements — ~NN%** — table `State | Requirement | Source`.

4. **§2 Non-functional requirements — ~NN%** — same table.

5. **§3 User stories — ~NN% · N complete · N partial · N empty** — three groups. Complete: the

story and what proves it. Partial: percentage and reason. Empty: the owning batch.

6. **Executive reading** — batches closed, the three percentages, where the remaining work

converges, live risks: blocked batches and the human decisions they wait on, verification

recorded `not-run`.

7. **What is left to reach 100%** — numbered, by owning batch.

Keep it a reading, not an audit: one line per item, the executive reading in a handful of

lines. A disagreement is flagged once, where it bites, not re-argued in every section.

### Delta

With `since`, read `SPRINTS.md` and `AGENT_PROGRESS.md` as they were at that point

(`git show <rev>:<path>`; a batch resolves to the commit that closed it — a bare batch id

means the sprint in scope — and a date to the last commit before it). Apply the **same item

list** to both states, show "(before NN%)" beside each percentage and mark the items whose

state changed. No argument, no delta. Nothing is persisted between runs.

## Rules

- **Read-only, always.** If the conversation surfaces something that belongs in the plan,

say it is the planner's job; do not write it.

- An axis the repository does not support reads **"not derivable"** and names what is

missing. Never fill it from general knowledge of what such a product usually needs.

- Disagreement between plan, handoff and git is **flagged, never resolved**: a `DONE` whose

entry records a check `not-run` reads "met, unverified"; commits belonging to no batch are

listed as work the plan does not know.

- Answer in the language the human is using.