speclisted

Resolve **$ARGUMENTS** against the locked pack + blueprint. This is the build-time counterpart to the pipeline: the specs are already written, and the job here is to find what they say — not to reconstruct it from the code or from context. ## 1. Look it up ```bash node "${CLAUDE_SKILL_DIR}/../../scripts/spec-lookup.js" $ARGUMENTS ``` The index is built from the artifacts on every run, so it is never stale against an amendment that landed a minute ago. Variants when the exact id is unknown: `--list` (every id grouped by kind, `--list AC` for one kind), `--grep <text>` (ids whose label matches), `--files` (the spec file set with the read order). Add `--idea <slug>` when the workspace holds more than one spec. ## 2. Read around it, not just at it An id's own row rarely carries every constraint that applies to it: - **`AC-NN-n`** → also that feature spec's `bp:edge-cases` and `bp:states`; a criterion is often narrower than the behaviour around it. - **`fs-NN`** → `bp:trace` (what in the pack authorises this feature at all) and `bp:open-decisions` (what was deliberately delegated, each with a `DR-n`). - **`ST-<entity>-n`** → the whole `bp:state-machines` table: transitions are owned, and the interesting rule is usually which transitions are *absent*. - **`INV-n` / `JOB-n`** → the conflict-domain rows for the same entity; an invariant that holds within one feature can still break across two. - **`CAP-NN-n` / `EV-n`** → the subsystem's `bp:degradation` and `bp:budgets`