codebyplan 1.13.49 → 1.13.50

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.

package/templates/skills/cbp-frontend-a11y/reference/contrast-visual.md

@@ -1,122 +0,0 @@
-# Contrast and Visual Accessibility Reference
-
-## WCAG 2.1 AA Contrast Requirements
-
-All text and UI components must meet these minimum contrast ratios:
-
-| Content type | Minimum ratio | Standard |
-|-------------|--------------|---------|
-| Normal text (< 18pt / < 14pt bold) | **4.5:1** | WCAG 2.1 AA SC 1.4.3 |
-| Large text (≥ 18pt / ≥ 14pt bold) | **3:1** | WCAG 2.1 AA SC 1.4.3 |
-| UI components (borders, icons, form controls) | **3:1** | WCAG 2.1 AA SC 1.4.11 |
-| Graphical objects (data chart elements, icons conveying meaning) | **3:1** | WCAG 2.1 AA SC 1.4.11 |
-
-**Decorative** elements (purely ornamental, no meaning) are EXEMPT.
-
-### Verification
-
-Use design tokens from `packages/design-tokens/` to derive hex values, then verify with a contrast checker:
-
-- Browser DevTools Accessibility panel
-- `npx @accessibility-checker/cli` against the rendered component
-- Design-tool plugins (Figma Contrast, Stark)
-
-If a token pair is new, record the ratio in a comment in the SCSS: `/* contrast: 5.2:1 vs --color-surface */`.
-
-## Focus Visible
-
-Focus indicators must NEVER be suppressed via `outline: none` or `outline: 0` without providing a replacement that meets **3:1 contrast** against adjacent colour:
-
-```scss
-// Anti-pattern — removes all visible focus indicator
-&:focus {
-  outline: none; // WCAG failure
-}
-
-// Correct — custom focus ring that meets 3:1 contrast
-&:focus-visible {
-  outline: 2px solid var(--color-focus-ring);   // 3:1 minimum
-  outline-offset: 2px;
-}
-```
-
-Use `:focus-visible` (not `:focus`) for the custom ring — `:focus-visible` suppresses the ring for mouse clicks while preserving it for keyboard navigation.
-
-The WCAG 2.2 enhanced criterion (SC 2.4.11, AAA) requires 3:1 contrast + 2px outline area. Target this for new components.
-
-## Colour-Only State Communication
-
-State conveyed through colour alone is a WCAG 2.1 AA failure (SC 1.4.1). Always pair colour with at least one of: icon, text label, pattern, or shape.
-
-| Anti-pattern | Fix |
-|-------------|-----|
-| Red border = error (colour only) | Red border + error icon + "Invalid email" text |
-| Green = online (colour only) | Green dot + "Online" text label |
-| Yellow = warning (colour only) | Yellow background + warning icon + descriptive text |
-| Active nav item is blue (colour only) | Blue + `aria-current="page"` + underline or bold weight |
-
-## prefers-reduced-motion
-
-Users with vestibular disorders may configure `prefers-reduced-motion: reduce` in their OS. Honour it:
-
-```scss
-@keyframes slideIn {
-  from { transform: translateX(-100%); }
-  to   { transform: translateX(0); }
-}
-
-.panel {
-  animation: slideIn 300ms ease-out;
-
-  @media (prefers-reduced-motion: reduce) {
-    animation: none;
-    // Provide instant appearance or a fade (no translate/scale/spin)
-  }
-}
-```
-
-For JavaScript-driven animations:
-
-```ts
-const prefersReduced = window.matchMedia('(prefers-reduced-motion: reduce)').matches;
-if (!prefersReduced) {
-  // run animation
-}
-```
-
-Transitions that solely affect `opacity` (fade) are generally safe — opacity changes do not trigger vestibular responses. Transforms (`translate`, `scale`, `rotate`) and large motion sweeps are the primary triggers.
-
-## Touch Target Size
-
-Interactive elements must have a minimum tap target of **44 × 44 CSS px** (Apple HIG / WCAG 2.5.5 AAA, de-facto standard):
-
-```scss
-.icon-button {
-  min-width: 44px;
-  min-height: 44px;
-  display: flex;
-  align-items: center;
-  justify-content: center;
-}
-```
-
-When the visible icon is smaller (e.g. 24px), expand the tap target with padding:
-
-```scss
-.icon-button {
-  padding: 10px; // 24px icon + 2×10px padding = 44px touch target
-}
-```
-
-On mobile breakpoints specifically, verify that adjacent interactive elements have at least 8px spacing between tap target edges to prevent accidental activation.
-
-## Text Resizing
-
-Users who increase browser text size up to 200% must be able to read and use all content without horizontal scroll (WCAG 1.4.4). Use relative units:
-
-- `font-size`: `rem` (relative to browser root, respects user preference)
-- `line-height`: unitless (e.g. `1.5`) or `em`
-- Container widths: `max-width` in `ch` or `%`, never fixed `px` for reading columns
-- Spacing: `em` for component-internal spacing; `rem` for layout spacing
-
-Avoid `px` for font sizes on text elements that users may need to scale.