codebyplan 1.13.61 → 1.13.63

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

@@ -1,8 +1,9 @@
 ---
 name: cbp-build-cc-mode
-description: Audit + apply the CHK-109 model/effort convention across every authoring skill and agent under `packages/codebyplan-package/templates/`. Skills set `effort:` only and inherit the session model; agents pin `model:` + `effort:`. Bare invocation audits and reports frontmatter gaps; with a path argument, edits the target file's frontmatter to the convention-decided values.
+description: Audit + apply the CHK-229 model/effort convention across every authoring skill and agent under `packages/codebyplan-package/templates/`. Skills set `model: inherit` + `effort:`; agents pin `model:` + `effort:`. Bare invocation audits and reports frontmatter gaps; with a path argument, edits the target file's frontmatter to the convention-decided values.
 argument-hint: "[path-to-agent-or-skill]"
 allowed-tools: Read, Write, Edit, Glob, Grep
+model: inherit
 effort: xhigh
 ---
 
@@ -12,8 +13,8 @@ Audit or apply the canonical model/effort frontmatter convention across every au
 
 The convention splits by surface:
 
-- **Skills do NOT pin `model:`.** A skill's inline turn runs inside the user's active session, so it must inherit the session model. Pinning a model (a) forces a model the user did not choose and (b) can carry the session's 1M `[1m]` context tier onto the skill, producing `API Error: Usage credits required for 1M context`. Skills set `effort:` only.
-- **Agents pin `model:` explicitly.** A spawned/forked subagent should not silently inherit the parent's model or context tier — every agent states its model so each subagent's cost/quality is auditable. Agents set both `model:` and `effort:`.
+- **Skills set `model: inherit` AND `effort:`.** The `model: inherit` value signals explicitly that the skill inherits the user's active session model — it is the standard value. A non-inherit model or an absent model field is a gap. A justified explicit pin (e.g. `model: sonnet`) is permitted when documented here as an exception.
+- **Agents pin `model:` explicitly.** A spawned/forked subagent must not silently inherit the parent's model or context tier — every agent states its model so each subagent's cost/quality is auditable. Agents set both `model:` and `effort:`. `model: inherit` is NOT permitted for agents.
 
 ## When to Use
 
@@ -23,33 +24,40 @@ The convention splits by surface:
 
 ## Decision Matrix
 
-### Skills — `effort:` only, never `model:`
+### Skills — `model: inherit` + `effort:`
 
-Omit `model:` entirely (inherit the session model). Set `effort:` per the skill's nature. Default `effort: xhigh`; tiers:
+Set `model: inherit` (the standard value) and `effort:` per the skill's nature. Default `effort: xhigh`; tiers:
 
-| effort   | use for                                                | examples                                                                                                                                                              |
-| -------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `xhigh`  | deep authoring / planning / orchestration (most skills) | build-cc-*, checkpoint-check/end/plan, round-start/input/execute, task-create/start/complete/testing, standalone-task-*, frontend-*, ship, ship-configure, supabase-*, setup-e2e/eslint, session-end |
-| `high`   | summary / orchestration, lighter than xhigh            | checkpoint-create, checkpoint-start, checkpoint-update, round-end, task-check, standalone-task-check, ship-main, merge-main                                           |
-| `medium` | moderate, scoped sync work                             | refresh-infra                                                                                                                                                        |
-| `low`    | pure mechanical / dispatch / templated work            | checkpoint-complete, round-check, round-complete, round-update, todo, session-start, git-commit, git-branch-feat-create    |
+| effort   | use for                                                | examples                                                                                                                                                                    |
+| -------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `xhigh`  | deep authoring / planning / orchestration (most skills) | build-cc-*, checkpoint-check/end/plan, finalize, frontend-design, map-architecture, round-build/plan, ship, standalone-task-complete, supabase-migrate, task-start, verify |
+| `high`   | lighter orchestration, review, setup, targeted flows   | checkpoint-create/start, frontend-ui/ux, merge-main, refresh-arch-map, session-end, setup-cd/ci/e2e/eslint, ship-configure/main, standalone-task-check/create/start/testing, stripe, supabase-branch-check/setup, task-create |
+| `medium` | moderate, scoped sync work                             | checkpoint-update, clear-prep, todo                                                                                                                                          |
+| `low`    | pure mechanical / dispatch / templated work            | checkpoint-complete, clear-continue, git-commit, git-branch-feat-create, round-complete, session-start                                                                      |
 
-A skill that carries a `model:` line is a **gap** — remove it unless a deliberate, documented exception is recorded here (currently none).
+A skill with an absent `model:` field or a non-`inherit` model value is a **gap** — add `model: inherit` or document the exception here before applying a different pin.
+
+> **Note on effort tiers**: `max` is the highest frontmatter effort tier. `ultracode` is a SESSION-ONLY runtime mode (`/effort ultracode`) — it is NOT a valid frontmatter value and `validate-skill.sh` rejects `effort: ultracode` with an explicit error.
 
 ### 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-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:
+Default `model: sonnet` + `effort: xhigh`. Ten of the 17 authoring agents take the default (`cbp-cc-executor`, `cbp-database-agent`, `cbp-improve-claude`, `cbp-research`, `cbp-round-builder`, `cbp-round-planner`, `cbp-security-agent`, `cbp-stripe-agent`, `cbp-testing-qa-agent`, `cbp-verify-reviewer`). The other seven are exceptions:
 
 | agent                | model  | effort | reason                                                                              |
 | -------------------- | ------ | ------ | ----------------------------------------------------------------------------------- |
 | cbp-mechanical-edits | haiku  | low    | Mechanical rename/substitution/frontmatter-edit subagent; no judgment, pure dispatch |
 | cbp-map-architecture | sonnet | high   | Read-only module analyzer; bounded structured-map generation, lighter than xhigh     |
+| cbp-e2e-maestro      | sonnet | high   | E2E specialist: bounded test-execution scope; sonnet+high calibrated in CHK-229      |
+| cbp-e2e-playwright   | sonnet | high   | E2E specialist: bounded test-execution scope; sonnet+high calibrated in CHK-229      |
+| cbp-e2e-tauri        | sonnet | high   | E2E specialist: bounded test-execution scope; sonnet+high calibrated in CHK-229      |
+| cbp-e2e-vscode       | sonnet | high   | E2E specialist: bounded test-execution scope; sonnet+high calibrated in CHK-229      |
+| cbp-e2e-xcuitest     | sonnet | high   | E2E specialist: bounded test-execution scope; sonnet+high calibrated in CHK-229      |
 
 `model: inherit` is NOT permitted for agents — pin an explicit alias (`sonnet` / `haiku`) or a full ID.
 
 ## Precedence Rule
 
-A skill's `effort:` applies to the inline-running turn (the orchestrator turn that invokes the skill); the skill runs on that turn's inherited model. An agent's `model:` / `effort:` apply to the spawned/forked subagent context. For `context: fork` skills, the agent named in `agent:` governs the forked subagent (per the official Claude Code spec) — so a forked skill's model comes from that agent, not from the skill.
+A skill's `effort:` applies to the inline-running turn (the orchestrator turn that invokes the skill); the skill runs on that turn's inherited model (declared via `model: inherit`). An agent's `model:` / `effort:` apply to the spawned/forked subagent context. For `context: fork` skills, the agent named in `agent:` governs the forked subagent (per the official Claude Code spec) — so a forked skill's model comes from that agent, not from the skill.
 
 ## Audit Mode
 
@@ -70,10 +78,10 @@ Invoked with a path argument (the target `SKILL.md` or agent `.md`). Procedure:
 1. Read the file. Identify the name from the `name:` frontmatter (or the path basename).
 2. Look up the target from the convention above.
 3. Use Edit to set the frontmatter to the target, preserving every other field and the entire body:
-   - **Skill**: REMOVE any `model:` line; set/keep a valid `effort:` (default `xhigh`).
+   - **Skill**: SET `model: inherit` if absent (or correct a non-inherit pin); set/keep a valid `effort:` (default `xhigh`).
    - **Agent**: set `model:` and `effort:` to the table values.
-4. If the name is NOT covered, surface via AskUserQuestion: current state, propose the default (skill → no `model:` + `xhigh`; agent → `sonnet` + `xhigh`), and ask whether to (a) record an exception entry here first, or (b) apply the default.
+4. If the name is NOT covered, surface via AskUserQuestion: current state, propose the default (skill → `model: inherit` + `xhigh`; agent → `sonnet` + `xhigh`), and ask whether to (a) record an exception entry here first, or (b) apply the default.
 
 ## Self-Conformance
 
-This skill is itself a skill: its frontmatter sets `effort: xhigh` and NO `model:`. The first audit run after editing this file MUST emit `ok` for `packages/codebyplan-package/templates/skills/cbp-build-cc-mode/SKILL.md` — if it doesn't, the convention is out of sync with reality and must be reconciled before any further apply.
+This skill is itself a skill: its frontmatter declares `model: inherit` + `effort: xhigh`. The first audit run after editing this file MUST emit `ok` for `packages/codebyplan-package/templates/skills/cbp-build-cc-mode/SKILL.md` — if it doesn't, the convention is out of sync with reality and must be reconciled before any further apply.

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

@@ -3,6 +3,7 @@ name: cbp-build-cc-rule
 description: Build a path-scoped rule file at .claude/rules/{name}.md following the official memory/rules spec (paths globs, always-loaded vs on-demand, symlinks) plus CBP conventions (scope field for structural classification — required only on user-created rules (validate-structure-scope.sh), narrow-paths discipline; hook warns at 100 lines, blocks at 200).
 argument-hint: '[name] [--scope=project|user] [--paths="glob,glob"]'
 allowed-tools: Read, Write, Edit, Glob, Grep
+model: inherit
 effort: xhigh
 ---
 

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

@@ -3,6 +3,7 @@ name: cbp-build-cc-settings
 description: Create or update Claude Code settings.json / settings.local.json / managed-settings.json following the official settings spec — scopes, permissions, hooks, sandbox, attribution, plugins, env vars, JSON schema validation.
 argument-hint: "[action] [--scope=user|project|local|managed]"
 allowed-tools: Read, Write, Edit, Glob, Grep, Bash(jq *)
+model: inherit
 effort: xhigh
 ---
 

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

@@ -25,7 +25,7 @@ Precedence is `deny > ask > allow`; arrays union across scopes (managed/user/pro
 - **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`.
+- **Read/safe CLI commands** (both `codebyplan X` and `npx codebyplan X`): `whoami`, `statusline`, `ports`, `tech-stack`, `eslint`, `round`, `help`, `--version`.
 
 ### `ask` — the deliberate confirm-gate
 

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

@@ -54,7 +54,7 @@ Source: official Claude Code settings spec. Grouped by category. All fields are
 | `model` | Override default model |
 | `modelOverrides` | Map model IDs (e.g. Bedrock profile ARNs) |
 | `availableModels` | Restrict which models `/model` exposes |
-| `effortLevel` | Persist effort across sessions |
+| `effortLevel` | Persist effort across sessions. Valid values: `low \| medium \| high \| xhigh` only — `max` and `ultracode` are session-only and rejected here. See `rules/effort-and-ultracode.md`. |
 | `alwaysThinkingEnabled` | Extended thinking on by default |
 | `showThinkingSummaries` | Show thinking summaries |
 

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

@@ -3,6 +3,7 @@ name: cbp-build-cc-skill
 description: Build a Claude Code skill at .claude/skills/{name}/SKILL.md following the official skills spec — frontmatter, supporting files (templates, examples, reference, scripts), invocation control, argument substitution, dynamic context, fork-to-subagent, allowed-tools.
 argument-hint: "[skill-name] [--scope=project|user] [--fork] [--disable-model-invocation]"
 allowed-tools: Read, Write, Edit, Glob, Grep, Bash(mkdir *), Bash(chmod *)
+model: inherit
 effort: xhigh
 ---
 
@@ -97,7 +98,7 @@ Key fields by use case:
 | Hide from `/` menu                                   | `user-invocable: false`                                                                                                                                                                                                          |
 | Pre-approve tools                                    | `allowed-tools: Bash(git add *) Bash(git commit *)`                                                                                                                                                                              |
 | Accept arguments                                     | `argument-hint: [file] [mode]`, optionally `arguments: [file mode]` for named `$file`/`$mode`                                                                                                                                    |
-| Set effort (do NOT set model)                        | `effort: xhigh` — default for plugin skills; lower (`high`/`low`) per [/cbp-build-cc-mode](../build-cc-mode/SKILL.md). **Omit `model:`** so the skill inherits the active session model — pinning one forces a model the user didn't choose and can carry the session's 1M `[1m]` tier onto the skill (→ "usage credits required for 1M context"). Pin `model:` only as a deliberate, documented exception |
+| Set model + effort                                   | `model: inherit` (the standard value — explicitly signals session-model inheritance) and `effort: xhigh` (default for plugin skills; lower tiers `high`/`medium`/`low` per [/cbp-build-cc-mode](../build-cc-mode/SKILL.md)). A non-`inherit` model pin forces a model the user didn't choose and can carry the session's 1M `[1m]` tier onto the skill (→ "usage credits required for 1M context"), so pin only as a deliberate, documented exception |
 | Path-scoped auto-load                                | `paths: ["src/api/**/*.ts"]`                                                                                                                                                                                                     |
 | Fork to subagent                                     | `context: fork`, `agent: Explore`                                                                                                                                                                                                |
 

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

@@ -12,7 +12,7 @@ Source: official Claude Code skills spec. All fields are optional; `description`
 | `disable-model-invocation` | `true` → only user can invoke (via `/name`). Upstream skills that auto-trigger this skill MUST emit a `Next: /name` directive instead — model invocation is blocked by the runtime; see SKILL.md Step 4 "Convention: User-only / permission-gated finalizer" |
 | `user-invocable` | `false` → hidden from `/` menu, Claude-only |
 | `allowed-tools` | Pre-approve tools while the skill is active |
-| `model` | Override model for this skill's turn. **CBP skills normally OMIT this** so the skill inherits the active session model. Pinning a model (e.g. `sonnet`) forces that model and can carry the session's 1M `[1m]` context tier onto the skill, triggering "usage credits required for 1M context". Set it only as a deliberate, documented exception — see [/cbp-build-cc-mode](../../build-cc-mode/SKILL.md) |
+| `model` | Model for this skill's turn. **CBP skills set `model: inherit`** (the standard value — explicitly signals session-model inheritance). A non-`inherit` pin (e.g. `sonnet`) forces that model and can carry the session's 1M `[1m]` context tier onto the skill, triggering "usage credits required for 1M context"; use only as a deliberate, documented exception — see [/cbp-build-cc-mode](../../build-cc-mode/SKILL.md) |
 | `effort` | Override effort level (`low`/`medium`/`high`/`xhigh`/`max`). **Plugin skills authored in CBP MUST set this explicitly** (no commented-out placeholder); defaults to `xhigh`. See [/cbp-build-cc-mode](../../build-cc-mode/SKILL.md) for the matrix |
 | `context` | `fork` → run in a subagent |
 | `agent` | Subagent type when `context: fork` — built-in or custom |

package/templates/skills/cbp-build-cc-skill/scripts/validate-skill.sh

@@ -57,19 +57,22 @@ if grep -qE '^scope:\s*' <<< "$fm"; then
   fi
 fi
 
-# Model — skills MUST NOT pin a model. A skill's inline turn runs in the user's
-# active session, so it inherits the session model. Pinning one forces a model the
-# user didn't choose and can carry the session's 1M [1m] context tier onto the skill
-# ("API Error: Usage credits required for 1M context"). Agents pin model explicitly
-# (validate-agent.sh) — skills never do.
-if grep -qE '^model:' <<< "$fm"; then
-  model=$(grep -E '^model:' <<< "$fm" | head -1 | sed -E 's/^model:[[:space:]]*//; s/[[:space:]]*$//')
-  err "skills must NOT set 'model:' (found '$model') — skills inherit the session model; remove the line (see /cbp-build-cc-mode)"
+# Model — skills MUST declare 'model: inherit' to signal session-model inheritance
+# explicitly. Absent = warning (should be added); non-enum value = error.
+# Valid values: inherit | sonnet | opus | haiku | fable | opusplan | claude-<id> | <id>[1m]
+# Agents pin explicit model values (validate-agent.sh); skills use 'inherit'.
+model_val=$(grep -E '^model:' <<< "$fm" | head -1 | sed -E 's/^model:[[:space:]]*//; s/[[:space:]]*$//' || true)
+if [ -z "$model_val" ]; then
+  echo "  WARN: model: absent — add 'model: inherit' (skills must declare session-model inheritance)" >&2
+elif ! [[ "$model_val" =~ ^(inherit|sonnet|opus|haiku|fable|opusplan|claude-[a-z0-9][a-z0-9.-]*|.*\[1m\])$ ]]; then
+  err "model: invalid value '$model_val' (valid values: inherit | sonnet | opus | haiku | fable | opusplan | claude-<id> | <id>[1m])"
 fi
 
 # Effort (if present)
 effort=$(grep -E '^effort:' <<< "$fm" | head -1 | sed -E 's/^effort:[[:space:]]*//; s/[[:space:]]*$//; s/^"(.*)"$/\1/' || true)
-if [ -n "$effort" ] && [[ ! "$effort" =~ ^(low|medium|high|xhigh|max)$ ]]; then
+if [ "$effort" = "ultracode" ]; then
+  err "effort: ultracode is a session-only mode, not a frontmatter effort — use max + /effort ultracode"
+elif [ -n "$effort" ] && [[ ! "$effort" =~ ^(low|medium|high|xhigh|max)$ ]]; then
   err "effort invalid: '$effort'"
 fi
 

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

@@ -3,6 +3,7 @@ scope: org-shared
 name: cbp-checkpoint-check
 description: Full re-evaluation of a checkpoint with before/after comparison
 argument-hint: [CHK-NNN]
+model: inherit
 effort: xhigh
 ---
 
@@ -133,6 +134,10 @@ Aggregate the files touched across all tasks (reusing Step 4's deduplicated tabl
 
    See `cbp-verify` reference `findings-presentation.md` "Infra Issue Absorption Contract — Infra-Class Issue Catalog" row "Checkpoint-level e2e failure" for the routing rationale.
 
+#### Orchestration (optional)
+
+Step 5b's parallel whole-checkpoint `cbp-e2e-*` specialist dispatch MAY be authored as a `Workflow(...)` script instead of ad-hoc `Task`/`Agent` spawning — for deterministic fan-out across eligible frameworks and schema-validated aggregation. This is opt-in (ultracode session or explicit user request); the dispatch flow above stays the DEFAULT and is unchanged. See `rules/workflow-orchestration.md`.
+
 ### Step 6: User Discussion
 
 Present findings and discuss with user:

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

@@ -2,6 +2,7 @@
 name: cbp-checkpoint-complete
 description: Complete a checkpoint after all tasks are done
 argument-hint: [checkpoint-number]
+model: inherit
 effort: low
 ---
 

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

@@ -2,6 +2,7 @@
 name: cbp-checkpoint-create
 description: Mechanical checkpoint creation — capture the user's description, infer title + goal, dedup against existing modules, create the checkpoint row + feat branch, then hand off to /cbp-checkpoint-plan for deep planning. Creates ZERO tasks.
 argument-hint: [checkpoint description]
+model: inherit
 effort: high
 ---
 
@@ -59,35 +60,25 @@ Skip when the description has zero domain matches OR the user already named a ta
 
 Lightweight inference from the description — no deep analysis. **Title**: concise, ≤80 chars. **Goal**: ≤300 chars, a faithful restatement of intent (not a plan).
 
-### Step 6: Claim-or-Open Prompt
-
-Ask the user via AskUserQuestion whether to claim this checkpoint now:
-
-- **Claim for me + this worktree** (default) — resolve `npx codebyplan resolve-worktree 2>/dev/null` and set it as the checkpoint `worktree_id` at create. The creator carries momentum straight through plan → start.
-- **Leave it open** — create with `worktree_id` null so anyone free can claim it later via `/cbp-checkpoint-start`.
-
-Record the choice; it drives both the create call (Step 7) and the plan→start routing in `/cbp-checkpoint-plan`.
-
-### Step 7: Create Checkpoint Row
+### Step 6: Create Checkpoint Row
 
 `codebyplan checkpoint create` (CLI write-through: writes `.codebyplan/state/checkpoints/<id>.json` + REST). Pass flags:
 - `--repo-id` (from `.codebyplan/repo.json`), `--title`, `--goal`, `--deadline`, `--status pending`
 - `--ideas` JSON `[{ description: <raw user text> }]`
-- `--worktree-id` the resolved worktree **only if the user chose "claim"**; omit when "leave open"
 
-Do **not** pass `--number` — the database auto-assigns the next per-repo checkpoint number via a `BEFORE INSERT` trigger (advisory-locked `MAX(number)+1` scoped to `repo_id`). The DB-assigned number comes back on the created row (and is written into `.codebyplan/state/checkpoints/<id>.json`); read it for the branch slug (Step 8) and the result display (Step 9).
+Do **not** pass `--number` — the database auto-assigns the next per-repo checkpoint number via a `BEFORE INSERT` trigger (advisory-locked `MAX(number)+1` scoped to `repo_id`). The DB-assigned number comes back on the created row (and is written into `.codebyplan/state/checkpoints/<id>.json`); read it for the branch slug (Step 7) and the result display (Step 8).
 
 Break-glass fallback: MCP `create_checkpoint` (also omit `number`) when the CLI is unavailable.
 
-This is the first identity-stamping point — when claiming, passing `worktree_id` here engages the CHK-104 hard-lock from birth. No `context`, `research`, `plan`, or tasks are written here.
+Assignment (`assigned_user_id`) is stamped server-side from the caller's JWT when the checkpoint is activated via `/cbp-checkpoint-start` — it is not set at create time. No `context`, `research`, `plan`, or tasks are written here.
 
-### Step 8: Create + Switch to Feat Branch
+### Step 7: Create + Switch to Feat Branch
 
-`{NNN}` below is the DB-assigned checkpoint number read back from the Step 7 `codebyplan checkpoint create` response.
+`{NNN}` below is the DB-assigned checkpoint number read back from the Step 6 `codebyplan checkpoint create` response.
 
 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.
 
-**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:
+**7.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 6 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
@@ -95,14 +86,14 @@ 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):
+(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 7.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:
+**7.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}")
@@ -121,13 +112,13 @@ Persist the branch via `codebyplan checkpoint update --id <checkpoint-id> --bran
 
 **Note — Supabase preview branch**: no Supabase branch is created here. Creation is lazy — it happens on the first DB change when `/cbp-supabase-migrate` runs on this feat branch, which provisions a Supabase branch named identically to the git branch. See `cbp-supabase-migrate` Step 2.3 for the creation protocol.
 
-### Step 9: Show Result + Auto-Trigger Plan
+### Step 8: Show Result + Auto-Trigger Plan
 
 ```
 ## Checkpoint Created
 
 **CHK-NNN**: [title]  •  **Deadline**: [date]  •  **Branch**: feat/CHK-NNN-slug
-**Claim**: [claimed by this worktree / left open]
+**Assignment**: stamped on activation via /cbp-checkpoint-start
 **Worktree**: `npx codebyplan worktree add CHK-{NNN}`
 
 Now planning CHK-NNN… handing off to /cbp-checkpoint-plan.
@@ -138,6 +129,6 @@ Auto-trigger `/cbp-checkpoint-plan {NNN}` in the same context. This skill create
 ## Integration
 
 - **Runs inline**: mechanical setup only — no assessment, research, Q&A, plan, or tasks
-- **Reads**: `.codebyplan/state/checkpoints/*.json` (local-first; `npx codebyplan sync` if stale; MCP `get_checkpoints` break-glass); `.codebyplan/repo.json`, `.codebyplan/git.json`; `npx codebyplan resolve-worktree`
-- **Writes**: `codebyplan checkpoint create` (description-only ideas + deadline + optional worktree_id), `codebyplan checkpoint update --branch-name` (break-glass: MCP `create_checkpoint` / `update_checkpoint`)
+- **Reads**: `.codebyplan/state/checkpoints/*.json` (local-first; `npx codebyplan sync` if stale; MCP `get_checkpoints` break-glass); `.codebyplan/repo.json`, `.codebyplan/git.json`
+- **Writes**: `codebyplan checkpoint create` (description-only ideas + deadline), `codebyplan checkpoint update --branch-name` (break-glass: MCP `create_checkpoint` / `update_checkpoint`)
 - **Triggers**: `/cbp-checkpoint-plan` (auto)

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

@@ -1,6 +1,7 @@
 ---
 name: cbp-checkpoint-end
 description: Single point for all shipment — branch promotion to main via /cbp-ship-main, runtime deploy via /cbp-ship, branch cleanup, summary. Standalone tasks bypass shipment entirely.
+model: inherit
 effort: xhigh
 ---
 
@@ -161,6 +162,10 @@ If `/cbp-ship` reports `aborted_at` (user aborted) or any surface failed verific
 
 If the repo has zero configured surfaces (very early-stage), `/cbp-ship` exits with `## No deployable surfaces configured` — that's a success state, continue to cleanup.
 
+#### Orchestration (optional)
+
+The multi-step shipment coordinated here (Step 5 `/cbp-ship-main` → Step 7 `/cbp-ship` → screenshot upload) MAY be expressed as a `Workflow(...)` pipeline instead of ad-hoc sequential invocation. This is opt-in (ultracode session or explicit user request); the sequential flow above stays the DEFAULT and is unchanged. See `rules/workflow-orchestration.md`.
+
 ### Step 7.5: Upload E2E Screenshots to DB (best-effort)
 
 After `/cbp-ship` completes successfully, upload the checkpoint's new/changed committed E2E screenshots to the CodeByPlan DB so they can be reviewed per-checkpoint in the web UI (CHK-171). This step is **best-effort and non-blocking** — a failure here MUST NOT halt shipment or cleanup.
@@ -260,6 +265,41 @@ After the feat branch git delete, run the same conditional Supabase teardown for
   - If not found: no-op silently — idempotent, not-found is success.
   - If the `list_branches` call itself fails (network, auth, or a non-success response — distinct from a successful lookup that returns no match): emit a non-blocking warning that the Supabase preview branch for `$FEAT_BRANCH` may still exist and should be verified in the dashboard. Do not treat an API failure as a not-found success.
 
+### Step 9.5: Physical Git-Worktree Cleanup
+
+After the feat branch has been git-deleted (Step 9), check whether a git worktree is still
+checked out to that now-deleted branch and clean it up if safe.
+
+```bash
+git worktree list --porcelain
+```
+
+Scan the output for any `worktree` entry whose `branch` field matches `refs/heads/$FEAT_BRANCH`
+(i.e. the feat branch just deleted in Step 9). For each matching worktree path:
+
+**Case A — the current session is NOT inside that worktree path:**
+
+```bash
+codebyplan worktree remove <path>
+git worktree prune
+```
+
+Record the removed path in `WORKTREES_REMOVED[]`. If `codebyplan worktree remove` exits
+non-zero, emit a non-blocking warning and continue — a failed removal does not halt shipment.
+
+**Case B — the current session IS inside that worktree path (i.e. `$PWD` starts with
+`<path>`):**
+
+Do NOT self-remove. Surface a single directive (no A/B/C menu):
+
+> "This session is inside the worktree at `<path>`. After switching to your main checkout,
+> run `codebyplan worktree remove <path>` to clean it up."
+
+Record the path in `WORKTREES_REMOVED[]` as `{ path, status: 'pending_manual_cleanup' }`.
+
+If `git worktree list --porcelain` finds no worktree checked out to the deleted feat branch,
+skip this step silently — `WORKTREES_REMOVED` stays empty.
+
 ### Step 10: Save Shipment Results and Summary
 
 Update checkpoint context via `codebyplan checkpoint update <id> --context '{"shipment": {...}}'` (CLI write-through); use MCP `update_checkpoint` as documented break-glass when the CLI is unavailable. The `shipment` block contains both branch promotion AND runtime surface results (from `/cbp-ship` Step 7):
@@ -275,6 +315,7 @@ context.shipment: {
   stale_branches_cleaned: [list of deleted git branches],
   feat_branch_deleted: true/false,
   supabase_branches_deleted: [list of Supabase preview branch names removed in Steps 8–9],
+  worktrees_removed: WORKTREES_REMOVED,      // from Step 9.5 — paths removed or pending manual cleanup
   e2e_images_uploaded: E2E_IMAGES_UPLOADED   // from Step 7.5 — { count, stored_paths, skipped, error? } (CHK-171)
 }
 ```
@@ -305,6 +346,7 @@ Present summary:
 - Stale branches deleted: [N] ([list])
 - Feat branch: [deleted/kept]
 - Supabase preview branches deleted: [N] ([list from supabase_branches_deleted], or "none")
+- Git worktrees cleaned: [N] ([paths from worktrees_removed], or "none")
 
 ### Before/After Branch State
 - Before: [list of feat/* branches]

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

@@ -2,12 +2,13 @@
 name: cbp-checkpoint-plan
 description: Deep inline planning for a checkpoint — assess, gap-analyse, decide dependencies, compare alternatives, optionally e2e-probe a suspected-broken area, then create tasks as vertical slices. Runs after /cbp-checkpoint-create (mechanical) and before /cbp-checkpoint-start (activate + claim). Does NOT activate or claim.
 argument-hint: [checkpoint-number]
+model: inherit
 effort: xhigh
 ---
 
 # Checkpoint Plan Command
 
-Runs INLINE (no subagent) — all analysis and Q&A stay in the main session. This is the rigour stage that prevents half-baked plans: it discovers shortcomings, decides whether existing dependencies suffice or a new one is warranted, compares competing approaches, and only THEN creates tasks. It produces `plan.steps[]` + tasks but **never activates the checkpoint and never claims a user/worktree** — that is `/cbp-checkpoint-start`.
+Runs INLINE (no subagent) — all analysis and Q&A stay in the main session. This is the rigour stage that prevents half-baked plans: it discovers shortcomings, decides whether existing dependencies suffice or a new one is warranted, compares competing approaches, and only THEN creates tasks. It produces `plan.steps[]` + tasks but **never activates the checkpoint and never claims a user** — that is `/cbp-checkpoint-start`.
 
 ## Pipeline
 
@@ -36,7 +37,7 @@ Malformed (non-numeric, contains `-`): surface `checkpoint-plan: invalid argumen
 2. Read task files under `.codebyplan/state/checkpoints/<id>/tasks/*.json` (fallback: MCP `get_tasks(checkpoint_id)`) — load existing tasks. This sets the mode:
    - **fresh** — zero tasks: full plan + create all tasks.
    - **additive re-plan** — tasks exist: gap-analyse against them; only ADD new tasks or refine requirements for gaps. NEVER delete or overwrite an in-flight task.
-3. Note whether `worktree_id` is set (claimed at create) — drives routing in Step 11.
+3. Note whether `assigned_user_id` is set (claimed at activation) — drives routing in Step 11.
 
 ### Step 2: Assess Ideas + Codebase
 
@@ -49,6 +50,10 @@ Iterate ALL `ideas[]` (not just the first). For each:
 
 Write each idea's analysis into `ideas[N].assessment` (Claude-authored; never touch `description`, which is the user's words).
 
+#### Orchestration (optional)
+
+Step 2's `cbp-research` and any e2e-probe subagent spawns MAY be authored as a `Workflow(...)` script instead of ad-hoc `Task` spawning — useful when multiple ideas each warrant an independent research/assessment pass. This is opt-in (ultracode session or explicit user request); the single-spawn flow above stays the DEFAULT and is unchanged. See `rules/workflow-orchestration.md`.
+
 ### Step 3: Gap Analysis
 
 Find what the raw request misses — this is the core anti-"half-ass" step. Load `reference/gap-analysis-playbook.md` and run its two passes:
@@ -129,16 +134,18 @@ Final write of the complete `checkpoint.context` JSONB via `codebyplan checkpoin
 ...
 ```
 
-This skill does **NOT** activate the checkpoint and does **NOT** claim a user/worktree.
+This skill does **NOT** activate the checkpoint and does **NOT** claim a user.
+
+Resolve the current user: `npx codebyplan whoami --json` → `user_id`.
 
-- **Claimed by THIS session** — `worktree_id` is set AND equals `npx codebyplan resolve-worktree 2>/dev/null`: auto-trigger `/cbp-checkpoint-start` in the same context (the creator carries momentum into activation).
-- **Otherwise** — `worktree_id` is null, set to a different worktree, or `resolve-worktree` is empty: surface a single directive — `Next: /cbp-checkpoint-start` — so the owning session (or anyone free, if open) claims and starts it. Never auto-activate a checkpoint owned by a different worktree.
+- **Open or yours** — `whoami` returns a `user_id` AND `assigned_user_id` is either null (unclaimed) or equals caller `user_id`: auto-trigger `/cbp-checkpoint-start` in the same context. `assigned_user_id` is stamped on activation, so a freshly-created checkpoint (null) is claimed by `/cbp-checkpoint-start` itself — the creator carries momentum into activation.
+- **Owned by another, or no identity** — `assigned_user_id` is non-null and differs from caller `user_id`, or `whoami` returns no `user_id`: surface a single directive — `Next: /cbp-checkpoint-start` — so the owning session (or anyone free, if open) claims and starts it. Never auto-activate a checkpoint owned by a different user.
 
 ## Integration
 
-- **Reads**: `.codebyplan/state/checkpoints/<id>.json`, `checkpoints/<id>/tasks/*.json`, `session/current.json` (local-first; `npx codebyplan sync` if stale; break-glass: MCP `get_current_task`, `get_checkpoints`, `get_tasks`)
+- **Reads**: `.codebyplan/state/checkpoints/<id>.json`, `checkpoints/<id>/tasks/*.json`, `session/current.json` (local-first; `npx codebyplan sync` if stale; break-glass: MCP `get_current_task`, `get_checkpoints`, `get_tasks`); `npx codebyplan whoami --json`
 - **Writes**: `codebyplan checkpoint update` (ideas assessment, context, plan, research), `codebyplan task create` (break-glass: MCP `update_checkpoint`, `create_task`)
 - **Spawns**: `cbp-research` (level 2+ only), config-matched `cbp-e2e-*` specialist (opt-in discovery probe, `whole_checkpoint_mode` — see `context/testing/e2e.md` dispatch contract)
 - **Triggered by**: `/cbp-checkpoint-create` (auto), or user directly
-- **Triggers**: `/cbp-checkpoint-start` (auto when claimed at create; directive when left open)
-- **Never**: activates the checkpoint or claims a user/worktree — that is `/cbp-checkpoint-start`
+- **Triggers**: `/cbp-checkpoint-start` (auto when open/unclaimed or assigned to the current user; directive when owned by another or no identity)
+- **Never**: activates the checkpoint or claims a user — that is `/cbp-checkpoint-start`

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

@@ -2,12 +2,13 @@
 name: cbp-checkpoint-start
 description: Activate a planned checkpoint and claim it for the current user/worktree, then route into task work. Runs after /cbp-checkpoint-plan (which produces tasks but never activates). Refuses to start an unplanned checkpoint.
 argument-hint: [checkpoint-number]
+model: inherit
 effort: high
 ---
 
 # Checkpoint Start Command
 
-The activation + claim gate of the checkpoint pipeline. `/cbp-checkpoint-plan` produces tasks but deliberately leaves the checkpoint `pending` and possibly unclaimed so it can sit in a team queue. This skill flips it to `active`, claims it for the caller's worktree if still open, and routes into the first task.
+The activation + claim gate of the checkpoint pipeline. `/cbp-checkpoint-plan` produces tasks but deliberately leaves the checkpoint `pending` and unclaimed so it can sit in a team queue. This skill flips it to `active` — the server auto-stamps `assigned_user_id` from the caller's JWT on activation — and routes into the first task.
 
 ## Pipeline
 
@@ -19,7 +20,13 @@ The activation + claim gate of the checkpoint pipeline. `/cbp-checkpoint-plan` p
 
 ### Step 0: Parse `$ARGUMENTS`
 
-Source `repo_id` from `.codebyplan/repo.json`. Resolve caller worktree once for the whole skill: `CALLER_WT=$(npx codebyplan resolve-worktree 2>/dev/null)`.
+Source `repo_id` from `.codebyplan/repo.json`. Resolve the current user once for the whole skill:
+
+```bash
+npx codebyplan whoami --json   # → {"user_id":"<uuid>","email":"…"} or null
+```
+
+`USER_ID` = `user_id` from the result (may be null for anonymous/keychain-empty callers).
 
 | Shape | Resolves to |
 |-------|-------------|
@@ -30,55 +37,57 @@ Malformed (non-numeric, contains `-`): surface `checkpoint-start: invalid argume
 
 ### Step 1: Load Checkpoint + Tasks
 
-Read `.codebyplan/state/checkpoints/<id>.json` for `status`, `worktree_id`, `plan` (local-first; if missing/stale run `npx codebyplan sync` once; break-glass: MCP `get_checkpoints`). Read task files under `.codebyplan/state/checkpoints/<id>/tasks/*.json` (fallback: MCP `get_tasks(checkpoint_id)`).
+Read `.codebyplan/state/checkpoints/<id>.json` for `status`, `assigned_user_id`, `plan` (local-first; if missing/stale run `npx codebyplan sync` once; break-glass: MCP `get_checkpoints`). Read task files under `.codebyplan/state/checkpoints/<id>/tasks/*.json` (fallback: MCP `get_tasks(checkpoint_id)`).
 
 ### Step 2: Planned-Gate
 
 A checkpoint must be planned before it can start.
 
-- **No tasks AND empty `plan.steps[]`** → refuse: surface `CHK-NNN is not planned yet.` and auto-trigger `/cbp-checkpoint-plan {NNN}`. STOP. (An unplanned checkpoint is `worktree_id`-null, so there is nothing to own yet — always kick off planning, matching `/cbp-todo` Rule A.)
+- **No tasks AND empty `plan.steps[]`** → refuse: surface `CHK-NNN is not planned yet.` and auto-trigger `/cbp-checkpoint-plan {NNN}`. STOP. (An unplanned checkpoint is unassigned, so there is nothing to own yet — always kick off planning, matching `/cbp-todo` Rule A.)
 - **Already `active`** → no activation needed; skip to Step 3 for a claim-check only, then Step 5.
 - **`pending` with tasks** → proceed.
 
 ### Step 3: Claim Logic
 
-Compare the checkpoint's `worktree_id` against `CALLER_WT`:
+Compare the checkpoint's `assigned_user_id` against `USER_ID`:
 
-| Checkpoint `worktree_id` | Action |
-|--------------------------|--------|
-| null (left open at create) | Claim it: in Step 4 pass `worktree_id: CALLER_WT`. If `CALLER_WT` is empty, warn the checkpoint will stay unclaimed and proceed without it. |
-| equals `CALLER_WT` | Already yours — no-op. |
-| a DIFFERENT worktree | STOP. Surface: `CHK-NNN is claimed by worktree {other}; current worktree is {CALLER_WT}. If {other} is dead, a maintainer can release it via the release_assignment MCP tool, then re-run /cbp-checkpoint-start.` Do not activate. |
+| Checkpoint `assigned_user_id` | Action |
+|-------------------------------|--------|
+| null (open — not yet claimed) | Proceed to Step 4 activation. The server will stamp `assigned_user_id = USER_ID` (from JWT) on `status=active`. If `USER_ID` is null (anonymous caller), warn the checkpoint will stay unclaimed and proceed. |
+| equals `USER_ID` | Already yours — no-op. Proceed to Step 5. |
+| a DIFFERENT user (non-null) | STOP. Surface: `CHK-NNN is assigned to user <assigned_user_id-email-or-uuid>; you are <USER_ID-email-or-uuid>. Ask the owner to release the assignment, or a maintainer can use the release_assignment tool, then re-run /cbp-checkpoint-start.` Do not activate. |
 
-This mirrors the CHK-104 hard-lock model — never wrest a checkpoint from a live worktree.
+Never wrest a checkpoint from another user.
 
 ### Step 4: Activate
 
-If the checkpoint is already `active` AND `worktree_id` already equals `CALLER_WT` (the Step 3 no-op row), skip this step entirely and proceed to Step 5 — nothing to write.
+If the checkpoint is already `active` AND `assigned_user_id` already equals `USER_ID` (the Step 3 no-op row), skip this step entirely and proceed to Step 5 — nothing to write.
+
+Otherwise set the checkpoint `active` via `codebyplan checkpoint update --id <checkpoint-id> --status active` (CLI write-through; break-glass: MCP `update_checkpoint`). The server auto-stamps `assigned_user_id = ctx.userId` (from the JWT) on activation — no client-side user param required. After the write, read the row back to confirm `assigned_user_id` is non-null.
 
-Otherwise set the checkpoint `active` via `codebyplan checkpoint update --id <checkpoint-id> --status active` (CLI write-through; break-glass: MCP `update_checkpoint`), plus `--worktree-id CALLER_WT` when claiming per Step 3. For MCP break-glass path: `caller_worktree_id` identifies the calling worktree and is auto-injected by the `cbp-mcp-caller-worktree-inject.sh` PreToolUse hook (CHK-198 TASK-2); the server falls back to the repo `main` worktree only when it is absent. If the checkpoint was already `active` but a claim is still needed, skip the status write and only write `worktree_id`.
+If the checkpoint was already `active` but `assigned_user_id` is still null (edge case: prior activation without a valid JWT), re-read and surface a warning rather than silently proceeding.
 
 ### Step 5: Route
 
 Follow the close-out routing convention — auto-trigger the next same-context step, never an A/B/C menu. `{first-pending-task}` is the lowest-numbered pending task from Step 1 (not necessarily TASK-1, since additive re-planning may have completed earlier ones):
 
-- **Claimed by THIS session** (`CALLER_WT` now owns the checkpoint): auto-trigger `/cbp-task-start {chk}-{first-pending-task}` in the same context.
-- **`CALLER_WT` empty / unresolved**: surface a single directive — `Next: /cbp-task-start {chk}-{first-pending-task}` — and let the user proceed.
+- **Claimed by THIS session** (`USER_ID` is non-null and now owns the checkpoint): auto-trigger `/cbp-task-start {chk}-{first-pending-task}` in the same context.
+- **`USER_ID` null / anonymous**: surface a single directive — `Next: /cbp-task-start {chk}-{first-pending-task}` — and let the user proceed.
 
 Show a one-line confirmation before routing:
 
 ```
 ## Checkpoint Started
 
-**CHK-NNN**: [title]  •  **Status**: active  •  **Claimed by**: [worktree or "open"]
+**CHK-NNN**: [title]  •  **Status**: active  •  **Claimed by**: [user email or "open"]
 **Next task**: TASK-[N] — [title]
 **Worktree**: `npx codebyplan worktree add CHK-{NNN}`
 ```
 
 ## Integration
 
-- **Reads**: `.codebyplan/state/checkpoints/<id>.json`, `checkpoints/<id>/tasks/*.json` (local-first; `npx codebyplan sync` if stale; break-glass: MCP `get_checkpoints`, `get_tasks`); `npx codebyplan resolve-worktree`
-- **Writes**: `codebyplan checkpoint update --status active [--worktree-id <id>]` (CLI write-through; break-glass: MCP `update_checkpoint`; `caller_worktree_id` auto-injected by cbp-mcp-caller-worktree-inject.sh hook on the MCP path)
-- **Triggered by**: `/cbp-checkpoint-plan` (auto when claimed at create), `/cbp-todo` (planned-but-pending gate), or user directly
+- **Reads**: `.codebyplan/state/checkpoints/<id>.json`, `checkpoints/<id>/tasks/*.json` (local-first; `npx codebyplan sync` if stale; break-glass: MCP `get_checkpoints`, `get_tasks`); `npx codebyplan whoami --json`
+- **Writes**: `codebyplan checkpoint update --status active` (CLI write-through; break-glass: MCP `update_checkpoint`; server auto-stamps `assigned_user_id` from JWT on activation)
+- **Triggered by**: `/cbp-checkpoint-plan` (auto when open/unclaimed or assigned to the current user), `/cbp-todo` (planned-but-pending gate), or user directly
 - **Triggers**: `/cbp-task-start` (auto when claimed), or `/cbp-checkpoint-plan` (when the checkpoint is unplanned)
 - **Never**: plans or creates tasks — that is `/cbp-checkpoint-plan`

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

@@ -2,7 +2,8 @@
 name: cbp-checkpoint-update
 description: Update checkpoint state (activate, update context, etc.)
 argument-hint: [checkpoint-number]
-effort: high
+model: inherit
+effort: medium
 ---
 
 # Checkpoint Update Command
@@ -42,7 +43,7 @@ Given the parse from Step 0.5:
 | Parse | Resolution path |
 |-------|-----------------|
 | `{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`). |
+| _(empty)_ | Read `.codebyplan/state/session/current.json` 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-finalize` expand path)