updatelisted

Specs move while code stands still. This skill finds the gap and writes it down; it does **not** implement anything. Target (may be empty): $ARGUMENTS ## 1. What changed, who is affected Argument given → that spec file, or the `requirements.md` row matching the keyword. Nothing given → sweep `.claude/docs/specs/memory/*.md` and `requirements.md`. Establish the *delta* — what is different now — working through the source-priority list `requirements.md` declares, highest first; the live decision channel outranks every distilled file. Old wording gone → reconstruct it from dated notes ("supersedes …", "reversed YYYY-MM-DD", the row's status text) and what the task docs assumed at the time. Cannot state the before-state → write the delta as new-rule-only and flag it in the report. Join the delta to prior work: ```bash jq -s -c 'group_by(.doc)[] | last | select((.req[]? == <N>) or (.specs[]? | contains("<spec>")))' .claude/clio/index.jsonl jq -s -c 'group_by(.id)[] | last | select(.status!="done" and ((.req[]? == <N>) or (.specs[]? | contains("<spec>"))))' .claude/clio/debt.jsonl ``` Open the matching docs and read `## Decisions`, `## Side Effects`, `## Follow-up` — that is what a spec change invalidates. Note the code paths named there for `code[]`. ## 2. Decide the status `blocked_by` is decisive, not `status`: `status` says how far the work got, `blocked_by` says whether anyone may start. | `status` | `blocked_by` | Meaning | May implement? | |---|---|---|---| | `pend