/status — ADLC Status Dashboard

You are generating a status report of all ADLC work in the current project.

Ethos

!test -s .adlc/ETHOS.md && cat .adlc/ETHOS.md || echo No ethos found — run /init, or /adlc:init on the plugin install, to vendor .adlc/ETHOS.md

See also /manifest — /status reads this local checkout; /manifest derives in-flight work across all sessions from the remote (open PRs + pushed feat/REQ-* branches), with an advisory overlap report. Use /manifest to see what other people are working on before you start.

Context

Run this block first, with your shell tool, and read its output before you continue. Each read prints a notice instead of failing when its file is absent.

# adlc-context
echo '--- Specs directory'
ls .adlc/specs/ 2>/dev/null || echo 'No specs found'
echo '--- Bugs directory'
ls .adlc/bugs/ 2>/dev/null || echo 'No bugs found'
echo '--- Current branch'
git branch --show-current 2>/dev/null || echo 'Not a git repo'

Input

The filter is the argument: whatever follows /status in the invocation (on Claude Code it can also arrive as an ARGUMENTS: line appended to this text). With none, report everything.

Prerequisites

Before proceeding, verify that the .adlc/specs/ directory exists (this skill reads requirement and task frontmatter from there). .adlc/bugs/ and live pipeline-state.json files are read when present but are not required. If .adlc/specs/ does not exist, stop and tell the user: "The .adlc/ structure hasn't been initialized. Run /init (/adlc:init on the plugin install) first to set up the project context."

Instructions

Step 1: Scan All ADLC Artifacts

Detect repository mode — read .adlc/config.yml. If it declares more than one entry under repos:, this is cross-repo mode; otherwise single-repo mode.

1. Read all requirement.md files under .adlc/specs/REQ-*/ (this repo)
2. Read all task files under .adlc/specs/REQ-*/tasks/
3. Read all bug reports under .adlc/bugs/ — including the optional introduced_by / attribution frontmatter, which supplies the Incident Attribution section below
4. Read all pipeline-state.json files under .adlc/specs/REQ-*/ for live pipeline progress
5. Also check for nested .adlc/ directories (e.g., api/.adlc/)
6. Extract frontmatter (id, title, status, updated) from each artifact, plus a requirement's lane and lane_escalated (REQ-652). A missing lane means full.

Cross-repo scan (only in cross-repo mode): for every sibling declared in .adlc/config.yml:

• Resolve the sibling's absolute path from repos[<id>].path
• Read <sibling-path>/.adlc/specs/REQ-*/pipeline-state.json to find REQs where the sibling was primary. Any of those that have a repos block listing the current repo as touched: true represents cross-repo work that affects us but originates elsewhere.
• Capture REQ id, primary repo id, state file path, and current phase for the cross-repo report section (Step 2).

Cross-repo scan is read-only — /status never modifies sibling repos.

Step 2: Build Status Report

Organize the report as follows:

Requirements Summary Table

For each requirement:

• Count total tasks and completed tasks
• Calculate progress percentage
• Show status from frontmatter
• Lane (REQ-652 BR-15): the spec's lane, lite or full; print full when the key is absent. A lite REQ has no task files by design, so show its Tasks cell as — rather than 0/0.
• Escalated: the date and trigger from lane_escalated (the part before the detail), or blank when the spec has none

Active Pipelines

If any pipeline-state.json files exist with "completed": false, show:

• Lane column: the state file's lane.current, marked (escalated) when lane.escalations is non-empty. A state file without a lane object is a full-lane run: print full. A lite run's Phases 1–3 appear in completedPhases with "skipped": "lite" history entries; report them as skipped, not as run.
• Primary column: which repo the REQ originates from (the repo holding the state file). In single-repo mode this is always the current repo; omit the column if no cross-repo config exists.
• Touched Repos column: only populated in cross-repo mode — list every repo id from the state file's repos block where touched: true, with a ✓ for merged and a clock for in-progress.

Phase names: 0=Worktree, 1=Validate Spec, 2=Architect, 3=Validate Tasks, 4=Implement, 5=Verify, 6=Create PR, 7=PR Cleanup, 7.5=Canary, 8=Wrapup

Separate the genuinely-active from the never-closed (BUG-193). A completed:false state file is not proof of an active pipeline — a run that merged its PR but skipped the Phase 8 close-out leaves the same signature, and those files never self-correct. Before listing a REQ as active, test these offline invariants and report any that trip under a Stale Pipeline State heading instead, with the reconciliation as the recommended action:

Confirm against the forge before reconciling — gh pr view <prNumber> --json state,mergedAt — and write the real merge commit and timestamp into the phase-8 phaseHistory entry rather than a synthesized one. Never infer a merge from the requirement's status alone.

Cross-Repo Activity (cross-repo mode only)

If the cross-repo scan found REQs originating elsewhere that touch this repo, surface them separately so the user sees inbound cross-repo work without losing context on local REQs:

"Branch Here" is detected by checking git -C <this-repo> branch --list feat/REQ-xxx-*. If absent, the REQ hasn't reached Phase 4 yet or this repo isn't touched after all.

In-Progress Work

List any artifacts with status in-review, approved, or in-progress tasks:

• Which requirement they belong to
• What phase they're in (spec, architecture, tasks, implementation)
• What's blocking progress (if any)

Open Bugs

Incident Attribution

Which shipped REQs have produced incidents (REQ-593). Derived at read time by scanning .adlc/bugs/ frontmatter — the reverse edge is never stored in a REQ spec, because a stored backlink rots silently when an artifact is moved or renumbered (BR-4, LESSON-019).

Source the partial and call it in the same fenced block (the cross-fence-fn rule):

ADLC_TOOLKIT_ROOT="${CLAUDE_PLUGIN_ROOT}"; [ -n "$ADLC_TOOLKIT_ROOT" ] || [ ! -d "$HOME/.claude/skills/partials" ] || ADLC_TOOLKIT_ROOT="$HOME/.claude/skills"; [ -n "$ADLC_TOOLKIT_ROOT" ] || ADLC_TOOLKIT_ROOT=$(cat "$HOME/.claude/adlc/plugin-root" 2>/dev/null); export ADLC_TOOLKIT_ROOT="${ADLC_TOOLKIT_ROOT:-$HOME/.claude/skills}"
if [ -f .adlc/partials/attribution.sh ]; then . .adlc/partials/attribution.sh; else . "$ADLC_TOOLKIT_ROOT/partials/attribution.sh"; fi
# Emits one "BUG-id<TAB>REQ-id" line per attributed edge; add a REQ id as a second
# argument to filter to that REQ's incidents. Strictly read-only.
adlc_attr_bugs_with_attribution "$PWD"

One row per REQ that has at least one attributed bug, with the count and the BUG ids. A bug carrying no introduced_by is simply absent — it is not an error. When nothing is attributed, print No attributed incidents yet. rather than an empty table or a warning.

This section reads .adlc/bugs/ only. It modifies no file, and in particular opens nothing under .adlc/specs/**.

Conflict Resolutions

Which pipeline runs resolved a merge or rebase conflict mid-run, and whether the resolution was verified (BUG-212). Read from each spec's pipeline-state.json conflictsResolved array — the record written at the moment of resolution, not the runner's narrative. Strictly read-only; a state file without the key is simply a run that resolved nothing.

# One row per recorded resolution. `conflictsResolved` is optional and additive:
# a state file without it parses unchanged (absent == none resolved).
for f in .adlc/specs/REQ-*/pipeline-state.json; do
  [ -f "$f" ] || continue
  python3 - "$f" <<'PYEOF'
import json, sys, os
p = sys.argv[1]; req = os.path.basename(os.path.dirname(p)).split("-", 2)[:2]
try:
    s = json.load(open(p))
except (OSError, ValueError):
    sys.exit(0)  # unreadable state is /status Step 1's concern, not this section's
for e in s.get("conflictsResolved") or []:
    print("\t".join(["-".join(req), str(e.get("phase", "?")), ",".join(e.get("files") or []),
                     str(e.get("resolvedBy", "?")), str(e.get("strategy", "?")),
                     "yes" if e.get("verified") else "no", str(e.get("resolvedAt", "?"))]))
PYEOF
done

When no run has a recorded resolution, print No recorded conflict resolutions. rather than an empty table. An entry with verified: no is not an error — it is the honest value the record exists to surface.

Escalations

Which REQs started on the lite lane and escalated to the full lane, and why (REQ-652). Read from each spec's pipeline-state.json lane.escalations array, which is written at the moment of escalation. Strictly read-only; a state file without a lane object is a full-lane run and contributes nothing.

# One row per recorded escalation. `lane` is optional and additive:
# a state file without it parses unchanged (absent == full lane, nothing escalated).
# `find`, not a bare glob: zsh aborts on an unmatched glob (LESSON-335). `-I` keeps
# a stray json.py in the project root off sys.path.
find .adlc/specs -mindepth 2 -maxdepth 2 -name pipeline-state.json -type f 2>/dev/null | sort | while IFS= read -r f; do
  command python3 -I - "$f" <<'PYEOF'
import json, sys, os
p = sys.argv[1]; req = os.path.basename(os.path.dirname(p)).split("-", 2)[:2]
try:
    s = json.load(open(p))
except (OSError, ValueError):
    sys.exit(0)  # unreadable state is /status Step 1's concern, not this section's
lane = s.get("lane") if isinstance(s, dict) else None
esc = lane.get("escalations") if isinstance(lane, dict) else None
def cell(v):
    return " ".join(str(v).split())  # one line, no tabs: free-text details stay in their column
for e in esc if isinstance(esc, list) else []:
    if not isinstance(e, dict):
        continue
    print("\t".join(["-".join(req)] + [cell(e.get(k, "?")) for k in ("phase", "trigger", "detail", "actor", "at")]))
PYEOF
done

When no run has a recorded escalation, print No recorded lane escalations. rather than an empty table. A spec with lane_escalated but no state file (another machine, or a torn-down worktree) still shows in the Requirements Summary's Escalated column.

Recently Completed

List artifacts completed in the last 7 days (by updated date).

Step 3: Apply Filters (if provided)

• If a REQ ID is given, show detailed status for just that requirement and its tasks
• If "in-progress" is given, show only non-complete work
• If "bugs" is given, show only bug reports
• If no filter, show the full dashboard

Step 4: Highlight Action Items

At the bottom, list recommended next actions:

• Specs that are draft and need validation (not lite-lane specs, which run from draft: those need /proceed)
• Approved specs that need architecture/tasks (not lite-lane specs, which have none by design: those need /proceed)
• Tasks that are ready to implement (dependencies met)
• Bugs that are open and unassigned