codebyplan 1.13.49 → 1.13.51

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

@@ -11,7 +11,7 @@ Activate the session, open a fresh session log, and surface the previous log's p
 
 ## Instructions
 
-Run Steps 0 through 5.8 silently (no intermediate output) — except Step 0 aborts the session on MCP failure, Step 1.4 may surface a one-line fast-forward note or warning, Step 1.5 may surface a one-line infra-drift nudge, Step 1.55 may surface a one-line architecture-map drift nudge, Step 1.6 may run an install-and-halt path, Step 1.7 may surface a one-line LSP binary nudge, Step 4.5 may auto-resume a handoff and exit session-start entirely (no Step 6 output), and Step 5.7 may surface an approval gate. (Step numbers are organizational labels; execution order is 0 → 1 → 1.4 → 1.5 → 1.55 → 1.6 → 1.7 → 3 → 4 → 4.5 → 5 → 5.7 → 5.8 → 6 → 7.) Produce ONE output block at Step 6, then auto-trigger or stop per Step 7.
+Run Steps 0 through 5.8 silently (no intermediate output) — except Step 0 aborts the session on MCP failure, Step 1.5 may surface a one-line infra-drift nudge, Step 1.55 may surface a one-line architecture-map drift nudge, Step 1.6 may run an install-and-halt path, Step 1.7 may surface a one-line LSP binary nudge, Step 4.5 may auto-resume a handoff and exit session-start entirely (no Step 6 output), and Step 5.7 may surface an approval gate. (Step numbers are organizational labels; execution order is 0 → 1 → 1.5 → 1.55 → 1.6 → 1.7 → 3 → 4 → 4.5 → 5 → 5.7 → 5.8 → 6 → 7.) Produce ONE output block at Step 6, then auto-trigger or stop per Step 7.
 
 ### Step 0: MCP Health Gate
 
@@ -50,23 +50,11 @@ Extract `worktree_id` and `error_kind` from the JSON output.
 
 Pass `WORKTREE_ID` to MCP tools that support it. Null `WORKTREE_ID` means the (device, path, branch) tuple is unregistered — note this for Step 6.
 
-### Step 1.4: Home-Branch Fast-Forward
-
-Keep this worktree's **home branch** rooted at the freshest production tip — no prompt, fully non-blocking. Home branches are the folder-named placeholder branches each worktree rests on (e.g. `codebyplan-web`); `feat/*` branches are deliberately skipped — they integrate via `/cbp-merge-main` with QA, never an auto fast-forward.
-
-Run `codebyplan session home-ff` and parse the JSON output (`{ result: 'skipped'|'warn'|'fast_forwarded', reason?, warn? }`):
-
-- **`result === 'skipped'`** (non-home branch or production mismatch): proceed silently.
-- **`result === 'warn'`** (fast-forward attempt failed): surface the `warn` field as one line, then proceed silently.
-- **`result === 'fast_forwarded'`** (home branch updated): proceed silently.
-
-Never rebase, reset, force-push, or stash. A non-fast-forwardable home branch is a signal to reconcile manually, not to overwrite.
-
 ### Step 1.5: Infra Drift Check
 
-Surface — never block — when this worktree's source-monorepo `.claude/` infra has fallen behind. Runs after Step 1.4 and may add one line to the Step 6 output (`$PRODUCTION` is the branch resolved in Step 1.4). Consumer-repo package-version freshness is handled by Step 1.6 (the freshness gate), not here:
+Surface — never block — when this worktree's source-monorepo `.claude/` infra has fallen behind. Runs after Step 1 and may add one line to the Step 6 output (`$PRODUCTION` is `branch_config.production` read in Step 1). Consumer-repo package-version freshness is handled by Step 1.6 (the freshness gate), not here:
 
-- **Monorepo (concept A)** — both `packages/codebyplan-package/templates/` and `scripts/infra-drift.mjs` exist. Step 1.4 skips the fetch on a feat branch, so refresh `origin/$PRODUCTION` best-effort first, then run the reporter:
+- **Monorepo (concept A)** — both `packages/codebyplan-package/templates/` and `scripts/infra-drift.mjs` exist. Refresh `origin/$PRODUCTION` best-effort first, then run the reporter:
 
   ```bash
   git fetch origin "$PRODUCTION" 2>/dev/null || true
@@ -136,8 +124,6 @@ Run `codebyplan session freshness-gate --halt-on-update` and parse the JSON outp
 
     On this update-and-halt path the session is NOT continued: `update_session_state(activate)` is NOT called, `create_session_log` is NOT called, and `/cbp-todo` is NOT triggered.
 
-**Home branches are intentionally not guarded.** A worktree's folder-named home branch (e.g. `codebyplan-web`) is neither protected/main nor the canonical source, so the freshness gate returns `result !== 'guarded'` there and this gate fires exactly as on a feat branch. That is deliberate — the update lands on whatever branch the worktree is currently resting on (the "update the branch they're on, except main/canonical" decision), not an accidental halt.
-
 Populate the claude-status cache best-effort (pure cache population — never gates session-start):
 
 ```bash
@@ -271,7 +257,7 @@ Three-branch gate using `owned_count` and `total_count` from Step 5.8:
 
 - **Triggered by**: user invocation, `/clear` recovery
 - **Resolves**: `npx codebyplan resolve-worktree --json` (worktree id + distress signal; non-tuple-miss distress is non-blocking at session-start)
-- **Reads**: `.codebyplan/repo.json`, `.codebyplan/git.json` (`branch_config.production` for the Step 1.4 home-branch fast-forward), MCP `health_check` (Step 0 hard gate — stays MCP unconditionally); local-first reads (with `npx codebyplan sync` + MCP break-glass): `.codebyplan/state/session/current.json` (Step 4 previous log + Step 4.5 handoff probe), `.codebyplan/state/checkpoints/<id>.json` / `tasks/<id>.json` / `rounds/<id>.json` (Step 4.5 freshness probe), `.codebyplan/state/todos.json` (Step 5.7 active-task lookup); MCP `get_checkpoints({ repo_id, status: 'active' })` (Step 5.8 ownership partition — MCP only, no local mirror for active-filter query); `scripts/infra-drift.mjs` + a best-effort `git fetch` (Step 1.5 monorepo drift); `npx codebyplan arch-map drift` + `.codebyplan/architecture.json` presence (Step 1.55 architecture-map drift nudge, non-blocking); `codebyplan session home-ff` (Step 1.4 home-branch fast-forward); `codebyplan session freshness-gate --halt-on-update` (Step 1.6 package-freshness gate); `codebyplan session infra-files --json --task-files <csv>` (Step 5.7 infra-file set math); `npx codebyplan lsp --check` (Step 1.7 LSP binary nudge — reads `.codebyplan/lsp.json`, non-blocking). Reads at Step 3 and later do NOT fire on a Step 0 MCP hard-fail or the Step 1.6 update-and-halt path
+- **Reads**: `.codebyplan/repo.json`, `.codebyplan/git.json` (`branch_config.production` for Step 1.5 infra-drift fetch), MCP `health_check` (Step 0 hard gate — stays MCP unconditionally); local-first reads (with `npx codebyplan sync` + MCP break-glass): `.codebyplan/state/session/current.json` (Step 4 previous log + Step 4.5 handoff probe), `.codebyplan/state/checkpoints/<id>.json` / `tasks/<id>.json` / `rounds/<id>.json` (Step 4.5 freshness probe), `.codebyplan/state/todos.json` (Step 5.7 active-task lookup); MCP `get_checkpoints({ repo_id, status: 'active' })` (Step 5.8 ownership partition — MCP only, no local mirror for active-filter query); `scripts/infra-drift.mjs` + a best-effort `git fetch` (Step 1.5 monorepo drift); `npx codebyplan arch-map drift` + `.codebyplan/architecture.json` presence (Step 1.55 architecture-map drift nudge, non-blocking); `codebyplan session freshness-gate --halt-on-update` (Step 1.6 package-freshness gate); `codebyplan session infra-files --json --task-files <csv>` (Step 5.7 infra-file set math); `npx codebyplan lsp --check` (Step 1.7 LSP binary nudge — reads `.codebyplan/lsp.json`, non-blocking). Reads at Step 3 and later do NOT fire on a Step 0 MCP hard-fail or the Step 1.6 update-and-halt path
 - **Writes**: `codebyplan session create-log` (Step 5 — CLI write-through; break-glass: MCP `create_session_log`), `codebyplan session update-state --action activate` (Step 3 — CLI write-through to `.codebyplan/state/session/state.json`; break-glass: MCP `update_session_state`) — both SKIPPED on a Step 0 MCP hard-fail and on the Step 1.6 update-and-halt path
 - **Spawns**: none
 - **Triggers**: `/cbp-git-commit` (conditional, on user approval at Step 5.7 or the Step 1.6 update path), `handoff.command` (on fresh handoff hit at Step 4.5), `/cbp-todo` (auto fall-through when owned_count >= 1 or total_count === 0; STOPS with no trigger when total_count >= 1 AND owned_count === 0; NOT triggered on a Step 0 hard-fail or the Step 1.6 update-and-halt path)

package/templates/skills/cbp-supabase-migrate/SKILL.md

@@ -170,7 +170,7 @@ Stop.
 
 ### Record connection
 
-Record the branch so cleanup (see `cbp-checkpoint-end`, `cbp-git-worktree-remove`) and other
+Record the branch so cleanup (see `cbp-checkpoint-end`, `codebyplan worktree remove CHK-NNN`) and other
 skills can discover it. Phrase any context payload as prose — the MCP edge rejects raw
 uppercase database keywords (Cloudflare WAF).
 

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

@@ -120,7 +120,12 @@ Save agent output to task context: `codebyplan task update --id <taskId> --check
 
 **READY + satisfied:**
 
-**Next**: Run `/clear`, then `/cbp-task-testing {chk-task}` to run comprehensive task-level testing.
+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:**
 
@@ -130,7 +135,9 @@ Issues found that need addressing:
 - [issue 2]
 ```
 
-Suggest: `/cbp-round-input` with specific issues. **STOP HERE** — wait for user.
+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:**
 
@@ -139,7 +146,7 @@ Scope issues identified that require a new task:
 - [scope issue]
 ```
 
-Suggest: `/cbp-task-create`. **STOP HERE** — wait for user.
+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:**
 
@@ -147,7 +154,7 @@ Suggest: `/cbp-task-create`. **STOP HERE** — wait for user.
 Code review passed but [N] files need user approval.
 ```
 
-Suggest: Approve files, then re-run `/cbp-task-check`. **STOP HERE** — wait for user.
+Suggest: Approve files, then re-run `/cbp-task-check`. **STOP HERE** — wait for user (approval is a user action — not auto-triggered).
 
 ## Key Rules
 
@@ -161,5 +168,5 @@ Suggest: Approve files, then re-run `/cbp-task-check`. **STOP HERE** — wait fo
 
 - **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**: emits directive `Next: /clear, then /cbp-task-testing {chk-task}` on READY + satisfied (cross-context — testing is heavyweight, fresh context helps)
+- **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)

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

@@ -2,6 +2,7 @@
 name: cbp-task-complete
 description: Complete current task
 argument-hint: [chk-task]
+triggers: [cbp-task-start, cbp-checkpoint-check]
 effort: xhigh
 ---
 
@@ -155,7 +156,7 @@ Show the completion summary:
 **Warnings**: [any QA / file-approval warnings from Step 3, or "none"]
 ```
 
-Then route. Same-context transitions (next task in this checkpoint) auto-trigger via the Skill tool. Cross-context transitions (checkpoint done → /cbp-checkpoint-check, session end) surface as a single directive 'Next: /clear, then /cbp-X' for the user to invoke after refreshing context.
+Then route. Same-context transitions (next task in this checkpoint) auto-trigger `cbp-task-start` via the Skill tool. Checkpoint-done (last task) also auto-triggers `cbp-checkpoint-check` via the Skill tool (`ask`-tier — the permission prompt is the human gate; the 200K context guard handles oversized contexts via the cbp-clear-prep flow). Only the no-task-anywhere session-end fallback surfaces as a single directive (`Next: Run /clear, then /cbp-session-end`) for the user to invoke.
 
 #### 9a — Determine routing context
 
@@ -179,16 +180,13 @@ Use the Skill tool with `skill: cbp-task-start` and `args: "{NEXT_CHK}-{NEXT_TAS
 
 If no next task is found (no pending work anywhere in the repo), emit directive and stop: `Next: Run /clear, then /cbp-session-end.`
 
-#### 9c — Checkpoint-done directive (last task in checkpoint)
+#### 9c — Checkpoint-done auto-trigger (last task in checkpoint)
 
-The checkpoint has no remaining tasks. Emit this directive and stop:
-
-```
-CHK-{NNN} is fully tasked. Run /clear, then /cbp-checkpoint-check to verify and ship.
-Alternatives: /cbp-checkpoint-update {NNN} to expand the checkpoint with more tasks, or /cbp-session-end to wrap up here.
-```
-
-Do NOT use AskUserQuestion here — this is a directive, not a menu. The user runs whichever command fits their intent.
+The checkpoint has no remaining tasks. Invoke `cbp-checkpoint-check` via the Skill tool.
+`cbp-checkpoint-check` is `ask`-tier — the harness permission prompt IS the human gate; the
+user confirms (or declines) before checkpoint verification and ship begins. If the context
+window is above the 200K threshold the `cbp-skill-context-guard.sh` hook will block it and
+direct you to run `/cbp-clear-prep` first; otherwise checkpoint-check starts on confirmation.
 
 ## Integration
 
@@ -197,5 +195,5 @@ Do NOT use AskUserQuestion here — this is a directive, not a menu. The user ru
 - **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`/`get_tasks` break-glass)
 - **Writes**: `codebyplan task update` for `files_changed` (CLI write-through; MCP `update_task` break-glass); MCP `complete_task` for task completion (kept MCP — CLI cannot forward `caller_worktree_id`)
 - **Uses skills (inline, no sub-agent)**: `cleanup` (if deletions), `migration` (if exports renamed)
-- **Triggers**: Same-context transitions auto-trigger via the Skill tool (next task in checkpoint → `/cbp-task-start {N}`). Cross-context transitions emit a directive `Next: /clear, then /cbp-X` for the user to invoke.
+- **Triggers**: Same-context transitions auto-trigger via the Skill tool (next task in checkpoint → `cbp-task-start {N}`, `allow`-tier, fires silently). Checkpoint-done → auto-triggers `cbp-checkpoint-check` via Skill tool (`ask`-tier, permission prompt IS the human gate). No-task-anywhere fallback → directive `Next: Run /clear, then /cbp-session-end.`
 - **Checkpoint-bound only** — for standalone tasks use `/cbp-standalone-task-complete`

package/templates/skills/cbp-task-complete/reference/checkpoint-done-branching.md

@@ -1,8 +1,8 @@
-# Checkpoint-Done Branching in `/cbp-task-complete` Step 9
+# Checkpoint-Done Auto-Trigger in `/cbp-task-complete` Step 9
 
-When the just-completed task was the LAST pending task in its checkpoint (every sibling task has `status === 'completed'`), Step 9c emits a directive instead of a routing menu. The user reads the directive and runs whichever command fits their intent — no AskUserQuestion.
+When the just-completed task was the LAST pending task in its checkpoint (every sibling task has `status === 'completed'`), Step 9c auto-triggers `cbp-checkpoint-check` via the Skill tool — no routing menu, no manual `/clear` directive.
 
-This file describes the detection logic, the directive form, and the standalone fall-through.
+This file describes the detection logic, the auto-trigger form, and the standalone fall-through.
 
 ## Detection
 
@@ -10,39 +10,32 @@ The skill detects "checkpoint done" at Step 9 by:
 
 1. Reading `current_task.checkpoint_id`. If `null` → standalone — see "Standalone Fall-Through" below.
 2. Calling `get_tasks(checkpoint_id)` and checking that EVERY task other than the just-completed one has `status === 'completed'`.
-3. If yes, the checkpoint has no pending or in-progress siblings — emit the Step 9c directive.
+3. If yes, the checkpoint has no pending or in-progress siblings — fire the Step 9c auto-trigger.
 
-## Step 9c Directive Form
+## Step 9c Auto-Trigger Form
 
-When all siblings are done, the skill emits:
+When all siblings are done, the skill invokes `cbp-checkpoint-check` via the Skill tool:
 
-```
-CHK-{NNN} is fully tasked. Run /clear, then /cbp-checkpoint-check to verify and ship.
-Alternatives: /cbp-checkpoint-update {NNN} to expand the checkpoint with more tasks, or /cbp-session-end to wrap up here.
-```
+- `cbp-checkpoint-check` is `ask`-tier — the harness permission prompt IS the human gate. The user confirms (or declines) before checkpoint verification and the shipment chain begin.
+- No `/clear` is emitted unconditionally. If the `cbp-skill-context-guard.sh` hook detects the context window is above the 200K threshold it blocks the skill and directs you to run `/cbp-clear-prep` first (which writes a handoff; the user then runs `/clear`, then `/cbp-clear-continue` resumes); otherwise checkpoint-check starts immediately on confirmation.
 
-This is a directive, not a menu. No AskUserQuestion. The user runs whichever command fits their intent:
-
-- `/clear` then `/cbp-checkpoint-check` — verify deliverables and begin the shipment chain
-- `/cbp-checkpoint-update {NNN}` — expand the checkpoint with more tasks (routes through `checkpoint-update` FIRST, not directly to `task-create`)
-- `/cbp-session-end` — wrap up here
-
-The skill does NOT auto-invoke any of these. Emit the directive, then stop.
+There is no AskUserQuestion menu. Expanding the checkpoint with more tasks (`/cbp-checkpoint-update`) or wrapping up the session (`/cbp-session-end`) are no longer surfaced as inline alternatives — the deterministic next step on checkpoint-done is `cbp-checkpoint-check`. (The user can still invoke those other skills manually at any time; they are simply not part of the auto-flow.)
 
 ## Standalone Fall-Through
 
 When the just-completed task is standalone (`checkpoint_id === null`):
 
-- The Step 9c directive does NOT apply. There is no checkpoint to ship, expand, or defer.
+- The Step 9c auto-trigger does NOT apply. There is no checkpoint to verify or ship.
 - Step 9 falls through to next-task routing per `next-step-heuristic.md` "Standalone Variant":
   - If a next pending task is found (standalone or in-progress checkpoint): auto-trigger via Skill tool — no AskUserQuestion, no /clear.
   - If no pending tasks remain anywhere: emit single directive `**Next**: Run /clear, then /cbp-session-end.` — all known work complete.
 
 ## What the Skill Does NOT Do
 
-Never auto-trigger `/cbp-checkpoint-check`, `/cbp-checkpoint-update`, or auto-mark the checkpoint complete — those are cross-context transitions that emit a single directive, not auto-invocations. Never combine the Step 9c directive with the Step 9b auto-trigger in the same response — one or the other based on detection, not both.
+- Never combine the Step 9c auto-trigger (checkpoint done → `cbp-checkpoint-check`) with the Step 9b auto-trigger (next task in checkpoint → `cbp-task-start`) in the same response — fire one or the other based on detection, not both.
+- Never present a multi-option AskUserQuestion menu for routing between known-next skills (per the close-out-routing rule — auto-trigger or a single directive, never an A/B/C menu).
 
 ## Pairs With
 
-- `next-step-heuristic.md` — sibling reference for non-last-task-in-checkpoint case (Step 9b auto-trigger)
-- `.claude/skills/cbp-checkpoint-update/SKILL.md` — destination of the expand path; accepts the entry-context preamble described in Step 9c
+- `next-step-heuristic.md` — sibling reference for the non-last-task-in-checkpoint case (Step 9b auto-trigger)
+- `.claude/skills/cbp-checkpoint-check/SKILL.md` — the auto-triggered destination on checkpoint-done

package/templates/skills/cbp-task-complete/reference/next-step-heuristic.md

@@ -17,19 +17,17 @@ No AskUserQuestion, no `/clear`. The skill fires immediately.
 
 ## Case 2 — Cross-Context (checkpoint done, session end)
 
-When the checkpoint is fully done or no pending tasks exist in the current context, emit a single directive line at the end of skill output and stop:
+Two sub-cases:
 
-```
-**Next**: Run /clear, then /cbp-checkpoint-check.
-```
+**Checkpoint done** (last task in the checkpoint complete): auto-trigger `cbp-checkpoint-check` via the Skill tool. `cbp-checkpoint-check` is `ask`-tier — the permission prompt is the human gate; the 200K context guard handles oversized contexts (via `cbp-clear-prep`) only when context is near the limit. No unconditional `/clear`. (See `checkpoint-done-branching.md`.)
 
-Or for session-end:
+**Session end** (no pending tasks anywhere): emit a single directive line at the end of skill output and stop:
 
 ```
 **Next**: Run /clear, then /cbp-session-end.
 ```
 
-The user runs the command after refreshing context. No menu, no options — just one directive.
+The user runs session-end after refreshing context. No menu, no options — just one directive.
 
 ## Rule
 

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

@@ -2,7 +2,7 @@
 name: cbp-task-testing
 description: Run comprehensive task-level testing after /cbp-task-check passes
 argument-hint: [chk-task]
-triggers: [cbp-task-complete]
+triggers: [cbp-task-complete, cbp-round-input]
 effort: xhigh
 ---
 
@@ -233,21 +233,16 @@ Collect failures from automated tests (Step 6), cross-round code review (Step 6.
 All tests passed for TASK-[N]. Routing to task-complete...
 ```
 
-Auto-trigger `/cbp-task-complete`.
+Invoke `cbp-task-complete` via the Skill tool. `cbp-task-complete` is `ask`-tier — the harness
+permission prompt IS the human gate; the user confirms (or declines) before task commit,
+merge-main, and completion.
 
 **Minor problems found:**
 
----
-
-**Next:**
-Run `/cbp-round-input` to:
-
-- Address the minor issues found during testing
-- Create a focused round for fixes
-
----
+Invoking `cbp-round-input` to address the minor issues found during testing...
 
-Waiting for user to run `/cbp-round-input`.
+Invoke `cbp-round-input` via the Skill tool. `cbp-round-input` is `allow`-tier — it auto-fires
+silently.
 
 **Major problems found:**
 
@@ -278,5 +273,5 @@ Waiting for user to run `/cbp-task-create`.
 
 - **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 aggregated files
 - **Writes**: `codebyplan task update` (CLI write-through; MCP `update_task` break-glass)
-- **Triggers**: `/cbp-task-complete` (auto, when ALL PASS)
-- **Triggered by**: user runs `/cbp-task-testing {chk-task}` per directive from `/cbp-task-check` on READY verdict (after `/cbp-round-execute`-driven validation completed all rounds)
+- **Triggers**: `cbp-task-complete` (auto via Skill tool, when ALL PASS — `ask`-tier, permission prompt IS the human gate); `cbp-round-input` (auto via Skill tool, on minor problems — `allow`-tier, fires silently)
+- **Triggered by**: `cbp-task-check` auto-triggers this skill via Skill tool on READY verdict; `cbp-task-testing` is `allow`-tier and fires silently (no permission prompt)

package/templates/skills/cbp-frontend-a11y/SKILL.md

@@ -1,108 +0,0 @@
----
-name: cbp-frontend-a11y
-description: Pre-implementation accessibility playbook loaded BEFORE writing UI / styling code. Produces a per-component checklist of WCAG 2.1 AA obligations from semantic HTML, ARIA roles/states, keyboard patterns, and contrast requirements.
-effort: xhigh
----
-
-# Frontend Accessibility (Pre-Implementation Playbook)
-
-Loaded by `round-executor` Step 2.6 BEFORE any UI or styling file is written, AFTER `frontend-design` has committed to an aesthetic direction. Produces a concrete pre-write checklist — not a post-implementation audit.
-
-## When this skill fires
-
-Invoked when the wave's `skill_preloads[]` contains `"frontend-a11y"` (set by planner Phase 5.6 when `wave.files[]` includes UI-bearing paths). See `rules/frontend-accessibility-invocation.md` for the trigger gate.
-
-If none of the wave files are UI-bearing, skip — proceed to Step 3.
-
-## Phase 1: Read tokens and sibling components
-
-1. Identify design tokens from the plan's context or `frontend-design` output — colour tokens are needed for contrast checks.
-2. Glob for sibling components in the same directory as files being authored. Read 1-2 examples to understand existing `aria-*` usage, `role` attributes, keyboard handlers, focus management patterns.
-3. Note the established a11y posture: does the codebase already use `role="dialog"` patterns? Does it trap focus in modals? Are there custom keyboard handlers?
-
-## Phase 2: Detect the stack
-
-Read the planner's `test_strategy.platform` or grep for signal files:
-
-| Signal | Stack |
-|--------|-------|
-| `next.config.ts` | Next.js (App Router) |
-| `expo` in deps | React Native / Expo |
-| `tauri.conf.json` | Tauri web view |
-
-Load the matching reference doc from `reference/` (relative to this SKILL.md):
-
-- Next.js / web: read `reference/semantic-html.md`, `reference/aria-roles-states.md`, `reference/keyboard-patterns.md`, `reference/contrast-visual.md`
-- React Native: read `reference/aria-roles-states.md`, `reference/contrast-visual.md` (semantic HTML n/a for RN)
-- Tauri web view: same as Next.js / web
-
-## Phase 3: Load reference docs
-
-For the detected stack, read EACH applicable reference doc in sequence. Do not skip — the pre-write checklist is derived from their combined content.
-
-Reference docs (paths relative to this SKILL.md):
-
-- `reference/semantic-html.md` — landmark roles, heading hierarchy, element semantics, anti-patterns
-- `reference/aria-roles-states.md` — role table, aria-label vs aria-labelledby, live regions, expanded/pressed/hidden
-- `reference/keyboard-patterns.md` — focus management, tab order, Esc, arrow keys, focus traps, type-ahead
-- `reference/contrast-visual.md` — WCAG 2.1 AA ratios, focus-visible, colour-only state, reduced-motion, touch targets
-
-## Phase 4: Commit to per-component obligations
-
-For each component or element type in `wave.files[]`, derive explicit obligations from the reference docs. Group by component:
-
-```
-Component: <ComponentName> (<path>)
-  - Semantic: [e.g. "use <button> not <div onClick>"]
-  - ARIA: [e.g. "aria-expanded on disclosure trigger"]
-  - Keyboard: [e.g. "Esc closes; focus returns to trigger"]
-  - Contrast: [e.g. "border token needs 3:1 vs background — verify"]
-  - Touch: [e.g. "min 44x44px tap target on mobile"]
-```
-
-Unknown component types get the universal checklist from Phase 5.
-
-## Phase 5: Universal guidelines (applied to every component)
-
-Regardless of component type, every UI component must satisfy:
-
-1. Every interactive element is keyboard-reachable and activatable (Enter/Space for buttons, Enter for links)
-2. Focus-visible is never removed via `outline: none` without a custom indicator meeting 3:1 contrast
-3. No state conveyed via colour alone — icon + text + colour
-4. `prefers-reduced-motion` media query wraps any animation
-5. Touch targets ≥ 44×44 CSS px
-6. Images have `alt` text (decorative images use `alt=""`)
-7. Form inputs have associated `<label htmlFor>` or `aria-label`
-
-## Phase 6: Output pre-write checklist
-
-Produce a flat checklist in `round.context.frontend_a11y_checklist`:
-
-```yaml
-frontend_a11y_checklist:
-  - component: "<ComponentName>"
-    file: "<path>"
-    items:
-      - "[Semantic] use <button> not <div onClick>"
-      - "[ARIA] aria-expanded on trigger; aria-controls referencing panel id"
-      - "[Keyboard] Esc closes panel; focus returns to trigger"
-      - "[Contrast] verify focus ring token meets 3:1 vs background"
-      - "[Touch] min 44x44px on mobile breakpoint"
-```
-
-The executor consults this checklist when authoring each component in Step 3.
-
-## Output back to round-executor
-
-```yaml
-round.context.frontend_a11y_loaded: true
-round.context.frontend_a11y_checklist: [per-component checklist items]
-```
-
-## Integration
-
-- **Invoked by**: `round-executor` Step 2.6 (when `"frontend-a11y"` in `wave.skill_preloads[]`)
-- **Reads**: `reference/semantic-html.md`, `reference/aria-roles-states.md`, `reference/keyboard-patterns.md`, `reference/contrast-visual.md`
-- **Output consumed by**: `round-executor` Step 3 (implementation guidance)
-- **Pairs with**: `frontend-design` (invoked first in Step 2.6), `frontend-ui` + `frontend-ux` (post-implementation Step 3.8)
-- **Trigger rule**: `rules/frontend-accessibility-invocation.md`

package/templates/skills/cbp-frontend-a11y/reference/aria-roles-states.md

@@ -1,130 +0,0 @@
-# ARIA Roles, States, and Properties Reference
-
-**Golden rule**: Prefer native HTML semantics. ARIA fills gaps — it does not replace semantic elements. An `<input type="checkbox">` is always better than `<div role="checkbox">`.
-
-## When to Add a Role
-
-Use `role` ONLY when no native HTML element maps to the semantic need:
-
-| Pattern | Native element | ARIA role (fallback) |
-|---------|---------------|----------------------|
-| Dialog / modal | — | `role="dialog"` + `aria-modal="true"` |
-| Alerting status message | — | `role="status"` or `role="alert"` |
-| Tab list | — | `role="tablist"`, `role="tab"`, `role="tabpanel"` |
-| Custom listbox | — | `role="listbox"`, `role="option"` |
-| Progress indicator | `<progress>` | `role="progressbar"` if `<progress>` unstyled |
-| Tooltip | `title` attr (limited) | `role="tooltip"` + `aria-describedby` |
-
-## aria-label vs aria-labelledby vs aria-describedby
-
-| Attribute | Use when | Priority |
-|-----------|----------|----------|
-| `aria-labelledby` | A visible text element names this element | Highest — overrides aria-label and native label |
-| `aria-label` | No visible text label exists (icon buttons, close buttons) | Medium |
-| `aria-describedby` | Additional descriptive text supplements the label | Lowest — supplementary, not a primary name |
-
-Examples:
-```jsx
-// Icon button — no visible label
-<button aria-label="Close dialog">
-  <Icon name="x" aria-hidden="true" />
-</button>
-
-// Element labelled by visible heading
-<section aria-labelledby="billing-heading">
-  <h2 id="billing-heading">Billing</h2>
-</section>
-
-// Field with hint text
-<input id="password" aria-describedby="password-hint" />
-<span id="password-hint">Must be at least 8 characters</span>
-```
-
-## Live Regions
-
-Announce dynamic content changes to screen readers without moving focus.
-
-| Role / Attribute | Urgency | Use for |
-|-----------------|---------|---------|
-| `aria-live="polite"` | Waits for user to be idle | Status messages, form validation summaries, search result counts |
-| `aria-live="assertive"` | Interrupts immediately | Critical errors, session timeout warnings |
-| `role="status"` | Same as `aria-live="polite"` | Status messages (shorthand) |
-| `role="alert"` | Same as `aria-live="assertive"` | Error alerts (shorthand) |
-
-Anti-pattern: using `role="alert"` for non-urgent messages — screen reader interruptions are disruptive. Reserve for true emergencies.
-
-```jsx
-// Status (polite)
-<div role="status" aria-live="polite">{statusMessage}</div>
-
-// Error (assertive)
-<div role="alert">{errorMessage}</div>
-```
-
-## Common State Attributes
-
-| Attribute | Values | Use for |
-|-----------|--------|---------|
-| `aria-expanded` | `true` / `false` | Disclosure triggers (accordion, dropdown, menu) |
-| `aria-pressed` | `true` / `false` / `"mixed"` | Toggle buttons (bold, like, mute) |
-| `aria-hidden` | `true` | Decorative elements, icon-only images — removes from accessibility tree |
-| `aria-checked` | `true` / `false` / `"mixed"` | Custom checkbox/radio when not using `<input type="checkbox">` |
-| `aria-disabled` | `true` | Visually disabled but still focusable (use sparingly) |
-| `aria-selected` | `true` / `false` | Selected tab, selected option in listbox |
-| `aria-current` | `"page"` / `"step"` / `true` | Current item in nav, current step in wizard |
-
-```jsx
-// Accordion trigger
-<button
-  aria-expanded={isOpen}
-  aria-controls="panel-1"
->
-  Section title
-</button>
-<div id="panel-1" hidden={!isOpen}>...</div>
-
-// Toggle button
-<button
-  aria-pressed={isBold}
-  onClick={() => setIsBold(!isBold)}
->
-  Bold
-</button>
-
-// Decorative icon
-<svg aria-hidden="true" focusable="false">...</svg>
-```
-
-## aria-hidden Usage Rules
-
-- `aria-hidden="true"` removes element and ALL descendants from accessibility tree
-- Never place `aria-hidden="true"` on a focusable element (keyboard users still reach it)
-- Common correct uses: decorative icons, background images, duplicate visible text (when the accessible name comes from aria-label)
-
-```jsx
-// Correct: icon inside labelled button
-<button aria-label="Delete">
-  <TrashIcon aria-hidden="true" />
-</button>
-
-// Wrong: aria-hidden on focusable element
-<button aria-hidden="true">...</button>  // users can still Tab to it
-```
-
-## Dialog Pattern
-
-```jsx
-<dialog
-  role="dialog"
-  aria-modal="true"
-  aria-labelledby="dialog-title"
-  aria-describedby="dialog-description"
->
-  <h2 id="dialog-title">Confirm deletion</h2>
-  <p id="dialog-description">This action cannot be undone.</p>
-  <button onClick={onConfirm}>Delete</button>
-  <button onClick={onClose}>Cancel</button>
-</dialog>
-```
-
-Focus must move INTO the dialog on open and RETURN to the trigger on close. See `keyboard-patterns.md` for focus trap implementation.