codebyplan 1.13.12 → 1.13.14

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.`
 
@@ -178,7 +201,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,7 +213,7 @@ 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 }
 
@@ -216,8 +239,8 @@ Trigger `/cbp-round-end`.
 
 ## 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 + 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)

package/templates/skills/cbp-standalone-task-check/SKILL.md

@@ -0,0 +1,152 @@
+---
+scope: repo-only:codebyplan
+name: cbp-standalone-task-check
+description: AI production review for the current standalone task
+argument-hint: [task]  # e.g. `45` (standalone TASK-45)
+triggers: [cbp-standalone-task-testing]
+effort: high
+---
+
+# Standalone Task Check Command
+
+AI-driven production readiness review for standalone tasks. Spawns the `cbp-task-check` agent for thorough verification including user satisfaction discussion. This command is a thin orchestrator — the agent does the heavy lifting.
+
+## Inline-Fallback for Spawn Failure
+
+If the `cbp-task-check` agent spawn fails for any reason, follow the canonical inline-fallback procedure documented in `skills/cbp-round-end/SKILL.md` "Inline-fallback for any spawn failure". Walk every agent phase inline with the same Read/Grep depth the agent would have used — do not skip phases.
+
+## When Used
+
+- After all rounds complete and all files approved (auto-triggered by `/cbp-round-update`)
+- Before `/cbp-standalone-task-testing`
+- Never skippable
+
+## Instructions
+
+### Step 1: Parse `$ARGUMENTS`
+
+| Shape | Regex | Resolves to |
+|-------|-------|-------------|
+| `{task}` (e.g. `45`) | `^[0-9]+$` | Standalone TASK-{task} |
+| _(empty)_ | — | Use MCP `get_current_standalone_task` to find the active in-progress task |
+
+Any multi-segment input is an error:
+
+```
+standalone-task-check: argument `{value}` looks like a checkpoint-task pair.
+Use /cbp-task-check {chk}-{task} for checkpoint-bound tasks.
+Standalone tasks use a bare number, e.g. /cbp-standalone-task-check 45.
+```
+
+Error cases: any multi-segment input, `abc`, `108-`, `-1`, anything with whitespace or non-numeric characters.
+
+#### Worked examples
+
+- `standalone-task-check 45` → standalone TASK-45
+- `standalone-task-check` (no arg) → active in-progress task via `get_current_standalone_task`
+- `standalone-task-check 141-3` → error: "Use /cbp-task-check {chk}-{task} for checkpoint-bound tasks."
+- `standalone-task-check abc` → error: malformed
+
+### Step 1.5: Get Current Task
+
+| Parse | Resolution path |
+|-------|-----------------|
+| `{task}` | MCP `get_standalone_tasks(repo_id)` → filter `number === {task}`. |
+| _(empty)_ | MCP `get_current_standalone_task(repo_id)` — finds the active in-progress task. |
+
+If no in-progress task, show error and stop.
+
+### Step 2: Quick Gate — Verify All Rounds Complete
+
+Use MCP `get_standalone_rounds(standalone_task_id)`. Verify all rounds are `completed`.
+
+If any rounds still in_progress:
+
+```
+## Cannot Run Standalone Task Check
+
+Standalone TASK-[N] has an active round (Round [N]). Complete it first:
+- Run `/cbp-round-update` to finish the round
+```
+
+Stop here.
+
+### Step 3: Load All Context
+
+1. Get task details: id, title, requirements, context, qa
+2. Get all rounds via `get_standalone_rounds(standalone_task_id)`: number, requirements, context, qa, files_changed
+
+No checkpoint context is needed — standalone tasks have no parent checkpoint.
+
+### Step 4: Spawn Task Check Agent
+
+Spawn `cbp-task-check` agent with full context:
+
+```yaml
+input:
+  task_number: [N]
+  round_number: [total rounds]
+  checkpoint: null
+  task: { id, title, requirements, context, files_changed, qa }
+  rounds: [{ number, requirements, context, qa, files_changed }]
+```
+
+Wait for agent to complete. Agent handles all phases including user satisfaction discussion.
+
+### Step 5: Save Agent Output
+
+Save agent output to task context via MCP `update_standalone_task`:
+
+- `task.context.check_verdict` = agent output (verdict, requirements_check, etc.)
+
+```
+update_standalone_task(task_id, context: { ...existing, check_verdict: agentOutput })
+```
+
+### Step 6: Route Based on Verdict
+
+**READY + satisfied:**
+
+**Next**: Run `/clear`, then `/cbp-standalone-task-testing {task}` to run comprehensive task-level testing.
+
+**NOT READY — fixable issues:**
+
+```
+Issues found that need addressing:
+- [issue 1]
+- [issue 2]
+```
+
+Suggest: `/cbp-round-input` with specific issues. Stop — wait for user.
+
+**NOT READY — needs new task:**
+
+```
+Scope issues identified that require a new task:
+- [scope issue]
+```
+
+Suggest: `/cbp-standalone-task-create`. Stop — wait for user.
+
+**NOT READY — approvals missing:**
+
+```
+Code review passed but [N] files need user approval.
+```
+
+Suggest: Approve files, then re-run `/cbp-standalone-task-check {task}`. Stop — wait for user.
+
+## Key Rules
+
+- **Never skippable** — mandatory before `/cbp-standalone-task-testing`
+- **This is AI review + user satisfaction** — not automated testing
+- **Read all changed files** — agent does the heavy lifting
+- **No file changes** — review only, never edit
+- **No checkpoint context** — standalone tasks are self-contained
+
+## Integration
+
+- **Reads**: MCP `get_current_standalone_task`, `get_standalone_tasks`, `get_standalone_rounds`, all changed files (via agent)
+- **Writes**: MCP `update_standalone_task` (context.check_verdict)
+- **Triggers**: emits directive `Next: /clear, then /cbp-standalone-task-testing {task}` on READY + satisfied
+- **Triggered by**: `/cbp-round-update` (auto, when all files approved)