T-FWZH-task-work-detects-self-modifying-skill

Status: closed/done · Impact: low · Complexity: small

Parked pending the project-local skill extension mechanism (T-R4XL-project-local-skill-extension-mechanism). The proposed fix below hard-codes plugin/skills/*/SKILL.md path matching into the general /sdlc:task-work skill, which would only ever fire when the consuming project IS the SDLC plugin itself. That’s an SDLC-only carve-out in a general skill — wrong shape. Once the extension mechanism lands, this task is picked up by re-routing the behavior into a project-local extension (.claude/skills/task-work-extension/ or .claude/hooks/) rather than plugin/skills/task-work/SKILL.md.

task-work detects when a task touches its own SKILL.md and notes runtime/worktree split

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

Goal

When a task’s ## Files to touch list includes plugin/skills/task-work/SKILL.md (or any other skill’s SKILL.md that is currently executing), the operator can momentarily worry that they’re modifying the running skill mid-flight. They’re not — the runtime version is loaded from the global plugin path, not the worktree — but there is no in-band signal that surfaces this. A one-line note at Step 1 of /sdlc:task-work would eliminate the confusion. Cited by T-T879-task-work-uses-per-project-quality-checks.

Today

/sdlc:task-work Step 1 reads the task file and prints a summary but does not inspect ## Files to touch for self-references. From the originating post-mortem:

This task modifies the very skill (plugin/skills/task-work/SKILL.md) that drove its execution. Worked fine because the runtime version is loaded from the global plugin path, not the worktree — but there’s no mechanism that surfaces this to the orchestrator at task pickup. Fix: /sdlc:task-work could detect when a task’s ## Files to touch list includes its own SKILL.md and emit a one-line note at Step 1 explaining the runtime/worktree split, so the operator doesn’t worry about the recursion mid-flight.

Skill: plugin/skills/task-work/SKILL.md Step 1 (read and validate the task).

Proposed

Step 1 of /sdlc:task-work parses the ## Files to touch section of the incoming task. If any line references plugin/skills/task-work/SKILL.md (or, more generally, any SKILL.md path under plugin/skills/), emit a one-line informational note of the form:

note: this task modifies plugin/skills/<name>/SKILL.md — the runtime
version is loaded from ${CLAUDE_PLUGIN_ROOT}, not the worktree, so edits
take effect only after the merged PR propagates to the global plugin path.

The note is informational only. It does not block, downshift, or re-route the task.

Approach

In plugin/skills/task-work/SKILL.md Step 1, after the task is read and validated, scan ## Files to touch for paths matching plugin/skills/*/SKILL.md. Use a simple regex; this section is plain markdown bullets.
If any match is found, print the runtime/worktree note exactly once, listing the matched SKILL paths.
Keep the change inline in SKILL.md if it’s small (a step bullet plus the note template). If it grows past a few lines, extract a helper under plugin/skills/task-work/scripts/.

Files to touch

plugin/skills/task-work/SKILL.md — add the self-modifying-skill scan and one-line note to Step 1.

Acceptance criteria

AC-1: A task whose ## Files to touch lists plugin/skills/task-work/SKILL.md triggers the runtime/worktree note at Step 1 of /sdlc:task-work.
AC-2: A task that touches a different skill’s SKILL.md (e.g. plugin/skills/task-define/SKILL.md) also triggers the note, naming that skill.
AC-3: A task that does not touch any SKILL.md emits no extra output at Step 1.

Out of scope

Blocking or downshifting on self-modification. The note is purely informational.
Detecting indirect modifications (e.g. a task that edits a script imported by a SKILL). Direct SKILL.md references only.

Dependencies

none

Discovery context

Spawned by /sdlc:task-work post-mortem of T-T879-task-work-uses-per-project-quality-checks on 2026-05-20.

← Back to Tasks