codebyplan 1.13.13 → 1.13.15

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

@@ -5,6 +5,27 @@ description: Summary wrap-up after testing phase completes
 effort: high
 ---
 
+## Kind Detection
+
+Inspect the resolved identifier from argument parsing to determine the task kind:
+
+| Identifier shape | KIND |
+|-----------------|------|
+| `{task}-{round}` (2-segment, e.g. `45-2`) | `standalone` |
+| `{chk}-{task}-{round}` (3-segment, e.g. `141-3-1`) | `checkpoint` |
+| _(empty / free-text)_ | Check `get_current_standalone_task` first; if found → `standalone`. Else → `checkpoint` via `get_current_task`. |
+
+Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
+
+| Operation | `checkpoint` KIND | `standalone` KIND |
+|-----------|------------------|-------------------|
+| Get task | `get_current_task(repo_id)` | `get_current_standalone_task(repo_id)` |
+| Get rounds | `get_rounds(task_id)` | `get_standalone_rounds(standalone_task_id)` |
+| Add round | `add_round(task_id, ...)` | `add_standalone_round(standalone_task_id, ...)` |
+| Update round | `update_round(round_id, ...)` | `update_standalone_round(standalone_round_id, ...)` |
+| Complete round | `complete_round(round_id, duration_minutes?)` | `complete_standalone_round(standalone_round_id, duration_minutes?, caller_worktree_id)` ⚠️ `caller_worktree_id` is REQUIRED for standalone |
+| Update task | `update_task(task_id, ...)` | `update_standalone_task(standalone_task_id, ...)` |
+
 # Round End Command
 
 Summary phase — presents what was done, then runs code quality review to catch bugs and logic errors that automated checks miss.
@@ -21,14 +42,16 @@ See `reference/inline-fallback.md` for full trigger table, procedure, and covera
 
 ## Identifier Notation
 
-This skill operates on the **active** task/round resolved via MCP `get_current_task` / `get_rounds` and does not accept a positional identifier argument. Canonical chk-task-round notation — used in prose, error messages, and cross-references — follows `.claude/rules/notation-consistency.md` "CHK / TASK / ROUND Identifier Notation": `108-1` (CHK-108 TASK-1), `45` (standalone TASK-45), `108-1-2` (round 2 of CHK-108 TASK-1), `45-2` (round 2 of standalone TASK-45).
+This skill operates on the **active** task/round resolved via MCP and does not accept a positional identifier argument. Canonical chk-task-round notation — used in prose, error messages, and cross-references — follows `.claude/rules/notation-consistency.md` "CHK / TASK / ROUND Identifier Notation": `108-1` (CHK-108 TASK-1), `45` (standalone TASK-45), `108-1-2` (round 2 of CHK-108 TASK-1), `45-2` (round 2 of standalone TASK-45).
 
 ## Instructions
 
 ### Step 1: Get Current Task and Round
 
-Use MCP `get_current_task` with repo_id (pass `checkpoint_id` if known to avoid disambiguation) to find the active task.
-Use MCP `get_rounds` for the task to find the in-progress round.
+Use Kind Detection above to set KIND. Then:
+
+- **checkpoint KIND**: MCP `get_current_task(repo_id)` (pass `checkpoint_id` if known) to find the active task. MCP `get_rounds(task_id)` to find the in-progress round.
+- **standalone KIND**: MCP `get_current_standalone_task(repo_id)` to find the active task. MCP `get_standalone_rounds(standalone_task_id)` to find the in-progress round.
 
 Load round context with all outputs (executor_output, testing_qa_output, reviewer_output).
 
@@ -70,11 +93,11 @@ Merge with previous rounds (supersede items for re-modified files, preserve veri
 
 ### Step 4: Update Task Files and QA
 
-Update via MCP:
+Update via MCP using KIND-appropriate tools:
 
-- `update_task(task_id, files_changed: [...])` — merge with existing
-- `update_round(round_id, files_changed: [...], qa: {items: [auto_qa items + default_checklist items]})` — round-specific
-- `update_task(task_id, qa: {items: [auto_qa items + default_checklist items]})` — aggregated
+- `update_task(task_id, files_changed: [...])` / `update_standalone_task(standalone_task_id, files_changed: [...])` — merge with existing
+- `update_round(round_id, files_changed: [...], qa: {items: [auto_qa items + default_checklist items]})` / `update_standalone_round(standalone_round_id, ...)` — round-specific
+- `update_task(task_id, qa: {items: [auto_qa items + default_checklist items]})` / `update_standalone_task(standalone_task_id, qa: {items: [auto_qa items + default_checklist items]})` — aggregated
 
 ### Step 5: Present Summary
 
@@ -137,8 +160,8 @@ Example tables and the `inline` option gating spec: see `reference/findings-pres
 - Auto-accept ALL findings into `improve_round_findings[]` regardless of severity (the user opted into the loop).
 - Skip the polish-spiral stop-gate (auto-loop has its own cap-exhausted termination).
 - Skip the user findings-decision prompt.
-- Save findings via `update_round` exactly as in manual mode.
-- Auto-trigger `/cbp-round-update` immediately. round-update Step 6 will decide whether to spawn another round or exit clean (see cbp-round-update SKILL.md Step 6).
+- Save findings via `update_round` / `update_standalone_round` per KIND exactly as in manual mode.
+- Auto-trigger `/cbp-round-update` immediately. round-update Step 4 will decide whether to spawn another round or exit clean (see cbp-round-update SKILL.md Step 4).
 
 **Else (manual mode — flag absent or false):**
 
@@ -146,7 +169,7 @@ Run the existing flow:
 
 1. After round 2+, surface the polish-spiral stop-gate per `polish-spiral-stop-gate.md` (defer-to-followups vs continue).
 2. Surface the findings-decision AskUserQuestion (with optional `inline` per the gating rules in `reference/findings-presentation.md`).
-3. Save accepted/rejected findings to round context via MCP `update_round`:
+3. Save accepted/rejected findings to round context via MCP `update_round` / `update_standalone_round` per KIND:
    ```json
    {
      "context": {
@@ -167,7 +190,7 @@ Run the existing flow:
 ## Integration
 
 - **Triggered by**: `/cbp-round-execute` (auto, after all waves + testing complete)
-- **Reads**: MCP `get_current_task`, `get_rounds`, round context
-- **Writes**: MCP `update_round`, `update_task` (files_changed, qa, findings)
+- **Reads**: MCP `get_current_task` / `get_current_standalone_task`, `get_rounds` / `get_standalone_rounds` (per KIND), round context
+- **Writes**: MCP `update_round` / `update_standalone_round`, `update_task` / `update_standalone_task` (files_changed, qa, findings) — per KIND
 - **Spawns**: `cbp-improve-round` (code quality review)
 - **Triggers**: `/cbp-round-update` (auto, after findings handled)

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

@@ -5,6 +5,27 @@ description: Execute the approved plan from /cbp-round-start — runs per-wave e
 effort: xhigh
 ---
 
+## Kind Detection
+
+Inspect the resolved identifier from argument parsing to determine the task kind:
+
+| Identifier shape | KIND |
+|-----------------|------|
+| `{task}-{round}` (2-segment, e.g. `45-2`) | `standalone` |
+| `{chk}-{task}-{round}` (3-segment, e.g. `141-3-1`) | `checkpoint` |
+| _(empty / free-text)_ | Check `get_current_standalone_task` first; if found → `standalone`. Else → `checkpoint` via `get_current_task`. |
+
+Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
+
+| Operation | `checkpoint` KIND | `standalone` KIND |
+|-----------|------------------|-------------------|
+| Get task | `get_current_task(repo_id)` | `get_current_standalone_task(repo_id)` |
+| Get rounds | `get_rounds(task_id)` | `get_standalone_rounds(standalone_task_id)` |
+| Add round | `add_round(task_id, ...)` | `add_standalone_round(standalone_task_id, ...)` |
+| Update round | `update_round(round_id, ...)` | `update_standalone_round(standalone_round_id, ...)` |
+| Complete round | `complete_round(round_id, duration_minutes?)` | `complete_standalone_round(standalone_round_id, duration_minutes?, caller_worktree_id)` ⚠️ `caller_worktree_id` is REQUIRED for standalone |
+| Update task | `update_task(task_id, ...)` | `update_standalone_task(standalone_task_id, ...)` |
+
 # Round Execute Command
 
 Execution and validation phase. Receives the approved plan from `/cbp-round-start`, dispatches wave executors, runs per-wave `cbp-testing-qa-agent` in parallel, and routes to `/cbp-round-end`.
@@ -17,14 +38,16 @@ Execution and validation phase. Receives the approved plan from `/cbp-round-star
 
 ## Identifier Notation
 
-This skill operates on the **active** task/round resolved via MCP `get_current_task` / `get_rounds` and does not accept a positional identifier argument. Canonical chk-task-round notation — used in prose, error messages, and cross-references — follows `.claude/rules/notation-consistency.md` "CHK / TASK / ROUND Identifier Notation": `108-1` (CHK-108 TASK-1), `45` (standalone TASK-45), `108-1-2` (round 2 of CHK-108 TASK-1), `45-2` (round 2 of standalone TASK-45).
+This skill operates on the **active** task/round resolved via MCP and does not accept a positional identifier argument. Canonical chk-task-round notation — used in prose, error messages, and cross-references — follows `.claude/rules/notation-consistency.md` "CHK / TASK / ROUND Identifier Notation": `108-1` (CHK-108 TASK-1), `45` (standalone TASK-45), `108-1-2` (round 2 of CHK-108 TASK-1), `45-2` (round 2 of standalone TASK-45).
 
 ## Instructions
 
 ### Step 1: Get Current Task and Round
 
-Use MCP `get_current_task` with repo_id (pass checkpoint_id if known) to find the active task.
-Use MCP `get_rounds` for the task to find the in-progress round.
+Use Kind Detection above to set KIND. Then:
+
+- **checkpoint KIND**: MCP `get_current_task(repo_id)` (pass checkpoint_id if known) to find the active task. MCP `get_rounds(task_id)` to find the in-progress round.
+- **standalone KIND**: MCP `get_current_standalone_task(repo_id)` to find the active task. MCP `get_standalone_rounds(standalone_task_id)` to find the in-progress round.
 
 If no in-progress round: `No active round. Run /cbp-round-start first.`
 
@@ -161,11 +184,35 @@ Input contracts: `cbp-testing-qa-agent` receives `executor_output`, `testing_pro
 
 ### Step 5b: Post-E2E Screenshot Review (cbp-frontend-ui Phase 6.5)
 
-Aggregate screenshots across ALL specialists that ran: `screenshots = Object.values(round.context.e2e_outputs ?? {}).flatMap(o => o.screenshots ?? [])`. When the aggregated list is non-empty, invoke the `cbp-frontend-ui` skill with `phase: 'screenshot_review'` (input: `files_changed`, `e2e_screenshots: <aggregated screenshots>`, `context: { checkpoint_goal, round_requirements }`). Under this phase the skill runs only Phase 6.5 (Rendered-Output Visual Review) + 7 + 8 — Phases 1-6 (style) already ran inline at executor Step 3.8 with `phase: 'style_only'`.
+Aggregate across ALL specialists that ran:
+
+```js
+screenshots = Object.values(round.context.e2e_outputs ?? {}).flatMap(o => o.screenshots ?? []);
+e2e_gallery  = Object.values(round.context.e2e_outputs ?? {}).flatMap(o => o.e2e_gallery  ?? []);
+```
+
+**Auto-new baseline handling**: for each entry in `e2e_gallery` where `is_new === true`, the
+specialist has already run `git add <committed_path>`. No additional user gate is needed.
+**Changed-baseline handling**: entries where `is_new === false` AND `baseline_diff_pct > threshold`
+are `visual_regression` — do NOT auto-accept; surface as blocking gate at Step 7.
+
+Persist `e2e_gallery` to `round.context.e2e_gallery` (additive alongside existing
+`round.context.e2e_outputs`). This field is consumed by TASK-3 / checkpoint-end for DB upload.
+Note: `e2e_gallery[]` is aggregated and persisted regardless of whether `cbp-frontend-ui` runs — the empty-gallery enforcement lives in `cbp-task-check` Phase 4, while the `screenshots[]` visual review (frontend-ui Phase 6.5) is a separate concern gated on `screenshots[]` being non-empty.
+
+When the aggregated `screenshots` list is non-empty, invoke the `cbp-frontend-ui` skill with
+`phase: 'screenshot_review'` (input: `files_changed`, `e2e_screenshots: <aggregated screenshots>`,
+`context: { checkpoint_goal, round_requirements }`). Under this phase the skill runs only
+Phase 6.5 (Rendered-Output Visual Review) + 7 + 8 — Phases 1-6 (style) already ran at Step 3.8.
 
-Persist findings to `round.context.frontend_ui_review` (merge with Step 3.8's style-only output if present). Baseline-regression findings surface as a BLOCKING gate at `/cbp-round-end` Step 7 (an explicit accept-or-fix user decision; baselines are NEVER auto-accepted); rendered_visual critical findings are surfaced in the Step 7 findings presentation. Neither auto-fails the round. cbp-testing-qa-agent does NOT read these findings (full independence per Step 5).
+Persist findings to `round.context.frontend_ui_review` (merge with Step 3.8's style-only output
+if present). Baseline-regression findings surface as a BLOCKING gate at `/cbp-round-end` Step 7
+(an explicit accept-or-fix user decision; changed baselines are NEVER auto-accepted);
+rendered_visual critical findings are surfaced in the Step 7 findings presentation. Neither
+auto-fails the round. cbp-testing-qa-agent does NOT read these findings (full independence).
 
-**Skip** when `round.context.e2e_outputs` is absent/empty, the aggregated `screenshots` list is empty, or `testing_profile === 'claude_only'`.
+**Skip** when `round.context.e2e_outputs` is absent/empty, the aggregated `screenshots` list
+is empty, or `testing_profile === 'claude_only'`.
 
 ### Step 6: Hard-Fail Routing
 
@@ -178,7 +225,7 @@ Per-wave hard-fail signal — true when ANY hold:
 **All waves hard_fail: false** → proceed to Step 7. **Any wave hard_fail: true**:
 
 - **Simple fixes** (type errors, lint, missing imports, test assertion fixes, e2e `real`-category with clear code-side root cause, no prior re-trigger this round) → save failure details to round context; retrigger the failing wave's executor; re-run testing-qa AND the eligible `cbp-e2e-*` specialists for that wave.
-- **Structural OR already re-triggered once OR e2e preflight aborts OR `e2e_eligible_skipped`** → save failure context via MCP `update_round`; auto-trigger `/cbp-round-input`. STOP.
+- **Structural OR already re-triggered once OR e2e preflight aborts OR `e2e_eligible_skipped`** → save failure context via MCP `update_round` / `update_standalone_round` per KIND; auto-trigger `/cbp-round-input`. STOP.
 
 ## Inline execution fallback
 
@@ -190,11 +237,11 @@ When `cbp-testing-qa-agent` spawn fails OR the resolved `testing_profile` is `cl
 
 ### Step 7: Save Executor Output
 
-Update round context via MCP `update_round`:
+Update round context via MCP `update_round` / `update_standalone_round` per KIND:
 
-- `context`: { ...existing, executor_output, testing_qa_output, e2e_eligible, e2e_outputs, frontend_ui_review }
+- `context`: { ...existing, executor_output, testing_qa_output, e2e_eligible, e2e_outputs, e2e_gallery, frontend_ui_review }
 
-`e2e_outputs` (a framework-keyed map of specialist outputs, e.g. `{ playwright: {...}, maestro: {...} }`) and `frontend_ui_review` are present only when the gates above admitted them (≥1 eligible framework ran AND Step 5b ran). `e2e_eligible[]` records which frameworks were eligible this round and drives the Step 6 `e2e_eligible_skipped` check.
+`e2e_outputs` (a framework-keyed map of specialist outputs, e.g. `{ playwright: {...}, maestro: {...} }`), `e2e_gallery` (aggregated flat array of committed-PNG entries across all specialists — consumed by TASK-3 / checkpoint-end for DB upload), and `frontend_ui_review` are present only when the gates above admitted them (≥1 eligible framework ran AND Step 5b ran). `e2e_eligible[]` records which frameworks were eligible this round and drives the Step 6 `e2e_eligible_skipped` check.
 
 ### Step 8: Auto-trigger Round End
 
@@ -211,13 +258,13 @@ Trigger `/cbp-round-end`.
 - `testing_profile` from `task.context` governs which checks run — read it once in Step 2; pass to every testing-qa + e2e specialist spawn
 - `claude_only` profile skips all agent spawns (testing-qa AND `cbp-e2e-*`); runs hook syntax and skill structure checks inline
 - E2E dispatch is **config-driven and opt-out** (`.codebyplan/e2e.json`), not gated on `has_ui_work`/`testing_profile` — an eligible framework that silently does not run is an `e2e_eligible_skipped` hard-fail (`rules/e2e-mandatory.md`)
-- Step 5b (cbp-frontend-ui Phase 6.5) runs only when e2e produced screenshots — gated on the aggregated `e2e_outputs[*].screenshots[]` being non-empty
+- Step 5b (cbp-frontend-ui Phase 6.5) runs only when e2e produced screenshots — gated on the aggregated `e2e_outputs[*].screenshots[]` being non-empty; `e2e_gallery[]` is always aggregated and persisted when any specialist ran
 - Claude NEVER git adds files in round commands
 
 ## Integration
 
-- **Reads**: MCP `get_current_task`, `get_rounds`
-- **Writes**: MCP `update_round` (context with executor_output + testing_qa_output + e2e_eligible + e2e_outputs + frontend_ui_review)
+- **Reads**: MCP `get_current_task` / `get_current_standalone_task`, `get_rounds` / `get_standalone_rounds` (per KIND)
+- **Writes**: MCP `update_round` / `update_standalone_round` (context with executor_output + testing_qa_output + e2e_eligible + e2e_outputs + e2e_gallery + frontend_ui_review) — per KIND
 - **Spawns**: `cbp-round-executor` (per wave or single), `cbp-testing-qa-agent` (per wave, parallel sibling of the `cbp-e2e-*` specialists), the `cbp-e2e-*` specialists (config-driven dispatch per `context/testing/e2e.md`, one per eligible framework in `.codebyplan/e2e.json`), `cbp-database-agent` (if DB work), `cbp-security-agent` (if security review needed)
 - **Skill invocations**: `cbp-frontend-ui` at Step 5b with `phase: 'screenshot_review'` (post-e2e)
 - **Triggers**: `/cbp-round-end` (auto)

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

@@ -6,6 +6,27 @@ argument-hint: [chk-task-round | task-round | requirements-text]
 effort: xhigh
 ---
 
+## Kind Detection
+
+Inspect the resolved identifier from argument parsing to determine the task kind:
+
+| Identifier shape | KIND |
+|-----------------|------|
+| `{task}-{round}` (2-segment, e.g. `45-2`) | `standalone` |
+| `{chk}-{task}-{round}` (3-segment, e.g. `141-3-1`) | `checkpoint` |
+| _(empty / free-text)_ | Check `get_current_standalone_task` first; if found → `standalone`. Else → `checkpoint` via `get_current_task`. |
+
+Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
+
+| Operation | `checkpoint` KIND | `standalone` KIND |
+|-----------|------------------|-------------------|
+| Get task | `get_current_task(repo_id)` | `get_current_standalone_task(repo_id)` |
+| Get rounds | `get_rounds(task_id)` | `get_standalone_rounds(standalone_task_id)` |
+| Add round | `add_round(task_id, ...)` | `add_standalone_round(standalone_task_id, ...)` |
+| Update round | `update_round(round_id, ...)` | `update_standalone_round(standalone_round_id, ...)` |
+| Complete round | `complete_round(round_id, duration_minutes?)` | `complete_standalone_round(standalone_round_id, duration_minutes?, caller_worktree_id)` ⚠️ `caller_worktree_id` is REQUIRED for standalone |
+| Update task | `update_task(task_id, ...)` | `update_standalone_task(standalone_task_id, ...)` |
+
 # Round Input Command
 
 Gathers input for a new round. Performs deep analysis of unapproved files, requirements coverage, and testing-QA failures before formulating requirements. Follow-up rounds get the same depth as round 1.
@@ -28,7 +49,7 @@ Try the numeric identifier regex first: `^[0-9]+(-[0-9]+){0,2}$`
 | `{task}` (e.g. `45`) | 1 | Standalone TASK-{task} next round (matches cbp-task-start standalone convention) |
 | `{chk}-{task}` (e.g. `108-1`) | 2 | CHK-{chk} TASK-{task} next round (round number implicit — round-input creates a new round) |
 | `{chk}-{task}-{round}` (e.g. `108-1-2`) | 3 | CHK-{chk} TASK-{task} targeting ROUND-{round} (existing round context) |
-| _(no match / empty)_ | — | Free-text requirements (passed through to Step 5) OR empty → use `get_current_task` |
+| _(no match / empty)_ | — | Free-text requirements (passed through to Step 5) OR empty → use Kind Detection |
 
 If the argument matches the numeric regex, resolve the target task/round from DB. If no match (or empty), treat the argument as free-text requirements and proceed to Step 2 for context (free-text path still runs deep analysis before Step 5).
 
@@ -37,16 +58,16 @@ If the argument matches the numeric regex, resolve the target task/round from DB
 - `round-input 45` → standalone TASK-45 next round
 - `round-input 108-1` → CHK-108 TASK-1 next round
 - `round-input 108-1-2` → CHK-108 TASK-1 ROUND-2
-- `round-input` (no arg) → active task via `get_current_task`
+- `round-input` (no arg) → active task via Kind Detection
 - `round-input Fix the broken lint rule in the auth module` → free-text requirements (numeric regex fails → falls through to free-text path)
 
 > **Note on 2-segment divergence**: `round-input 108-1` resolves to **CHK-108 TASK-1** (targeting that task's next round). This diverges from `/cbp-round-start` where the 2-segment `108-1` means **standalone TASK-108 ROUND-1**. Round-input always operates on a task-level context (it creates a new round on a task), so the round number is implicit and 2 segments are interpreted as `{chk}-{task}`. To target a standalone task here, use the 1-segment form `45`. To target a specific existing round, use the 3-segment form `108-1-2`.
 
 ### Step 2: Deep Analysis (MANDATORY — always runs)
 
-**2a:** Load task via MCP `get_current_task` (pass `checkpoint_id` if known to avoid disambiguation) — get `files_changed`, `requirements`, `context`, `qa`
+**2a:** Load task via KIND-appropriate MCP tool (`get_current_task` or `get_current_standalone_task`) — get `files_changed`, `requirements`, `context`, `qa`
 
-**2b:** Load all rounds via MCP `get_rounds(task_id)` — get previous round context, testing-qa output
+**2b:** Load all rounds via MCP `get_rounds(task_id)` (checkpoint KIND) or `get_standalone_rounds(standalone_task_id)` (standalone KIND) — get previous round context, testing-qa output
 
 **2c:** Identify unapproved files from `task.files_changed` where `user_approved === false`
 
@@ -123,10 +144,10 @@ Based on the analysis + user input, create detailed requirements that:
 
 If the new round requirements change the task direction:
 
-1. Update task context via MCP `update_task(task_id, context: { ... })`:
+1. Update task context via MCP `update_task(task_id, context: { ... })` / `update_standalone_task(standalone_task_id, context: { ... })` per KIND:
    - Add new decisions to `context.decisions[]`
    - Update `context.discoveries[]` if applicable
-2. If checkpoint-level changes needed, update checkpoint context via MCP `update_checkpoint`
+2. If checkpoint-level changes needed (checkpoint KIND only), update checkpoint context via MCP `update_checkpoint`
 
 ### Step 7: Auto-trigger Round Start
 
@@ -145,8 +166,8 @@ Trigger `/cbp-round-start` with the round requirements as arguments.
 If this command is triggered **directly** (not via `/cbp-todo`) and no context is available in the session:
 
 1. Read `.codebyplan/repo.json` for `repo_id`
-2. Use MCP `get_current_task` to load checkpoint + task
-3. Use MCP `get_rounds(task_id)` to load round history
+2. Use Kind Detection to determine KIND, then use the appropriate MCP tool to load checkpoint + task
+3. Use MCP `get_rounds(task_id)` / `get_standalone_rounds(standalone_task_id)` per KIND to load round history
 4. Continue from Step 2 (deep analysis handles all context loading)
 
 ## Key Rules
@@ -160,6 +181,6 @@ If this command is triggered **directly** (not via `/cbp-todo`) and no context i
 ## Integration
 
 - **Triggered by**: `/cbp-round-update` (auto, unapproved files), `/cbp-round-execute` (auto, on hard-fail after retry exhausted), `/cbp-todo` (after /clear), user manually
-- **Reads**: MCP `get_current_task`, `get_rounds`, file contents (Read tool)
-- **Writes**: MCP `update_task` (context), `update_checkpoint` (context, if needed)
+- **Reads**: MCP `get_current_task` / `get_current_standalone_task`, `get_rounds` / `get_standalone_rounds` (per KIND), file contents (Read tool)
+- **Writes**: MCP `update_task` / `update_standalone_task` (context), `update_checkpoint` (context, if checkpoint KIND and needed)
 - **Triggers**: `/cbp-round-start` (auto)

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

@@ -7,6 +7,27 @@ argument-hint: [chk-task-round | task-round | requirements-text]  # e.g. `108-1-
 effort: xhigh
 ---
 
+## Kind Detection
+
+Inspect the resolved identifier from argument parsing to determine the task kind:
+
+| Identifier shape | KIND |
+|-----------------|------|
+| `{task}-{round}` (2-segment, e.g. `45-2`) | `standalone` |
+| `{chk}-{task}-{round}` (3-segment, e.g. `141-3-1`) | `checkpoint` |
+| _(empty / free-text)_ | Check `get_current_standalone_task` first; if found → `standalone`. Else → `checkpoint` via `get_current_task`. |
+
+Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
+
+| Operation | `checkpoint` KIND | `standalone` KIND |
+|-----------|------------------|-------------------|
+| Get task | `get_current_task(repo_id)` | `get_current_standalone_task(repo_id)` |
+| Get rounds | `get_rounds(task_id)` | `get_standalone_rounds(standalone_task_id)` |
+| Add round | `add_round(task_id, ...)` | `add_standalone_round(standalone_task_id, ...)` |
+| Update round | `update_round(round_id, ...)` | `update_standalone_round(standalone_round_id, ...)` |
+| Complete round | `complete_round(round_id, duration_minutes?)` | `complete_standalone_round(standalone_round_id, duration_minutes?, caller_worktree_id)` ⚠️ `caller_worktree_id` is REQUIRED for standalone |
+| Update task | `update_task(task_id, ...)` | `update_standalone_task(standalone_task_id, ...)` |
+
 # Round Start Command
 
 Planning phase for a new round. Analyzes context, creates plan, gets user approval. NO execution or testing — those are separate commands.
@@ -31,7 +52,7 @@ Inline-fallback is NOT a quality downgrade trapdoor — Phase 1.5 row-by-row ver
 /cbp-round-start (planning) → [user approval] → /cbp-round-execute (auto)
 ```
 
-**Auto-loop mode**: when `round.context.auto_loop_mode === true` flows in from `/cbp-round-input`, Step 6 (Q&A) and Step 8 (user approval) skip user prompts. See cbp-round-update SKILL.md Step 6 (auto-loop decision) and cbp-round-end SKILL.md Step 8 for the full contract.
+**Auto-loop mode**: when `round.context.auto_loop_mode === true` flows in from `/cbp-round-input`, Step 6 (Q&A) and Step 8 (user approval) skip user prompts. See cbp-round-update SKILL.md Step 4 (auto-loop decision) and cbp-round-end SKILL.md Step 8 for the full contract.
 
 ## Instructions
 
@@ -44,7 +65,7 @@ Disambiguate the argument up front. Three input shapes (see `.claude/rules/notat
 | `{chk}-{task}-{round}` (e.g. `108-1-2`) | `^[0-9]+-[0-9]+-[0-9]+$` | **Identifier**: targets round {round} of CHK-{chk} TASK-{task}. Sets `target_checkpoint`, `target_task`, `target_round`. |
 | `{task}-{round}` (e.g. `45-2`) | `^[0-9]+-[0-9]+$` | **Identifier**: targets round {round} of standalone TASK-{task}. Sets `target_task`, `target_round` (no checkpoint). |
 | Non-empty, non-identifier-shaped | — | **Free-text round requirements** (the round-input passthrough path). |
-| _(empty)_ | — | No identifier, no requirements text — derive task/round from `get_current_task` / `get_rounds`. |
+| _(empty)_ | — | No identifier, no requirements text — derive task/round from Kind Detection above. |
 
 Malformed identifier shapes (`108-`, `-1-2`, `108--1`, `abc-1`) — surface this error and stop, mirroring `/cbp-task-start`'s error vocabulary:
 
@@ -62,7 +83,7 @@ round-start: invalid argument `{value}`. Expected:
 - `round-start 45-2` → resolve standalone TASK-45, target round 2
 - `round-start 108-1` → **standalone TASK-108 round 1** (NOT CHK-108 TASK-1). The 2-segment form means `{task}-{round}`; checkpoint-bound round-targeting requires all three numbers (`108-1-2`). If you got here trying to target CHK-108 TASK-1, you want `108-1-2` (specifying a round number) or `/cbp-task-start 108-1` (specifying just a task).
 - `round-start "Implement OAuth flow per CHK-X plan"` → free-text path; current-task/round derivation from state
-- `round-start` (empty) → derive from `get_current_task` / `get_rounds`; round 1 uses `task.requirements`
+- `round-start` (empty) → derive from Kind Detection; round 1 uses `task.requirements`
 - `round-start 108-` → error: malformed identifier
 - `round-start -1-2` → error: malformed identifier
 - `round-start abc-1` → error: malformed identifier
@@ -71,17 +92,17 @@ round-start: invalid argument `{value}`. Expected:
 
 ### Step 1: Get Current Task
 
-If Step 0 produced an identifier (`target_task` set): resolve directly per the identifier (bound or standalone) — MCP `get_checkpoints` + `get_tasks`, or `get_tasks(standalone: true)`.
+If Step 0 produced an identifier (`target_task` set): resolve directly per the identifier (bound or standalone) — use KIND-appropriate MCP tools per the Kind Detection table above.
 
-Otherwise: use MCP `get_current_task` with repo_id (pass checkpoint_id if known to avoid disambiguation) to find the active checkpoint and in-progress task.
+Otherwise: use Kind Detection to determine KIND, then use MCP `get_current_task` (checkpoint KIND) or `get_current_standalone_task` (standalone KIND) with repo_id to find the active task.
 
 If no in-progress task and Step 0 produced no identifier, show error: `No active task. Run /cbp-task-start first.`
 
 ### Step 2: Determine Round Number
 
-If Step 0 produced `target_round`: use that as the round number directly (may target an existing round for resume, or N+1 for a new round — disambiguate by checking MCP `get_rounds`).
+If Step 0 produced `target_round`: use that as the round number directly (may target an existing round for resume, or N+1 for a new round — disambiguate by checking MCP `get_rounds` / `get_standalone_rounds` per KIND).
 
-Otherwise: use MCP `get_rounds` for the task; count existing rounds; next is N+1.
+Otherwise: use MCP `get_rounds` (checkpoint KIND) or `get_standalone_rounds` (standalone KIND) for the task; count existing rounds; next is N+1.
 
 ### Step 3: Gather Round Requirements
 
@@ -99,8 +120,8 @@ Otherwise: use MCP `get_rounds` for the task; count existing rounds; next is N+1
 
 ### Step 4: Create Round in DB
 
-Use MCP `add_round`:
-- `task_id`: current task ID
+Use MCP `add_round` (checkpoint KIND) or `add_standalone_round` (standalone KIND):
+- `task_id` (checkpoint) / `standalone_task_id` (standalone): current task ID
 - `number`: next round number
 - `status`: "in_progress"
 - `started_at`: now (ISO format)
@@ -115,7 +136,7 @@ Load from checkpoint and task:
 - Task context and requirements
 - Resources from checkpoint and task (documentation links, API docs, guides)
 - Previous round results (files_changed, QA results)
-- For round 2+: load the latest completed round's `context.testing_qa_output` and `context.executor_output` via `get_rounds` response
+- For round 2+: load the latest completed round's `context.testing_qa_output` and `context.executor_output` via `get_rounds` / `get_standalone_rounds` per KIND
 - Identify unapproved files from task.files_changed (where user_approved === false)
 
 ### Step 6: First Round Analysis (Round 1 only)
@@ -126,7 +147,7 @@ For the first round only:
 2. Identify any ambiguities or gaps
 3. If questions are needed, ask user via AskUserQuestion (max 4 per batch)
 4. If task context changes from Q&A answers:
-   - Update task context via MCP `update_task(task_id, context: {...})`
+   - Update task context via MCP `update_task(task_id, context: {...})` / `update_standalone_task(standalone_task_id, context: {...})` per KIND
    - Save Q&A decisions as `context.decisions[]`
 
 Skip this step for round 2+ (context already established via `/cbp-round-input`).
@@ -199,7 +220,7 @@ Single-wave plans present the existing flat plan view (no wave table) — backwa
 
 ### Step 9: Auto-trigger Round Execute
 
-On approval, save planner output to round context via MCP `update_round`, then trigger `/cbp-round-execute`.
+On approval, save planner output to round context via MCP `update_round` / `update_standalone_round` per KIND, then trigger `/cbp-round-execute`.
 
 ```
 Plan approved. Starting execution phase...
@@ -215,8 +236,8 @@ Plan approved. Starting execution phase...
 
 ## Integration
 
-- **Reads**: MCP `get_current_task`, `get_rounds`
-- **Writes**: MCP `add_round`, `update_round`, `update_task` (context only)
+- **Reads**: MCP `get_current_task` / `get_current_standalone_task`, `get_rounds` / `get_standalone_rounds` (per KIND)
+- **Writes**: MCP `add_round` / `add_standalone_round`, `update_round` / `update_standalone_round`, `update_task` / `update_standalone_task` (context only) — per KIND
 - **Spawns**: `cbp-task-planner`
 - **Triggers**: `/cbp-round-execute` (auto, on plan approval)
 - **Triggered by**: `/cbp-task-start` (round 1), `/cbp-round-input` (round 2+)

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

@@ -3,10 +3,31 @@ scope: org-shared
 name: cbp-round-update
 description: Check file approvals, complete round, and route to next step
 argument-hint: [chk-task-round | task-round]
-triggers: [cbp-round-input, cbp-task-check]
+triggers: [cbp-round-input, cbp-task-check, cbp-standalone-task-check]
 effort: low
 ---
 
+## Kind Detection
+
+Inspect the resolved identifier from argument parsing to determine the task kind:
+
+| Identifier shape | KIND |
+|-----------------|------|
+| `{task}-{round}` (2-segment, e.g. `45-2`) | `standalone` |
+| `{chk}-{task}-{round}` (3-segment, e.g. `141-3-1`) | `checkpoint` |
+| _(empty / free-text)_ | Check `get_current_standalone_task` first; if found → `standalone`. Else → `checkpoint` via `get_current_task`. |
+
+Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
+
+| Operation | `checkpoint` KIND | `standalone` KIND |
+|-----------|------------------|-------------------|
+| Get task | `get_current_task(repo_id)` | `get_current_standalone_task(repo_id)` |
+| Get rounds | `get_rounds(task_id)` | `get_standalone_rounds(standalone_task_id)` |
+| Add round | `add_round(task_id, ...)` | `add_standalone_round(standalone_task_id, ...)` |
+| Update round | `update_round(round_id, ...)` | `update_standalone_round(standalone_round_id, ...)` |
+| Complete round | `complete_round(round_id, duration_minutes?)` | `complete_standalone_round(standalone_round_id, duration_minutes?, caller_worktree_id)` ⚠️ `caller_worktree_id` is REQUIRED for standalone |
+| Update task | `update_task(task_id, ...)` | `update_standalone_task(standalone_task_id, ...)` |
+
 # Round Update Command
 
 Checks file approval status, completes the round, and routes to next step. NEVER asks the user to git add or stage anything — it only reads current state.
@@ -29,7 +50,7 @@ Parse the argument using the canonical chk-task-round notation (see `.claude/rul
 |-------|-------|-------------|
 | `{chk}-{task}-{round}` (e.g. `108-1-2`) | `^[0-9]+-[0-9]+-[0-9]+$` | Checkpoint-bound: CHK-{chk} TASK-{task} ROUND-{round} |
 | `{task}-{round}` (e.g. `45-2`) | `^[0-9]+-[0-9]+$` | Standalone: standalone TASK-{task} ROUND-{round} |
-| _(empty)_ | — | Use MCP `get_current_task` / `get_rounds` to find the active task and latest round |
+| _(empty)_ | — | Use Kind Detection to find active task and latest round |
 
 Anything else is malformed — surface this error and stop:
 
@@ -46,7 +67,7 @@ Error cases: `abc`, `108-`, `-1`, anything with whitespace or non-numeric charac
 
 - `round-update 108-1-2` → CHK-108 TASK-1 ROUND-2
 - `round-update 45-2` → standalone TASK-45 ROUND-2
-- `round-update` (no arg) → active task and latest in-progress round via `get_current_task` + `get_rounds`
+- `round-update` (no arg) → active task and latest in-progress round via Kind Detection
 - `round-update abc` → error: malformed
 
 ### Step 1.5: Get Current Task and Round
@@ -56,8 +77,8 @@ Given the parse from Step 1:
 | Parse | Resolution path |
 |-------|-----------------|
 | `{chk}-{task}-{round}` | MCP `get_checkpoints(repo_id)` → filter `number === {chk}`. MCP `get_tasks(checkpoint_id)` → filter `number === {task}`. MCP `get_rounds(task_id)` → filter `number === {round}`. |
-| `{task}-{round}` | MCP `get_tasks(repo_id, standalone: true)` → filter `number === {task}`. MCP `get_rounds(task_id)` → filter `number === {round}`. |
-| _(empty)_ | MCP `get_current_task(repo_id)` to find active task. MCP `get_rounds(task_id)` to find latest round (in-progress or completed). |
+| `{task}-{round}` | MCP `get_standalone_rounds` via `get_current_standalone_task` or direct task lookup → filter `number === {round}`. |
+| _(empty)_ | Use Kind Detection: checkpoint KIND → MCP `get_current_task(repo_id)` + `get_rounds(task_id)`; standalone KIND → MCP `get_current_standalone_task(repo_id)` + `get_standalone_rounds(standalone_task_id)`. |
 
 If no task found: `No active task. Nothing to update.`
 
@@ -108,7 +129,16 @@ If the command exits non-zero, surface the stderr and STOP. Do NOT proceed to St
 ### Step 3: Complete Round
 
 Calculate duration from `started_at` to now in minutes.
-Use MCP `complete_round(round_id, duration_minutes)`.
+
+- **checkpoint KIND**: MCP `complete_round(round_id, duration_minutes)`.
+- **standalone KIND**: MCP `complete_standalone_round(standalone_round_id, duration_minutes, caller_worktree_id)`. ⚠️ `caller_worktree_id` is REQUIRED — resolve via `CALLER_WT=$(npx codebyplan resolve-worktree 2>/dev/null)`. If `CALLER_WT` is empty, surface this warning and ask user to confirm before proceeding:
+
+  ```
+  Warning: could not resolve caller_worktree_id (npx codebyplan resolve-worktree returned empty).
+  The complete_standalone_round call may be rejected by the pre-guard. Proceed anyway? (yes / no)
+  ```
+
+  If user confirms yes, proceed with `caller_worktree_id: ""`. If no, stop.
 
 ### Step 4: Auto-Loop Decision
 
@@ -118,7 +148,7 @@ Procedure:
 
 1. Compute `next_index = (round.context.auto_loop_index ?? 0) + 1`.
 2. **If `next_index > (round.context.auto_loop_cap ?? 5)`**: surface the cap-exhausted prompt via AskUserQuestion (options: extend cap, stop loop / drop into round-input, close task as-is). Persist `round.context.auto_loop_cap_exhausted = { user_choice, decided_at }` and route per choice.
-3. **Otherwise**: persist `round.context.auto_loop_decision = { spawned_next: true, next_index, decided_at }` on the CURRENT round via `update_round` (audit trail), then auto-trigger `/cbp-round-input` with NO AskUserQuestion. Pass `auto_loop_mode: true`, `auto_loop_index: next_index`, `auto_loop_cap: (prior cap ?? 5)` forward — round-start Step 4 persists them on the new round.
+3. **Otherwise**: persist `round.context.auto_loop_decision = { spawned_next: true, next_index, decided_at }` on the CURRENT round via `update_round` / `update_standalone_round` per KIND (audit trail), then auto-trigger `/cbp-round-input` with NO AskUserQuestion. Pass `auto_loop_mode: true`, `auto_loop_index: next_index`, `auto_loop_cap: (prior cap ?? 5)` forward — round-start Step 4 persists them on the new round.
 
 > **Permission-gate note**: the "NO AskUserQuestion" in item 3 governs only the auto-loop's decision to spawn `/cbp-round-input` — it does not add a prompt for that hand-off. It is NOT a bypass of the Step 1.6 permission gate: when the spawned round eventually re-enters `/cbp-round-update`, Step 1.6 prompts again (the gate always fires, including inside the auto-loop).
 
@@ -135,7 +165,7 @@ If BOTH signals are clean, fall through to Step 5 (exit routing).
 Survey rounds produce no file diff; A/B/C predicates assume `files_changed[]` non-empty. Survey routing is decided by `improve_round_findings[]` instead:
 
 - `improve_round_findings[]` non-empty → auto-trigger `/cbp-round-input`
-- `improve_round_findings[]` empty → auto-trigger `/cbp-task-check`
+- `improve_round_findings[]` empty → checkpoint KIND: auto-trigger `/cbp-task-check`; standalone KIND: auto-trigger `/cbp-standalone-task-check`
 
 Output: `"## Round [N] Complete — Survey Round"` with duration, files=0, findings count, routing message. Skip Branches A/B/C.
 
@@ -150,7 +180,7 @@ Output: `"## Round [N] Complete — Survey Round"` with duration, files=0, findi
 
 Surface AskUserQuestion (clean-exit user-gate):
 
-- **(a) close & complete round** → auto-trigger `/cbp-task-check`
+- **(a) close & complete round** → checkpoint KIND: auto-trigger `/cbp-task-check`; standalone KIND: auto-trigger `/cbp-standalone-task-check`
 - **(b) start new round** → auto-trigger `/cbp-round-input`
 
 Persist `round.context.auto_loop_exit = { staged_count, unstaged_count, route, decided_at }`.
@@ -187,11 +217,12 @@ Unreachable in the auto-loop path — Step 4 catches it first. Retained for MANU
 - **Step 4 owns the dirty-loop case**; Step 5 owns the clean-exit case. Step 5 Branch C is for manual invocation only.
 - **NEVER ask user to git add files** — only reads staging status. **NEVER stage files** — Claude does not touch git staging area.
 - Auto-triggered by `/cbp-round-end`, or run manually by user.
+- **standalone KIND Step 3**: `caller_worktree_id` is REQUIRED for `complete_standalone_round` — always resolve and pass it.
 
 ## Integration
 
 - **Gates**: Step 1.6 permission gate — asks the user to confirm before any side effect; **Cancel** aborts cleanly with no writes. Fires on every invocation incl. the Step 4 auto-loop; sits before and independent of the top-of-file Step 2 hard gate.
 - **Triggered by**: `/cbp-round-end` (auto), or user manually
-- **Reads**: MCP `get_current_task`, `get_rounds`; delegates git+approval sync to `npx codebyplan round sync-approvals`
-- **Writes**: MCP `update_round` (auto_loop_decision / auto_loop_exit / auto_loop_cap_exhausted), `complete_round`; round+task files_changed written by CLI
-- **Triggers**: `/cbp-round-input` (Step 4 dirty-loop spawn; Branch A 'b' choice; Branch B auto-loop-exit; Branch C manual), `/cbp-task-check` (Branch A 'a' choice; Branch D survey-clean), staging-gate stop (Branch B manual mode), cap-exhausted prompt routes from Step 4 (any of the three options)
+- **Reads**: MCP `get_current_task` / `get_current_standalone_task`, `get_rounds` / `get_standalone_rounds` (per KIND); delegates git+approval sync to `npx codebyplan round sync-approvals`
+- **Writes**: MCP `update_round` / `update_standalone_round` (auto_loop_decision / auto_loop_exit / auto_loop_cap_exhausted); `complete_round` / `complete_standalone_round` (per KIND); round+task files_changed written by CLI
+- **Triggers**: `/cbp-round-input` (Step 4 dirty-loop spawn; Branch A 'b' choice; Branch B auto-loop-exit; Branch C manual), `/cbp-task-check` (Branch A 'a' choice per checkpoint KIND; Branch D survey-clean per checkpoint KIND), `/cbp-standalone-task-check` (Branch A 'a' choice per standalone KIND; Branch D survey-clean per standalone KIND), staging-gate stop (Branch B manual mode), cap-exhausted prompt routes from Step 4 (any of the three options)