sdlc-status
Skill0 starsChanged 39 days agoMITView on GitHub
Show a quick readout of the current work queue: task counts by state, the active task, and the most recently completed task. Also surfaces any non-terminal pipeline runs (so a stalled /sdlc run can't hide). Reads TASKS.md and .claude/pipeline/ directly — no subagents, no dashboards. Invoke via /sdlc-status or when the user asks "what's left?", "current task?", "status". Read-only by default; `--prune-stale` and `--reconcile` are opt-in, confirm-gated cleanup of stale/orphaned pipeline envelopes.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- michaellam26/pathfindertheir own version, first seen Aug 22, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- michaellam26/pathfinder★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository14 other files it gives its agents.
- AGENTS.mdAGENTS.md
- brainstormSkill
- brainstorm-teamSkill
- code-tourSkill
- dead-code-reviewSkill
- docstring-syncSkill
- flowsimSkill
- gotchaSkill
- plan-htmlSkill
- repo-healthSkill
- repo-onboardingSkill
- sdlcSkill
- taskSkill
- test-checkSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 7 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 34
Treat missing fields as "unknown" rather than as errors.
- Very specific: line 61
Waves line: Run bash scripts/close-tasks.sh waves --file TASKS.md --gate first.
- Distinctive: line 82
If there's no active task, say "no active task — next up: <first pending>".
- Distinctive: line 88
After the summary, print one recommended next command with a one-line reason.
- Distinctive: line 120
List them and ask for one confirmation: before touching anything: show each slug, stage, age, and why it qualifies.
- Distinctive: line 131
No subagent calls, no multi-step workflows.
- Distinctive: line 132
Keep the output under 6 lines unless the user asks for detail.
- Distinctive: line 133
If the user wants more (e.g., "show all pending"), list them in a compact table but still no subagent.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Status — one-glance work readout
Toolkit paths. Every toolkit script or template path cited here resolves, first hit wins, against: a repo-local copy installed by
setup.sh; else the plugin root (this skill's base directory two levels up,<base>/../..) when it holds that path; else~/.claude/brainstorm-toolkit/(the global shell install).
Flow
- Read
TASKS.mdat the repo root. If missing, report "no TASKS.md yet — run/repo-onboardingor/task <description>to create one" and stop. - Count checkbox states across the file:
[ ]→ pending[~]→ in progress[x]→ done
- Identify the active task: the first
[~]row, or if none, the first[ ]row. - Identify the last completed: the most recent
[x]row (top of theDonesection, or last[x]before it). Parse optional metadata markers on each row (additive — absent fields are fine):
_started_at: YYYY-MM-DD__completed_at: YYYY-MM-DD__blocked_reason: <short reason>_
Treat missing fields as "unknown" rather than as errors. Do not warn.
- Compute summaries:
- Cycle time per
[x]row =completed_at − started_atin days, when both are present. Surface the median across the most recent ~10 done rows; skip rows where either field is unknown. - Blocked-reason rollup: count distinct
_blocked_reason: …_values under theBlockedsection.
- Cycle time per
- Scan pipeline run-state (the discipline signal). Follow
skills/sdlc/templates/envelope-staleness.md— the shared scan, including its false-positive guards (skip onmain_branch, at most one report, silence when nothing changed). Read-only here: surface non-terminal and stale runs, don't rewrite them.--prune-staleand--reconcilebelow are the only mutating paths.
--reconcile — backlog drift. TASKS.md and the run envelopes can disagree, and
nothing surfaced it before. Run bash scripts/close-tasks.sh reconcile --file TASKS.md
(add --apply only after a single confirmation; without it the command writes nothing).
It reports drift in both directions — a complete/completed envelope whose matched rows
are still open (terminal_envelope_open_rows), an in_progress envelope with no TASKS.md row
referencing it at all (inprogress_envelope_no_row), a [x] row filed outside ## Done
(active_section_closed_row), and a [ ]/[~] row filed under ## Done
(done_section_open_row). A _followup_ or _manual_ row is exempt from the
terminal-envelope open-row finding — it was left open on purpose, not forgotten. A row whose
_phase: N_ tag names a phase its own plan file has no #### Phase N heading for is
reported too. Print drift_count and one line per finding; say
backlog: no drift when clean. Skip silently when scripts/close-tasks.sh is absent
(--no-copy-scripts installs).
Waves line. Run bash scripts/close-tasks.sh waves --file TASKS.md --gate first. The rule it
applies: off when pipeline.action_items.enabled is false (a veto, whatever files exist), on when
true, and when absent on only if the file named by pipeline.action_items.file (default
ACTION_ITEMS.md) exists beside TASKS.md and its first line is the generated banner
(<!-- generated — edit TASKS.md). Read both keys first; never test the default name when file
is set. When it prints enabled: true, run
bash scripts/close-tasks.sh waves --file TASKS.md — read-only, no --write: this skill never
regenerates the file — and take summary and overlaps[] from its JSON. Skip silently when the
feature is off or scripts/close-tasks.sh is absent (--no-copy-scripts installs).
8. Print a 3–7 line summary:
TASKS: N pending · M in_progress · K done · B blocked
Active: (P<pri>) <title> — plans/tasks/task-<N>-<slug>.md
Last done: <title> (cycle: <D> days, or "unknown")
Median cycle (last 10): <D> days (omit if all unknown)
Blocked reasons: <reason1> ×N · <reason2> ×M (omit if no blocked rows)
Pipeline: <slug> @ <stage> (<pipeline>, in_progress 3d — reconcile) (omit if none non-terminal)
Waves: now N across L lane(s), next M (omit if skipped; one ⚠ line per overlap)If there's no active task, say "no active task — next up: <first pending>".
A non-terminal pipeline run is the one thing worth making loud — it's how a
skipped/abandoned pipeline becomes visible instead of lingering in JSON.
Next step
After the summary, print one recommended next command with a one-line reason. Highest match wins; stop at the first hit:
- Paused/failed run on this branch →
/sdlc <input> --resume. Read the failing stage's sidecar and name the class in the reason — flaky (a test flips across loops) · code-defect (a consistent assertion failure) · plan-wrong (the failure contradicts a plan step) · config-missing (a command/env the runner needs). For a code defect, recommend/task fix: <one-line failure>first, then the resume. - Non-terminal run whose work looks landed (
base_commitis an ancestor of HEAD) →/sdlc-status --prune-staleto reconcile. - Pending sentinel (
.claude/.next-actionnon-empty) → surface each line'scmdverbatim. Never consume the sentinel here; this skill is read-only. - A plan file with no pipeline run →
/sdlc <plan>. [~]in-progress TASKS.md row →/sdlc task-<N>.[ ]pending rows → the top one that is not tagged_manual_in its trailer (the text after the last—; human-only work every dispatch path refuses — seetemplates/TASKS.md.template), falling through to the next pending row when it is:/taskif small and bounded,/sdlcif it needs the full pipeline. If every remaining pending row is_manual_, say so instead of recommending a command.- Nothing queued →
/brainstormfor ideation, or/repo-healthfor a hygiene sweep.
Print it as Next: <command> — <reason>. Recommend only; never execute.
--prune-stale (opt-in cleanup — the one write exception)
Detection alone leaves stale envelopes flagged forever. /sdlc-status --prune-stale
lets you actually clear them — confirm-gated, never automatic:
- Find pipeline runs that are non-terminal (
in_progress/paused) and either older thandiscipline.staleness_hours(default 24) or whosebase_commitis not a real git object (git cat-file -e <base_commit>fails — a synthetic/placeholder base that nothing will ever reconcile). - List them and ask for one confirmation before touching anything: show each slug, stage, age, and why it qualifies.
- On confirm, for each: if its
base_commitis an ancestor of HEAD (work landed), setrun.json.status = "abandoned"and append a one-line note; if it's a synthetic/garbage envelope, remove the.claude/pipeline/<slug>/directory. Report what was pruned.
Rules
- Pure read by default, no file writes. The sole exception is
--prune-staleabove, which is explicit and confirm-gated. - No subagent calls, no multi-step workflows.
- Keep the output under 6 lines unless the user asks for detail.
- If the user wants more (e.g., "show all pending"), list them in a compact table but still no subagent.
- Missing
_started_at_/_completed_at_/_blocked_reason_markers are reported as "unknown"; never raise an error or refuse to summarize.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

