T-IXV6-task-review-checks-ac-fixture-relevance

Status: closed/obsoleted · Impact: medium · Complexity: medium

Auto-generated from a /sdlc:task-work post-mortem. Review and promote to open/ready before picking up.

Goal

Acceptance criteria in tasks often name concrete fixture artifacts (other task slugs, PR numbers, branch names) that the AC is meant to be exercised against. Those references rot — the named fixture gets closed, merged, or deleted before the depending task is picked up — and the rot is only discovered at /sdlc:task-work pick-up time, which forces a triage step before any implementation can start. /sdlc:task-review already audits every unfinished task for relevance; extending it to also check that fixture references in ## Acceptance criteria are still in their expected state would catch this drift earlier and let task-review either downshift the task to planning/needs-definition or surface the rot for a human to refresh. Closing this gap shortens the inner loop on T-RDKI-extract-task-close-out-skill and any future task that pins ACs to live fixtures.

Today

From the originating post-mortem:

AC-2 and AC-3 fixture rot: the named tasks (add-epic-entity-task-depends-on-dependencies, build-import-planning-skill) were both already closed/done by the time this task was picked up, breaking the literal AC wording. Required a triage step and a user decision (synthetic fixtures) before any code was written.

plugin/skills/task-review/SKILL.md walks each unfinished task and updates impact, complexity, last_reviewed, and (sometimes) status, but it does not parse the ## Acceptance criteria section for references back to other task slugs or PR numbers, and it does not warn when such a reference no longer matches the real-world state. Today the rot is only surfaced at /sdlc:task-work pick-up time, where it costs a triage round-trip with the user.

Proposed

/sdlc:task-review includes a “fixture relevance” sub-check per task. Resolution is surfaced in the synthesis report, not via a new per-task interactive prompt — task-review only prompts the user for ambiguous closures today, and adding a new per-task prompt branch is heavier than the value of this check warrants:

Parse ## Acceptance criteria for inline references that look like fixture pins — other task slugs (YYYY-MM-DD-...), PR numbers (#N), branch names (feat/...), worktree paths (.claude/worktrees/...).
For each, verify the expected state. Task-slug references should resolve to a real task; their current status should match what the AC implicitly assumes.
When a mismatch is found, emit a fixture-rot flag on the task’s per-task review output AND surface it as a dedicated section in the synthesis report (e.g. “Tasks with fixture rot: N — refresh ACs via /sdlc:task-define <slug>”).

Approach

Add a fixture-reference extractor inline in plugin/skills/task-review/SKILL.md’s per-task sub-agent procedure (regex over ## Acceptance criteria; tolerant of markdown link shapes and inline backticks). Keep the extractor inline rather than a helper script — it’s a small regex pass and a helper would be premature.
For each extracted reference, resolve it: task slug → docs/planning/tasks/<slug>.md frontmatter; PR number → gh pr view; branch → git show-ref --verify. Cache resolutions per review pass.
Emit a fixture-rot: <list> line per affected task in the per-task return. Aggregate in the synthesis report as a dedicated “Tasks with fixture rot” section, suggesting /sdlc:task-define <slug> as the way to refresh.
Fixture corpus for AC tests lives at plugin/skills/task-review/tests/fixtures/. Each fixture is a small task tree with a deliberately-rotted AC; the runner (or a new plugin/skills/task-review/tests/run_evals.py) exercises the extractor and asserts the expected flag.

Files to touch

Location	Kind	Change
`plugin/skills/task-review/SKILL.md`	modify	add the fixture-relevance
`plugin/skills/task-review/tests/fixtures/` (new)	new	fixture
`plugin/skills/task-review/tests/run_evals.py` (new)	new	runner

Acceptance criteria

AC-1: Running /sdlc:task-review against a fixture corpus at plugin/skills/task-review/tests/fixtures/ that contains a task whose ## Acceptance criteria names a now-closed task slug emits a fixture-rot line on the per-task output and a dedicated “Tasks with fixture rot” section in the synthesis report. (auto via the new tests/run_evals.py)
AC-2: PR-number references in ACs (#123) that resolve to a non-existent PR are surfaced the same way. (auto)
AC-3: A task with no fixture references in its ACs is unaffected — no extra flags, no entry in the synthesis report’s fixture-rot section. (auto)

Out of scope

Auto-rewriting the AC text. The skill flags rot but leaves the fix to the user (or to a future, more aggressive task).
Generalizing the check to other sections (Goal / Approach / Files to touch). Start with ACs; extend later if useful.

Dependencies

none

Discovery context

Spawned by /sdlc:task-work post-mortem of T-RDKI-extract-task-close-out-skill on 2026-05-20.

← Back to Tasks