From e9a74e91b03e0edaa0b968e4ea8d71eded1faa31 Mon Sep 17 00:00:00 2001 From: Benjamin Borbe Date: Sat, 11 Jul 2026 10:17:25 +0200 Subject: [PATCH 1/2] =?UTF-8?q?auto-chain=20work-on=20commands=20into=20pl?= =?UTF-8?q?anning=20=E2=86=92=20execution?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- CHANGELOG.md | 4 ++++ commands/execute-task.md | 2 +- commands/plan-task.md | 2 +- commands/work-on-goal.md | 12 +++++++----- commands/work-on-task.md | 39 ++++++++++++++++++++++++++------------- commands/work-on.md | 12 ++++++------ 6 files changed, 45 insertions(+), 26 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index aefb2ca..b195605 100644 --- a/CHANGELOG.md +++ b/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 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` (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) diff --git a/commands/execute-task.md b/commands/execute-task.md index d08b0f5..d17412c 100644 --- a/commands/execute-task.md +++ b/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: diff --git a/commands/plan-task.md b/commands/plan-task.md index 931829c..d60ce64 100644 --- a/commands/plan-task.md +++ b/commands/plan-task.md @@ -141,7 +141,7 @@ Print: `⚠ Task improved to X/10. Phase unchanged. Remaining: . 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: diff --git a/commands/work-on-goal.md b/commands/work-on-goal.md index db417a1..debefd6 100644 --- a/commands/work-on-goal.md +++ b/commands/work-on-goal.md @@ -26,9 +26,13 @@ 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: ` 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: ` line and follow `commands/work-on-task.md` Phase 5 exactly. + + **Interactive mode — auto-chain the selected task:** invoke `Skill: vault-cli:plan-task ""`, then on `✅ Plan ready` invoke `Skill: vault-cli:execute-task ""` (flips `planning → execution`, prints first subtask + DoD). If plan-task reports unresolved gaps, stop at planning and print what remains — never force-execute. + + **Non-interactive / headless mode — signal only** (no chaining, since `plan-task` / `execute-task` may call `AskUserQuestion`): ``` ✅ Oriented: . Next: → /vault-cli:plan-task "" — validate the plan (Success Criteria + subtasks) @@ -36,8 +40,6 @@ The goal name is **required** — pass it as a quoted string. (Focus-page auto-d → /vault-cli:complete-task "" — 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 ""` → context + task selection +2. `/vault-cli:work-on-goal ""` → context + task selection, then auto-chain the selected task plan → execute (interactive) 3. Start work with full context Sibling commands: diff --git a/commands/work-on-task.md b/commands/work-on-task.md index 21b8287..c973497 100644 --- a/commands/work-on-task.md +++ b/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: " [--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,15 +56,15 @@ 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: '` — 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: ` line (verbatim). -2. **Print the signal** (substitute ``): +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: . Next: → /vault-cli:plan-task "" — validate the plan (Success Criteria + subtasks) @@ -72,16 +72,29 @@ Runs only after Phase 2 returned a `found` task — never on `not_found` (Phase → /vault-cli:complete-task "" — 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 ""`. 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 ready` → invoke `Skill: vault-cli:execute-task ""`. That re-checks the hard gates, flips `planning → execution`, and prints the first subtask + DoD reminder. 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. Print: + ``` + ⚠ Stopped at planning — plan not ready. Remaining: . + → Re-run /vault-cli:plan-task "" when ready, then /vault-cli:execute-task "". + ``` + - Any other terminal line (task closed, phase already past planning, `❌ …`) → relay plan-task's output verbatim; do NOT force execute. + +`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,7 +103,7 @@ 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 @@ -98,4 +111,4 @@ Task lifecycle: - 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). diff --git a/commands/work-on.md b/commands/work-on.md index 18a5799..708baf3 100644 --- a/commands/work-on.md +++ b/commands/work-on.md @@ -36,7 +36,7 @@ Auto-detects whether `` 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 `` 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 `` from the `📋 Task: ` 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 `` from the `📋 Task: ` line and follow `commands/work-on-task.md` Phase 5 exactly: **interactive mode auto-chains** `Skill: vault-cli:plan-task ""` → (on `✅ Plan ready`) `Skill: vault-cli:execute-task ""`, 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 auto-chains the selected task once `work-on-goal-assistant` surfaces it). ### 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` From fc0acc1ec964081bb807944adffc866da58f9d03 Mon Sep 17 00:00:00 2001 From: Benjamin Borbe Date: Sat, 11 Jul 2026 10:26:45 +0200 Subject: [PATCH 2/2] =?UTF-8?q?handle=20plan-task=20'=E2=9C=85=20Task=20sh?= =?UTF-8?q?arpened'=20terminal=20line=20in=20auto-chain?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- CHANGELOG.md | 2 +- commands/work-on-goal.md | 2 +- commands/work-on-task.md | 6 +++--- commands/work-on.md | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index b195605..7e17922 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -10,7 +10,7 @@ Please choose versions by [Semantic Versioning](http://semver.org/). ## 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 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` (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`) +- 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 diff --git a/commands/work-on-goal.md b/commands/work-on-goal.md index debefd6..faa7b54 100644 --- a/commands/work-on-goal.md +++ b/commands/work-on-goal.md @@ -30,7 +30,7 @@ The goal name is **required** — pass it as a quoted string. (Focus-page auto-d After the assistant returns (ends with `Ready to work on this task.`), resolve the selected task name from its `📋 Task: ` line and follow `commands/work-on-task.md` Phase 5 exactly. - **Interactive mode — auto-chain the selected task:** invoke `Skill: vault-cli:plan-task ""`, then on `✅ Plan ready` invoke `Skill: vault-cli:execute-task ""` (flips `planning → execution`, prints first subtask + DoD). If plan-task reports unresolved gaps, stop at planning and print what remains — never force-execute. + **Interactive mode — auto-chain the selected task:** invoke `Skill: vault-cli:plan-task ""`, then on either success line — `✅ Plan ready` (phase still `planning`) or `✅ Task sharpened` (task already past planning) — invoke `Skill: vault-cli:execute-task ""` (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`): ``` diff --git a/commands/work-on-task.md b/commands/work-on-task.md index c973497..c609919 100644 --- a/commands/work-on-task.md +++ b/commands/work-on-task.md @@ -77,13 +77,13 @@ Runs only after Phase 2 returned a `found` task — never on `not_found` (Phase a. **Plan.** Invoke `Skill: vault-cli:plan-task ""`. 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 ready` → invoke `Skill: vault-cli:execute-task ""`. That re-checks the hard gates, flips `planning → execution`, and prints the first subtask + DoD reminder. 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. Print: + - **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 ""`. 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: . → Re-run /vault-cli:plan-task "" when ready, then /vault-cli:execute-task "". ``` - - Any other terminal line (task closed, phase already past planning, `❌ …`) → relay plan-task's output verbatim; do NOT force execute. + - `❌ …` (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). diff --git a/commands/work-on.md b/commands/work-on.md index 708baf3..ba265af 100644 --- a/commands/work-on.md +++ b/commands/work-on.md @@ -50,7 +50,7 @@ Auto-detects whether `` is a task or goal, then dispatches to t ### 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.`, resolve `` from the `📋 Task: ` line and follow `commands/work-on-task.md` Phase 5 exactly: **interactive mode auto-chains** `Skill: vault-cli:plan-task ""` → (on `✅ Plan ready`) `Skill: vault-cli:execute-task ""`, 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 auto-chains the selected task once `work-on-goal-assistant` surfaces it). +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 `` from the `📋 Task: ` line and follow `commands/work-on-task.md` Phase 5 exactly: **interactive mode auto-chains** `Skill: vault-cli:plan-task ""` → (on `✅ Plan ready`) `Skill: vault-cli:execute-task ""`, 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: ` line and auto-chains that task's plan → execute. ### Phase 4 — Handle not_found (always create)