T-PZW5-task-work-step-6-inline-impl-fallback

Status: closed/done · Impact: medium · 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 6 (“Delegate implementation to a sub-agent”) hard-assumes the parent agent has the Agent (sub-agent dispatch) tool. When the skill is invoked from a context that lacks Agent — e.g. a resumed-mid-flight task-work, a manual operator without sub-agent grants — Step 6 has no documented fallback and the parent either errors out or improvises silently. Closing this gap removes an ambient prerequisite that today’s prose leaves implicit.

Today

Step 6 prose in ${CLAUDE_PLUGIN_ROOT}/skills/task-work/SKILL.md (line 230):

Launch a sub-agent with the Agent tool. Brief it like a colleague who just walked in: …

No mention of what to do if Agent is unavailable. The skill’s allowed-tools: frontmatter does declare Agent (line 15), but a parent context can still reach Step 6 without Agent actually present — e.g. a resumed task-work session in a harness that doesn’t honour the declaration, or a manual operator invocation. That is exactly what happened during the resumed implementation of T-RNW9-task-close-out-verifies-pr-on-main: the parent had no Agent available, silently improvised inline implementation, and the run succeeded. Step 8’s spawn-from-post-mortem dispatch makes the same hard Agent assumption (SKILL.md line 351). Both need an explicit fallback contract so the silent improvisation becomes a documented path.

Proposed

Document an inline-implementation fallback for Steps 6 and 8. Add a ### Fallback: inline implementation subsection to Step 6 describing:

When the fallback applies: the Agent tool is unavailable in the current context.
What the parent must still do: run Step 7 quality checks, run Step 8 spawn-from-post-mortem (with the same fallback for the Agent dispatch there), and emit the same completion marker as the sub-agent path would have.
What discipline is required: treat each AC as a discrete commit, do not skip the quality-check loop, do not collapse the post-mortem into an inline summary.

Step 8 references the same fallback subsection (DRY — single source of fallback truth) so the contract covers both delegation points consistently.

Approach

Edit plugin/skills/task-work/SKILL.md Step 6: append a ### Fallback: inline implementation subsection with the three bullets above (when, what, discipline).
Edit Step 8’s spawn-from-post-mortem dispatch in the same file: add a one-line pointer (“If Agent is unavailable, follow the Step 6 fallback contract”) so the same path covers post-mortem spawning.
Add an entry to plugin/skills/task-work/invariants.yaml pinning the literal heading ### Fallback: inline implementation so future edits can’t silently drop the fallback.
Verify by running the existing invariants linter against the updated SKILL.md.

Files to touch

plugin/skills/task-work/SKILL.md — append fallback subsection to Step 6; one-line pointer in Step 8.
plugin/skills/task-work/invariants.yaml — pin the fallback heading.

Acceptance criteria

AC-1: plugin/skills/task-work/SKILL.md Step 6 contains a ### Fallback: inline implementation subsection enumerating when it applies, what the parent must still do, and what discipline is required.
AC-2: Step 8 references the Step 6 fallback contract (single source of fallback truth).
AC-3: plugin/skills/task-work/invariants.yaml pins the literal heading ### Fallback: inline implementation and the invariants linter passes against the updated SKILL.md.

Out of scope

Adding the Agent tool to every skill’s frontmatter. This task is about Step 6’s contract, not about a global allowed-tools audit (which is its own task).
Re-architecting Step 6 to not need sub-agents. The sub-agent dispatch is desirable for context isolation; this task only closes the “what if it’s unavailable” gap.

Dependencies

none

Discovery context

Spawned by /sdlc:task-work post-mortem of T-RNW9-task-close-out-verifies-pr-on-main on 2026-05-20.

Post-mortem

Captured by /sdlc:task-work on 2026-05-22. PR: pending.

Acceptance criteria coverage

AC-1: auto — invariants linter (plugin/scripts/lint_skill_prose.py) passed against the updated SKILL.md, which verifies the ### Fallback: inline implementation H3 exists in Step 6.
AC-2: auto — command grep for “Step 6 fallback contract” in SKILL.md matches the new Step 8 pointer line.
AC-3: auto — invariants.yaml carries the new required_phrases entry pinning ### Fallback: inline implementation; linter passed.

What worked

The skill’s invariants-linter mechanism gave a one-shot, machine-checkable home for the AC-3 pin without any new tooling.
This run executed Step 6 via the inline fallback being added by the task itself — a satisfying validation that the documented fallback path is enough to ship a real change.

Friction and automation gaps

Step 5b’s start_task.py rebase surfaced a frontmatter merge conflict between the verify-stamp commit (set readiness_verified_at to the new ISO timestamp) and the start-commit (bumped last_reviewed to today and changed status). The conflict resolution is mechanical — keep both updated values — and could be auto-resolved by start_task.py rather than dropped on the operator. Task 2026-05-21-start-task-handles-frontmatter-rebase-cleanly already exists for this exact gap, so no new task needed. → T-2QXZ-start-task-handles-frontmatter-rebase-cleanly
The /sdlc:task-work skill prose Step 6 said “Launch a sub-agent with the Agent tool” with no fallback documented; the inline implementation this run performed was exactly the friction the task was created to close. Closed by this PR.

Spawned follow-up tasks

T-2QXZ-start-task-handles-frontmatter-rebase-cleanly — linked (existing planning/draft task already covers the start_task.py rebase auto-resolve gap).

← Back to Tasks