codebyplan 1.13.53 → 1.13.55

package/templates/skills/cbp-build-cc-mode/SKILL.md

@@ -38,7 +38,7 @@ A skill that carries a `model:` line is a **gap** — remove it unless a deliber
 
 ### Agents — `model:` + `effort:`
 
-Default `model: sonnet` + `effort: xhigh`. Fifteen of the 17 authoring agents take the default (`cbp-cc-executor`, `cbp-database-agent`, `cbp-improve-claude`, `cbp-improve-round`, `cbp-research`, `cbp-round-executor`, `cbp-security-agent`, `cbp-task-check`, `cbp-task-planner`, `cbp-testing-qa-agent`, `cbp-e2e-playwright`, `cbp-e2e-maestro`, `cbp-e2e-tauri`, `cbp-e2e-vscode`, `cbp-e2e-xcuitest`). The other two are exceptions:
+Default `model: sonnet` + `effort: xhigh`. Fifteen of the 17 authoring agents take the default (`cbp-cc-executor`, `cbp-database-agent`, `cbp-improve-claude`, `cbp-research`, `cbp-round-builder`, `cbp-security-agent`, `cbp-stripe-agent`, `cbp-verify-reviewer`, `cbp-round-planner`, `cbp-testing-qa-agent`, `cbp-e2e-playwright`, `cbp-e2e-maestro`, `cbp-e2e-tauri`, `cbp-e2e-vscode`, `cbp-e2e-xcuitest`). The other two are exceptions:
 
 | agent                | model  | effort | reason                                                                              |
 | -------------------- | ------ | ------ | ----------------------------------------------------------------------------------- |

package/templates/skills/cbp-build-cc-settings/reference/cbp-permission-policy.md

@@ -22,7 +22,7 @@ Precedence is `deny > ask > allow`; arrays union across scopes (managed/user/pro
 
 ### `allow` — the autonomous workflow surface
 
-- **Non-lifecycle, non-shipment `/cbp-*` skills** — authoring (`cbp-build-cc-*`), frontend (`cbp-frontend-*`), git (`cbp-git-*`, `cbp-merge-main`, `cbp-refresh-infra`), round work (`cbp-round-check`/`-end`/`-input`/`-start`/`-update` — `cbp-round-update` is autonomous triage that only reads round state and routes to `cbp-round-complete` or `cbp-round-input`, so it runs without a prompt), setup/configure (`cbp-setup-*`, `cbp-ship-configure`, `cbp-supabase-*`), task prep (`cbp-task-check`/`-create`/`-start`/`-testing`, `cbp-standalone-task-check`/`-testing`), planning (`cbp-checkpoint-plan`/`-update`), plus `cbp-session-start` and `cbp-todo`. Invoking a skill is the intended mode of operation; the gated side effects happen inside via the Bash/MCP tools the skill calls, which carry their own tiering. The lifecycle/state-transition and plan-approval skills are the exception — they live in `ask` (next section).
+- **Non-lifecycle, non-shipment `/cbp-*` skills** — authoring (`cbp-build-cc-*`), frontend (`cbp-frontend-*`), git (`cbp-git-*`, `cbp-merge-main`, `cbp-refresh-infra`), round work (`cbp-round-plan`, `cbp-verify` — `cbp-verify` is the autonomous verify stage that runs deterministic gates, proves execution, spawns the fresh-context reviewer, and routes to `cbp-round-complete` or `cbp-round-plan`, so it runs without a prompt), setup/configure (`cbp-setup-*`, `cbp-ship-configure`, `cbp-supabase-*`), task prep (`cbp-task-create`/`-start`, `cbp-standalone-task-check`/`-testing`), planning (`cbp-checkpoint-plan`/`-update`), plus `cbp-session-start` and `cbp-todo`. Invoking a skill is the intended mode of operation; the gated side effects happen inside via the Bash/MCP tools the skill calls, which carry their own tiering. The lifecycle/state-transition and plan-approval skills are the exception — they live in `ask` (next section).
 - **All `mcp__codebyplan__*` reads** (`get_*`, `list_*`, `search_*`, `health_check`, `lookup_symbol`, `resolve_library_id`, `get_chunk`).
 - **Routine workflow-write MCP tools** the pipeline calls many times per task: create/update/complete checkpoint, task, and round; session log + session-state writes; `create_worktree`, `add_library`, `flag_stale_chunk`, `update_server_config`, `update_eslint_repo_config`, `update_task_template`. Gating these with `ask` would make the autonomous workflow unusable.
 - **Read/safe CLI commands** (both `codebyplan X` and `npx codebyplan X`): `whoami`, `resolve-worktree`, `statusline`, `ports`, `tech-stack`, `eslint`, `round`, `help`, `--version`.
@@ -30,8 +30,8 @@ Precedence is `deny > ask > allow`; arrays union across scopes (managed/user/pro
 ### `ask` — the deliberate confirm-gate
 
 - **Production-shipment skills**: `cbp-ship`, `cbp-ship-main`, `cbp-checkpoint-end` — these promote/deploy to production, so they prompt even in an otherwise auto-allowed setup.
-- **Lifecycle / state-transition skills**: `cbp-checkpoint-start`, `cbp-checkpoint-create`, `cbp-checkpoint-check`, `cbp-checkpoint-complete`, `cbp-round-complete`, `cbp-session-end`, `cbp-task-complete`, `cbp-standalone-task-create`, `cbp-standalone-task-start`, `cbp-standalone-task-complete` — these open or close checkpoints, tasks, rounds, and sessions (advancing workflow state in the database), so they stop for explicit confirmation rather than running autonomously. `cbp-round-complete` is the permission-gated round finalizer (reconciles the user's `git add`s, completes the round, routes onward); its `ask` prompt replaces the in-skill confirmation that used to live in `cbp-round-update` — which is now an autonomous, `allow`-tier triage step.
-- **Plan-approval gate**: `cbp-round-execute` — the round plan is approved by confirming this `ask` prompt rather than via an in-skill AskUserQuestion. `cbp-round-start` runs its planning Q&A, then hands off to `cbp-round-execute`; the permission prompt is the user's go/no-go on the plan.
+- **Lifecycle / state-transition skills**: `cbp-checkpoint-start`, `cbp-checkpoint-create`, `cbp-checkpoint-check`, `cbp-checkpoint-complete`, `cbp-round-complete`, `cbp-session-end`, `cbp-finalize`, `cbp-standalone-task-create`, `cbp-standalone-task-start`, `cbp-standalone-task-complete` — these open or close checkpoints, tasks, rounds, and sessions (advancing workflow state in the database), so they stop for explicit confirmation rather than running autonomously. `cbp-round-complete` is the permission-gated round finalizer (reconciles the user's `git add`s, completes the round, routes onward); its `ask` prompt is the human gate downstream of `cbp-verify` — the autonomous, `allow`-tier verify stage whose triage routes here.
+- **Plan-approval gate**: `cbp-round-build` — the round plan is approved by confirming this `ask` prompt rather than via an in-skill AskUserQuestion. `cbp-round-plan` runs its planning Q&A, then hands off to `cbp-round-build`; the permission prompt is the user's go/no-go on the plan.
 - **Destructive / admin MCP tools**: `delete_session_log`, `delete_worktree`, `create_repo`, `release_assignment`. (The launch and member-admin tools were dropped from the MCP surface in CHK-180 — those concerns are web-app only now.)
 - **Mutating / external / clobber-risk CLI commands** (both prefixes): `setup`, `login`, `logout`, `upgrade-auth`, `config` (can overwrite committed `.codebyplan/` files), `branch` (rewrites branch config), `ship`, `claude` (`install`/`update`/`uninstall` overwrite `.claude/`).
 
@@ -53,11 +53,11 @@ A skill invokes the next skill via the Skill tool at the appropriate routing bra
 ### How the human gate works
 
 - **`allow`-tier** skill: the harness auto-fires it silently when the triggering skill invokes it.
-  No permission prompt. Use for safe, routine-flow skills (e.g. `cbp-task-testing`,
-  `cbp-round-input`) where the trigger condition already encodes the human intent.
+  No permission prompt. Use for safe, routine-flow skills (e.g. `cbp-verify`,
+  `cbp-round-plan`) where the trigger condition already encodes the human intent.
 - **`ask`-tier** skill: the harness pauses and shows a permission prompt before the skill runs.
   **That prompt IS the human gate** — it replaces the old "Next: /cbp-X, run it yourself"
-  manual directive. Use for lifecycle/state-transition skills (e.g. `cbp-task-complete`,
+  manual directive. Use for lifecycle/state-transition skills (e.g. `cbp-finalize`,
   `cbp-checkpoint-check`) where a deliberate confirmation is still desirable.
 
 This means:
@@ -70,7 +70,7 @@ This means:
 
 The `cbp-skill-context-guard.sh` PreToolUse hook denies heavy close-out skills when the
 context window exceeds `CBP_CONTEXT_WARN_TOKENS` (default 200 000 tokens). The heavy allowlist
-is: `cbp-round-execute`, `cbp-task-testing`, `cbp-standalone-task-testing`,
+is: `cbp-round-build`, `cbp-verify`, `cbp-standalone-task-testing`,
 `cbp-checkpoint-check`, `cbp-checkpoint-end`.
 
 When the guard fires, it directs the model to run `/cbp-clear-prep` instead. The flow is:

package/templates/skills/cbp-build-cc-skill/SKILL.md

@@ -81,7 +81,7 @@ A Task-pattern skill that must only run on explicit user confirmation is a **per
 
 - MUST carry `disable-model-invocation: true` — the model cannot invoke it; only the user can (via `/skill-name`).
 - Any upstream skill that auto-triggers it MUST instead emit a `Next: /skill-name` directive and STOP — model invocation of a `disable-model-invocation` skill is blocked at the runtime level.
-- Canonical example: `/cbp-round-complete` (the round finalizer). `/cbp-round-update` routes a clean triage via a `Next: /cbp-round-complete` directive and stops — it cannot invoke round-complete directly.
+- Canonical example: `/cbp-round-complete` (the round finalizer). `/cbp-verify` routes a clean round via a `Next: /cbp-round-complete` directive and stops — it cannot invoke round-complete directly.
 
 ### Step 5 — Fill the frontmatter
 

package/templates/skills/cbp-build-cc-skill/reference/cbp-quality.md

@@ -79,14 +79,14 @@ A skill should do one thing in the pipeline. If a skill both plans AND executes,
 
 | Wrong                                   | Right                                                        |
 | --------------------------------------- | ------------------------------------------------------------ |
-| `/cbp-round` (plans + executes + tests) | `/cbp-round-start` → `/cbp-round-execute` → `/cbp-round-end` |
+| `/cbp-round` (plans + executes + tests) | `/cbp-round-plan` → `/cbp-round-build` → `/cbp-verify` |
 
 ### Pipeline Clarity
 
 If the skill is part of a chain, show it:
 
 ```
-/cbp-round-start (planning) → /cbp-round-execute (ask-tier permission = plan approval)
+/cbp-round-plan (planning) → /cbp-round-build (ask-tier permission = plan approval)
 ```
 
 ### Approval Gates

package/templates/skills/cbp-build-cc-skill/reference/fork-eligibility.md

@@ -4,7 +4,7 @@
 parent conversation and, per the runtime, **runs in the background by default**. It is
 isolation for a *whole skill*, not a way to delegate one sub-step. A forked body therefore
 cannot drive the main pipeline: it can't `AskUserQuestion`, can't auto-trigger another
-skill, and can't run an inline-fallback that the orchestrator depends on.
+skill, and can't run the deterministic fallback path the orchestrator depends on.
 
 So forking only helps a narrow shape of skill. The canonical eligible example is
 [examples/fork-skill.md](../examples/fork-skill.md): a single self-contained analytical task
@@ -19,20 +19,20 @@ A skill is **fork-eligible** only when ALL hold:
 3. It does **not route** — no auto-trigger of another skill, no close-out directive that must
    fire in the main context.
 4. It does **not fan out** — it does not spawn multiple subagents and coordinate them.
-5. It has **no inline-fallback** contract the orchestrator relies on.
+5. It has **no deterministic fallback** path the orchestrator relies on.
 
 Fail any one → the skill stays **inline** (main context). Inline skills still get clean
 context isolation the right way: by delegating their heavy step to a dedicated **agent**
-(e.g. `cbp-task-check`, `cbp-improve-round`, `cbp-round-executor`). The agent is the
+(e.g. `cbp-verify-reviewer`, `cbp-round-builder`). The agent is the
 isolation boundary; the skill stays in the main thread to orchestrate, route, and interact.
 
 ## When NOT to use `context: fork` (the disqualifying patterns)
 
 | Pattern | Why it can't fork | Example skills |
 |---------|-------------------|----------------|
-| **fan-out** | spawns multiple agents in parallel and coordinates them | `cbp-round-execute`, `cbp-checkpoint-check`, `cbp-map-architecture`, `cbp-refresh-arch-map` |
-| **spawn-then-route** | spawns one agent, then `AskUserQuestion` / auto-triggers the next skill / runs inline-fallback | `cbp-task-check`, `cbp-standalone-task-check`, `cbp-round-start`, `cbp-round-end`, `cbp-checkpoint-plan` |
-| **inline-by-design** | interactive Q&A or stepwise writes that must stay in the main context | `cbp-task-create`, `cbp-task-complete`, `cbp-round-update`, `cbp-merge-main` |
+| **fan-out** | spawns multiple agents in parallel and coordinates them | `cbp-round-build`, `cbp-checkpoint-check`, `cbp-map-architecture`, `cbp-refresh-arch-map` |
+| **spawn-then-route** | spawns one agent, then `AskUserQuestion` / auto-triggers the next skill | `cbp-verify`, `cbp-standalone-task-check`, `cbp-round-plan`, `cbp-checkpoint-plan` |
+| **inline-by-design** | interactive Q&A or stepwise writes that must stay in the main context | `cbp-task-create`, `cbp-finalize`, `cbp-merge-main` |
 | **consumed-inline** | invoked *by* an agent (e.g. round-executor) and applies fixes synchronously into that context | `cbp-frontend-design`, `cbp-frontend-ui`, `cbp-frontend-ux` |
 | **doc-ref-only** | mentions subagents/fork only as documentation; runs inline authoring | the `cbp-build-cc-*` authoring skills, `cbp-supabase-migrate` |
 
@@ -40,28 +40,25 @@ isolation boundary; the skill stays in the main thread to orchestrate, route, an
 
 Every skill whose `SKILL.md` touches the subagent/fork boundary — by spawning a subagent, by
 being invoked inline by an agent, or by documenting the feature — was classified against the
-eligibility test. **Result: 0 of 25 are fork-eligible** — none were migrated, because every
+eligibility test. **Result: 0 of 22 are fork-eligible** — none were migrated, because every
 one either already isolates heavy work in a dedicated agent (the correct boundary) or depends
 on inline orchestration/interaction that a background fork would break.
 
 | Skill | Pattern | Fork-eligible |
 |-------|---------|:---:|
-| cbp-round-execute | fan-out | no |
+| cbp-round-build | fan-out | no |
 | cbp-checkpoint-check | fan-out | no |
 | cbp-map-architecture | fan-out | no |
 | cbp-refresh-arch-map | fan-out | no |
-| cbp-round-start | spawn-then-route | no |
-| cbp-round-end | spawn-then-route | no |
-| cbp-task-check | spawn-then-route | no |
+| cbp-round-plan | spawn-then-route | no |
+| cbp-verify | spawn-then-route | no |
 | cbp-standalone-task-check | spawn-then-route | no |
 | cbp-checkpoint-plan | spawn-then-route | no |
-| cbp-round-update | inline-by-design | no |
 | cbp-task-create | inline-by-design | no |
 | cbp-standalone-task-create | inline-by-design | no |
-| cbp-task-complete | inline-by-design | no |
+| cbp-finalize | inline-by-design | no |
 | cbp-standalone-task-complete | inline-by-design | no |
 | cbp-merge-main | inline-by-design | no |
-| cbp-task-testing | inline-by-design | no |
 | cbp-standalone-task-testing | inline-by-design | no |
 | cbp-frontend-design | consumed-inline | no |
 | cbp-frontend-ui | consumed-inline | no |

package/templates/skills/cbp-checkpoint-check/SKILL.md

@@ -127,11 +127,11 @@ Aggregate the files touched across all tasks (reusing Step 4's deduplicated tabl
    Continue to Step 6.
 
 5. **On fail** (any framework `f`: `e2e_outputs[f].status === 'failed'` OR `e2e_outputs[f].test_results.failed > 0`): build a failure summary from `e2e_outputs[*].test_results.failures[]` aggregated and grouped by `category`. Surface via `AskUserQuestion`:
-   - **(a) Create fix-task in CHK-{NNN} (recommended)** — run `codebyplan task create` (CLI write-through; break-glass: MCP `create_task`) with `checkpoint_id=current_checkpoint_id`, `title="Fix checkpoint-level e2e failures (CHK-{NNN})"`, `requirements` containing the detailed failure breakdown (category counts, files involved, pages broken, screenshot paths from `e2e_outputs[*].screenshots[]`), AND `context: { source_checkpoint_id, e2e_failure_summary: { category_counts, pages_broken, screenshot_paths }, fix_type: "checkpoint_e2e" }` so downstream `cbp-task-planner` can verify failure premises. Per `cbp-round-end` reference `findings-presentation.md` "Infra Issue Absorption Contract — Resolve-in-Current-Scope by Default", checkpoint-level e2e failures absorb into the active checkpoint — not standalone.
+   - **(a) Create fix-task in CHK-{NNN} (recommended)** — run `codebyplan task create` (CLI write-through; break-glass: MCP `create_task`) with `checkpoint_id=current_checkpoint_id`, `title="Fix checkpoint-level e2e failures (CHK-{NNN})"`, `requirements` containing the detailed failure breakdown (category counts, files involved, pages broken, screenshot paths from `e2e_outputs[*].screenshots[]`), AND `context: { source_checkpoint_id, e2e_failure_summary: { category_counts, pages_broken, screenshot_paths }, fix_type: "checkpoint_e2e" }` so downstream `cbp-round-planner` can verify failure premises. Per `cbp-verify` reference `findings-presentation.md` "Infra Issue Absorption Contract — Resolve-in-Current-Scope by Default", checkpoint-level e2e failures absorb into the active checkpoint — not standalone.
    - **(b) Surface as warning only — proceed to checkpoint-end** — append `| Checkpoint E2E | warning | N failures (deferred) |` to Step 5 QA Summary; continue to Step 6.
    - **(c) Halt — review manually** — STOP and wait for the user.
 
-   See `cbp-round-end` reference `findings-presentation.md` "Infra Issue Absorption Contract — Infra-Class Issue Catalog" row "Checkpoint-level e2e failure" for the routing rationale.
+   See `cbp-verify` reference `findings-presentation.md` "Infra Issue Absorption Contract — Infra-Class Issue Catalog" row "Checkpoint-level e2e failure" for the routing rationale.
 
 ### Step 6: User Discussion
 

package/templates/skills/cbp-checkpoint-create/SKILL.md

@@ -87,7 +87,22 @@ This is the first identity-stamping point — when claiming, passing `worktree_i
 
 Read `.codebyplan/git.json` `branch_config.production` (default `"main"`) as `BASE`. codebyplan repos are main-only — never create or branch from a `development`/integration branch.
 
-Compute the slug deterministically:
+**8.1 — Reuse the cloud-created branch when present.** When the repo is GitHub-connected, the CHK-207 `create-feat-branch` Edge Function fires on the Step 7 row INSERT, creates `feat/CHK-{NNN}-<slug>` on origin, and writes `branch_name` back to the checkpoint row. Creating a second, differently-slugged branch here orphans the cloud one — so re-read the row first:
+
+```bash
+sleep 5  # give the INSERT webhook a moment to write branch_name back
+npx codebyplan sync 2>/dev/null || true
+BRANCH=$(jq -r '.branch_name // empty' ".codebyplan/state/checkpoints/{checkpoint-id}.json" 2>/dev/null)
+```
+
+(Break-glass: MCP `get_checkpoints` and read the row's `branch_name`.) If `BRANCH` is non-empty, check out the existing remote branch and skip 8.2 entirely — do NOT push (it already exists on origin) and do NOT persist `--branch-name` (the Edge Function already recorded it):
+
+```bash
+git fetch origin "$BRANCH"
+git checkout -b "$BRANCH" --track "origin/$BRANCH"
+```
+
+**8.2 — Fallback: create the branch locally.** Only when `BRANCH` is empty (repo not GitHub-connected, or the webhook hasn't landed). Compute the slug deterministically:
 
 ```bash
 SLUG=$(codebyplan slug "{checkpoint title}")

package/templates/skills/cbp-checkpoint-update/SKILL.md

@@ -44,9 +44,9 @@ Given the parse from Step 0.5:
 | `{chk}` | Scan `.codebyplan/state/checkpoints/*.json` for `number === {chk}` (local-first; if missing/stale run `npx codebyplan sync` once; break-glass: MCP `get_checkpoints`). |
 | _(empty)_ | Read `.codebyplan/state/session/current.json` (with worktree_id from `npx codebyplan resolve-worktree`) to find the active checkpoint (fallback: MCP `get_current_task`). If no active checkpoint, scan local state for `pending` checkpoints (fallback: MCP `get_checkpoints` filtered by `pending`). |
 
-### Step 1.5: Detect Entry Context (from `/cbp-task-complete` expand path)
+### Step 1.5: Detect Entry Context (from `/cbp-finalize` expand path)
 
-When invoked with a preamble naming `Triggered from /cbp-task-complete with intent: expand`, the user just completed the last task in the checkpoint and chose Option B "Expand checkpoint with more tasks" per `task-complete/reference/checkpoint-done-branching.md`.
+When invoked with a preamble naming `Triggered from /cbp-finalize with intent: expand`, the user just completed the last task in the checkpoint and chose Option B "Expand checkpoint with more tasks" per `task-complete/reference/checkpoint-done-branching.md`.
 
 In that case, lead with explicit guidance:
 
@@ -111,4 +111,4 @@ Otherwise, no follow-up directive — the user is back in control.
 
 - **Reads**: `.codebyplan/state/session/current.json`, `checkpoints/<id>.json` (local-first; `npx codebyplan sync` if stale; break-glass: MCP `get_current_task`, `get_checkpoints`)
 - **Writes**: `codebyplan checkpoint update --id <id> [--field value ...]` (CLI write-through; break-glass: MCP `update_checkpoint`)
-- **Triggered by**: User directly, OR `/cbp-task-complete` Step 9c (expand path) — see `task-complete/reference/checkpoint-done-branching.md`
+- **Triggered by**: User directly, OR `/cbp-finalize` Step 9c (expand path) — see `task-complete/reference/checkpoint-done-branching.md`

package/templates/skills/cbp-clear-continue/SKILL.md

@@ -14,7 +14,7 @@ handoff file so a stale snapshot never misleads a future session.
 ## When Used
 
 - After running `/clear` following a `/cbp-clear-prep` capture
-- The user is ready to re-run the heavy skill (cbp-round-execute, cbp-task-testing,
+- The user is ready to re-run the heavy skill (cbp-round-build, cbp-verify,
   cbp-standalone-task-testing, cbp-checkpoint-check, cbp-checkpoint-end) that was denied
 
 ## Instructions
@@ -62,7 +62,7 @@ so even if the skill fails the handoff is gone and the user starts fresh next ti
 
 Invoke the skill from `next_action` via the Skill tool, passing any recorded arguments.
 
-Example: if `next_action` is `/cbp-round-execute 217-2-1`, invoke `Skill(cbp-round-execute)`
+Example: if `next_action` is `/cbp-round-build 217-2-1`, invoke `Skill(cbp-round-build)`
 with args `217-2-1`.
 
 If the context window is STILL above threshold after `/clear` (unusual — compact may help),

package/templates/skills/cbp-clear-prep/SKILL.md

@@ -9,7 +9,7 @@ effort: xhigh
 # cbp-clear-prep
 
 Capture a handoff snapshot before clearing context. Invoked when the `cbp-skill-context-guard`
-PreToolUse hook denies a heavy skill (cbp-round-execute, cbp-task-testing,
+PreToolUse hook denies a heavy skill (cbp-round-build, cbp-verify,
 cbp-standalone-task-testing, cbp-checkpoint-check, cbp-checkpoint-end) because the context
 window exceeds the configured threshold.
 
@@ -24,7 +24,7 @@ window exceeds the configured threshold.
 ### Step 1 — Identify the blocked skill
 
 Check `$ARGUMENTS` first. If empty, identify the blocked skill from the recent guard deny message
-in context — it will be one of: `cbp-round-execute`, `cbp-task-testing`,
+in context — it will be one of: `cbp-round-build`, `cbp-verify`,
 `cbp-standalone-task-testing`, `cbp-checkpoint-check`, `cbp-checkpoint-end`.
 
 ### Step 2 — Resolve active task and round (local-first)
@@ -43,7 +43,7 @@ Capture: `checkpoint_id`, `checkpoint_number`, `task_id`, `task_number`, `round_
 
 From context, determine:
 - The exact skill the user was trying to invoke (blocked skill from Step 1)
-- Any arguments it was called with (e.g. `cbp-round-execute` args: `217-2-1`)
+- Any arguments it was called with (e.g. `cbp-round-build` args: `217-2-1`)
 - Any relevant in-flight state (round goal, step in progress, pending decisions)
 
 ### Step 4 — Write the handoff file

package/templates/skills/{cbp-task-complete → cbp-finalize}/SKILL.md

@@ -1,22 +1,22 @@
 ---
-name: cbp-task-complete
-description: Complete current task
+name: cbp-finalize
+description: Finalize and complete the current task — commit, merge main, push, complete
 argument-hint: [chk-task]
 triggers: [cbp-task-start, cbp-checkpoint-check]
 effort: xhigh
 ---
 
-# Task Complete Command
+# Finalize Command
 
-Complete the current task. Auto-triggered by `/cbp-task-testing` when all tests pass. Can also be run manually.
+Finalize and complete the current task. Auto-triggered by `/cbp-verify` (scope=task) once it writes a `READY` verdict. Can also be run manually.
 
-This skill is gated by an `ask`-tier `Skill(cbp-task-complete)` permission rule in `settings.json`. **The permission prompt IS the user confirmation** — there is NO AskUserQuestion inside this skill. A declined permission is a clean no-op (nothing committed, merged, pushed, or completed).
+This skill is gated by an `ask`-tier `Skill(cbp-finalize)` permission rule in `settings.json`. **The permission prompt IS the user confirmation** — there is NO AskUserQuestion inside this skill. A declined permission is a clean no-op (nothing committed, merged, pushed, or completed).
 
 ## 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"):
+Parse the argument using the canonical chk-task-round notation (see `cbp-round-plan` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary"):
 
 | Shape | Regex | Resolves to |
 |-------|-------|-------------|
@@ -27,23 +27,23 @@ Parse the argument using the canonical chk-task-round notation (see `cbp-round-s
 Anything else is malformed — surface this error and stop:
 
 ```
-task-complete: invalid argument `{value}`. Expected:
+finalize: invalid argument `{value}`. Expected:
   108-1  → CHK-108 TASK-1 (checkpoint-bound)
   (empty) → active in-progress task
 
 For standalone tasks, use `/cbp-standalone-task-complete {N}`.
-For a specific round, use `/cbp-round-update 108-1-2`.
+For a specific round, use `/cbp-round-plan 108-1-2`.
 ```
 
-Error cases: `108-1-2` (that is round-update's shape), `abc`, `108-`, `-1`, `108--1`, anything with whitespace or non-numeric characters.
+Error cases: `108-1-2` (that is round-plan's shape), `abc`, `108-`, `-1`, `108--1`, anything with whitespace or non-numeric characters.
 
 #### Worked examples
 
-- `task-complete 108-1` → CHK-108 TASK-1
-- `task-complete` (no arg) → active in-progress task via `get_current_task`
-- `task-complete 45` → error: "Use /cbp-standalone-task-complete 45 instead — bare numbers no longer route to standalone tasks."
-- `task-complete 108-1-2` → error: "use `/cbp-round-update 108-1-2`"
-- `task-complete abc` → error: malformed
+- `finalize 108-1` → CHK-108 TASK-1
+- `finalize` (no arg) → active in-progress task via `get_current_task`
+- `finalize 45` → error: "Use /cbp-standalone-task-complete 45 instead — bare numbers no longer route to standalone tasks."
+- `finalize 108-1-2` → error: "use `/cbp-round-plan 108-1-2`"
+- `finalize abc` → error: malformed
 
 ### Step 1.5: Get Current Task
 
@@ -65,28 +65,24 @@ If any round is `in_progress`:
 ```
 ## Cannot Complete Task
 
-TASK-[N] has an active round (Round [N]). Run `/cbp-round-update` to finish it.
+TASK-[N] has an active round (Round [N]). Run `/cbp-round-complete` to finish it.
 ```
 
 Stop here.
 
-Verify at least one round has `testing_qa_output` in its context. If not:
+Verify at least one round has a `verify_manifest` in its context (the durable record `/cbp-verify` writes — gates + execution proof). If not:
 
 ```
 ## Cannot Complete Task
 
-No testing-qa-agent validation found. Run `/cbp-round-start` to execute a validated round.
+No /cbp-verify run found on any round. Run `/cbp-round-plan` to execute a verified round.
 ```
 
 Stop here.
 
-### Step 2.5: Verify `/cbp-task-check` Has Run
+### Step 2.5: Verify `/cbp-verify` (scope=task) Has Run READY
 
-`task.context.check_verdict` must exist and have `verdict: 'READY'`. If not, surface "Run `/cbp-task-check` first" and stop.
-
-### Step 2.6: Verify `/cbp-task-testing` Has Run
-
-`task.context.task_testing_output` must exist with `all_passed: true`. If not, surface "Run `/cbp-task-testing` first" and stop.
+`task.context.verify_verdict` must exist and have `verdict: 'READY'` (written by `/cbp-verify` Phase 6 when it runs at task scope — whole-repo `codebyplan check --scope task`, holistic `cbp-verify-reviewer`, and the single batched human walkthrough all passed). If absent or not `READY`, surface "Run `/cbp-verify` first" and stop.
 
 ### Step 3: Verify QA and File Approval
 
@@ -95,7 +91,7 @@ Load `task.qa` and `task.files_changed`:
 1. **QA**: count items by status (pass / fail / pending / skipped) across all types.
 2. **Files**: list any file with `user_approved === false`.
 
-If any QA item is `fail`/`pending` or any file is unapproved, **surface the warnings in the output and continue** — record them for the Step 9 summary. There is NO confirmation AskUserQuestion here: `Skill(cbp-task-complete)` is `ask`-tier, so the harness permission prompt that gated this skill IS the user's confirmation to complete. The hard gates in Steps 2–2.6 (all rounds completed, ≥1 round has `testing_qa_output`, `check_verdict` READY, `task_testing_output.all_passed`) already block completion when prerequisites are unmet; these QA / file-approval items are warnings, not blockers.
+If any QA item is `fail`/`pending` or any file is unapproved, **surface the warnings in the output and continue** — record them for the Step 9 summary. There is NO confirmation AskUserQuestion here: `Skill(cbp-finalize)` is `ask`-tier, so the harness permission prompt that gated this skill IS the user's confirmation to complete. The hard gates in Steps 2–2.5 (all rounds completed, ≥1 round has a `verify_manifest`, `verify_verdict` READY) already block completion when prerequisites are unmet; these QA / file-approval items are warnings, not blockers.
 
 ### Step 4: Aggregate Files Changed
 
@@ -113,10 +109,10 @@ Otherwise: invoke `/cbp-git-commit` to stage approved files and create the commi
 
 ### Step 5.5: Merge Production Branch (mandatory)
 
-Now that task work is committed, ensure the feat branch is current with the latest production (main) work. Running the merge AFTER the commit means `/cbp-merge-main` resolves conflicts against committed work on a clean tree — no dirty-tree interleave, no Step-0 dirty-tree prompt for the task files. This still prevents shipping a stale PR and surfaces conflicts at task-complete time rather than at PR review.
+Now that task work is committed, ensure the feat branch is current with the latest production (main) work. Running the merge AFTER the commit means `/cbp-merge-main` resolves conflicts against committed work on a clean tree — no dirty-tree interleave, no Step-0 dirty-tree prompt for the task files. This still prevents shipping a stale PR and surfaces conflicts at finalize time rather than at PR review.
 
 1. Trigger `/cbp-merge-main`.
-2. If the skill exits with failure (offline, unresolved conflicts, user-aborted): surface the failure and STOP — do NOT proceed to Step 5.7 (push) or Step 7 (complete). The task commit from Step 5 persists; the user resolves and re-invokes `/cbp-task-complete`, which re-runs the merge on the now-clean tree.
+2. If the skill exits with failure (offline, unresolved conflicts, user-aborted): surface the failure and STOP — do NOT proceed to Step 5.7 (push) or Step 7 (complete). The task commit from Step 5 persists; the user resolves and re-invokes `/cbp-finalize`, which re-runs the merge on the now-clean tree.
 3. If the skill exits with QA warnings the user chose to commit-as-is: continue to Step 5.7; surface a soft warning in the Step 9 output (`⚠ Merged with QA failures pending fix in follow-up`).
 4. On clean success: continue to Step 5.7.
 
@@ -190,9 +186,9 @@ direct you to run `/cbp-clear-prep` first; otherwise checkpoint-check starts on
 
 ## Integration
 
-- **Triggered by**: `/cbp-task-testing` (auto, when ALL PASS) — NOT directly from `/cbp-task-check`
-- **Chain**: `/cbp-task-check` → `/cbp-task-testing` → `/cbp-task-complete`
-- **Reads**: `.codebyplan/state/checkpoints/*.json`, `checkpoints/<id>/tasks/*.json`, `checkpoints/<id>/tasks/<id>/rounds/*.json`, `todos.json` (local-first; `npx codebyplan sync` on miss; MCP `get_current_task`/`get_rounds`/`get_tasks` break-glass)
+- **Triggered by**: `/cbp-verify` (auto, scope=task, when it writes `verify_verdict.verdict === 'READY'`)
+- **Chain**: `/cbp-verify` (scope=task READY) → `/cbp-finalize`
+- **Reads**: `.codebyplan/state/checkpoints/*.json`, `checkpoints/<id>/tasks/*.json`, `checkpoints/<id>/tasks/<id>/rounds/*.json`, `todos.json` (local-first; `npx codebyplan sync` on miss; MCP `get_current_task`/`get_rounds`/`get_tasks` break-glass) — including each round's `verify_manifest` and `task.context.verify_verdict`
 - **Writes**: `codebyplan task update` for `files_changed` (CLI write-through; MCP `update_task` break-glass); MCP `complete_task` for task completion (kept MCP — CLI cannot forward `caller_worktree_id`)
 - **Uses skills (inline, no sub-agent)**: `cleanup` (if deletions), `migration` (if exports renamed)
 - **Triggers**: Same-context transitions auto-trigger via the Skill tool (next task in checkpoint → `cbp-task-start {N}`, `allow`-tier, fires silently). Checkpoint-done → auto-triggers `cbp-checkpoint-check` via Skill tool (`ask`-tier, permission prompt IS the human gate). No-task-anywhere fallback → directive `Next: Run /clear, then /cbp-session-end.`

package/templates/skills/{cbp-task-complete → cbp-finalize}/reference/checkpoint-done-branching.md

@@ -1,4 +1,4 @@
-# Checkpoint-Done Auto-Trigger in `/cbp-task-complete` Step 9
+# Checkpoint-Done Auto-Trigger in `/cbp-finalize` Step 9
 
 When the just-completed task was the LAST pending task in its checkpoint (every sibling task has `status === 'completed'`), Step 9c auto-triggers `cbp-checkpoint-check` via the Skill tool — no routing menu, no manual `/clear` directive.
 

package/templates/skills/{cbp-task-complete → cbp-finalize}/reference/next-step-heuristic.md

@@ -1,4 +1,4 @@
-# Next-Step Heuristic for `/cbp-task-complete` Step 9
+# Next-Step Heuristic for `/cbp-finalize` Step 9
 
 Close-out routing splits into two cases by context-continuity.
 

package/templates/skills/cbp-frontend-design/SKILL.md

@@ -133,7 +133,7 @@ If any check fails, fix before proceeding to Step 3.
 
 ## Output back to the round-executor
 
-After Phase 6, the executor proceeds to Step 3 with the brand commitment + stack reference + direction in working memory. Round-executor records `frontend_design_loaded: { stack, direction, tokens_path }` in `round.context` so `frontend-ui` (Step 3.8) and `cbp-improve-round` can verify the commitment was honoured.
+After Phase 6, the executor proceeds to Step 3 with the brand commitment + stack reference + direction in working memory. Round-executor records `frontend_design_loaded: { stack, direction, tokens_path }` in `round.context` so `frontend-ui` (Step 3.8) and `cbp-verify-reviewer` can verify the commitment was honoured.
 
 ## Integration
 

package/templates/skills/cbp-frontend-ui/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cbp-frontend-ui
-description: Visual quality self-review pass invoked twice per round — once by round-executor Step 3.8 (phase 'style_only', no screenshots) for token/spacing/typography/color/cohesion, once by /cbp-round-execute Step 5b (phase 'screenshot_review', with e2e screenshots) for rendered-output review and baseline regressions. Default phase 'full' runs everything for back-compat.
+description: Visual quality self-review pass invoked twice per round — once by round-executor Step 3.8 (phase 'style_only', no screenshots) for token/spacing/typography/color/cohesion, once by /cbp-round-build Step 5b (phase 'screenshot_review', with e2e screenshots) for rendered-output review and baseline regressions. Default phase 'full' runs everything for back-compat.
 effort: xhigh
 ---
 
@@ -9,7 +9,7 @@ effort: xhigh
 Invoked twice per round in non-`claude_only` profiles:
 
 1. `round-executor` Step 3.8 — `phase: 'style_only'`, no e2e screenshots. Reviews token/spacing/typography/color/cohesion against the just-written code.
-2. `/cbp-round-execute` Step 5b — `phase: 'screenshot_review'`, with screenshots from the `cbp-e2e-*` specialists. Reviews rendered output and detects baseline regressions.
+2. `/cbp-round-build` Step 5b — `phase: 'screenshot_review'`, with screenshots from the `cbp-e2e-*` specialists. Reviews rendered output and detects baseline regressions.
 
 Default `phase: 'full'` runs everything (back-compat for any caller not yet migrated). Inline counterpart of the up-front `frontend-design` skill — `frontend-design` decides direction before code; `frontend-ui` reviews and polishes after code.
 
@@ -35,7 +35,7 @@ input:
   context:
     checkpoint_goal: string
     round_requirements: string
-  e2e_screenshots:                          # Required for phase 'screenshot_review' or 'full' (when present); empty / omitted for 'style_only'. Sourced from the aggregated round.context.e2e_outputs[*].screenshots (populated by the cbp-e2e-* specialists at /cbp-round-execute Step 5).
+  e2e_screenshots:                          # Required for phase 'screenshot_review' or 'full' (when present); empty / omitted for 'style_only'. Sourced from the aggregated round.context.e2e_outputs[*].screenshots (populated by the cbp-e2e-* specialists at /cbp-round-build Step 5).
     - test_name: string
       path: string                          # Repo-relative or absolute path to PNG
       page_or_screen: string
@@ -184,7 +184,7 @@ For each screenshot in `e2e_screenshots[]`:
 
 Populate `screenshot_review` totals.
 
-**Do not attempt to auto-fix `rendered_visual` or `baseline_regression` findings** — they surface as a blocking gate at `/cbp-round-end` Step 7 (accept-or-fix) and feed the fix loop, because the root cause is typically in app code/data, not in the SCSS.
+**Do not attempt to auto-fix `rendered_visual` or `baseline_regression` findings** — they surface as a blocking gate at `/cbp-verify` (round scope, accept-or-fix) and feed the fix loop, because the root cause is typically in app code/data, not in the SCSS.
 
 ### Phase 7: Aggregate Findings
 
@@ -255,9 +255,9 @@ Go beyond fixing violations — actively improve visual quality. If spacing coul
 
 - **Loaded twice per round** (non-`claude_only` profiles):
   1. `round-executor` Step 3.8 with `phase: 'style_only'` and empty `e2e_screenshots[]` — reviews the just-written code's tokens/spacing/typography/color/cohesion (mandatory when files_changed contains UI / styling files)
-  2. `/cbp-round-execute` Step 5b with `phase: 'screenshot_review'` and screenshots aggregated from `round.context.e2e_outputs[*].screenshots` — runs Phase 6.5 only (rendered-output review + baseline regressions). Skipped when no e2e ran (`claude_only` / `backend`, or no eligible framework in `.codebyplan/e2e.json`).
+  2. `/cbp-round-build` Step 5b with `phase: 'screenshot_review'` and screenshots aggregated from `round.context.e2e_outputs[*].screenshots` — runs Phase 6.5 only (rendered-output review + baseline regressions). Skipped when no e2e ran (`claude_only` / `backend`, or no eligible framework in `.codebyplan/e2e.json`).
 - **Also invoked by**: `/cbp-checkpoint-check` with screenshots aggregated from a whole-checkpoint e2e run
-- **Consumes**: `e2e_screenshots[]` aggregated from `round.context.e2e_outputs[*].screenshots` (populated by the `cbp-e2e-*` specialists at `/cbp-round-execute` Step 5)
+- **Consumes**: `e2e_screenshots[]` aggregated from `round.context.e2e_outputs[*].screenshots` (populated by the `cbp-e2e-*` specialists at `/cbp-round-build` Step 5)
 - **Output written to**: `round.context.frontend_ui_review` — when invoked twice per round, the second invocation merges with the first
-- **Downstream gate**: this skill emits `findings[]` only. Changed-baseline-regression findings (`is_new === false`) surface as a BLOCKING gate at `/cbp-round-end` Step 7 (never auto-accepted); new-screen baselines (`is_new === true`) are auto-committed and reviewed semantically only; rendered-visual critical findings are surfaced in the Step 7 findings presentation.
+- **Downstream gate**: this skill emits `findings[]` only. Changed-baseline-regression findings (`is_new === false`) surface as a BLOCKING gate at `/cbp-verify` (round scope, never auto-accepted); new-screen baselines (`is_new === true`) are auto-committed and reviewed semantically only; rendered-visual critical findings are surfaced in the `/cbp-verify` findings presentation.
 - **Paired with**: `frontend-design` (pre-implementation aesthetic decision), `frontend-ux` (interaction-quality self-review, also Step 3.8)

package/templates/skills/cbp-git-commit/SKILL.md

@@ -31,7 +31,7 @@ Create a commit using conventional commits format, then push to origin.
 
 | Flag | File Source | Use Case |
 |------|-------------|----------|
-| `--task` | All staged files | `/cbp-task-complete` |
+| `--task` | All staged files | `/cbp-finalize` |
 | `--all` | All staged files | Explicit full commit |
 | `--scope-task` | Intersection of `task.files_changed[].path` and `git diff --cached --name-only` | Foreign-staged files exist alongside task work; user wants to commit only the task's files in this commit |
 | (none) | All staged files | Default behavior |
@@ -264,9 +264,9 @@ Stage the missing files or use --all.
 ## Integration
 
 - **Reads (--scope-task)**: Local state task file `.codebyplan/state/checkpoints/*/tasks/*.json` (in_progress); on miss `npx codebyplan sync` once; MCP `get_current_task` as documented break-glass when the state dir is absent and sync fails.
-- **Called by**: `/cbp-session-end`, `/cbp-task-complete`, `/cbp-checkpoint-complete`, manual
+- **Called by**: `/cbp-session-end`, `/cbp-finalize`, `/cbp-checkpoint-complete`, manual
 - **Scope usage by commands**:
-  - `/cbp-task-complete` -> `--no-push` (commit all staged)
+  - `/cbp-finalize` -> `--no-push` (commit all staged)
   - `/cbp-checkpoint-complete` -> no scope needed
   - `/cbp-session-end` -> `--all` or no scope (commit all staged)
 - **Rules**: `/.claude/rules/git-workflow.md`

package/templates/skills/cbp-merge-main/SKILL.md

@@ -8,12 +8,12 @@ effort: high
 
 Codifies the long-lived-branch-integration auto-memory rule (`[[feedback_long-lived-branch-integration]]`): when working on a feat branch that has diverged from main, merge main INTO the feat branch (not the reverse), resolve conflicts with the user, run a scoped QA pass, then return control to the caller — never rebase, never force-push, never push automatically.
 
-Triggered by `/cbp-task-start` (Step 3.6, optional stale-check), `/cbp-task-complete` (Step 5.5, mandatory pre-push — runs after the task commit on a clean tree), and `/cbp-checkpoint-end` (Step 0, mandatory pre-shipment). User can also invoke manually at any time.
+Triggered by `/cbp-task-start` (Step 3.6, optional stale-check), `/cbp-finalize` (Step 5.5, mandatory pre-push — runs after the task commit on a clean tree), and `/cbp-checkpoint-end` (Step 0, mandatory pre-shipment). User can also invoke manually at any time.
 
 ## When to Use
 
 - **Auto-trigger (optional)**: `/cbp-task-start` Step 3.6 detects the feat branch is >10 commits behind `origin/{BASE}` OR the last fetch is >24h old.
-- **Auto-trigger (mandatory)**: `/cbp-task-complete` Step 5.5 — mandatory pre-push, after the task commit; runs on a clean tree to ensure the feat branch includes the latest main work before the single trailing push.
+- **Auto-trigger (mandatory)**: `/cbp-finalize` Step 5.5 — mandatory pre-push, after the task commit; runs on a clean tree to ensure the feat branch includes the latest main work before the single trailing push.
 - **Auto-trigger (mandatory)**: `/cbp-checkpoint-end` Step 0 — always run before shipment to ensure no main drift reaches production.
 - **Manual invocation**: user runs `/cbp-merge-main` directly when they know main has advanced and want to pull it in immediately.
 
@@ -82,7 +82,7 @@ Supabase migrations are version-keyed by their numeric filename prefix. Two file
 
    - **Rename HEAD-side (Recommended when a main migration is already applied to a shared remote)** — rename the local file to a fresh, sequential timestamp that respects existing apply-order dependencies (probe `supabase migration list --db-url <preview>` if a preview branch exists, or inspect FK references in surrounding migrations). The orchestrator runs `git mv <old> <new>` itself; the rename lands in the git index and is picked up by the re-probe at step 5.
    - **Rename main-side (manual, OUT-OF-SKILL)** — only when the main file definitely has not been applied anywhere yet AND the user has write access to `{BASE}`. This skill does NOT touch the main branch: it runs on a feat branch (Step 0 enforces this) and the Key Rules below forbid any push from this skill. The user must, in a separate terminal: `git checkout {BASE} && git mv <old> <new> && git commit -m "fix(migration): rename to resolve collision with feat/..." && git push origin {BASE}`. After that push is confirmed remote-side, re-invoke `/cbp-merge-main` — Step 1 will fetch the updated main tip and Step 1.5 will re-probe with the rename in place.
-   - **Defer to a new task in the active checkpoint** — `git merge --abort` is unnecessary because Step 2 has not started. Create a CHK-bound task per `cbp-round-end` reference `findings-presentation.md` "Infra Issue Absorption Contract — Resolve-in-Current-Scope by Default" and STOP `/cbp-merge-main`. Resume after the task completes.
+   - **Defer to a new task in the active checkpoint** — `git merge --abort` is unnecessary because Step 2 has not started. Create a CHK-bound task per `cbp-verify` reference `findings-presentation.md` "Infra Issue Absorption Contract — Resolve-in-Current-Scope by Default" and STOP `/cbp-merge-main`. Resume after the task completes.
    - **Abort merge** — STOP the skill. User decides later.
 
 4. After any HEAD-side rename action, re-execute Step 1.5 (collisions may chain — fixing one can expose another). The CLI probes the HEAD side via `git ls-files` (so staged renames are visible), matching the documented re-probe behavior. Main-side renames require a fresh `/cbp-merge-main` invocation (the user manually fetched and re-ran per option 2 above), not an in-skill loop.
@@ -209,7 +209,7 @@ Return control to the caller. **This skill NEVER pushes** — the caller decides
 
 - **Triggered by**:
   - `/cbp-task-start` Step 3.6 (optional stale-check: >10 commits behind OR >24h fetch age)
-  - `/cbp-task-complete` Step 5.5 (mandatory pre-push, after task commit)
+  - `/cbp-finalize` Step 5.5 (mandatory pre-push, after task commit)
   - `/cbp-checkpoint-end` Step 0 (mandatory pre-shipment)
   - User-invocable manually
 - **Reads**: `.codebyplan/git.json`, local state `.codebyplan/state/checkpoints/<id>.json` + `.../tasks/<id>.json`; on miss `npx codebyplan sync` once; MCP `get_checkpoints` (active-filter multi-checkpoint scan) / MCP `get_tasks` as documented break-glass when the state dir is absent and sync fails (full cross-checkpoint scan). Git state.