| description | Render the full project stack — everything done, in flight, queued, and blocked, as one verified tree |
|---|
Render the CURRENT FULL STACK of this project: one tree showing where we
are, root to leaf — the whole endeavor, not just the active task. An
optional argument narrows it (/stack <subtree>) or asks for brevity
(/stack brief = top two levels only).
The stack is only useful if it is true. Before drawing it:
- Read the project's durable work-state files (whatever this project uses: PROGRESS.md, a ledger, plan/roadmap docs, TODO files, reviewer state files) for the declared plan and its stage list.
- Read recent
git log --oneline(andgit status) and reconcile it against the declared plan: what has actually landed since the plan was written? What is uncommitted/in flight right now? - LIVENESS-CHECK anything load-bearing that documents merely claim: a "done" whose artifact you can cheaply confirm in the tree (file exists, test exists, caller wired), confirm it; a "pending" that git shows landed, correct it. Stale work-state files drift in BOTH directions — done-but-listed-open and open-but-marked-done are equally common. Never render a status you know how to verify but didn't.
- If the conversation established statuses more recent than any file, those win — but mark anything delivered-but-unconfirmed honestly (e.g. "ruled, pending acknowledgment").
A single fenced tree, then a short prose reading. Legend:
✓done — verified, with its receipt compressed inline (the one-line what-and-proof: key numbers, the commit/test/gate that certifies it)▶in flight NOW — this is where the leaf-level detail goes⏳queued — named scope, one line each; enough that a reader knows what the item IS without another document🔒blocked on a human decision — say whose and what question
Structure rules:
- Root = the overall endeavor. Nest by arc/phase/batch as the project actually organizes work; sequence top-to-bottom in execution order.
- COMPRESS completed eras: a finished multi-week arc is one or two lines naming what it proved, not its history. Detail budget goes to the in-flight item and the next few queued ones.
- Sub-item detail uses interior bullets (
·separators) rather than deeper nesting once past ~3 levels — keep the tree scannable. - Include the milestone gates as their own nodes (merge, release, freeze…) with their acceptance bar stated in a few words.
- Everything AFTER the current milestone (post-merge queues, future phases, long-term direction) appears compressed at the bottom so the stack always shows the whole journey, not just the current leg.
- Wide content must not wrap badly: keep tree lines under ~76 chars.
The prose reading after the tree (a short paragraph, not a section): state plainly where we are, what the current bottleneck or risk is, and — when the project distinguishes them — the difference between the nearest usable milestone and the fully-gated one (e.g. "working build" vs "trustworthy merge"), with the critical path to the nearest one. End with any honesty caveats: unverified claims, undelivered rulings, stale inputs you could not check.
No cheerleading, no padding. A ✓ earns its mark only if verified; where you trusted a document without checking, say so. The reader uses this to make sequencing decisions — an optimistic stack is worse than none.
(Written by Claude)