T-DV8J-task-work-relevance-verifies-cli-flag-claims

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.

Goal

/sdlc:task-work Step 2’s relevance check only walks file paths extracted by a regex sweep — it doesn’t validate claims-about-flags the task body makes (e.g. “the script has no --dry-run flag yet”). That class of staleness slips through, and the implementer then discovers mid-execution that the Today section is wrong. Closing the gap means relevance check catches stale flag claims the same way it catches missing file paths. Surfaced during T-AWEM-sdlc-setup-seeds-hooks-gitignore-unignore.

Today

plugin/skills/task-work/SKILL.md Step 2 (Relevance check) extracts file paths via a regex and confirms each exists, plus command greps for cited symbols. There is no check for cited CLI flags. The originating task’s Today section asserted “the script also has no --dry-run flag yet; adding one is part of this task’s scope per AC-3” — but plugin/skills/setup/setup_planning.py already had --dry-run plumbed when the task was picked up. The relevance check passed silently; the operator discovered the mismatch only when looking at the script.

Direct quote from the post-mortem:

The Today section asserted “the script also has no --dry-run flag yet” — but the script already had --dry-run plumbed when this task was picked up. The relevance check in /sdlc:task-work Step 2 didn’t surface that mismatch because the regex sweep only looks at file paths, not at claims-about-flags.

Proposed

Step 2’s relevance check additionally extracts back-ticked CLI flags from the Today section (regex roughly \—[a-z][a-z0-9-]+`) and, for each flag paired with a cited script path, command greps the script for an add_argument(…”—”…)line. A claim shaped like "no—yet" that finds anadd_argument` hit in the cited script is flagged the same way a missing path is.

Approach

1. In Step 2 of task-work/SKILL.md, document a fourth bullet alongside the existing path / symbol / relevance_note checks: “extract back-ticked CLI flags from any sentence that says ‘no --X yet’ or ‘lacks --X’; for each, grep the nearest cited script path for add_argument(..."--<flag>"...). If a hit, surface the mismatch.”
2. Optionally factor the check into a small Python helper at plugin/skills/task-work/relevance_check.py so the regex + add_argument grep is uniform across runs. The helper would take the task path and the worktree root and emit a list of (claim, contradicting-evidence) pairs.
3. Update plugin/skills/task-work/SKILL.md to describe the new check and (if a helper exists) reference it.

Files to touch

Location	Kind	Change
plugin/skills/task-work/SKILL.md	modify	extend Step 2’s relevance-check
plugin/skills/task-work/relevance_check.py	new	(new, optional) —

Acceptance criteria

• AC-1: A task whose Today section says “the script has no --dry-run flag yet” while the cited script actually has add_argument("--dry-run", ...) is flagged by Step 2’s relevance check and surfaced to the user before status flips to in-progress.
• AC-2: A task with no flag claims (the common case) passes the new check silently — no false positives on every run.

Out of scope

• Auto-fixing the Today section. Flagging is enough; the operator decides whether to update the spec or proceed.
• Cross-language flag detection (argparse-only is fine for this project’s tooling).

Dependencies

• none

Discovery context

Spawned by /sdlc:task-work post-mortem of T-AWEM-sdlc-setup-seeds-hooks-gitignore-unignore on 2026-05-21. The /sdlc:task-work run discovered the stale “no —dry-run yet” claim after implementation began rather than during relevance check.

Review feedback (from PR #91, closed for refactor)

Reviewer (sksizer) pushback on the initial implementation: the proposed flag-claim detector reads as “very specific for verifying tasks that alter skills files — not a general task-flow improvement.” The concern is that bolting this narrow check directly into the upstream plugin/skills/task-work/ keeps the plugin general-purpose versus accreting checks that only fire for self-modifying-skill / self-modifying-tool tasks inside this repo.

Reviewer’s prompt for the redesign: “Is there a more general way we could do something like this? Perhaps by allowing project-level task-work or other skill plugins or behavior overrides?”

Implications for re-pickup post-refactor:

• Do not land the flag-claim check as a hardcoded fourth bullet in upstream plugin/skills/task-work/SKILL.md Step 2.
• Consider whether this check belongs as a project-local extension to task-work’s relevance check (under .claude/skills/) rather than upstream — or whether the upstream skill needs a generic extension/override seam that this and similar SDLC-on-SDLC dev checks can plug into.
• Either way, the upstream task-work skill should stay general; repo-specific staleness patterns (like “no --X yet” claims in Today sections of skill-editing tasks) live with the project, not the plugin.

---

← Back to Tasks