Auto-chain work-on commands into planning → execution

CHANGELOG.md

@@ -8,6 +8,10 @@ Please choose versions by [Semantic Versioning](http://semver.org/).
 * MINOR version when you add functionality in a backwards-compatible manner, and
 * PATCH version when you make backwards-compatible bug fixes.
 
+## Unreleased
+
+- change(workon): `/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, they run `plan-task` and — when the plan is good (`✅ Plan ready`, or `✅ Task sharpened` for a task already past planning) — `execute-task`, landing the task in `phase: execution` (or re-surfacing the work block if already there) with its first subtask shown. The planning gate stays enforced: if `plan-task` finds real gaps the chain stops at `planning` (never force-executes an unready plan). Non-interactive / headless invocations keep the signal-only behavior (no chaining, since `plan-task` / `execute-task` may call `AskUserQuestion`)
+
 ## v0.97.0
 
 - change(workon): `/vault-cli:work-on-task` and `/vault-cli:work-on` now always create the local task file on `not_found` instead of prompting first. `work-on-task` creates a task unconditionally (Jira tickets with no matching Obsidian file included); `work-on` free text asks only task-vs-goal with no "don't create" escape, and Jira IDs go straight to task. Non-interactive mode still creates nothing. Softened the "consent gate" wording in `work-on-task-assistant` accordingly (agent behavior unchanged — it still emits the `not_found:` verdict and never creates)

commands/execute-task.md

@@ -132,7 +132,7 @@ If `# Definition of Done` is absent or empty: omit the "When done, verify" block
 Task lifecycle:
 
 1. `/vault-cli:create-task` — capture (lenient)
-2. `/vault-cli:work-on-task` — orient (status + guides + daily note) + signal next steps
+2. `/vault-cli:work-on-task` — orient (status + guides + daily note), then auto-chain plan → execute (interactive)
 3. `/vault-cli:plan-task` — sharpen (5 hard gates); never flips phase
 4. **`/vault-cli:execute-task`** — the sole gate; flips planning → execution + prints first subtask + DoD reminder — this command
 5. Start work — while working, use any of:

commands/plan-task.md

@@ -141,7 +141,7 @@ Print: `⚠ Task improved to X/10. Phase unchanged. Remaining: <bullets>. Re-run
 Task lifecycle:
 
 1. `/vault-cli:create-task` — capture (lenient)
-2. `/vault-cli:work-on-task` — orient (status + guides + daily note)
+2. `/vault-cli:work-on-task` — orient (status + guides + daily note), then auto-chain into this command (interactive)
 3. **`/vault-cli:plan-task`** — sharpen (5 hard gates); never flips `planning → execution` — this command
 4. `/vault-cli:execute-task` — gate planning → execution; flips phase + prints first subtask + DoD reminder
 5. Start work — while working, use any of:

commands/work-on-goal.md

@@ -26,18 +26,20 @@ The goal name is **required** — pass it as a quoted string. (Focus-page auto-d
      prompt: 'Find goal: {goal_name} and prepare work context'
    ```
 
-3. **Signal next steps**
+3. **Drive to execution**
 
-   After the assistant returns (ends with `Ready to work on this task.`), resolve the selected task name from its `📋 Task: <name>` line and print the next-step signal — identical to `commands/work-on-task.md` Phase 5:
+   After the assistant returns (ends with `Ready to work on this task.`), resolve the selected task name from its `📋 Task: <name>` line and follow `commands/work-on-task.md` Phase 5 exactly.
+
+   **Interactive mode — auto-chain the selected task:** invoke `Skill: vault-cli:plan-task "<name>"`, then on either success line — `✅ Plan ready` (phase still `planning`) or `✅ Task sharpened` (task already past planning) — invoke `Skill: vault-cli:execute-task "<name>"` (idempotent: flips `planning → execution` and prints first subtask + DoD, or re-surfaces the work block if already in execution, or refuses if done). If plan-task reports unresolved gaps (`⚠ …` / score < 8), stop at planning and print what remains — never force-execute. On a plan-task `❌ …` hard error, relay it verbatim.
+
+   **Non-interactive / headless mode — signal only** (no chaining, since `plan-task` / `execute-task` may call `AskUserQuestion`):
    ```
    ✅ Oriented: <name>. Next:
    → /vault-cli:plan-task "<name>"     — validate the plan (Success Criteria + subtasks)
    → /vault-cli:execute-task "<name>"  — begin executing (flips planning → execution)
    → /vault-cli:complete-task "<name>" — close when done
    ```
 
-   Do NOT auto-invoke `plan-task` or `execute-task` — the operator runs each deliberately.
-
 The assistant returns:
 - Goal summary and domain
 - Domain-level operational guides (from semantic search or Glob fallback)
@@ -52,7 +54,7 @@ The assistant returns:
 
 Goal-first workflow:
 1. Pick goal name (from your notes, focus page, etc.)
-2. `/vault-cli:work-on-goal "<name>"` → context + task selection
+2. `/vault-cli:work-on-goal "<name>"` → context + task selection, then auto-chain the selected task plan → execute (interactive)
 3. Start work with full context
 
 Sibling commands:

commands/work-on-task.md

@@ -1,5 +1,5 @@
 ---
-description: Find task details, transition Jira, set status, track on daily note, discover guides, then signal the plan → execute → complete next steps
+description: Find task details, transition Jira, set status, track on daily note, discover guides, then auto-chain planning → execution (interactive) or signal the next steps (non-interactive)
 argument-hint: "<jira-id-or-text> [--non-interactive]"
 allowed-tools: [Task, AskUserQuestion, Skill, Bash(vault-cli *)]
 ---
@@ -20,7 +20,7 @@ Find task details and relevant operational guides before starting work. Delegate
    - Parse `$ARGUMENTS`: if it contains `--non-interactive` → set `MODE=non_interactive` and strip that flag token from the arguments; otherwise `MODE=interactive`. Parsing is self-contained here — it does not depend on any other command. Use the stripped arguments as the task identifier everywhere below — NEVER pass the flag token into the assistant prompt or task search.
    - If no argument remains after stripping: `❌ Pass a task identifier or description.` and STOP
 
-   **`MODE=non_interactive`** exists for headless callers — e.g. `vault-cli work-on`'s Claude bootstrap runs `claude --print`, which cannot answer `AskUserQuestion`, so an interactive gate would block until the session-start timeout. In this mode the command NEVER calls `AskUserQuestion` and Phase 4's auto-create is skipped (the interactive create-task skill cannot run headlessly). Phase 5 only prints the next-step signal (no interactive commands), so it runs identically in both modes.
+   **`MODE=non_interactive`** exists for headless callers — e.g. `vault-cli work-on`'s Claude bootstrap runs `claude --print`, which cannot answer `AskUserQuestion`, so an interactive gate would block until the session-start timeout. In this mode the command NEVER calls `AskUserQuestion` and Phase 4's auto-create is skipped (the interactive create-task skill cannot run headlessly). Phase 5 forks on mode: non-interactive prints the next-step signal only — it does NOT chain, because `plan-task` / `execute-task` may call `AskUserQuestion` and would hang a headless caller; interactive auto-chains through planning → execution.
 
 2. **Invoke work-on-task-assistant**
    ```
@@ -29,7 +29,7 @@ Find task details and relevant operational guides before starting work. Delegate
      prompt: 'Find details and guides for: {stripped arguments}'
    ```
 
-3. **Next-step signal (Phase 5).** If the assistant's report ends with `Ready to work on this task.` (the `found` case), continue to Phase 5 below. If the report contains the `not_found:` marker, skip Phase 5 and run Phase 4 (Handle not_found) instead.
+3. **Drive to execution (Phase 5).** If the assistant's report ends with `Ready to work on this task.` (the `found` case), continue to Phase 5 below (auto-chain in interactive mode, signal only in non-interactive). If the report contains the `not_found:` marker, skip Phase 5 and run Phase 4 (Handle not_found) instead.
 
 4. **Done**
 
@@ -56,32 +56,45 @@ The agent (dispatched in `## Process` step 2) emits a structured `not_found` ver
 4. **On create success** (create-task skill returns the new task file path or reports success): re-invoke `Task tool with subagent_type: 'vault-cli:work-on-task-assistant' prompt: 'Find details and guides for: <new task title>'` — same form as the Phase 2 invocation, but with the new task title. The agent's standard Phase 2–8 prep mutations then run against the just-created task.
    **On create failure or user cancel inside `vault-cli:create-task`** (the skill returns a non-success status, errors out, or the user aborts midway through its interactive prompts): print `❌ Task creation failed or was cancelled. No task created; no follow-up invocation.` and STOP — do NOT re-invoke `vault-cli:work-on-task-assistant`, do NOT retry the create.
 
-## Phase 5 — Signal next steps
+## Phase 5 — Auto-chain plan → execute (interactive) / signal (non-interactive)
 
-`work-on-task` **orients only**. It does NOT sharpen or gate — the operator drives those with explicit commands, so each lifecycle step stays a deliberate action. After the assistant returns a `found` task, print the next-step signal so the operator knows exactly what to run.
+After the assistant returns a `found` task, `work-on-task` **drives the task toward execution** rather than stopping at a signal. It orients, then plans, then — when the plan is clean — enters execution and surfaces the first subtask. It never forces execution past an unready plan: the planning gate is still real, just auto-invoked.
 
-Runs only after Phase 2 returned a `found` task — never on `not_found` (Phase 4 handles that branch). Text-only, so it is safe in `MODE=non_interactive`.
+Runs only after Phase 2 returned a `found` task — never on `not_found` (Phase 4 handles that branch).
 
 1. **Resolve the task name** from the assistant's `📋 Task: <name>` line (verbatim).
 
-2. **Print the signal** (substitute `<name>`):
+2. **Non-interactive mode (`MODE=non_interactive`) — signal only, no chain.** `plan-task` and `execute-task` may call `AskUserQuestion`; a headless `claude --print` caller cannot answer, so chaining would hang. Print the signal and STOP:
    ```
    ✅ Oriented: <name>. Next:
    → /vault-cli:plan-task "<name>"     — validate the plan (Success Criteria + subtasks)
    → /vault-cli:execute-task "<name>"  — begin executing (flips planning → execution)
    → /vault-cli:complete-task "<name>" — close when done
    ```
 
-`work-on-task` never mutates phase beyond the assistant's orient (`status → in_progress`, `phase → planning`). Plan → execute → complete are deliberate operator actions, each run when the operator is ready.
+3. **Interactive mode — auto-chain through the phases.**
+
+   a. **Plan.** Invoke `Skill: vault-cli:plan-task "<name>"`. It runs the planning gates itself — passes clean with no questions when the task already has Success Criteria + goal-reaching subtasks (e.g. recurring / runbook tasks), or asks its normal targeted questions when there are real gaps. Let it run its own fix loop.
+
+   b. **Branch on plan-task's terminal line:**
+      - **Plan is good → proceed to execute-task.** Two success lines both qualify: `✅ Plan ready` (plan just passed, phase still `planning`) OR `✅ Task sharpened` (the task was already past planning — plan-task validated but didn't move phase). In both cases invoke `Skill: vault-cli:execute-task "<name>"`. execute-task owns the phase logic and is idempotent: it flips `planning → execution` and prints the first subtask + DoD; or, when the task is already in `execution` / `ai_review` / `human_review`, re-surfaces the first unchecked subtask + DoD ("where was I?"); or, when the task is `done` / closed, prints its own refusal. The combined plan-task + execute-task output IS the final output — do NOT re-print the signal.
+      - `⚠ Task improved …` / score < 8 / gaps the operator left unresolved → do NOT execute (planning gate not cleared). Print:
+        ```
+        ⚠ Stopped at planning — plan not ready. Remaining: <bullets from plan-task>.
+        → Re-run /vault-cli:plan-task "<name>" when ready, then /vault-cli:execute-task "<name>".
+        ```
+      - `❌ …` (plan-task hard error — task not found, input error) → relay plan-task's output verbatim; do NOT invoke execute-task.
+
+`work-on-task` orients, then drives. In interactive mode a task with an already-complete plan lands in `phase: execution` with its first subtask surfaced, in one command. A task with real planning gaps stops at `planning` after plan-task's questions — the gate is enforced, not skipped. Non-interactive callers keep the deliberate signal (no chaining).
 
 ## Integration
 
 Task lifecycle:
 
 1. `/vault-cli:create-task` — capture (lenient)
-2. **`/vault-cli:work-on-task`** — orient (status + guides + daily note) + signal plan → execute → complete — this command
-3. `/vault-cli:plan-task` — sharpen (5 hard gates); never flips phase; run directly after work-on-task
-4. `/vault-cli:execute-task` — gate planning → execution; flips phase + prints first subtask + DoD reminder; run directly after plan-task
+2. **`/vault-cli:work-on-task`** — orient (status + guides + daily note), then auto-chain plan → execute (interactive) or signal (non-interactive) — this command
+3. `/vault-cli:plan-task` — sharpen (5 hard gates); never flips phase; auto-invoked by work-on-task (interactive), or run directly
+4. `/vault-cli:execute-task` — gate planning → execution; flips phase + prints first subtask + DoD reminder; auto-invoked by work-on-task when the plan is clean, or run directly
 5. Start work — while working, use any of:
    - `/vault-cli:update-task` — log completed work, sync to daily note / parent goal
    - `/vault-cli:task-status` — grouped-checkbox status (Success Criteria / Tasks / DoD) + next step
@@ -90,12 +103,12 @@ Task lifecycle:
 7. `/vault-cli:complete-task` — close task
 8. `/vault-cli:session-close` — verify session is safe to end (synced, committed, no orphaned state)
 
-`work-on-task` orients and stops, printing the next-step signal. The operator then runs `/plan-task`, `/execute-task`, and `/complete-task` as deliberate steps. The end state after `/work-on-task` is always `phase: planning` — the operator decides when to sharpen and when to start executing.
+In interactive mode `work-on-task` orients, then auto-chains: it runs `/plan-task` and, when the plan is clean, `/execute-task` — so the end state is `phase: execution` with the first subtask surfaced (or `phase: planning` if plan-task found real gaps). In non-interactive mode it orients and stops at `phase: planning`, printing the signal. `/complete-task` is always a deliberate operator step.
 
 ## Notes
 
 - No hardcoded Jira hostname, project key, or vault path — everything detected at runtime
 - Works in Personal, Brogrammers, Trading, or any future vault registered with `vault-cli config`
 - Each vault session loads a single Atlassian MCP under the canonical name `atlassian` (see vault-specific `mcp-*.json` configs); the agent uses `mcp__atlassian__*` regardless of which Jira instance is active
 - The agent searches; the slash command auto-creates the task file on `not_found` (interactive mode).
-- **Phase 5 is the next-step signal, not an auto-chain.** Phase 2 → Phase 5 covers the "I want to work on this task" intent by orienting (status, guides, daily note) and then printing the plan → execute → complete signal. `work-on-task` never invokes `plan-task` or `execute-task` — the operator runs each deliberately. This keeps every phase transition an explicit action and stops `execute-task` from being a silent no-op. Phase 5 is skipped on the `not_found` branch (Phase 4 handles that).
+- **Phase 5 auto-chains in interactive mode, signals in non-interactive.** Phase 2 → Phase 5 covers the "I want to work on this task" intent by orienting (status, guides, daily note), then driving: interactive invocations run `plan-task` and — when it reports `✅ Plan ready` — `execute-task`, landing the task in `phase: execution` with its first subtask surfaced. 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 invocations print the plan → execute → complete signal instead of chaining, because `plan-task` / `execute-task` may call `AskUserQuestion` and would hang a headless `claude --print` caller. Phase 5 is skipped on the `not_found` branch (Phase 4 handles that).

commands/work-on.md

@@ -36,7 +36,7 @@ Auto-detects whether `<name-or-jira-id>` is a task or goal, then dispatches to t
      subagent_type: 'vault-cli:work-on-task-assistant'
      prompt: 'Find details and guides for: {argument}'
    ```
-   Then continue with Phase 3 (next-step signal), identical to `commands/work-on-task.md` Phase 5.
+   Then continue with Phase 3 (drive to execution), identical to `commands/work-on-task.md` Phase 5.
 
 5. **If `goal`**: invoke the `vault-cli:work-on-goal-assistant` agent:
    ```
@@ -48,9 +48,9 @@ Auto-detects whether `<name-or-jira-id>` is a task or goal, then dispatches to t
 
 6. **If `not_found`**: run Phase 4 (Handle not_found).
 
-### Phase 3 — Next-step signal
+### Phase 3 — Drive to execution
 
-When the `work-on-task-assistant` (task route) or `work-on-goal-assistant` (goal route) report ends with `Ready to work on this task.`, print the plan → execute → complete signal exactly as `commands/work-on-task.md` Phase 5 — resolve `<name>` from the `📋 Task: <name>` line. Do NOT auto-invoke `plan-task` or `execute-task`; the operator runs each deliberately.
+When the `work-on-task-assistant` (task route) or `work-on-goal-assistant` (goal route) report ends with `Ready to work on this task.`, resolve `<name>` from the `📋 Task: <name>` line and follow `commands/work-on-task.md` Phase 5 exactly: **interactive mode auto-chains** `Skill: vault-cli:plan-task "<name>"` → (on `✅ Plan ready`) `Skill: vault-cli:execute-task "<name>"`, stopping at planning if plan-task reports unresolved gaps; **non-interactive / headless mode prints the plan → execute → complete signal only** (no chaining — `plan-task` / `execute-task` may call `AskUserQuestion`). This applies to both the task route and the goal route. The goal route does NOT re-invoke `work-on-goal-assistant` — it takes the selected task name from the assistant's already-returned `📋 Task: <name>` line and auto-chains that task's plan → execute.
 
 ### Phase 4 — Handle not_found (always create)
 
@@ -72,9 +72,9 @@ Branch on the Phase 1 classification path:
 Task lifecycle (extends `commands/work-on-task.md` Integration section):
 
 1. `/vault-cli:create-task` / `/vault-cli:create-goal` — capture
-2. **`/vault-cli:work-on`** — orient + auto-detect type + dispatch + signal next steps — this command
-3. `/vault-cli:plan-task` — sharpen (run directly after work-on)
-4. `/vault-cli:execute-task` — gate planning → execution (run directly after plan-task)
+2. **`/vault-cli:work-on`** — orient + auto-detect type + dispatch, then auto-chain plan → execute (interactive) or signal (non-interactive) — this command
+3. `/vault-cli:plan-task` — sharpen; auto-invoked by work-on (interactive), or run directly
+4. `/vault-cli:execute-task` — gate planning → execution; auto-invoked by work-on when the plan is clean, or run directly
 5. Work → `/vault-cli:update-task` / `/vault-cli:task-status`
 6. `/vault-cli:sync-progress` → `/vault-cli:complete-task`
 7. `/vault-cli:session-close`