codebyplan 1.13.52 → 1.13.54

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

@@ -1,197 +0,0 @@
----
-name: cbp-round-input
-description: Gather input for a new round with deep analysis of unapproved work
-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`. (Kind-detection is MCP-unavoidable — no identifier yet means no local path to probe; subsequent operations are local-first per the rows below.) |
-
-Set `KIND` for the rest of this skill. MCP tool names 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 | `add_round(task_id, ...)` | `add_standalone_round(standalone_task_id, ...)` |
-| Update round | `update_round(round_id, ...)` | `update_standalone_round(standalone_round_id, ...)` |
-| 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.
-
-## When Used
-
-- After `/cbp-round-update` triages a round as not-clean and routes here, or `/cbp-round-complete` routes here (files left unapproved after completing the round)
-- After `/cbp-round-execute` Step 6 routes here (structural failure or retry-exhausted hard-fail)
-- After `/clear` + `/cbp-todo` reloads context and triggers this
-- When user wants to start a new round with specific changes
-
-## Instructions
-
-### Step 1: Parse `$ARGUMENTS`
-
-Try the numeric identifier regex first: `^[0-9]+(-[0-9]+){0,2}$`
-
-| Shape | Segments | Resolves to |
-|-------|----------|-------------|
-| `{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 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).
-
-#### Worked examples
-
-- `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 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:
-- **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(repo_id)` when state dir is absent and sync fails. Get `files_changed`, `requirements`, `context`, `qa`.
-- **standalone KIND** — MCP `get_current_standalone_task(repo_id)`. (Standalone KIND still uses MCP until a later task.)
-
-**2b:** Load all rounds:
-- **checkpoint KIND** — Read `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>/rounds/*.json` (local-first; break-glass: MCP `get_rounds(task_id)`). Get previous round context, testing-qa output.
-- **standalone KIND** — MCP `get_standalone_rounds(standalone_task_id)`.
-
-**2c:** Identify unapproved files from `task.files_changed` where `user_approved === false`
-
-**2d:** Read the content of each unapproved file (using Read tool, max 5 files, first 100 lines each)
-
-**2e:** Cross-reference with task requirements — for each requirement, is it met or missed?
-
-**2f:** Extract testing-qa failures from latest round context (`context.testing_qa_output`)
-
-**2g:** Extract code review findings from latest round context (`context.improve_round_findings`).
-These are out-of-scope findings from the `improve-round` agent — bugs, logic errors, edge cases
-that round-end could not auto-apply inline (they reference files outside the prior round's
-`files_changed[]`). Include them as high-priority requirements.
-
-**2h:** Identify root causes — not "file X is wrong" but "requirement Y was not met because Z"
-
-**2i:** Produce structured analysis summary
-
-### Step 3: Present Analysis
-
-Show the analysis to the user:
-
-```
-## Follow-up Round Analysis
-
-### Unapproved Files ([N])
-| File | Action | Issue |
-|------|--------|-------|
-| path | modified | [what's wrong based on reading the file] |
-
-### Requirements Coverage
-| Requirement | Status | Gap |
-|-------------|--------|-----|
-| [req] | met/missed | [what's missing] |
-
-### Testing-QA Issues (from previous round)
-- [issue 1 from testing-qa output]
-- [issue 2]
-
-### Code Review Findings (from improve-round)
-| # | Severity | File | Issue |
-|---|----------|------|-------|
-| [findings accepted by user in previous round-end] |
-
-### Root Causes
-1. [root cause with explanation]
-2. [root cause with explanation]
-```
-
-### Step 4: Choose Mode
-
-**If `round.context.auto_loop_mode === true` on the prior round**: skip the AskUserQuestion below. Auto-pick "Start round with these findings" using the analysis directly. Set the next round's `auto_loop_mode = true`, carry `auto_loop_index` and `auto_loop_cap` forward into round-start args.
-
-**Else (manual mode — flag absent or false)**, ask user via AskUserQuestion:
-
-- **Start round with these findings** — use analysis as requirements
-- **Discuss first** — open conversation about the analysis
-- **Adjust** — user provides their own requirements
-
-If "Discuss first": enter open discussion about the analysis. When direction is clear, proceed to Step 5.
-If "Adjust": user provides their own requirements, merged with analysis context.
-
-### Step 5: Formulate Requirements
-
-Based on the analysis + user input, create detailed requirements that:
-
-- Reference specific root causes identified in Step 2
-- Include full task requirements context
-- Are as thorough as round 1 (not quick fixes)
-- Include checkpoint and task context for the planner
-
-**Under `auto_loop_mode`**: requirements come VERBATIM from the prior round's `improve_round_findings[]` and `testing_qa_output` failures, treated as a flat list. Test failures are listed first (they block shipping); reviewer findings follow. Both sets are included unchanged — do not re-summarise or re-prioritise either. The auto-loop transcribes the prior reviewer's output directly.
-
-### Step 6: Update Context (if direction changed)
-
-If the new round requirements change the task direction:
-
-1. Update task context per KIND:
-   - **checkpoint KIND**: `codebyplan task update --id <task_id> --checkpoint-id <checkpoint_id> --context '<json>'` (CLI write-through: local state file + REST). Break-glass fallback: MCP `update_task(task_id, context: { ... })` when the CLI is unavailable.
-   - **standalone KIND**: MCP `update_standalone_task(standalone_task_id, context: { ... })`. (Standalone KIND still uses MCP until a later task.)
-   - Add new decisions to `context.decisions[]`
-   - Update `context.discoveries[]` if applicable
-2. If checkpoint-level changes needed (checkpoint KIND only): `codebyplan checkpoint update --id <checkpoint_id> --context '<json>'` (CLI write-through). Break-glass fallback: MCP `update_checkpoint`.
-
-### Step 7: Auto-trigger Round Start
-
-Pass the new requirements to `/cbp-round-start`:
-
-```
-Starting new round with updated requirements...
-```
-
-Trigger `/cbp-round-start` with the round requirements as arguments.
-
-**Under `auto_loop_mode`**: pass `auto_loop_mode: true`, `auto_loop_index: N`, `auto_loop_cap: C` into round-start's args/context so round-start Step 4 can persist them on the new round and downstream skills (round-execute, round-end) read them.
-
-## Fallback: Context Recovery
-
-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 Kind Detection to determine KIND, then:
-   - **checkpoint KIND**: Read local `.codebyplan/state/` files for checkpoint + task (break-glass: MCP `get_current_task`).
-   - **standalone KIND**: MCP `get_current_standalone_task`.
-3. Load round history:
-   - **checkpoint KIND**: Read `.codebyplan/state/checkpoints/<id>/tasks/<id>/rounds/*.json` (break-glass: MCP `get_rounds(task_id)`).
-   - **standalone KIND**: MCP `get_standalone_rounds(standalone_task_id)`.
-4. Continue from Step 2 (deep analysis handles all context loading)
-
-## Key Rules
-
-- **Deep analysis is MANDATORY** — always runs, even if arguments provided (for context)
-- **Analysis reads from local state first**, falling back to MCP only when state files are absent and sync fails
-- **Follow-up rounds get same depth as round 1** — no quick-fix behavior
-- **Never ask to git add** — user file approval (git staging) is reconciled by `/cbp-round-complete`
-- **Update all context locations** — task, checkpoint, and round should all have consistent information
-
-## Integration
-
-- **Triggered by**: `/cbp-round-update` (auto, not-clean triage), `/cbp-round-complete` (auto, files left unapproved after completing the round), `/cbp-round-execute` (auto, on hard-fail after retry exhausted), `/cbp-todo` (after /clear), user manually
-- **Reads (checkpoint KIND)**: `.codebyplan/state/checkpoints/<id>.json`, `checkpoints/<id>/tasks/<id>.json`, `checkpoints/<id>/tasks/<id>/rounds/*.json` (local-first; break-glass: MCP `get_current_task` / `get_rounds`), file contents (Read tool)
-- **Reads (standalone KIND)**: MCP `get_current_standalone_task` / `get_standalone_rounds` (standalone KIND still uses MCP until a later task)
-- **Writes (checkpoint KIND)**: `codebyplan task update` (context), `codebyplan checkpoint update` (context, if needed). Break-glass: MCP `update_task` / `update_checkpoint`.
-- **Writes (standalone KIND)**: MCP `update_standalone_task` / (checkpoint via MCP `update_checkpoint` if needed). (Standalone KIND still uses MCP until a later task.)
-- **Triggers**: `/cbp-round-start` (auto)

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