codebyplan 1.13.53 → 1.13.54

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

@@ -1,261 +0,0 @@
----
-name: cbp-round-start
-description: Start a round — planning phase only
-triggers: [cbp-round-execute]
-argument-hint: [chk-task-round | task-round | requirements-text]  # e.g. `108-1-2`, `45-2`, or free-text from /cbp-round-input
-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. Read/write sources vary by KIND:
-
-| Operation | `checkpoint` KIND | `standalone` KIND |
-|-----------|------------------|-------------------|
-| Get task | local state (break-glass: `get_current_task`) | `get_current_standalone_task(repo_id)` |
-| Get rounds | local state (break-glass: `get_rounds`) | `get_standalone_rounds(standalone_task_id)` |
-| Add round | `codebyplan round add` (break-glass: `add_round`) | `add_standalone_round(standalone_task_id, ...)` |
-| Update round | `codebyplan round update` (break-glass: `update_round`) | `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 | `codebyplan task update` (break-glass: `update_task`) | `update_standalone_task(standalone_task_id, ...)` |
-
-> **Note**: The `standalone` KIND column uses MCP tools unchanged — standalone local-first migration is out of scope for this task and will be addressed in a later task.
-
-# Round Start Command
-
-Planning phase for a new round. Analyzes context, creates a plan, then auto-triggers `/cbp-round-execute` — the `ask`-tier permission prompt on that skill IS the user's plan approval. NO execution or testing — those are separate commands.
-
-## Inline-Fallback for Planner Spawn Failure
-
-If the `cbp-task-planner` agent spawn fails for any reason (`API Error: Extra usage required`, monthly Agent usage cap, provider 5xx, rate limit, context overflow), the orchestrator MUST follow the canonical inline-fallback procedure documented in `skills/cbp-round-end/SKILL.md` "Inline-fallback for any spawn failure".
-
-Procedure summary (pointer back to canonical):
-
-1. Detect the failure class from the error string; record `round.context.planner_findings.spawn_failure = { class, error_message, decided_at }`.
-2. Walk the planner's documented Phase 0-8 checklist inline using `Read` / `Grep` / `Bash` / MCP `get_*` — `agents/cbp-task-planner.md` is the inline script. Phase 1.5 (Requirement Premise Verification) and Phase 4.7 (Migration Shape-Distribution Pre-Flight) are MANDATORY in fallback mode — these are the gates the agent uniquely enforces; skipping them produces unverified plans.
-3. Populate the planner's output contract (`approved_plan` shape: `files_to_modify[]`, `deliverables`, `specialist_needs`, `round_type`, `shape_distribution` if applicable, `context_summary`) with `mode: 'inline_fallback'`.
-4. Apply the pre-emptive-skip rule: when the same failure class fired in the previous spawn of this session, skip the spawn attempt entirely and go straight to inline.
-5. Continue the skill — do NOT abort. Step 9 auto-triggers `/cbp-round-execute`; the `ask`-tier permission prompt on that skill is the user's plan approval (see Step 8).
-
-Inline-fallback is NOT a quality downgrade trapdoor — Phase 1.5 row-by-row verification is mandatory. A fallback plan that skipped premise verification is a regression caught by the next session's cbp-improve-round.
-
-## Pipeline
-
-```
-/cbp-round-start (planning) → /cbp-round-execute (ask-tier permission = plan approval)
-```
-
-**Auto-loop mode**: when `round.context.auto_loop_mode === true` flows in from `/cbp-round-input`, Step 6 (Q&A) is skipped and Step 8's `/cbp-round-execute` permission is auto-approved. See cbp-round-update SKILL.md Step 3b (auto-loop decision) and cbp-round-end SKILL.md Step 8 for the full contract.
-
-## Instructions
-
-### Step 0: Parse `$ARGUMENTS` shape
-
-Disambiguate the argument up front. Three input shapes:
-
-### CHK / TASK / ROUND Identifier Notation Vocabulary
-
-| Shape | Regex | Meaning |
-|-------|-------|---------|
-| `{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 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:
-
-```
-round-start: invalid argument `{value}`. Expected:
-  108-1-2  → round 2 of CHK-108 TASK-1
-  45-2     → round 2 of standalone TASK-45
-  (free-text) → round requirements (typical from /cbp-round-input)
-  (empty)  → derive from active task/round state
-```
-
-#### Worked examples
-
-- `round-start 108-1-2` → resolve CHK-108 TASK-1, target round 2
-- `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 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
-
-> **Mental-model warning**: `task-start` and `round-start` interpret the SAME `108-1` argument differently. `task-start 108-1` → CHK-108 TASK-1 (checkpoint-bound task). `round-start 108-1` → standalone TASK-108 round 1 (because round-start needs three numbers for a checkpoint-bound round). When in doubt, write all three: `round-start 108-1-2`.
-
-### Step 1: Get Current Task
-
-If Step 0 produced an identifier (`target_task` set): resolve directly per the identifier (bound or standalone) — use KIND-appropriate sources per the Kind Detection table above.
-
-Otherwise: use Kind Detection to determine KIND, then:
-- **checkpoint KIND**: read `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>.json` (local-first). If missing/stale, run `npx codebyplan sync` once and re-read. Break-glass fallback: MCP `get_current_task` when the state dir is absent and sync fails (daemon-dead + CLI-unavailable).
-- **standalone KIND**: MCP `get_current_standalone_task(repo_id)` — standalone tools are NOT migrated this task; standalone KIND still uses MCP until a later 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 reading local round files or MCP per KIND below).
-
-Otherwise:
-- **checkpoint KIND**: list `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>/rounds/` (local-first). If missing/stale, run `npx codebyplan sync` once and re-read. Break-glass fallback: MCP `get_rounds` when the state dir is absent and sync fails.
-- **standalone KIND**: MCP `get_standalone_rounds(standalone_task_id)` — standalone still uses MCP.
-
-Count existing rounds; next is N+1.
-
-### Step 3: Gather Round Requirements
-
-**If Step 0 parsed an identifier**: this skill was invoked to resume/start a specific round. Requirements come from existing round data (when the round exists) or task.requirements (for new round 1) — `$ARGUMENTS` is the identifier itself, NOT requirements text.
-
-**Else (free-text path), if round number is 1:**
-
-- Use `task.requirements` as the primary requirements
-- If `$ARGUMENTS` provided (free-text), merge as additional context
-
-**Else (free-text path), if round number > 1:**
-
-1. If `$ARGUMENTS` provided (from `/cbp-round-input`): use as round requirements
-2. If NO arguments: show error - `Round 2+ requires input. Run /cbp-round-input first.`
-
-### Step 4: Create Round in DB
-
-**checkpoint KIND**: `codebyplan round add --task-id <uuid> --checkpoint-id <uuid> --number <N> --status in_progress --started-at <ISO> --triggered-by <user|claude|auto_loop> [--requirements <text>] [--context <json>]` (CLI write-through: writes local state at `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>/rounds/<roundId>.json` + REST). Break-glass fallback: MCP `add_round` when the CLI is unavailable.
-
-**standalone KIND**: MCP `add_standalone_round(standalone_task_id, ...)` — standalone still uses MCP.
-
-Fields to supply:
-- `task_id` (checkpoint) / `standalone_task_id` (standalone): current task ID
-- `number`: next round number
-- `status`: "in_progress"
-- `started_at`: now (ISO format)
-- `triggered_by`: `"user"` | `"claude"` | `"auto_loop"` — `auto_loop` when `auto_loop_mode === true` flows in from round-input; `claude` when auto-triggered by testing failure; `user` otherwise
-- `requirements`: round requirements from Step 3
-- `context`: when `auto_loop_mode === true`, persist `auto_loop_mode: true`, `auto_loop_index: N`, `auto_loop_cap: C` into `round.context` (carried forward from round-input args)
-
-### Step 5: Load Context from DB
-
-Load from checkpoint and task:
-- Checkpoint context (decisions, dependencies, constraints, goal)
-- 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`:
-  - **checkpoint KIND**: read `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>/rounds/<roundId>.json` (local-first). If missing/stale, run `npx codebyplan sync` once and re-read. Break-glass fallback: MCP `get_rounds` when the state dir is absent and sync fails.
-  - **standalone KIND**: MCP `get_standalone_rounds(standalone_task_id)` — standalone still uses MCP.
-- Identify unapproved files from task.files_changed (where user_approved === false)
-
-### Step 6: First Round Analysis (Round 1 only)
-
-For the first round only:
-
-1. Analyze the task context and requirements thoroughly
-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:
-   - **checkpoint KIND**: `codebyplan task update --id <task-id> --checkpoint-id <uuid> --context <json>` (CLI write-through: local state at `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>.json` + REST). Break-glass fallback: MCP `update_task` when the CLI is unavailable.
-   - **standalone KIND**: MCP `update_standalone_task(standalone_task_id, context: {...})` — standalone still uses MCP.
-   - Save Q&A decisions as `context.decisions[]`
-
-Skip this step for round 2+ (context already established via `/cbp-round-input`).
-
-**If `auto_loop_mode === true`, skip Q&A regardless of round number** — the auto-loop already has authoritative requirements from the prior round's findings (round 1 is always manual in practice, but the rule is explicit so future round-1 auto-loops follow it).
-
-### Step 7: Spawn Task Planner Agent
-
-Spawn `cbp-task-planner` agent with:
-```yaml
-input:
-  task_number: N
-  round_number: N
-  requirements: task.requirements
-  round_requirements: [round-specific input from Step 3]
-  checkpoint: {id, title, goal, context}
-  task: {id, title, requirements, context}
-  previous_rounds: {count, files_pending, files_changed, testing_qa_output, unapproved_files}
-```
-
-**Round 2+ context**: The planner receives the previous round's testing-qa output and list of unapproved files.
-
-**Priority**: If `round_requirements` is set (round 2+), the planner focuses on those specific goals while respecting `task.requirements` as context.
-
-Wait for planner output.
-
-### Step 8: Present Plan
-
-Present the plan to user:
-
-```
-## Round [N] Plan
-
-**Goal**: [goal]
-
-### Steps:
-1. [step]
-2. [step]
-...
-
-### Files to modify:
-| File | Action | Purpose |
-|------|--------|---------|
-| ... | ... | ... |
-```
-
-**Wave table** — when `approved_plan.waves[]` contains ≥2 entries, render a wave summary table BEFORE the files table:
-
-```
-### Execution Waves
-| Wave | Agent type | Files | Depends on | Skill preloads |
-|------|-----------|-------|-----------|----------------|
-| web-ui | cbp-round-executor | 7 | — | cbp-frontend-design |
-| backend-api | cbp-round-executor | 4 | — | — |
-```
-
-Single-wave plans present the existing flat plan view (no wave table) — backward compatible.
-
-**Plan approval is the `ask`-tier `Skill(cbp-round-execute)` permission prompt** — there is NO approve/needs-changes/wrong AskUserQuestion here. After presenting the plan, proceed to Step 9, which auto-triggers `/cbp-round-execute`; the harness then shows the `ask`-tier permission prompt, and confirming it IS the user's go-ahead on the plan.
-
-**Denied-execute handling** — if the user declines the `/cbp-round-execute` permission, the plan does not run. Treat the decline as "the plan must change":
-
-- **Minor changes**: collect the user's feedback, re-spawn `cbp-task-planner` with it as a constraint (re-run Step 7), present the revised plan, and re-trigger `/cbp-round-execute`.
-- **Wrong direction**: save the rejection reason to round context and auto-trigger `/cbp-round-input` for new requirements.
-
-**If `auto_loop_mode === true`**: the loop auto-approves — log `round.context.plan_approval = { mode: "auto_loop", auto_approved_at: <ISO> }`, surface a one-line note `"Auto-approved under auto_loop_mode (round N of cap C)"`, and proceed to Step 9 (the `/cbp-round-execute` permission is auto-approved under the loop).
-
-### Step 9: Auto-trigger Round Execute
-
-Save planner output to round context, then trigger `/cbp-round-execute`. The `ask`-tier permission prompt on `/cbp-round-execute` is the user's plan approval (see Step 8).
-
-- **checkpoint KIND**: `codebyplan round update --id <round-id> --task-id <uuid> --checkpoint-id <uuid> --context <json>` (CLI write-through: local state at `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>/rounds/<roundId>.json` + REST). Break-glass fallback: MCP `update_round` when the CLI is unavailable.
-- **standalone KIND**: MCP `update_standalone_round(standalone_round_id, ...)` — standalone still uses MCP.
-
-```
-Starting execution phase...
-```
-
-## Key Rules
-
-- **Planning ONLY** — no code execution, no testing
-- Planner gets full context (checkpoint + task + previous rounds)
-- Round 1 auto-triggered from `/cbp-task-start`
-- Round 2+ triggered from `/cbp-round-input`
-- Claude NEVER git adds files in round commands
-
-## Integration
-
-- **Reads (checkpoint KIND)**: `.codebyplan/state/checkpoints/<id>.json`, `checkpoints/<id>/tasks/<id>.json`, `checkpoints/<id>/tasks/<id>/rounds/<id>.json` (local-first; `npx codebyplan sync` on miss; MCP `get_current_task` / `get_rounds` as break-glass)
-- **Reads (standalone KIND)**: MCP `get_current_standalone_task`, `get_standalone_rounds` — standalone still uses MCP
-- **Writes (checkpoint KIND)**: `codebyplan round add` (Step 4), `codebyplan round update` (Step 9), `codebyplan task update` (Step 6 context only) — break-glass: MCP `add_round` / `update_round` / `update_task`
-- **Writes (standalone KIND)**: MCP `add_standalone_round`, `update_standalone_round`, `update_standalone_task` — standalone still uses MCP
-- **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

@@ -1,120 +0,0 @@
----
-name: cbp-round-update
-description: Triage a finished round (Claude-only); direct user to run round-complete on a clean round, or trigger round-input when more work is needed
-argument-hint: [chk-task-round | task-round]
-triggers: [cbp-round-input]
-effort: low
----
-
-## Kind Detection
-
-Inspect the resolved identifier from argument parsing to determine the task kind:
-
-| Identifier shape | KIND |
-|-----------------|------|
-| `{task}-{round}` (2-segment, e.g. `45-2`) | `standalone` |
-| `{chk}-{task}-{round}` (3-segment, e.g. `141-3-1`) | `checkpoint` |
-| _(empty / free-text)_ | Check `get_current_standalone_task` first; if found → `standalone`. Else → `checkpoint` via `get_current_task`. |
-
-Set `KIND` for the rest of this skill. round-update is **read + triage only** — it reads round state and routes; it never completes the round or writes file approvals. Read/write sources vary by KIND:
-
-| Operation | `checkpoint` KIND | `standalone` KIND |
-|-----------|------------------|-------------------|
-| Get task | local state (break-glass: `get_current_task`) | `get_current_standalone_task(repo_id)` |
-| Get rounds | local state (break-glass: `get_rounds`) | `get_standalone_rounds(standalone_task_id)` |
-| Update round (audit only) | `codebyplan round update` (break-glass: `update_round`) | `update_standalone_round(standalone_round_id, ...)` |
-
-> **Note**: The `standalone` KIND column uses MCP tools unchanged — standalone local-first migration is out of scope for this task and will be addressed in a later task.
-
-The completion + file-approval reconcile (`sync-approvals`, `complete_round` / `complete_standalone_round`) now lives in `/cbp-round-complete`.
-
-# Round Update Command
-
-**Claude-only, autonomous triage.** round-update inspects a finished round's automated state — which files Claude approved (`claude_approved`), whether testing-QA hard-failed, and whether `improve-round` left outstanding findings — and routes to exactly one next step. It makes **no writes** beyond an audit breadcrumb and **never prompts the user**: it is auto-triggered by `/cbp-round-end` and runs without a confirmation gate. The user-facing confirmation has moved to `/cbp-round-complete` (an `ask`-tier permission prompt). round-update NEVER reads or touches git staging — user approval is reconciled later by `/cbp-round-complete`.
-
-## Routing in one line
-
-- **Round is clean** → **direct the user to run** `/cbp-round-complete` (the user-invoked finalizer reconciles your `git add`s and completes the round; round-update cannot invoke it — round-complete is `disable-model-invocation: true`).
-- **Round needs more work** → trigger `/cbp-round-input` (more changes / planning).
-
-## Instructions
-
-### Step 1: Parse `$ARGUMENTS`
-
-Parse the argument using the canonical chk-task-round notation (see `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary"):
-
-| Shape | Regex | Resolves to |
-|-------|-------|-------------|
-| `{chk}-{task}-{round}` (e.g. `108-1-2`) | `^[0-9]+-[0-9]+-[0-9]+$` | Checkpoint-bound: CHK-{chk} TASK-{task} ROUND-{round} |
-| `{task}-{round}` (e.g. `45-2`) | `^[0-9]+-[0-9]+$` | Standalone: standalone TASK-{task} ROUND-{round} |
-| _(empty)_ | — | Use Kind Detection to find active task and latest round |
-
-Anything else is malformed — surface this error and stop:
-
-```
-round-update: invalid argument `{value}`. Expected:
-  108-1-2  → CHK-108 TASK-1 ROUND-2 (checkpoint-bound)
-  45-2     → standalone TASK-45 ROUND-2
-  (empty)  → active task and latest round
-```
-
-Error cases: `abc`, `108-`, `-1`, anything with whitespace or non-numeric characters. Note that `108-1` is **valid** here — it resolves to standalone TASK-108 ROUND-1 per the 2-segment task-round form. To target a checkpoint-bound round, use the 3-segment form `108-1-2`.
-
-#### Worked examples
-
-- `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 Kind Detection
-- `round-update abc` → error: malformed
-
-### Step 1.5: Get Current Task and Round
-
-Given the parse from Step 1:
-
-| Parse | Resolution path |
-|-------|-----------------|
-| `{chk}-{task}-{round}` | Read `.codebyplan/state/checkpoints/` to find the checkpoint where `number === {chk}` (local-first; `npx codebyplan sync` on miss; break-glass: MCP `get_checkpoints(repo_id)`). Read `checkpoints/<id>/tasks/<taskId>.json` to find task where `number === {task}` (break-glass: MCP `get_tasks`). Read `checkpoints/<id>/tasks/<id>/rounds/<roundId>.json` to find round where `number === {round}` (break-glass: MCP `get_rounds`). |
-| `{task}-{round}` | MCP `get_standalone_rounds` via `get_current_standalone_task` or direct task lookup → filter `number === {round}`. Standalone still uses MCP. |
-| _(empty)_ | checkpoint KIND → read `.codebyplan/state/checkpoints/<id>/tasks/<id>.json` (local-first; sync on miss; break-glass: MCP `get_current_task` + `get_rounds`); standalone KIND → MCP `get_current_standalone_task(repo_id)` + `get_standalone_rounds(standalone_task_id)` — standalone still uses MCP. |
-
-If no task found: `No active task. Nothing to update.`
-
-This step is **read-only**. There is no permission gate — round-update is autonomous (see the Key Rules below).
-
-### Step 2: Triage the Round
-
-Read the latest round's context: `round.context.testing_qa_output.totals.hard_fail`, `round.context.improve_round_findings[]`, `round.context.round_type`, and `round.files_changed[]` (each entry's `claude_approved`). Compute a single `clean` verdict:
-
-- **Survey round** (`round.context.round_type === 'survey'`): no file diff exists, so QA/approval predicates do not apply. `clean = improve_round_findings[]` is empty.
-- **Normal round**: `clean = (every file in files_changed[] has claude_approved === true) AND testing_qa_output.totals.hard_fail === false AND improve_round_findings[]` is empty.
-
-Display a one-line triage summary, e.g. `"ROUND-N triage: clean"` or `"ROUND-N triage: N findings / hard_fail=true → needs another round"`. round-update reads `claude_approved` only — it does **not** read git staging or `user_approved`; those belong to `/cbp-round-complete`.
-
-### Step 3: Route
-
-**3a — Clean → direct the user to `/cbp-round-complete`.** STOP and surface the directive: `Round clean. Next: run /cbp-round-complete to reconcile your git adds and finalize.` round-update does NOT invoke round-complete — round-complete carries `disable-model-invocation: true`, so only the user can run it (its `ask`-tier permission prompt is the user's confirmation on that direct invoke). Once the user runs it, round-complete reconciles the `git add`s, completes the round, and routes onward (all files staged → task-check; some withheld → round-input). round-update writes nothing here beyond the Step 2 summary. In `auto_loop_mode`, a clean triage is the loop's success exit — the directive applies here too (the user invokes round-complete to finalize); the loop continues only via the not-clean path in 3b, and round-complete owns the degenerate clean-but-unstaged guard.
-
-**3b — Not clean → `/cbp-round-input`.** More changes or planning are needed. Routing is **independent of git staging** — round-input is reachable whether or not the user has staged anything (it performs its own deep analysis of the unapproved files). Two sub-cases:
-
-- **Auto-loop** (`round.context.auto_loop_mode === true`): compute `next_index = (round.context.auto_loop_index ?? 0) + 1`.
-  - If `next_index > (round.context.auto_loop_cap ?? 5)`: surface the cap-exhausted prompt via AskUserQuestion (a genuine multi-option user decision — keep it). 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.
-  - Otherwise: persist `round.context.auto_loop_decision = { spawned_next: true, next_index, decided_at }` on the current round (audit trail) — **checkpoint KIND**: `codebyplan round update --id <round-id> --task-id <uuid> --checkpoint-id <uuid> --context <json>` (break-glass: MCP `update_round`); **standalone KIND**: MCP `update_standalone_round(standalone_round_id, ...)` — standalone still uses MCP. Then auto-trigger `/cbp-round-input` with NO prompt. 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.
-- **Manual round**: auto-trigger `/cbp-round-input` directly (no prompt).
-
-## Key Rules
-
-- **Autonomous + Claude-only** — round-update never prompts before running. It is auto-triggered by `/cbp-round-end`. On a clean triage it **directs** the user to run `/cbp-round-complete` — it cannot invoke that skill (`disable-model-invocation: true`); the confirmation step is round-complete's own `ask`-tier permission prompt on the user's direct invoke, not an AskUserQuestion here. (The auto-loop cap-exhausted AskUserQuestion in Step 3b is a genuine user decision, not a run gate.)
-- **Triage, never finalize** — round-update does NOT call `sync-approvals`, `complete_round`, or `complete_standalone_round`, and does NOT write file approvals. All of that is `/cbp-round-complete`.
-- **Never touches git** — round-update reads `claude_approved` from the DB only; it never reads staging, asks the user to `git add`, or stages files.
-- **git-add independence** — the "needs more work" route to `/cbp-round-input` fires regardless of whether files are staged. There is no clean-but-unstaged dead-end.
-- **standalone parity** — KIND detection governs which read/audit tools are used; the clean→`/cbp-round-complete` and not-clean→`/cbp-round-input` routing is identical for both KINDs (round-complete and round-input self-detect KIND).
-
-## Integration
-
-- **Triggered by**: `/cbp-round-end` (auto), or user manually
-- **Reads (checkpoint KIND)**: `.codebyplan/state/checkpoints/<id>.json`, `checkpoints/<id>/tasks/<id>.json`, `checkpoints/<id>/tasks/<id>/rounds/<id>.json` (local-first; `npx codebyplan sync` on miss; MCP `get_current_task` / `get_checkpoints` / `get_tasks` / `get_rounds` as break-glass)
-- **Reads (standalone KIND)**: MCP `get_current_standalone_task`, `get_standalone_rounds` — standalone still uses MCP
-- **Writes (checkpoint KIND)**: `codebyplan round update` — audit only (`auto_loop_decision` / `auto_loop_cap_exhausted`; break-glass: MCP `update_round`). No completion, no file-approval writes.
-- **Writes (standalone KIND)**: MCP `update_standalone_round` — audit only — standalone still uses MCP
-- **Triggers**: `/cbp-round-input` (not-clean triage: outstanding findings, hard-fail, or unapproved Claude checks — fires independent of git staging; also the auto-loop dirty spawn), cap-exhausted prompt routes from Step 3b (any of the three options)
-- **Directs the user to**: `/cbp-round-complete` (clean triage) — round-update cannot invoke it (`disable-model-invocation: true`); it emits a `Next: /cbp-round-complete` directive and the user runs it (its `ask`-tier permission prompt is the confirmation)

package/templates/skills/cbp-ship/templates/workflow-eas-submit.yml

@@ -1,53 +0,0 @@
-name: EAS Build + Submit
-
-on:
-  push:
-    tags:
-      - 'mobile-v*.*.*'
-  workflow_dispatch:
-    inputs:
-      profile:
-        type: choice
-        description: Build profile
-        options: [preview, production]
-        default: preview
-      platform:
-        type: choice
-        description: Platform
-        options: [all, ios, android]
-        default: all
-
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: pnpm/action-setup@v3
-        with:
-          version: 10
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 22
-          cache: pnpm
-
-      - uses: expo/expo-github-action@v8
-        with:
-          eas-version: latest
-          token: ${{ secrets.EXPO_TOKEN }}
-
-      - run: pnpm install --frozen-lockfile
-
-      - name: EAS Build
-        run: |
-          cd apps/mobile
-          eas build --profile ${{ inputs.profile || 'preview' }} \
-                    --platform ${{ inputs.platform || 'all' }} \
-                    --non-interactive --no-wait
-
-      - name: EAS Submit (production only)
-        if: inputs.profile == 'production'
-        run: |
-          cd apps/mobile
-          eas submit --platform ${{ inputs.platform || 'all' }} --latest --non-interactive

package/templates/skills/cbp-ship/templates/workflow-vsce-publish.yml

@@ -1,31 +0,0 @@
-name: VS Code Marketplace publish
-
-on:
-  push:
-    tags:
-      - 'vscode-v*.*.*'
-  workflow_dispatch:
-
-jobs:
-  publish:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: pnpm/action-setup@v3
-        with:
-          version: 10
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 22
-          cache: pnpm
-
-      - run: pnpm install --frozen-lockfile
-      - run: pnpm --filter REPLACE_WITH_EXT_NAME build
-      - name: Publish to Marketplace
-        env:
-          VSCE_PAT: ${{ secrets.VSCE_PAT }}
-        run: |
-          cd apps/vscode
-          npx @vscode/vsce publish --no-yarn

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

@@ -1,172 +0,0 @@
----
-name: cbp-task-check
-description: AI production review for the current task
-argument-hint: [chk-task]
-triggers: [cbp-task-testing, cbp-round-input]
-effort: high
----
-
-# Task Check Command
-
-AI-driven production readiness review. 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. It is the **cross-round double-check**: rounds already own per-round QA (debug scan, security grep, audit, per-app build/lint/types), so this layer focuses on holistic concerns visible only across the full task diff — requirements traceability, checkpoint alignment, shippability, holistic code review, and scope drift — never re-running per-round checks.
-
-## Inline-Fallback for Spawn Failure
-
-If the `cbp-task-check` agent spawn fails for any reason (`API Error: Extra usage required`, monthly Agent usage cap, provider 5xx, rate limit, context overflow), the orchestrator MUST follow the canonical inline-fallback procedure documented in `skills/cbp-round-end/SKILL.md` "Inline-fallback for any spawn failure".
-
-Procedure summary (pointer back to canonical):
-
-1. Detect the failure class from the error string; record `round.context.task_check_findings.spawn_failure = { class, error_message, decided_at }`.
-2. Walk the agent's documented Phase 1-10 checklist inline using `Read` / `Grep` / `Bash` / MCP `get_*` tools — the agent's definition file is the inline script.
-3. Populate the agent's output contract (`verdict`, `route_recommendation`, `requirements_status`, `qa_status`, `code_review_findings`, `user_satisfaction`, `scope_divergence_detected`, etc.) with `mode: 'inline_fallback'` so analytics distinguishes.
-4. Apply the pre-emptive-skip rule: when the same failure class fired in the previous skill of this session, skip the spawn attempt entirely and go straight to inline.
-5. Continue the skill — do NOT abort. Inline-fallback is intended to keep the pipeline moving under sustained outages.
-
-Inline-fallback is NOT a quality downgrade trapdoor — every Phase from the agent definition MUST be walked, in order, with the same Read/Grep depth the agent would have used. Skipping phases under the banner of fallback is a separate failure mode that `cbp-improve-claude` flags as `inline_fallback_shortcutting`.
-
-## When Used
-
-- After all rounds complete and all files approved (auto-triggered by `/cbp-round-complete`)
-- Before `/cbp-task-testing`
-- `/cbp-task-check` is NEVER skippable
-
-## Instructions
-
-### Step 1: Parse `$ARGUMENTS`
-
-Parse the argument using the canonical chk-task-round notation (see `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary"):
-
-| Shape | Regex | Resolves to |
-|-------|-------|-------------|
-| `{chk}-{task}` (e.g. `108-1`) | `^[0-9]+-[0-9]+$` | Checkpoint-bound: CHK-{chk} TASK-{task} |
-| _(empty)_ | — | Resolve from local state per Step 1.5/2 (MCP `get_current_task` break-glass) — the active in-progress task |
-| `{task}` (bare number) | — | **Error**: "Use /cbp-standalone-task-check {N} instead — bare numbers no longer route to standalone tasks." |
-
-Anything else is malformed — surface this error and stop:
-
-```
-task-check: invalid argument `{value}`. Expected:
-  108-1  → CHK-108 TASK-1 (checkpoint-bound)
-  (empty) → active in-progress task
-
-For standalone tasks, use `/cbp-standalone-task-check {N}`.
-For a specific round, use `/cbp-round-update 108-1-2`.
-```
-
-Error cases: `108-1-2` (that is round-update's shape), `abc`, `108-`, `-1`, `108--1`, anything with whitespace or non-numeric characters.
-
-#### Worked examples
-
-- `task-check 108-1` → CHK-108 TASK-1
-- `task-check` (no arg) → active in-progress task via `get_current_task`
-- `task-check 45` → error: "Use /cbp-standalone-task-check 45 instead — bare numbers no longer route to standalone tasks."
-- `task-check 108-1-2` → error: "use `/cbp-round-update 108-1-2`"
-- `task-check abc` → error: malformed
-
-### Step 1.5: Get Current Task
-
-Given the parse from Step 1:
-
-| Parse | Resolution path |
-|-------|-----------------|
-| `{chk}-{task}` | Read `.codebyplan/state/checkpoints/*.json` → filter `number === {chk}`. Read `.codebyplan/state/checkpoints/<id>/tasks/*.json` → filter `number === {task}`. If missing/stale, run `npx codebyplan sync` once and re-read. Break-glass fallback: MCP `get_checkpoints`/`get_tasks` when state dir absent and sync fails. |
-| _(empty)_ | Read `.codebyplan/state/todos.json` → find the active in-progress task. If missing/stale, run `npx codebyplan sync` once and re-read. Break-glass fallback: MCP `get_current_task(repo_id)` when state dir absent and sync fails. |
-
-If no in-progress task, show error and stop.
-
-### Step 2: Quick Gate — Verify All Rounds Complete
-
-Read `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>/rounds/*.json` (local-first). If missing/stale, run `npx codebyplan sync` once and re-read. Break-glass fallback: MCP `get_rounds` when state dir absent and sync fails. Verify all rounds are `completed`.
-
-If any rounds still in_progress:
-
-```
-## Cannot Run Task Check
-
-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. Checkpoint details — from `.codebyplan/state/checkpoints/<checkpointId>.json` (already read in Step 1.5)
-2. Task details — from `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>.json` (already read in Step 1.5)
-3. All rounds — from `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>/rounds/*.json` (already read in Step 2)
-
-### Step 4: Spawn Task Check Agent
-
-Spawn `cbp-task-check` agent with full context:
-
-```yaml
-input:
-  task_number: [N]
-  round_number: [total rounds]
-  checkpoint: { id, title, goal, context }
-  task: { id, title, requirements, context, files_changed, qa }
-  rounds: [{ number, requirements, context, qa, files_changed }]
-```
-
-Wait for agent to complete. Agent handles all 10 phases including user satisfaction discussion.
-
-### Step 5: Save Agent Output
-
-Save agent output to task context: `codebyplan task update --id <taskId> --checkpoint-id <checkpointId> --context '{"check_verdict": ...}'` (CLI write-through: local state file + REST). Break-glass fallback: MCP `update_task` when CLI is unavailable.
-
-- `task.context.check_verdict` = agent output (verdict, requirements_check, etc.)
-
-### Step 6: Route Based on Verdict
-
-**READY + satisfied:**
-
-Starting task testing...
-
-Invoke `cbp-task-testing` via the Skill tool with the same `{chk-task}` argument. `cbp-task-testing`
-is `allow`-tier — it auto-fires silently. If the `cbp-skill-context-guard.sh` hook detects the
-context window is above the 200K threshold it will block the skill and direct you to run
-`/cbp-clear-prep` first; otherwise testing starts immediately.
-
-**NOT READY — fixable issues:**
-
-```
-Issues found that need addressing:
-- [issue 1]
-- [issue 2]
-```
-
-Invoking `cbp-round-input` to address the issues found during review...
-
-Invoke `cbp-round-input` via the Skill tool. `cbp-round-input` is `allow`-tier — it auto-fires silently.
-
-**NOT READY — needs new task:**
-
-```
-Scope issues identified that require a new task:
-- [scope issue]
-```
-
-Suggest: `/cbp-task-create`. **STOP HERE** — wait for user (creating a new task is a user scope decision — not auto-triggered).
-
-**NOT READY — approvals missing:**
-
-```
-Code review passed but [N] files need user approval.
-```
-
-Suggest: Approve files, then re-run `/cbp-task-check`. **STOP HERE** — wait for user (approval is a user action — not auto-triggered).
-
-## Key Rules
-
-- **`/cbp-task-check` is NEVER skippable** — mandatory before `/cbp-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
-- **Checkpoint-bound only** — for standalone tasks use `/cbp-standalone-task-check`
-
-## Integration
-
-- **Reads**: `.codebyplan/state/checkpoints/*.json`, `checkpoints/<id>/tasks/*.json`, `checkpoints/<id>/tasks/<id>/rounds/*.json`, `todos.json` (local-first; `npx codebyplan sync` on miss; MCP `get_current_task`/`get_rounds` break-glass), plus all changed files (via agent)
-- **Writes**: `codebyplan task update` (CLI write-through; MCP `update_task` break-glass)
-- **Triggers**: auto-triggers `cbp-task-testing` via Skill tool on READY + satisfied (`allow`-tier, fires silently; the 200K context guard handles oversized contexts via the cbp-clear-prep flow); auto-triggers `cbp-round-input` via Skill tool on NOT READY — fixable issues (`allow`-tier, fires silently)
-- **Triggered by**: `/cbp-round-complete` (auto, when all files approved)