implementing-blockslisted

## When this skill applies The target repo is a Spec Kit project: `.specify/` exists at repo root and at least one `specs/<NNN>-<feature>/tasks.md` is present with `#### Block <X>` PR-stack headings. One invocation implements **one** block — the unit of work that maps cleanly to one PR per [`reviewing-changes`](../reviewing-changes/SKILL.md) and the project's PR-size gate. If the repo is not a Spec Kit project, use [`running-tdd-cycles`](../running-tdd-cycles/SKILL.md) + [`reviewing-changes`](../reviewing-changes/SKILL.md) + [`committing-changes`](../committing-changes/SKILL.md) directly instead. ## Argument shape The caller passes one of: - A specific block name verbatim from a `####` heading — e.g. `Block A — Certificate codec (PR-A)`. - A task-ID range — e.g. `T005-T007, T027-T029`. - `next` or empty — let the skill analyse `tasks.md` and propose the next ready block. Anything else is treated as a semantic filter; if it's ambiguous, present the partial matches via `AskUserQuestion`. ### Filter validation contract (security) The argument MUST be validated against `tasks.md` content before it reaches the Phase 2 subagent prompt. Validation rules — applied in order: 1. **Empty / `next`** → accept. 2. **Exact match against a parsed `#### Block <X> — <name>` heading** in the active `tasks.md` → accept and use that verbatim heading text as the canonical `<FILTER>`. 3. **Task-ID range** matching `^T\d{3}(-T\d{3})?(,\s*T\d{3}(-T\d{3})?)*$` whose every ID exists in the act