agentleFS
exerias21exerias21/brainstorm-toolkit/skills/sdlc-status/SKILL.md

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

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    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.

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
  1. Distinctive:

    Treat missing fields as "unknown" rather than as errors.

    line 34
  2. Very specific:

    Waves line: Run bash scripts/close-tasks.sh waves --file TASKS.md --gate first.

    line 61
  3. Distinctive:

    If there's no active task, say "no active task — next up: <first pending>".

    line 82
  4. Distinctive:

    After the summary, print one recommended next command with a one-line reason.

    line 88
  5. Distinctive:

    List them and ask for one confirmation: before touching anything: show each slug, stage, age, and why it qualifies.

    line 120
  6. Distinctive:

    No subagent calls, no multi-step workflows.

    line 131
  7. Distinctive:

    Keep the output under 6 lines unless the user asks for detail.

    line 132
  8. Distinctive:

    If the user wants more (e.g., "show all pending"), list them in a compact table but still no subagent.

    line 133

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

  1. Read TASKS.md at the repo root. If missing, report "no TASKS.md yet — run /repo-onboarding or /task <description> to create one" and stop.
  2. Count checkbox states across the file:
    • [ ] → pending
    • [~] → in progress
    • [x] → done
  3. Identify the active task: the first [~] row, or if none, the first [ ] row.
  4. Identify the last completed: the most recent [x] row (top of the Done section, or last [x] before it).
  5. 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.

  6. Compute summaries:
    • Cycle time per [x] row = completed_at − started_at in 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 the Blocked section.
  7. Scan pipeline run-state (the discipline signal). Follow skills/sdlc/templates/envelope-staleness.md — the shared scan, including its false-positive guards (skip on main_branch, at most one report, silence when nothing changed). Read-only here: surface non-terminal and stale runs, don't rewrite them. --prune-stale and --reconcile below 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:

  1. 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.
  2. Non-terminal run whose work looks landed (base_commit is an ancestor of HEAD) → /sdlc-status --prune-stale to reconcile.
  3. Pending sentinel (.claude/.next-action non-empty) → surface each line's cmd verbatim. Never consume the sentinel here; this skill is read-only.
  4. A plan file with no pipeline run → /sdlc <plan>.
  5. [~] in-progress TASKS.md row → /sdlc task-<N>.
  6. [ ] 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 — see templates/TASKS.md.template), falling through to the next pending row when it is: /task if small and bounded, /sdlc if it needs the full pipeline. If every remaining pending row is _manual_, say so instead of recommending a command.
  7. Nothing queued → /brainstorm for ideation, or /repo-health for 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:

  1. Find pipeline runs that are non-terminal (in_progress/paused) and either older than discipline.staleness_hours (default 24) or whose base_commit is not a real git object (git cat-file -e <base_commit> fails — a synthetic/placeholder base that nothing will ever reconcile).
  2. List them and ask for one confirmation before touching anything: show each slug, stage, age, and why it qualifies.
  3. On confirm, for each: if its base_commit is an ancestor of HEAD (work landed), set run.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-stale above, 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.