Auto-chain work-on commands into planning → execution

[bborbe]

What

/vault-cli:work-on-task, /vault-cli:work-on, and /vault-cli:work-on-goal now auto-chain into planning → execution in interactive mode, instead of only printing the next-step signal.

After orienting (status, guides, daily note), the commands:

1. Run Skill: vault-cli:plan-task — passes clean with no questions when the task already has Success Criteria + goal-reaching subtasks (e.g. recurring / runbook tasks), else asks its normal targeted questions.
2. On ✅ Plan ready → run Skill: vault-cli:execute-task — flips planning → execution, prints the first subtask + DoD.

The planning gate stays enforced: if plan-task finds real gaps, the chain stops at planning — it never force-executes an unready plan.

Non-interactive stays signal-only

Headless claude --print callers (the vault-cli work-on bootstrap) can't answer AskUserQuestion, so chaining would hang. Non-interactive mode keeps the current signal-only behavior.

Why

work-on-task previously oriented only, printing a plan → execute → complete signal the operator had to run by hand. For recurring runbook tasks (already fully planned) that's three manual steps to reach the first actionable subtask. Auto-chaining collapses orient → plan → execute into one command while keeping the gate real.

Files

• commands/work-on-task.md — canonical Phase 5 rewrite (auto-chain / signal fork)
• commands/work-on.md, commands/work-on-goal.md — flip their "Do NOT auto-invoke" referencer lines to auto-chain per Phase 5
• commands/plan-task.md, commands/execute-task.md — Integration wording sync
• CHANGELOG.md — Unreleased bullet

[ben-s-pull-request-reviewer]

Now I have enough context. Let me compile the review findings:

Review Findings

Correctness Issues Found

1. work-on-task.md Phase 5 — Missing ✅ Task sharpened branch

plan-task.md can output ✅ Task sharpened. Score: X/10. Phase unchanged (was <phase>). when the task's phase is already past planning. The work-on-task.md Phase 5 branching logic (lines 79-86) handles ✅ Plan ready and ⚠ Task improved.../score < 8, but has no branch for ✅ Task sharpened. This causes ✅ Task sharpened output to fall through to the relay-only branch, which prints plan-task's output verbatim and does NOT invoke execute-task. This means a task already in execution phase would NOT get the expected Phase 5 auto-chain behavior — it would stop at planning output instead of proceeding.

2. work-on-goal.md Phase 3 — Missing ✅ Task sharpened branch

Same issue as above. work-on-goal.md Phase 3 follows work-on-task.md Phase 5, but also lacks a branch for ✅ Task sharpened. When a goal-selected task is already past planning, the chain stops at plan-task output instead of continuing to execute-task.

3. Double plan-task/execute-task in goal route (architectural)

When work-on-goal-assistant is invoked (goal route), it internally calls work-on-task-assistant in Phase 6, which performs Jira assignment, status updates, guide discovery, and readiness nudges. If the selected task has phase: todo, work-on-task-assistant's Phase 7.5 readiness nudge correctly prompts to run plan-task. But work-on-task-assistant itself doesn't invoke plan-task/execute-task — the slash command does. The actual plan-task/execute-task chain runs when work-on-goal.md Phase 3 extracts the task name and calls Phase 5. However, work-on-task-assistant already set the task to in_progress in Phase 3, and the work-on-goal.md Phase 3 will then call plan-task which re-checks everything. This is architecturally wasteful but not incorrect — plan-task handles already-planning-phase tasks gracefully by skipping the entry contract flip and just sharpening.

Task name extraction (📋 Task: <name>) — verified consistent and reliable. Both work-on-task-assistant.md (line 239) and work-on-goal-assistant.md (line 142) use this exact format.

Skill invocation security — verified. Skill: vault-cli:plan-task "<name>" and Skill: vault-cli:execute-task "<name>" extract <name> from the structured 📋 Task: line. No raw user input reaches the Skill tool unmediated.

Tests — These are markdown command documentation files; no executable tests exist for them. The vault-cli project has integration tests (integration/cli_test.go) and scenario tests (scenarios/*.md) but none exercise the slash command auto-chain behavior.

--non-interactive parsing — correctly implemented in work-on-task.md (line 20-21). The flag is stripped before the assistant is invoked, and MODE is set correctly for Phase 4 (skip create) and Phase 5 (signal only vs chain).

{
  "verdict": "request-changes",
  "summary": "The auto-chain feature works correctly for the primary path (task route with `✅ Plan ready`), but has a gap in the terminal-line branching logic: `✅ Task sharpened` output from plan-task (when task phase is already past planning) falls through to relay-only, stopping the chain instead of continuing to execute-task. This affects both work-on-task.md Phase 5 and work-on-goal.md Phase 3. Task name extraction and Skill invocation format are verified correct.",
  "comments": [
    {
      "file": "commands/work-on-task.md",
      "line": 79,
      "severity": "major",
      "message": "Phase 5 branching logic handles `✅ Plan ready` and `⚠ Task improved...`/`score<8`, but has no branch for `✅ Task sharpened` (plan-task output when phase is already past planning). Without this branch, tasks in execution/ai_review/human_review phases would be relayed verbatim and NOT auto-chain to execute-task — the planning gate would incorrectly stop a task that's already cleared it. Add: `else if plan-task output starts with \"✅ Task sharpened\" → relay verbatim (already past planning, no need to re-invoke execute-task which is idempotent anyway).`"
    },
    {
      "file": "commands/work-on-goal.md",
      "line": 33,
      "severity": "major",
      "message": "Phase 3 follows work-on-task.md Phase 5 but inherits the same missing `✅ Task sharpened` branch. When the goal-selected task is already past planning, the chain stops at plan-task output instead of continuing to execute-task. Apply the same fix as work-on-task.md: add an else-if branch for `✅ Task sharpened` output that relays verbatim."
    },
    {
      "file": "commands/work-on.md",
      "line": 53,
      "severity": "minor",
      "message": "Phase 3 describes following work-on-task.md Phase 5 'exactly', which includes the auto-chain behavior. However, work-on-goal.md Phase 3 (which work-on.md dispatches to for the goal route) does not re-invoke work-on-task-assistant — it extracts the task name from the already-returned assistant output and calls Phase 5 directly. This is architecturally correct but worth noting in the Phase 3 description for clarity."
    }
  ],
  "concerns_addressed": [
    "correctness: Terminal-line detection gap confirmed — `✅ Task sharpened` case missing from branching logic in both work-on-task.md and work-on-goal.md",
    "correctness: Task name extraction from `📋 Task: <name>` line verified consistent and reliable across both work-on-task-assistant and work-on-goal-assistant",
    "correctness: work-on-goal goal route correctly chains the selected task (from assistant output) not the original goal name",
    "security: Skill invocation format verified — no raw user input reaches Skill tool; task name extracted from structured assistant output line",
    "correctness: work-on.md Phase 3 dispatches to work-on-task-assistant (task route) or work-on-goal-assistant (goal route), then chains Phase 5 — goal route chains selected task as intended",
    "tests: No executable tests for slash command auto-chain behavior — integration/smoke tests would require full Claude Code session simulation"
  ]
}

superseded by new automated review

[ben-s-pull-request-reviewer]

Based on my review of the diff, this is a documentation-only change — all modified files are markdown command files (commands/) and CHANGELOG.md. No Go code, no tests, no build artifacts were changed.

Review findings:

✅ Correctness concerns addressed:

• Planning gate enforcement (work-on-task.md:88-92): Correctly documents that if plan-task reports ⚠ Task improved … / score < 8 / unresolved gaps, the chain stops at planning — never force-executes
• Non-interactive fallback (work-on-task.md:58-66): Correctly documents that --non-interactive mode prints signal only, never chains, because plan-task/execute-task may call AskUserQuestion and would hang claude --print
• Success trigger lines (work-on-task.md:77): Correctly identifies the two success terminal lines that trigger execute-task: ✅ Plan ready (plan passed, phase still planning) and ✅ Task sharpened (task already past planning)
• Idempotency (work-on-task.md:79-81): execute-task is described as idempotent — flips phase or re-surfaces work block
• Lifecycle consistency: All four modified command files (work-on.md, work-on-task.md, work-on-goal.md, plan-task.md) and the integration section of execute-task.md now consistently describe the same workflow

✅ No issues found: No code changes to review. This is purely documentation updates describing a new interactive-mode auto-chain feature with proper non-interactive fallback and planning gate enforcement.

{
  "verdict": "approve",
  "summary": "Pure documentation change adding auto-chain behavior to work-on commands in interactive mode (plan → execute) with non-interactive fallback to signal-only. Planning gate enforcement is correctly documented — chain stops at planning if plan-task finds gaps. All lifecycle integration sections are consistently updated across the four affected command files.",
  "comments": [],
  "concerns_addressed": [
    "correctness: auto-chain stops at planning gate when plan-task finds gaps — documented in work-on-task.md Phase 5b",
    "correctness: non-interactive mode (headless) signals only, never chains — documented with --non-interactive flag handling",
    "correctness: plan-task integration wording synced across plan-task.md, execute-task.md, work-on-task.md",
    "correctness: execute-task only runs after plan-task success lines (✅ Plan ready or ✅ Task sharpened) — documented in work-on-task.md Phase 5b"
  ]
}