T-ZFE9-task-work-uses-worktree-skill-md

Status: closed/superseded · Impact: medium · Complexity: large

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

Goal

When /sdlc:task-work runs against a task that itself modifies plugin/skills/task-work/SKILL.md (or any plugin file the running skill is loaded from), the change in the worktree is invisible to the current run — the harness loaded the skill from ${CLAUDE_PLUGIN_ROOT} at session start, not from the worktree. As a result, AC-1 of T-KPJE-task-branches-use-task-prefix — “a fresh /sdlc:task-work run creates task/<basename>” — could not be verified in the same run that landed the change; the run itself created feat/<basename> because the loaded SKILL.md still said feat/. Closing this loop would let task-work bootstrap from the worktree so self-modifying changes are exercised end-to-end on the run that introduces them.

Today

/sdlc:task-work’s runtime SKILL.md is loaded from ${CLAUDE_PLUGIN_ROOT}/skills/task-work/SKILL.md at session start. When a task edits that file in the worktree, the edits are visible only to the post-merge propagation pass (next session pickup) — the running session continues to execute the pre-edit prose. The project-local hook .sdlc/skill-ext/task-work/step1-post.sh warns about this on pickup, but the warning is informational, not a fix.

[T-FWZH-task-work-detects-self-modifying-skill](/planning/tasks/task-work-detects-self-modifying-skill/) already landed the detection via the project-local hook. The remaining gap is execution: actually loading the worktree’s SKILL.md instead of (or in addition to) the global one.

Proposed

A bootstrap mechanism that lets the operator opt in to running task-work from the worktree’s SKILL.md when the task being worked modifies the skill. Concretely: the project-local hook (or a new skill-ext shape) checks whether the worktree’s plugin/skills/task-work/SKILL.md differs from ${CLAUDE_PLUGIN_ROOT}/skills/task-work/SKILL.md; if so, surface an AskUserQuestion offering to re-bootstrap the run with the worktree’s version (via claude /sdlc:task-work-from-worktree <slug> or equivalent — exact UX TBD by the implementer).

Approach

Best-guess; uncertain — the implementer should refine.

Audit how the Claude Code harness resolves skill files at session start. Document the lookup path and whether any opt-in override exists (env var, settings.json key, etc.).
If an override exists, the fix may collapse to a project-local hook setting it when the worktree’s SKILL.md differs from the global. If not, the fix is harness-side and needs an upstream ask to the Claude Code team.
Design the user-facing flow: an AskUserQuestion at task pickup (“the worktree modifies the task-work skill; run with the worktree’s version?”) with a clean re-invocation path on “yes”.

Files to touch

Location	Kind	Change
`.sdlc/skill-ext/task-work/step1-post.sh`	modify	extend the existing
`plugin/skills/task-work/SKILL.md`	modify	IF the upstream harness
`(new)`	new	`.claude/scripts/bootstrap_task_work_from_worktree.sh`

Acceptance criteria

AC-1: a task that modifies plugin/skills/task-work/SKILL.md can be picked up such that the run uses the worktree’s SKILL.md, not the global one — verifiable by adding a sentinel string to the worktree’s SKILL.md and watching it surface in the run’s behavior.
AC-2: the default behavior (no opt-in) is unchanged from today — bootstrap-from-worktree is strictly opt-in to avoid surprising operators who don’t want self-modifying skill runs.

Out of scope

Making bootstrap-from-worktree the default. The risk of a worktree-side bug bricking the current task-work run is real; opt-in is the right initial posture.
Generalising to all skills. The task-work skill is the motivating case (it’s the one mechanically self-modifying via the task workflow); other skills can adopt the same shape later if they show the same pattern.

Dependencies

T-FWZH-task-work-detects-self-modifying-skill — the detection-only precursor that already shipped.

Discovery context

Spawned by /sdlc:task-work post-mortem of T-KPJE-task-branches-use-task-prefix on 2026-05-22.

Dedup search (spawn-from-post-mortem)

Bullet: Currently-running task-work skill loaded from CLAUDE_PLUGIN_ROOT, not the worktree, so AC for new task-work behavior cannot be verified in the same run that lands the change. Bootstrap mechanism to load SKILL.md from worktree. Keywords searched: claude_plugin_root, currently-running, task-work, bootstrap, mechanism, worktree, behavior, verified Excluded: 2026-05-20-task-branches-use-task-prefix Top candidates (score / status / headline):

55 / closed/done / 2026-05-19-task-work-uses-per-project-quality-checks — Make /sdlc:task-work quality-check commands per-project configurable
47 / closed/done / 2026-05-20-task-work-sub-agent-verdict-contract-clarity — Tighten task-work sub-agent verdict contract so ensure-ready’s READY marker isn’t mistaken for task-work’s final verdict
46 / closed/done / 2026-05-21-project-local-skill-extension-mechanism — Project-local skill extension / shadowing mechanism
44 / closed/done / 2026-05-20-orchestrator-categorized-in-flight-limits — Replace orchestrator parallelism cap with categorized in-flight limits configurable in sdlc.yaml
41 / closed/done / 2026-05-19-extract-task-close-out-skill — Extract task-work Step 11 into /sdlc:task-close-out skill Decision: SPAWNED

Dedup search (spawn-from-post-mortem)

Bullet: The plugin path ${CLAUDE_PLUGIN_ROOT}scripts/run_quality_checks.py resolves to the installed plugin, not the worktree under development, which makes the new flags invisible to invocations that use that path until the PR merges. This is the known issue tracked by T-ZFE9-task-work-uses-worktree-skill-md. Not a new gap, but it bit me again during dogfood (my first capture attempt against ${CLAUDE_PLUGIN_ROOT} failed because the installed plugin didn’t know about —baseline-dir). Reinforces priority of that task. Keywords searched: task-work-uses-worktree-skill-md, claude_plugin_root, run_quality_checks, baseline-dir, development, invocations, reinforces, installed Excluded: 2026-05-21-run-quality-checks-isolates-pre-existing-drift Top candidates (score / status / headline):

10 / planning/draft / 2026-05-22-investigate-bash-multiline-arg-glue — Investigate intermittent Bash-tool multi-line argv-glue parsing oddity
8 / closed/done / 2026-05-21-skill-md-runtime-drift-audit — Audit /sdlc:task-work SKILL.md against per-project runtime conventions
7 / planning/needs-definition / 2026-05-21-task-define-flags-spec-shell-drift — task-define flags task-spec shell invocations that drift from cited SKILL.md
7 / planning/draft / 2026-05-22-task-work-uses-worktree-skill-md — task-work loads SKILL.md from the worktree, not ${CLAUDE_PLUGIN_ROOT}
5 / closed/done / 2026-05-19-co-locate-skill-specific-scripts — Co-locate skill-specific scripts under their skill dir; promote when shared Decision: LINKED-EXISTING 2026-05-22-task-work-uses-worktree-skill-md Rationale: Bullet contains an explicit wikilink to this very task (“known issue tracked by T-ZFE9-task-work-uses-worktree-skill-md”). Author explicitly identified this task as the tracking item. Override script’s noisy top candidate (investigate-bash-multiline-arg-glue, score 10 — unrelated) per the explicit author signal. The bullet describes the same gap (resolution of plugin scripts/skills from worktree vs ${CLAUDE_PLUGIN_ROOT}); this task is the right home. Linked to: 2026-05-22-task-work-uses-worktree-skill-md Originating task: 2026-05-21-run-quality-checks-isolates-pre-existing-drift

← Back to Tasks