codebyplan 1.13.53 → 1.13.55

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

@@ -1,173 +0,0 @@
----
-name: cbp-round-end
-description: Summary wrap-up after testing phase completes
-effort: high
----
-
-# Round End Command
-
-Summary phase — presents what was done, then runs code quality review to catch bugs and logic errors that automated checks miss.
-
-**Inline-fallback for any spawn failure**: when `cbp-improve-round` (or any peer agent) fails to spawn, the orchestrator falls through to an inline procedure that produces equivalent (lower-fidelity but valid) output. The contract: detect failure class → record in `round.context.improve_round_findings.spawn_failure` → walk the agent's Phase checklist inline → continue the skill. Same procedure for every failure class (org/billing, monthly Agent cap, provider 5xx, rate limit, context overflow, tool not available). Pre-emptive skip applies when the same class fired on the prior round.
-
-See `reference/inline-fallback.md` for full trigger table, procedure, and coverage list.
-
-## Pipeline
-
-```
-/cbp-round-execute → /cbp-round-end → [code review + auto-apply in-scope] → /cbp-round-update
-```
-
-## 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 is defined in `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary".
-
-## Instructions
-
-### Step 1: Get Current Task and Round
-
-Read `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>.json` (local-first) to find the active task. 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).
-
-Read `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>/rounds/<roundId>.json` (local-first) to find the in-progress round. Same sync / break-glass pattern (MCP `get_rounds` as fallback).
-
-Load round context with all outputs (executor_output, testing_qa_output, reviewer_output).
-
-### Step 2: Collect Files Changed
-
-Collect all files changed during this round from:
-
-- Work executor output
-- `git diff --name-status HEAD` for final state
-
-Build the files list with approval status:
-
-```json
-[
-  {
-    "path": "src/file.ts",
-    "action": "modified",
-    "claude_approved": true,
-    "user_approved": false
-  }
-]
-```
-
-**claude_approved**: `true` if cbp-testing-qa-agent passed for this file. `false` if issues remain.
-**user_approved**: Always `false` initially. User approves via git staging or web UI.
-
-### Step 3: Collect QA Results
-
-**No QA runs here** — all QA was already executed by per-wave `cbp-testing-qa-agent` inside `/cbp-round-execute` Step 5.
-
-#### 3a — Collect items from agent outputs
-
-Collect from round context:
-
-- **Auto items**: from `testing_qa_output.auto_qa.items`
-- **Default items**: from `testing_qa_output.default_checklist.items`
-
-Merge with previous rounds (supersede items for re-modified files, preserve verified items).
-
-### Step 4: Update Task Files and QA
-
-- **Round files + QA**: `codebyplan round update --id <round-id> --task-id <uuid> --checkpoint-id <uuid> --files-changed <json> --qa <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.
-- **Task files_changed merge**: `codebyplan task update --id <task-id> --checkpoint-id <uuid> --files-changed <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.
-- **Task QA aggregated**: `codebyplan task update --id <task-id> --checkpoint-id <uuid> --qa <json>` (same CLI write-through). Break-glass: MCP `update_task`.
-
-### Step 5: Present Summary
-
-```
-## Round [N] Complete - Ready for Review
-
-### Work Done
-[Brief summary from executor_output]
-
-### Files Changed ([N] files, [N] need approval)
-| File | Action | Claude | User |
-|------|--------|--------|------|
-| src/file.ts | modified | approved | pending |
-
-### Auto Checks
-| Check | Status |
-|-------|--------|
-| Build | pass |
-| Lint | pass |
-| Types | pass |
-| Tests | pass/skipped |
-```
-
-### Step 6: Spawn Code Quality Review
-
-Spawn `cbp-improve-round` agent via Agent tool with:
-
-```yaml
-input:
-  repo_id: [from config]
-  task: {id, title, requirements, context}
-  round: {id, number, requirements, files_changed, context}
-  project_path: [working directory]
-```
-
-Wait for agent to complete. If the spawn fails for any reason, apply the inline-fallback procedure documented in `reference/inline-fallback.md` (record `round.context.improve_round_findings.spawn_failure`, walk the agent's Phase checklist inline, continue the skill).
-
-### Step 7: Present Findings
-
-**Baseline-regression blocking gate**: before presenting code-review findings, check `round.context.frontend_ui_review.findings[]` for any entry with `category: 'baseline_regression'` (any severity). When one or more such findings exist, surface them as a BLOCKING decision that MUST be resolved before routing to `/cbp-round-update`:
-
-- Present each regression: screenshot path, `baseline_diff_pct`, affected page/screen.
-- Ask the user via AskUserQuestion to choose:
-  - **(a) Treat as regression** — add a fix-round to address the visual change, OR
-  - **(b) Accept the new baseline** — run `pnpm exec playwright test --update-snapshots` in `apps/{app}` and commit the updated baselines.
-- Do NOT route to `/cbp-round-update` until the decision is recorded. Baselines are NEVER auto-accepted.
-
-`rendered_visual` critical findings from `round.context.frontend_ui_review.findings[]` are surfaced in the normal findings presentation below (not as a separate gate).
-
-**If `status: 'no_findings'`:** show `### Code Review\nNo issues found. Code looks good.` and skip to Step 8.
-
-**If findings exist**, present them grouped by severity (table + per-finding details).
-
-**Under `auto_loop_mode === true`**: do NOT auto-apply here — Step 8's auto-loop path accepts all findings into `improve_round_findings[]` and defers the fixes to the next loop round. Skip straight to Step 8.
-
-**Manual mode**: **auto-apply all in-scope findings inline**. A finding is *in-scope* when every file it references is within the round's `files_changed[]`. The round-end orchestrator (main context — it has Edit/Write) applies these fixes directly; the `cbp-improve-round` agent stays read-only/advisory and never writes. Record each applied fix in `round.context.inline_fix_log` (findings indices, rationale, `fixes[]`, applied_at). After applying, re-run the verification scoped to the modified files (hook syntax check for `.sh`; `cbp-testing-qa-agent` for code) per `reference/findings-presentation.md`; if it fails, do NOT record the fix — treat the finding as out-of-scope instead. Findings that reference files OUTSIDE `files_changed[]` are **out-of-scope** — do NOT apply them; save them to `improve_round_findings[]` so Step 8 routes them to `/cbp-round-input` or a new task. There is no findings-decision AskUserQuestion — the round was already approved at the `/cbp-round-execute` permission prompt. The baseline-regression gate above is the ONLY user decision in this step.
-
-Example tables and the in-scope/out-of-scope classification: see `reference/findings-presentation.md`.
-
-### Step 8: Route Based on Decisions
-
-**If `round.context.auto_loop_mode === true`** (auto-loop active):
-
-- Auto-accept ALL findings into `improve_round_findings[]` regardless of severity (the user opted into the loop).
-- Skip the polish-spiral stop-gate (auto-loop has its own cap-exhausted termination).
-- Skip Step 7's inline auto-apply (findings are deferred to the next loop round, not applied this round).
-- Save findings via `update_round` exactly as in manual mode.
-- Auto-trigger `/cbp-round-update` immediately. round-update triages the round and either routes to `/cbp-round-input` (spawn another round) or **directs the user to run** `/cbp-round-complete` on a clean exit — see cbp-round-update SKILL.md Step 2/3.
-
-**Else (manual mode — flag absent or false):**
-
-Step 7 already auto-applied in-scope findings and logged them to `round.context.inline_fix_log`. Now record any out-of-scope findings and route:
-
-1. **Polish-spiral stop-gate** (round 2+ only): if this is round 2 or later AND the prior round also ended with code-review fixes, surface a one-line stop-gate via AskUserQuestion — *defer remaining polish to a follow-up task* vs *continue with another round*. This is a genuine user decision about scope (it guards against endless low-value polish loops), not a flow-control prompt. Skip on round 1.
-2. Save out-of-scope findings (those NOT auto-applied in Step 7) to round context via `codebyplan round update --id <round-id> --task-id <uuid> --checkpoint-id <uuid> --context <json>` (break-glass: MCP `update_round`):
-   ```json
-   {
-     "context": {
-       "improve_round_findings": [out-of-scope findings]
-     }
-   }
-   ```
-3. Auto-trigger `/cbp-round-update`. round-update triages the round: if out-of-scope findings (or a hard-fail) remain it routes to `/cbp-round-input` (which picks up the findings from round context and includes them in the new round's requirements automatically); if the round is clean it **directs the user to run** `/cbp-round-complete` (the user-invoked finalizer that reconciles the user's `git add`s and completes the round).
-
-## Key Rules
-
-- Claude NEVER git adds files — user approval is via git staging at `/cbp-round-complete`
-- Auto-triggers `/cbp-round-update` after findings are handled
-- `/cbp-round-end` is auto-triggered by `/cbp-round-execute` (user does not call it directly)
-- In-scope findings are **auto-applied inline** by the round-end orchestrator (the round was already approved at the `/cbp-round-execute` permission); out-of-scope findings route to `/cbp-round-input`. `cbp-improve-round` stays read-only/advisory. Baseline-regression accept (Step 7 gate) stays a user decision — baselines are NEVER auto-accepted.
-
-## Integration
-
-- **Triggered by**: `/cbp-round-execute` (auto, after all waves + testing complete)
-- **Reads**: `.codebyplan/state/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)
-- **Writes**: `codebyplan round update` (Step 4 round files/QA, Step 8 findings; break-glass: MCP `update_round`), `codebyplan task update` (Step 4 files_changed + QA aggregated; break-glass: MCP `update_task`)
-- **Spawns**: `cbp-improve-round` (code quality review)
-- **Triggers**: `/cbp-round-update` (auto, after findings handled)

package/templates/skills/cbp-round-end/reference/inline-fallback.md

@@ -1,35 +0,0 @@
-# Inline-Fallback for Any Spawn Failure
-
-When `improve-round` (or any agent spawned by this or peer skills) fails to spawn, the orchestrator falls through to an inline procedure that produces equivalent (lower-fidelity but valid) output. Same contract for every failure class — no special-casing per class.
-
-## Trigger conditions (any one)
-
-| Failure class             | Detection signal                                                                      |
-| ------------------------- | ------------------------------------------------------------------------------------- |
-| Org/billing limit         | `API Error: Extra usage is required for 1M context` (the original Proposal U trigger) |
-| Monthly Agent usage cap   | `API Error: This conversation has reached the monthly Agent usage limit` or similar   |
-| Provider 5xx              | Spawn returns `API Error 500` / `502` / `503` — transient or sustained                |
-| Rate limit                | `API Error 429` with retry hint                                                       |
-| Context overflow at spawn | Spawn returns `Context window exceeded` before agent can run                          |
-| Tool not available        | Skill caller's tool surface lacks Agent (rare — only in nested-agent contexts)        |
-
-## Fallback procedure (uniform across all triggers)
-
-1. Note the failure: `agent_spawned: false`, `skip_reason: "<one-line failure class>"`. Save to `round.context.improve_round_findings.spawn_failure = { class, error_message, decided_at }`.
-2. Perform the agent's analysis inline using whatever tools the orchestrator has (typically `Read` + `Bash` grep/find/head + `Glob`/`Grep`). Use the agent's documented Phase checklist as the script — agents are essentially curated checklists; following them inline produces equivalent (lower-fidelity but valid) output.
-3. Record findings in the same shape the agent would have returned (`findings[]` array with `severity`, `category`, `file`, `description`, `suggested_fix`). Mark each with `mode: 'inline_fallback'` so analytics can distinguish.
-4. Continue the skill — do NOT abort the round on spawn failure. The fallback is intended to keep the pipeline moving; aborting would force the user to manually re-run when the same failure will recur.
-
-**Pre-emptive skip**: when the same failure class fired in the previous round of the same task, skip the spawn attempt entirely and go straight to inline. This avoids one wasted API call per round during a sustained outage.
-
-## Coverage
-
-This fallback applies to:
-
-- `improve-round` spawned by `/cbp-round-end` (Step 6) — original case
-- `task-planner` spawned by `/cbp-round-start` Step 7 — orchestrator falls back to inline planning using the planner's Phase checklist
-- `testing-qa-agent` spawned by `/cbp-round-execute` Step 5 (per-wave) — orchestrator runs build/lint/types/tests inline via Bash and aggregates results in the agent's output shape
-- `task-check` spawned by `/cbp-task-check` skill — orchestrator walks the agent's verdict checklist inline
-- `improve-claude` spawned by its caller (when re-enabled) — orchestrator walks the agent's Phase 0-7 inline
-
-For details, each spawning skill carries a brief "Inline fallback" section pointing back to this contract. The canonical reference is here.

package/templates/skills/cbp-round-execute/reference/inline-fallback.md

@@ -1,55 +0,0 @@
-# Inline-fallback procedures
-
-When `round-executor` or `testing-qa-agent` cannot be spawned (env limits, monthly cap, 5xx, rate limit, context overflow), the orchestrator falls through to an inline procedure that walks the agent's Phase checklist using its own tools.
-
-The two fallback modes are documented separately so the SKILL.md stubs can link the right section.
-
-## Execution fallback (round-executor spawn failed)
-
-Triggered when the executor agent spawn returns one of the failure classes documented in `agent-spawn-failure-fallback.md`. Procedure:
-
-1. Detect failure class from error string. Record:
-   ```yaml
-   round.context.executor_findings.spawn_failure:
-     class: "monthly_agent_usage_limit" | "provider_5xx" | "rate_limit_429" | "context_overflow_at_spawn" | "billing_limit"
-     error_message: "<verbatim>"
-     decided_at: "<ISO>"
-   ```
-2. For `.claude/`-only file sets, fall through to the 3-INLINE branch in `../SKILL.md` Step 3 (orchestrator routes per file-routing.md to the matching build-cc skill or direct Edit).
-3. For non-`.claude/` file sets, walk `agents/round-executor.md` Phase 1–4 inline using Read / Edit / Write / Bash / Glob / Grep. Step 3 (Implementation) is the load-bearing phase — apply each `files_to_modify[]` deliverable in order, respecting wave boundaries when wave mode is active.
-4. Populate the executor's output contract with `mode: 'inline_fallback'` so analytics distinguishes.
-5. Pre-emptive skip on repeat: if `prior_round.context.executor_findings.spawn_failure.class === current_class`, skip the spawn attempt entirely and go straight to inline.
-
-## Validation fallback (testing-qa-agent spawn failed OR claude_only profile)
-
-Triggered when testing-qa-agent spawn returns a failure class, OR when the resolved profile is `claude_only` (in which case the agent should not have been spawned at all). Procedure:
-
-1. Detect failure class. Record:
-   ```yaml
-   round.context.testing_qa_findings.spawn_failure:
-     class: "<failure_class>"
-     error_message: "<verbatim>"
-     decided_at: "<ISO>"
-   ```
-2. Apply the profile gate matrix from `agents/testing-qa-agent.md` Phase 3 to determine which checks are in-scope:
-   - `claude_only`: only hook bash syntax (`bash -n <hook>`) + skill structure validation (line counts, scope marker, /cbp-* legacy notation absent)
-   - `web`: skip desktop + backend
-   - `backend`: skip web + desktop
-   - `desktop`: skip web + backend
-   - `full_matrix`: all
-   - `cross_app`: union of touched apps
-3. Walk `agents/testing-qa-agent.md` Phase 1 (Setup) + Phase 2 (Discovery) + Phase 3 (Mandatory Automated Testing) inline using Read / Grep / Bash. Aggregate per-check results.
-4. Populate `testing_qa_output` shape with `mode: 'inline_fallback'`. For `claude_only` specifically, use `mode: 'inline_synthesised_for_claude_only_profile'` (the agent was never expected to spawn — this isn't a fallback, it's the documented happy path).
-5. Pre-emptive skip on repeat: if `prior_round.context.testing_qa_findings.spawn_failure.class === current_class`, skip the spawn attempt entirely.
-
-## Pre-emptive skip rule
-
-Per `agent-spawn-failure-fallback.md` item 5: when the same failure class fired in the previous round of the same task, skip the spawn attempt entirely and go straight to inline. This avoids one wasted API call per round during a sustained outage.
-
-## Pairs With
-
-- `../SKILL.md` — points at this reference for procedural detail
-- `agents/round-executor.md` — execution-fallback target agent
-- `agents/testing-qa-agent.md` — validation-fallback target agent + Phase 3 profile gate matrix
-- `rules/agent-spawn-failure-fallback.md` — required-coverage table; canonical failure classes
-- `rules/testing-profile.md` — claude_only profile detail; cross-app union semantics

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)