waterfall-tracking

name	waterfall-tracking
description	Stand up and maintain a visible stage-level task list for the /meta-dev 6-stage waterfall. Use in autopilot/walk runs so the user can walk away and watch Brainstorm→Design→Plan→Harden→Execute→Review progress live. Stage granularity only — never mirrors /meta-execute's per-task list.
allowed-tools	["TaskCreate","TaskUpdate","Bash"]

Waterfall Tracking Skill

Make the /meta-dev waterfall watchable. Cruise/walk exists so the user can walk away and see progress; the watching surface is a visible task list at stage granularity. This is the same proven discipline as /meta-execute's "visible main-thread task list" (commands/meta-execute.md → Prerequisite), one level up.

Invoked by /meta-dev at the start of any autopilot/walk run (keywords cruise/autopilot/auto/walk/unattended, the --cruise flag, or Accept-Edits mode). Mandatory in autopilot/walk; recommended-but-optional in interactive mode.

Procedure

1. Create once, up front (before Stage 1)

Call TaskCreate — one entry per waterfall stage, named for what it does. Chain dependencies (each stage depends on the prior):

Stage 1 — Brainstorm
Stage 2 — Design
Stage 3 — Plan (/meta-planner)
Stage 4 — Harden (/loop-gap)
Stage 5 — Execute (/meta-execute)
Stage 6 — Review (/meta-eval + audit + housekeeping)

No tracker visible = the run has not started correctly. For multi-item runs, create one stage list per subject and prefix entries with the subject so concurrent pipelines stay legible.

2. Update as state changes (never batched at the end)

• Stage starts → TaskUpdate to in_progress.
• Exit criteria met (the per-stage exit-criteria table in the plugin's dev-modes reference) → completed; then commit the stage artifacts.
• Stage halts after max retries → blocked with the failure reason; the rest of that subject's stages stay pending (error isolation — one subject's failure never halts others).
• Quick-fix bypass skips Stages 1-4 → mark them completed with a ⏭ skipped (trivial) note so the trail is honest about what actually ran.

2b. Mirror every transition to the durable dashboard (MANDATORY)

The TaskUpdate list is ephemeral — it vanishes when the run ends. So at every stage transition, alongside the TaskUpdate, emit a durable stage event (fire-and-forget — never let it block the run):

bash ${CLAUDE_PLUGIN_ROOT}/scripts/stage-emit.sh "<plan-path>" <stage> <status>

• <plan-path> — the plan file/dir for this subject (prefix per subject in multi-item runs).
• <stage> — brainstorm | design | plan | harden | execute | review (maps to 1→6).
• <status> — in_progress on start, completed on exit-criteria, blocked on halt — mirror the same status you pass to TaskUpdate.

stage-emit.sh patches the plan's YAML stage:/status: frontmatter in place — that frontmatter is the single source of truth for the plan's stage — and appends a slim history event to events.jsonl. /meta-dashboard then computes live from the plans via scripts/plan-index.py; there is no plan state.json to maintain. Emit on start AND on completion of each stage; emitting twice is harmless (last write wins). The stage-owning commands also emit when run standalone, so the dashboard stays correct whether the waterfall runs via /meta-dev or a command is invoked directly.

3. Nested, not duplicated

Stage 5 delegates to /meta-execute, which stands up its OWN per-checkbox list (one entry per checkbox in the plan — every ### Task N: AND every - [ ] subtask checkbox). That is a separate, much finer-grained tracker. Mark Stage 5 — Execute in_progress, let /meta-execute drive its task list, then mark Stage 5 completed on return. Never mirror execute's individual tasks into the stage list — two lists at two granularities, zero overlap.

Rules

• Stage granularity only. This list tracks the six waterfall stages, nothing finer.
• Live, not retrospective. Every transition is mirrored the moment it happens, never reconstructed at the end.
• Honest trail. Skips, blocks, and halts are shown as such — a completed stage means its exit criteria were genuinely met.