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.

Read narrowly — slices, never fewer sources. Plans and handoff logs grow for months: locate the sprint in scope and read that sprint, the decisions about it and the handoff entries of its batches — not the whole files. Every source in the list above is still read; what shrinks is how much of each. The reading is one pass by one reader, and its cost should not grow with the age of the repository. Whatever you did not open, name in the method note.

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.