T-BKRP-task-ensure-ready-verifies-named-consuming-skills
Status: closed/superseded · Impact: low · Complexity: small
Auto-generated from a /sdlc:task-work post-mortem. Review and
promote to open/ready before picking up.
Tasks that name a list of “consuming skills” in their Approach (e.g.
“cross-reference from task-work, task-close-out, task-new,
milestone-new, entities-migrate, import-planning”) occasionally
drift from the codebase — a skill in the list doesn’t actually
satisfy the criterion the task is asserting (e.g. doesn’t author
multi-line commits, doesn’t produce model-derived prose, etc.).
T-7UIC-investigate-sandbox-multiline-commit-denial surfaced
two of six named skills (task-new, milestone-new) that don’t
actually author multi-line commits, but the implementer only caught
this by manually grepping each skill. Catching this kind of
spec/codebase drift before implementation would save a round of
investigation and stop wrong-named skills from accumulating in the
spec.
/sdlc:task-ensure-ready runs a readiness gate before
/sdlc:task-work starts implementation, but the gate’s disqualifiers
(implementation-ready.md) only cover file-path and symbol-name
existence — not “every skill named under a criterion still matches
that criterion.” A spec that lists task-new as a “skill that
authors multi-line commits from model output” passes the gate today
because task-new exists; it does not pass because task-new
actually authors multi-line commits.
Proposed
Section titled “Proposed”/sdlc:task-ensure-ready runs a lightweight grep-based check when
the Approach section names a list of skills under a criterion the
task asserts (e.g. “skills that author multi-line commits”, “skills
that emit completion notes”). If a named skill’s SKILL.md doesn’t
match the criterion’s regex, the gate flags it as a
definition_gap. Pattern recognition is best-effort — the gate
doesn’t have to parse arbitrary natural language; it can hard-code
recognizers for the criteria the project has actually used
(starting with “authors multi-line commits” → mktemp.*sdlc-commit\|git commit -F).
Approach
Section titled “Approach”- Identify the small set of “consuming-skill” criteria the project
actually uses across
docs/planning/tasks/. Today: “authors multi-line commits” is the documented case; there may be one or two others. - Add a recognizer to
task-ensure-readythat scans the Approach section for skill-list shapes (e.g. inline-code skill names liketask-work,entities-migrate) under one of the known criteria. - For each named skill, grep its SKILL.md for the criterion’s
pattern. Flag mismatches as a
definition_gap.
Files to touch
Section titled “Files to touch”| Location | Kind | Change |
|---|---|---|
plugin/skills/task-ensure-ready/SKILL.md | new | describe the new |
plugin/skills/task-ensure-ready/ensure_ready_mutate.py | new | (or a new |
plugin/skills/task-ensure-ready/tests/run_evals.py | modify | fixture |
Acceptance criteria
Section titled “Acceptance criteria”- AC-1: A task spec that names
task-newunder “skills that author multi-line commits from model output” is flagged by/sdlc:task-ensure-readyasdefinition_gaprather than passing. - AC-2: A task spec that correctly names only commit-authoring skills under the same criterion passes the gate.
- AC-3: An eval fixture covers both cases under
plugin/skills/task-ensure-ready/tests/.
Out of scope
Section titled “Out of scope”- General natural-language understanding of the Approach section — the recognizer can hard-code the small set of known criteria.
- Verifying lists in body sections other than Approach.
Dependencies
Section titled “Dependencies”- none
Discovery context
Section titled “Discovery context”Spawned by /sdlc:task-work post-mortem of T-7UIC-investigate-sandbox-multiline-commit-denial on 2026-05-21.