codebyplan 1.13.28 → 1.13.30

package/templates/skills/cbp-round-complete/SKILL.md

@@ -0,0 +1,164 @@
+---
+scope: org-shared
+name: cbp-round-complete
+description: Reconcile user git-add approvals, complete the round, and route to the next step
+argument-hint: [chk-task-round | task-round]
+triggers: [cbp-task-check, cbp-standalone-task-check, cbp-round-input]
+effort: low
+---
+
+## Kind Detection
+
+Inspect the resolved identifier from argument parsing to determine the task kind:
+
+| Identifier shape | KIND |
+|-----------------|------|
+| `{task}-{round}` (2-segment, e.g. `45-2`) | `standalone` |
+| `{chk}-{task}-{round}` (3-segment, e.g. `141-3-1`) | `checkpoint` |
+| _(empty / free-text)_ | Check `get_current_standalone_task` first; if found → `standalone`. Else → `checkpoint` via `get_current_task`. |
+
+Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
+
+| Operation | `checkpoint` KIND | `standalone` KIND |
+|-----------|------------------|-------------------|
+| Get task | `get_current_task(repo_id)` | `get_current_standalone_task(repo_id)` |
+| Get rounds | `get_rounds(task_id)` | `get_standalone_rounds(standalone_task_id)` |
+| Update round | `update_round(round_id, ...)` | `update_standalone_round(standalone_round_id, ...)` |
+| Complete round | `complete_round(round_id, duration_minutes?)` | `complete_standalone_round(standalone_round_id, duration_minutes?, caller_worktree_id)` ⚠️ `caller_worktree_id` is REQUIRED for standalone |
+
+# Round Complete Command
+
+The **permission-gated finalizer** for a round that `/cbp-round-update` triaged as clean. It reconciles which files the **user** approved via `git add`, completes the round, and routes to the next step.
+
+This skill is gated by an `ask`-tier `Skill(cbp-round-complete)` permission rule in `settings.json`. **The permission prompt IS the user confirmation** — there is NO AskUserQuestion inside this skill. If the user declines the permission, the skill does not run: nothing is synced, no round is completed, and the user can stage files and re-invoke (directly or by re-running `/cbp-round-update`) when ready.
+
+## HARD GATE — Every Step Must Execute
+
+Step 2 (sync-approvals CLI) MUST exit 0. If it fails, do NOT proceed to Step 3. Before completing the round, verify:
+
+- [ ] `codebyplan round sync-approvals` exited 0
+
+If this is false: DO NOT proceed to Step 3.
+
+## Instructions
+
+### Step 1: Parse `$ARGUMENTS`
+
+Parse the argument using the canonical chk-task-round notation (see `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary"):
+
+| Shape | Regex | Resolves to |
+|-------|-------|-------------|
+| `{chk}-{task}-{round}` (e.g. `108-1-2`) | `^[0-9]+-[0-9]+-[0-9]+$` | Checkpoint-bound: CHK-{chk} TASK-{task} ROUND-{round} |
+| `{task}-{round}` (e.g. `45-2`) | `^[0-9]+-[0-9]+$` | Standalone: standalone TASK-{task} ROUND-{round} |
+| _(empty)_ | — | Use Kind Detection to find active task and latest round |
+
+Anything else is malformed — surface this error and stop:
+
+```
+round-complete: invalid argument `{value}`. Expected:
+  108-1-2  → CHK-108 TASK-1 ROUND-2 (checkpoint-bound)
+  45-2     → standalone TASK-45 ROUND-2
+  (empty)  → active task and latest round
+```
+
+Note that `108-1` is **valid** here — it resolves to standalone TASK-108 ROUND-1 per the 2-segment task-round form. To target a checkpoint-bound round, use the 3-segment form `108-1-2`.
+
+### Step 1.5: Get Current Task and Round
+
+Given the parse from Step 1:
+
+| Parse | Resolution path |
+|-------|-----------------|
+| `{chk}-{task}-{round}` | MCP `get_checkpoints(repo_id)` → filter `number === {chk}`. MCP `get_tasks(checkpoint_id)` → filter `number === {task}`. MCP `get_rounds(task_id)` → filter `number === {round}`. |
+| `{task}-{round}` | MCP `get_standalone_rounds` via `get_current_standalone_task` or direct task lookup → filter `number === {round}`. |
+| _(empty)_ | Use Kind Detection: checkpoint KIND → MCP `get_current_task(repo_id)` + `get_rounds(task_id)`; standalone KIND → MCP `get_current_standalone_task(repo_id)` + `get_standalone_rounds(standalone_task_id)`. |
+
+If no task found: `No active task. Nothing to complete.`
+
+### Step 2: Sync git diff + approvals via CLI
+
+Reconcile which files the user has approved by staging them. Run:
+
+```
+npx codebyplan round sync-approvals --round-id <round_id> --task-id <task_id>
+```
+
+The CLI auto-resolves the caller worktree id with the following precedence:
+1. `--caller-worktree-id <uuid>` override (if passed — skips all resolution)
+2. Per-device branch-keyed cache (`.codebyplan/worktree.local.json`)
+3. In-process tuple API call: `POST /worktrees/resolve` using `(device_id, repo_path, branch)`
+
+On the write path (non `--dry-run`), if the worktree id cannot be resolved the CLI **hard-fails with exit 1** and prints an actionable message. To pre-populate the cache:
+
+```
+npx codebyplan resolve-worktree --cache
+```
+
+If this worktree is not yet registered, run `npx codebyplan setup` first, then re-run `/cbp-round-complete`.
+
+The CLI parses `git status --short`, merges drift + staging + web-UI flag, and writes both round and task (forwarding `caller_worktree_id` on both writes so the server honors the feat-worktree lock). A **cleanly staged** file (`git add`-ed, no further unstaged changes) becomes `user_approved: true`.
+
+Read the stdout JSON: `{ added, stale_marked, reactivated, total_files }`.
+
+If the command exits non-zero, surface the stderr and STOP. Do NOT proceed to Step 3.
+
+This is the **single** explicit reconcile owned by this skill. (The `cbp-mcp-round-sync.sh` PostToolUse hook fires again right after Step 3's `complete_round` — see the note below — but that is the existing post-complete safety net, not a duplicate run to schedule here.)
+
+### Step 3: Complete the Round
+
+Calculate duration from the round's `started_at` to now in minutes.
+
+- **checkpoint KIND**: MCP `complete_round(round_id, duration_minutes)`.
+- **standalone KIND**: MCP `complete_standalone_round(standalone_round_id, duration_minutes, caller_worktree_id)`. ⚠️ `caller_worktree_id` is REQUIRED — resolve via `CALLER_WT=$(npx codebyplan resolve-worktree 2>/dev/null)`. If `CALLER_WT` is empty, surface this warning and ask the user to confirm before proceeding:
+
+  ```
+  Warning: could not resolve caller_worktree_id (npx codebyplan resolve-worktree returned empty).
+  The complete_standalone_round call may be rejected by the pre-guard. Proceed anyway? (yes / no)
+  ```
+
+  If the user confirms yes, proceed with `caller_worktree_id: ""`. If no, stop.
+
+`complete_round` / `complete_standalone_round` sets the round `completed`, locks all `file_changes` for the round (`approval_locked: true`), and returns `unapproved_files[]` + `unapproved_count`. Hold those for routing.
+
+> **PostToolUse hook note**: completing the round fires the `cbp-mcp-round-sync.sh` PostToolUse hook (matcher `mcp__codebyplan__complete_round`), which runs `sync-approvals` once more as a post-complete safety net for any approval drift between Step 2 and the lock. This is **expected** and is not double-processing — Step 2 is the pre-complete reconcile that makes `unapproved_count` accurate for routing; the hook is the existing catch-up. Note the hook matches `complete_round` only — `complete_standalone_round` is **not** covered by it (a pre-existing gap), so standalone rounds rely solely on this skill's Step 2 reconcile.
+
+### Step 4: Route
+
+**4a — Count files** — Display: `"Round N complete — Files: X total, Y approved, Z pending"`.
+
+**4b — Route on `unapproved_count`** (from Step 3's `complete_round` response):
+
+- **`unapproved_count === 0`** (every file user-approved): the user has signed off on the whole round.
+  - checkpoint KIND → auto-trigger `/cbp-task-check`.
+  - standalone KIND → auto-trigger `/cbp-standalone-task-check`.
+- **`unapproved_count > 0`** (user withheld approval on some files): the unstaged files are the signal that more work is wanted on them. Auto-trigger `/cbp-round-input` — its Step 2 deep analysis reads exactly those `user_approved === false` files and formulates the next round's requirements. This route is **independent of how many files are staged**; round-input is reachable even when zero files were staged.
+
+  - **Degenerate auto-loop guard**: if the just-completed round had `round.context.auto_loop_mode === true` AND it was a clean exit (no `improve_round_findings[]`, no hard-fail — which is why `/cbp-round-update` triaged it to round-complete in the first place), do NOT auto-trigger `/cbp-round-input`. Its auto-loop path transcribes the prior round's findings verbatim, and a clean round has none — auto-triggering would spin on an empty input. Instead surface the clean-exit note below and STOP; the user stages the pending files and re-invokes (or runs `/cbp-round-input` manually). Persist `round.context.round_complete.degenerate_auto_loop_exit = true`.
+
+    ```
+    ## Round N Complete — Auto-loop finished clean
+
+    **Files**: X total, Y approved, Z pending
+
+    Pending files passed all checks; they are just not staged. Stage them
+    (`git add <path>`) to finish the task, or run /cbp-round-input to start
+    another round.
+    ```
+
+Persist a breadcrumb on the round via `update_round` / `update_standalone_round` per KIND: `round.context.round_complete = { staged_count, unstaged_count, route, decided_at }`.
+
+## Key Rules
+
+- **Permission prompt = confirmation** — gated by `ask`-tier `Skill(cbp-round-complete)`. NEVER add an AskUserQuestion to confirm running; the harness prompt is the gate. A declined permission is a clean no-op.
+- **Step 2 (CLI) must exit 0** — if it fails, STOP before `complete_round`. The merge semantics are enforced by the CLI.
+- **NEVER ask the user to git add files** — Step 2 only reads staging status. **NEVER stage files** — Claude does not touch the git staging area; the user's `git add` is the approval signal.
+- **standalone KIND Step 3**: `caller_worktree_id` is REQUIRED for `complete_standalone_round` — always resolve and pass it.
+- **Auto-triggered by `/cbp-round-update`** (clean triage), or run manually by the user.
+
+## Integration
+
+- **Gates**: `ask`-tier `Skill(cbp-round-complete)` permission prompt — the harness confirms before the skill runs; a decline makes NO writes. There is no in-skill AskUserQuestion.
+- **Triggered by**: `/cbp-round-update` (auto, clean triage), or user manually
+- **Reads**: MCP `get_current_task` / `get_current_standalone_task`, `get_rounds` / `get_standalone_rounds` (per KIND); delegates git+approval sync to `npx codebyplan round sync-approvals`
+- **Writes**: MCP `complete_round` / `complete_standalone_round` (per KIND); `update_round` / `update_standalone_round` (`round_complete` breadcrumb); round+task `files_changed` written by the CLI
+- **Triggers**: `/cbp-task-check` (checkpoint KIND, all files approved), `/cbp-standalone-task-check` (standalone KIND, all files approved), `/cbp-round-input` (some files unapproved — fires independent of staging count)

package/templates/skills/cbp-round-end/SKILL.md

@@ -16,7 +16,7 @@ See `reference/inline-fallback.md` for full trigger table, procedure, and covera
 ## Pipeline
 
 ```
-/cbp-round-execute → /cbp-round-end → [code review + user decisions] → /cbp-round-update
+/cbp-round-execute → /cbp-round-end → [code review + auto-apply in-scope] → /cbp-round-update
 ```
 
 ## Identifier Notation
@@ -126,9 +126,13 @@ Wait for agent to complete. If the spawn fails for any reason, apply the inline-
 
 **If `status: 'no_findings'`:** show `### Code Review\nNo issues found. Code looks good.` and skip to Step 8.
 
-**If findings exist**, present them grouped by severity (table + per-finding details), then ask the user via AskUserQuestion which to fix: `all`, `1,2` (specific numbers), `none`, or `inline` (only when all findings qualify under the Trivial-Resolution Exception).
+**If findings exist**, present them grouped by severity (table + per-finding details).
 
-Example tables and the `inline` option gating spec: see `reference/findings-presentation.md`.
+**Under `auto_loop_mode === true`**: do NOT auto-apply here — Step 8's auto-loop path accepts all findings into `improve_round_findings[]` and defers the fixes to the next loop round. Skip straight to Step 8.
+
+**Manual mode**: **auto-apply all in-scope findings inline**. A finding is *in-scope* when every file it references is within the round's `files_changed[]`. The round-end orchestrator (main context — it has Edit/Write) applies these fixes directly; the `cbp-improve-round` agent stays read-only/advisory and never writes. Record each applied fix in `round.context.inline_fix_log` (findings indices, rationale, `fixes[]`, applied_at). After applying, re-run the verification scoped to the modified files (hook syntax check for `.sh`; `cbp-testing-qa-agent` for code) per `reference/findings-presentation.md`; if it fails, do NOT record the fix — treat the finding as out-of-scope instead. Findings that reference files OUTSIDE `files_changed[]` are **out-of-scope** — do NOT apply them; save them to `improve_round_findings[]` so Step 8 routes them to `/cbp-round-input` or a new task. There is no findings-decision AskUserQuestion — the round was already approved at the `/cbp-round-execute` permission prompt. The baseline-regression gate above is the ONLY user decision in this step.
+
+Example tables and the in-scope/out-of-scope classification: see `reference/findings-presentation.md`.
 
 ### Step 8: Route Based on Decisions
 
@@ -136,33 +140,31 @@ Example tables and the `inline` option gating spec: see `reference/findings-pres
 
 - Auto-accept ALL findings into `improve_round_findings[]` regardless of severity (the user opted into the loop).
 - Skip the polish-spiral stop-gate (auto-loop has its own cap-exhausted termination).
-- Skip the user findings-decision prompt.
+- Skip Step 7's inline auto-apply (findings are deferred to the next loop round, not applied this round).
 - Save findings via `update_round` exactly as in manual mode.
-- Auto-trigger `/cbp-round-update` immediately. round-update Step 6 will decide whether to spawn another round or exit clean (see cbp-round-update SKILL.md Step 6).
+- Auto-trigger `/cbp-round-update` immediately. round-update triages the round and either routes to `/cbp-round-input` (spawn another round) or `/cbp-round-complete` (clean exit) — see cbp-round-update SKILL.md Step 2/3.
 
 **Else (manual mode — flag absent or false):**
 
-Run the existing flow:
+Step 7 already auto-applied in-scope findings and logged them to `round.context.inline_fix_log`. Now record any out-of-scope findings and route:
 
-1. After round 2+, surface the polish-spiral stop-gate per `polish-spiral-stop-gate.md` (defer-to-followups vs continue).
-2. Surface the findings-decision AskUserQuestion (with optional `inline` per the gating rules in `reference/findings-presentation.md`).
-3. Save accepted/rejected findings to round context via MCP `update_round`:
+1. **Polish-spiral stop-gate** (round 2+ only): if this is round 2 or later AND the prior round also ended with code-review fixes, surface a one-line stop-gate via AskUserQuestion — *defer remaining polish to a follow-up task* vs *continue with another round*. This is a genuine user decision about scope (it guards against endless low-value polish loops), not a flow-control prompt. Skip on round 1.
+2. Save out-of-scope findings (those NOT auto-applied in Step 7) to round context via MCP `update_round`:
    ```json
    {
      "context": {
-       "improve_round_findings": [accepted findings],
-       "improve_round_rejected": [rejected findings with user reasons]
+       "improve_round_findings": [out-of-scope findings]
      }
    }
    ```
-4. Auto-trigger `/cbp-round-update`. round-update will see unapproved files and route to `/cbp-round-input`; `/cbp-round-input` picks up the findings from round context and includes them in the new round's requirements automatically.
+3. Auto-trigger `/cbp-round-update`. round-update triages the round: if out-of-scope findings (or a hard-fail) remain it routes to `/cbp-round-input` (which picks up the findings from round context and includes them in the new round's requirements automatically); if the round is clean it routes to `/cbp-round-complete` (the permission-gated finalizer that reconciles the user's `git add`s and completes the round).
 
 ## Key Rules
 
-- Claude NEVER git adds files — user does code review
+- Claude NEVER git adds files — user approval is via git staging at `/cbp-round-complete`
 - Auto-triggers `/cbp-round-update` after findings are handled
 - `/cbp-round-end` is auto-triggered by `/cbp-round-execute` (user does not call it directly)
-- Findings are **presented for user decision** — never auto-fix without user consent
+- In-scope findings are **auto-applied inline** by the round-end orchestrator (the round was already approved at the `/cbp-round-execute` permission); out-of-scope findings route to `/cbp-round-input`. `cbp-improve-round` stays read-only/advisory. Baseline-regression accept (Step 7 gate) stays a user decision — baselines are NEVER auto-accepted.
 
 ## Integration
 

package/templates/skills/cbp-round-end/reference/findings-presentation.md

@@ -1,6 +1,6 @@
 # Findings Presentation in `/cbp-round-end` Step 7
 
-When `improve-round` returns findings, Step 7 presents them grouped by severity and asks the user how to proceed.
+When `improve-round` returns findings, Step 7 presents them grouped by severity, then **auto-applies in-scope findings inline** (manual mode) or defers them to the next loop round (auto-loop mode). There is no findings-decision prompt.
 
 ## Example output
 
@@ -22,26 +22,16 @@ When `improve-round` returns findings, Step 7 presents them grouped by severity
 [description + suggested fix from agent]
 ```
 
-## AskUserQuestion options
+## Auto-apply model (manual mode)
 
-```
-Which findings should be fixed?
-- "all" — fix all findings in a new round
-- "1,2" — fix specific findings by number
-- "none" — skip all, proceed to round-update
-- "inline" — fix in THIS round before proceeding (only offered when all findings qualify under the Trivial-Resolution Exception below)
-- Or explain why specific findings are not issues
-```
-
-## "inline" option gating
+Step 7 auto-applies all **in-scope** findings inline — no user prompt. A finding is *in-scope* when every file it references is within the round's `files_changed[]`; it is *out-of-scope* otherwise.
 
-Only present the "inline" option when ALL pending findings simultaneously qualify under the **Trivial-Resolution Exception** (see subsection below):
+- **In-scope** → the round-end orchestrator (main context, has Edit/Write) applies the fix directly via `Edit` / `Write`, re-runs the verification commands (hook syntax check + `cbp-testing-qa-agent` scoped to modified files), and records it in `round.context.inline_fix_log = { findings: [ids], rationale, fixes: [...], applied_at: <ISO> }`. The `cbp-improve-round` agent stays read-only/advisory and never writes.
+- **Out-of-scope** → saved to `round.context.improve_round_findings[]`; Step 8 routes them to `/cbp-round-input` (next round) or a new task per the Infra Issue Absorption Contract below.
 
-1. Diff is comment-only, annotation-only, banner-only, or single-value rename — no logic, no control flow
-2. Each fix is under ~5 minutes of executor time
-3. Verification is automatic — the existing test/lint/audit pipeline confirms the change
+The only user decision in Step 7 is the **baseline-regression accept** gate (baselines are NEVER auto-accepted). Under `auto_loop_mode`, Step 7 does not auto-apply — all findings are accepted into `improve_round_findings[]` and deferred to the next loop round.
 
-If any finding fails these gates, omit the "inline" option entirely (revert to the 3-option prompt). When inline is chosen, apply the edits via direct `Edit`, re-run the verification commands (hook syntax check + `cbp-testing-qa-agent` scoped to modified files) and proceed to `/cbp-round-update` without spawning a new round. Document the decision in `round.context.inline_fix_log = { findings: [ids], rationale: "trivial-resolution exception", applied_at: <ISO> }` (mirrors the `bypass_log` shape from the Pipeline Bypass subsection below).
+The **Trivial-Resolution Exception** below still governs the deeper bypass cases (skipping executor / testing-qa / improve-round for ≤5-line non-logic corrective rounds); it is referenced by `/cbp-round-execute` and `/cbp-task-testing` for infra-issue absorption.
 
 ---
 

package/templates/skills/cbp-round-execute/SKILL.md

@@ -15,6 +15,10 @@ Execution and validation phase. Receives the approved plan from `/cbp-round-star
 /cbp-round-start → /cbp-round-execute → /cbp-round-end (auto)
 ```
 
+## Approval Model
+
+The `ask`-tier `Skill(cbp-round-execute)` permission prompt (configured in `settings.json`) is the **plan-approval gate** handed off from `/cbp-round-start`: confirming the permission approves the plan; declining it returns control to `/cbp-round-start` (re-plan with feedback) or `/cbp-round-input` (wrong direction). Once execution begins, the executors (`cbp-round-executor`, `cbp-mechanical-edits`) and the 3-INLINE / 3-SURVEY paths apply edits **automatically** — there is NO in-skill AskUserQuestion for approval. The only downstream user decisions are genuine ones: the dev-server start prompt (Step 4) and the baseline-regression accept gate (`/cbp-round-end` Step 7).
+
 ## Identifier Notation
 
 This skill operates on the **active** task/round resolved via MCP `get_current_task` / `get_rounds` and does not accept a positional identifier argument. Canonical chk-task-round notation is defined in `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary".

package/templates/skills/cbp-round-input/SKILL.md

@@ -24,7 +24,6 @@ Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
 | Get rounds | `get_rounds(task_id)` | `get_standalone_rounds(standalone_task_id)` |
 | Add round | `add_round(task_id, ...)` | `add_standalone_round(standalone_task_id, ...)` |
 | Update round | `update_round(round_id, ...)` | `update_standalone_round(standalone_round_id, ...)` |
-| Complete round | `complete_round(round_id, duration_minutes?)` | `complete_standalone_round(standalone_round_id, duration_minutes?, caller_worktree_id)` ⚠️ `caller_worktree_id` is REQUIRED for standalone |
 | Update task | `update_task(task_id, ...)` | `update_standalone_task(standalone_task_id, ...)` |
 
 # Round Input Command
@@ -33,7 +32,7 @@ Gathers input for a new round. Performs deep analysis of unapproved files, requi
 
 ## When Used
 
-- After `/cbp-round-update` routes here (unapproved files)
+- After `/cbp-round-update` triages a round as not-clean and routes here, or `/cbp-round-complete` routes here (files left unapproved after completing the round)
 - After `/cbp-round-execute` Step 6 routes here (structural failure or retry-exhausted hard-fail)
 - After `/clear` + `/cbp-todo` reloads context and triggers this
 - When user wants to start a new round with specific changes
@@ -78,8 +77,9 @@ If the argument matches the numeric regex, resolve the target task/round from DB
 **2f:** Extract testing-qa failures from latest round context (`context.testing_qa_output`)
 
 **2g:** Extract code review findings from latest round context (`context.improve_round_findings`).
-These are user-accepted findings from `improve-round` agent — bugs, logic errors, edge cases
-that the user agreed should be fixed. Include them as high-priority requirements.
+These are out-of-scope findings from the `improve-round` agent — bugs, logic errors, edge cases
+that round-end could not auto-apply inline (they reference files outside the prior round's
+`files_changed[]`). Include them as high-priority requirements.
 
 **2h:** Identify root causes — not "file X is wrong" but "requirement Y was not met because Z"
 
@@ -175,12 +175,12 @@ If this command is triggered **directly** (not via `/cbp-todo`) and no context i
 - **Deep analysis is MANDATORY** — always runs, even if arguments provided (for context)
 - **Analysis reads from DB (MCP)**, not conversation history
 - **Follow-up rounds get same depth as round 1** — no quick-fix behavior
-- **Never ask to git add** — file approval is handled by `/cbp-round-update`
+- **Never ask to git add** — user file approval (git staging) is reconciled by `/cbp-round-complete`
 - **Update all context locations** — task, checkpoint, and round should all have consistent information
 
 ## Integration
 
-- **Triggered by**: `/cbp-round-update` (auto, unapproved files), `/cbp-round-execute` (auto, on hard-fail after retry exhausted), `/cbp-todo` (after /clear), user manually
+- **Triggered by**: `/cbp-round-update` (auto, not-clean triage), `/cbp-round-complete` (auto, files left unapproved after completing the round), `/cbp-round-execute` (auto, on hard-fail after retry exhausted), `/cbp-todo` (after /clear), user manually
 - **Reads**: MCP `get_current_task` / `get_current_standalone_task`, `get_rounds` / `get_standalone_rounds` (per KIND), file contents (Read tool)
 - **Writes**: MCP `update_task` / `update_standalone_task` (context), `update_checkpoint` (context, if checkpoint KIND and needed)
 - **Triggers**: `/cbp-round-start` (auto)

package/templates/skills/cbp-round-start/SKILL.md

@@ -30,7 +30,7 @@ Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
 
 # Round Start Command
 
-Planning phase for a new round. Analyzes context, creates plan, gets user approval. NO execution or testing — those are separate commands.
+Planning phase for a new round. Analyzes context, creates a plan, then auto-triggers `/cbp-round-execute` — the `ask`-tier permission prompt on that skill IS the user's plan approval. NO execution or testing — those are separate commands.
 
 ## Inline-Fallback for Planner Spawn Failure
 
@@ -42,17 +42,17 @@ Procedure summary (pointer back to canonical):
 2. Walk the planner's documented Phase 0-8 checklist inline using `Read` / `Grep` / `Bash` / MCP `get_*` — `agents/cbp-task-planner.md` is the inline script. Phase 1.5 (Requirement Premise Verification) and Phase 4.7 (Migration Shape-Distribution Pre-Flight) are MANDATORY in fallback mode — these are the gates the agent uniquely enforces; skipping them produces unverified plans.
 3. Populate the planner's output contract (`approved_plan` shape: `files_to_modify[]`, `deliverables`, `specialist_needs`, `round_type`, `shape_distribution` if applicable, `context_summary`) with `mode: 'inline_fallback'`.
 4. Apply the pre-emptive-skip rule: when the same failure class fired in the previous spawn of this session, skip the spawn attempt entirely and go straight to inline.
-5. Continue the skill — do NOT abort. The plan still requires user approval at Step 9.
+5. Continue the skill — do NOT abort. Step 9 auto-triggers `/cbp-round-execute`; the `ask`-tier permission prompt on that skill is the user's plan approval (see Step 8).
 
 Inline-fallback is NOT a quality downgrade trapdoor — Phase 1.5 row-by-row verification is mandatory. A fallback plan that skipped premise verification is a regression caught by the next session's cbp-improve-round.
 
 ## Pipeline
 
 ```
-/cbp-round-start (planning) → [user approval] → /cbp-round-execute (auto)
+/cbp-round-start (planning) → /cbp-round-execute (ask-tier permission = plan approval)
 ```
 
-**Auto-loop mode**: when `round.context.auto_loop_mode === true` flows in from `/cbp-round-input`, Step 6 (Q&A) and Step 8 (user approval) skip user prompts. See cbp-round-update SKILL.md Step 4 (auto-loop decision) and cbp-round-end SKILL.md Step 8 for the full contract.
+**Auto-loop mode**: when `round.context.auto_loop_mode === true` flows in from `/cbp-round-input`, Step 6 (Q&A) is skipped and Step 8's `/cbp-round-execute` permission is auto-approved. See cbp-round-update SKILL.md Step 3b (auto-loop decision) and cbp-round-end SKILL.md Step 8 for the full contract.
 
 ## Instructions
 
@@ -176,7 +176,7 @@ input:
 
 Wait for planner output.
 
-### Step 8: User Approval
+### Step 8: Present Plan
 
 Present the plan to user:
 
@@ -208,24 +208,21 @@ Present the plan to user:
 
 Single-wave plans present the existing flat plan view (no wave table) — backward compatible.
 
-**If `auto_loop_mode === true`**: skip the AskUserQuestion below; auto-approve the plan. Log `round.context.plan_approval = { mode: "auto_loop", auto_approved_at: <ISO> }`. Surface a one-line note in the chat output: `"Auto-approved under auto_loop_mode (round N of cap C)"` so the user can see the loop is active. Proceed to Step 9.
+**Plan approval is the `ask`-tier `Skill(cbp-round-execute)` permission prompt** — there is NO approve/needs-changes/wrong AskUserQuestion here. After presenting the plan, proceed to Step 9, which auto-triggers `/cbp-round-execute`; the harness then shows the `ask`-tier permission prompt, and confirming it IS the user's go-ahead on the plan.
 
-**Else (manual mode)**, ask user via AskUserQuestion with explicit options:
+**Denied-execute handling** — if the user declines the `/cbp-round-execute` permission, the plan does not run. Treat the decline as "the plan must change":
 
-1. **Yes** — approve and start execution
-2. **No — needs changes** — user provides feedback, revise the plan (re-run Step 7 with feedback)
-3. **No — totally wrong** — discard plan, return to `/cbp-round-input` for new requirements
+- **Minor changes**: collect the user's feedback, re-spawn `cbp-task-planner` with it as a constraint (re-run Step 7), present the revised plan, and re-trigger `/cbp-round-execute`.
+- **Wrong direction**: save the rejection reason to round context and auto-trigger `/cbp-round-input` for new requirements.
 
-**If "Yes"**: proceed to Step 9.
-**If "Needs changes"**: collect user feedback, re-spawn `cbp-task-planner` with feedback as constraint, present revised plan, ask again.
-**If "Totally wrong"**: save rejection reason to round context, auto-trigger `/cbp-round-input`.
+**If `auto_loop_mode === true`**: the loop auto-approves — log `round.context.plan_approval = { mode: "auto_loop", auto_approved_at: <ISO> }`, surface a one-line note `"Auto-approved under auto_loop_mode (round N of cap C)"`, and proceed to Step 9 (the `/cbp-round-execute` permission is auto-approved under the loop).
 
 ### Step 9: Auto-trigger Round Execute
 
-On approval, save planner output to round context via MCP `update_round` / `update_standalone_round` per KIND, then trigger `/cbp-round-execute`.
+Save planner output to round context via MCP `update_round` / `update_standalone_round` per KIND, then trigger `/cbp-round-execute`. The `ask`-tier permission prompt on `/cbp-round-execute` is the user's plan approval (see Step 8).
 
 ```
-Plan approved. Starting execution phase...
+Starting execution phase...
 ```
 
 ## Key Rules