tribunal-kit 6.0.1 → 8.0.0

package/.agent/skills/emil-design-eng/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before designing or reviewing UI micro-animations, you MUST inspect:
+
 1. Frequency Gate (Section 54) → Never animate keyboard actions or high-frequency controls (100+ times/day); keep UI animations under 300ms
 2. Easing Rule (Section 75) → Use strong `ease-out` (`cubic-bezier(0.23, 1, 0.32, 1)`) for entering UI elements; ban `ease-in`
 3. Origin-Aware Popovers (Section 114) → Never animate scale from `scale(0)`; start at `scale(0.95)` with origin bound to trigger coordinates
@@ -35,44 +36,50 @@ You are a design engineer with the craft sensibility. You build interfaces where
 ## Core Philosophy
 
 ### Taste is trained, not innate
+
 Good taste is not personal preference. It is a trained instinct: the ability to see beyond the obvious and recognize what elevates. Develop it by surrounding yourself with great work, thinking deeply about why something feels good, and practicing relentlessly.
 
 ### Unseen details compound
+
 Most details users never consciously notice. That is the point. When a feature functions exactly as someone assumes it should, they proceed without giving it a second thought. Every decision below exists because the aggregate of invisible correctness creates interfaces people love without knowing why.
 
 ### Beauty is leverage
+
 People select tools based on the overall experience, not just functionality. Good defaults and good animations are real differentiators. Use beauty as leverage to stand out.
 
 ## Review Format (Required)
 
 When reviewing UI code, you MUST use a markdown table with Before/After columns. Do NOT use a list with "Before:" and "After:" on separate lines. Always output an actual markdown table like this:
 
-| Before | After | Why |
-| --- | --- | --- |
-| `transition: all 300ms` | `transition: transform 200ms ease-out` | Specify exact properties; avoid `all` |
-| `transform: scale(0)` | `transform: scale(0.95); opacity: 0` | Nothing in the real world appears from nothing |
-| `ease-in` on dropdown | `ease-out` with custom curve | `ease-in` feels sluggish; `ease-out` gives instant feedback |
-| No `:active` state on button | `transform: scale(0.97)` on `:active` | Buttons must feel responsive to press |
-| `transform-origin: center` | `transform-origin: var(--radix-popover-content-transform-origin)` | Popovers should scale from their trigger |
+| Before                       | After                                                             | Why                                                         |
+| ---------------------------- | ----------------------------------------------------------------- | ----------------------------------------------------------- |
+| `transition: all 300ms`      | `transition: transform 200ms ease-out`                            | Specify exact properties; avoid `all`                       |
+| `transform: scale(0)`        | `transform: scale(0.95); opacity: 0`                              | Nothing in the real world appears from nothing              |
+| `ease-in` on dropdown        | `ease-out` with custom curve                                      | `ease-in` feels sluggish; `ease-out` gives instant feedback |
+| No `:active` state on button | `transform: scale(0.97)` on `:active`                             | Buttons must feel responsive to press                       |
+| `transform-origin: center`   | `transform-origin: var(--radix-popover-content-transform-origin)` | Popovers should scale from their trigger                    |
 
 ## The Animation Decision Framework
 
 Before writing any animation code, answer these questions in order:
 
 ### 1. Should this animate at all?
+
 **Ask:** How often will users see this animation?
 
-| Frequency | Decision |
-| --- | --- |
-| 100+ times/day (keyboard shortcuts, command palette) | No animation. Ever. |
-| Tens of times/day (hover effects, list navigation) | Remove or drastically reduce |
-| Occasional (modals, drawers, toasts) | Standard animation |
-| Rare/first-time (onboarding, feedback forms, celebrations) | Can add delight |
+| Frequency                                                  | Decision                     |
+| ---------------------------------------------------------- | ---------------------------- |
+| 100+ times/day (keyboard shortcuts, command palette)       | No animation. Ever.          |
+| Tens of times/day (hover effects, list navigation)         | Remove or drastically reduce |
+| Occasional (modals, drawers, toasts)                       | Standard animation           |
+| Rare/first-time (onboarding, feedback forms, celebrations) | Can add delight              |
 
 **Never animate keyboard-initiated actions.** These actions are repeated hundreds of times daily. Animation makes them feel slow and disconnected.
 
 ### 2. What is the purpose?
+
 Valid purposes:
+
 - **Spatial consistency**: toast enters/exits from the same direction.
 - **State indication**: a morphing feedback button shows state change.
 - **Explanation**: a marketing animation showing a feature.
@@ -82,45 +89,52 @@ Valid purposes:
 If the purpose is just "it looks cool" and the user sees it often, don't animate.
 
 ### 3. What easing should it use?
+
 Is the element entering or exiting?
-  Yes → ease-out (starts fast, feels responsive)
-  No →
-    Is it moving/morphing on screen?
-      Yes → ease-in-out (natural acceleration/deceleration)
-    Is it a hover/color change?
-      Yes → ease
-    Is it constant motion?
-      Yes → linear
-    Default → ease-out
+Yes → ease-out (starts fast, feels responsive)
+No →
+Is it moving/morphing on screen?
+Yes → ease-in-out (natural acceleration/deceleration)
+Is it a hover/color change?
+Yes → ease
+Is it constant motion?
+Yes → linear
+Default → ease-out
 
 **Critical: use custom easing curves.**
+
 ```css
 /* Strong ease-out for UI interactions */
 --ease-out: cubic-bezier(0.23, 1, 0.32, 1);
 /* Strong ease-in-out for on-screen movement */
 --ease-in-out: cubic-bezier(0.77, 0, 0.175, 1);
 ```
+
 **Never use ease-in for UI animations.** It makes the interface feel sluggish.
 
 ### 4. How fast should it be?
-| Element | Duration |
-| --- | --- |
-| Button press feedback | 100-160ms |
+
+| Element                  | Duration  |
+| ------------------------ | --------- |
+| Button press feedback    | 100-160ms |
 | Tooltips, small popovers | 125-200ms |
-| Dropdowns, selects | 150-250ms |
-| Modals, drawers | 200-500ms |
+| Dropdowns, selects       | 150-250ms |
+| Modals, drawers          | 200-500ms |
 
 **Rule: UI animations should stay under 300ms.** Perception of speed matters as much as actual speed.
 
 ## Component Building Principles
 
 ### Buttons must feel responsive
+
 Add `transform: scale(0.97)` on `:active` with subtle transition (160ms ease-out).
 
 ### Never animate from scale(0)
+
 Start from `scale(0.95)` or higher combined with opacity.
 
 ### Make popovers origin-aware
+
 Popovers should scale in from their trigger, not from center. Explicitly set `transform-origin` to the trigger coordinates (e.g., `var(--radix-popover-content-transform-origin)`). Modals are exempt as they are viewport-centered.
 
 ---
@@ -141,6 +155,7 @@ Popovers should scale in from their trigger, not from center. Explicitly set `tr
 ### ✅ Pre-Flight Self-Audit
 
 Review these questions before confirming output:
+
 ```
 ✅ Did I justify the animation's existence based on frequency?
 ✅ Are all UI animations under 300ms?
@@ -152,5 +167,6 @@ Review these questions before confirming output:
 ### 🛑 Verification-Before-Completion (VBC) Protocol
 
 **CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
+
 - ❌ **Forbidden:** Declaring animation work complete because the code compiles.
 - ✅ **Required:** Provide evidence that the animation executes flawlessly at 60fps in the browser, adhering to the 300ms budget and easing rules.

package/.agent/skills/error-resilience/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before writing retry logic, circuit breakers, or error handling routines, you MUST inspect:
+
 1. Idempotency Key Rule for Retries (Section 123) → Require explicit idempotency keys when retrying non-safe operations (POST/PUT); ban un-keyed retries
 2. Exponential Backoff with Jitter (Section 106) → Implement randomized full jitter with capped exponential delays; ban fixed-delay retry loops
 3. Operational vs Programmer Error Split (Section 28) → Catch and recover strictly from `OperationalError` instances; allow programmer bugs (`TypeError`) to crash fast
@@ -102,7 +103,12 @@ const DEFAULT_RETRY: RetryOptions = {
   maxRetries: 3,
   baseDelayMs: 500,
   maxDelayMs: 15_000,
-  retryableErrors: (err) => err instanceof Error && (err.message.includes("ECONNRESET") || err.message.includes("ETIMEDOUT") || err.message.includes("503") || err.message.includes("429")),
+  retryableErrors: err =>
+    err instanceof Error &&
+    (err.message.includes('ECONNRESET') ||
+      err.message.includes('ETIMEDOUT') ||
+      err.message.includes('503') ||
+      err.message.includes('429')),
 };
 
 async function withRetry<T>(fn: () => Promise<T>, options: Partial<RetryOptions> = {}): Promise<T> {
@@ -122,16 +128,19 @@ async function withRetry<T>(fn: () => Promise<T>, options: Partial<RetryOptions>
       const capped = Math.min(exponential, opts.maxDelayMs);
       const jitter = Math.random() * capped;
 
-      console.warn(`[RETRY] Attempt ${attempt + 1}/${opts.maxRetries} failed. ` + `Retrying in ${Math.round(jitter)}ms...`);
+      console.warn(
+        `[RETRY] Attempt ${attempt + 1}/${opts.maxRetries} failed. ` +
+          `Retrying in ${Math.round(jitter)}ms...`,
+      );
 
       await sleep(jitter);
     }
   }
-  throw new Error("Unreachable");
+  throw new Error('Unreachable');
 }
 
 function sleep(ms: number): Promise<void> {
-  return new Promise((resolve) => setTimeout(resolve, ms));
+  return new Promise(resolve => setTimeout(resolve, ms));
 }
 
 // ❌ NEVER retry non-idempotent operations without idempotency keys
@@ -145,9 +154,9 @@ function sleep(ms: number): Promise<void> {
 
 ```typescript
 enum CircuitState {
-  CLOSED = "CLOSED", // Normal — requests pass through
-  OPEN = "OPEN", // Tripped — requests fail immediately
-  HALF_OPEN = "HALF_OPEN", // Testing — one request allowed
+  CLOSED = 'CLOSED', // Normal — requests pass through
+  OPEN = 'OPEN', // Tripped — requests fail immediately
+  HALF_OPEN = 'HALF_OPEN', // Testing — one request allowed
 }
 
 class CircuitBreaker {
@@ -210,7 +219,7 @@ const paymentCircuit = new CircuitBreaker(5, 30_000);
 
 const result = await paymentCircuit.execute(
   () => paymentGateway.charge(amount),
-  () => ({ status: "deferred", message: "Payment queued for retry" }),
+  () => ({ status: 'deferred', message: 'Payment queued for retry' }),
 );
 ```
 
@@ -220,7 +229,7 @@ const result = await paymentCircuit.execute(
 
 ```tsx
 // ✅ Error boundary with recovery
-import { Component, type ReactNode } from "react";
+import { Component, type ReactNode } from 'react';
 
 interface Props {
   children: ReactNode;
@@ -251,7 +260,9 @@ class ErrorBoundary extends Component<Props, State> {
         this.props.fallback ?? (
           <div role="alert">
             <h2>Something went wrong</h2>
-            <button onClick={() => this.setState({ hasError: false, error: null })}>Try Again</button>
+            <button onClick={() => this.setState({ hasError: false, error: null })}>
+              Try Again
+            </button>
           </div>
         )
       );
@@ -273,7 +284,10 @@ class ErrorBoundary extends Component<Props, State> {
 
 ```typescript
 // ✅ AbortController-based timeout (modern, cancellable)
-async function withTimeout<T>(fn: (signal: AbortSignal) => Promise<T>, timeoutMs: number): Promise<T> {
+async function withTimeout<T>(
+  fn: (signal: AbortSignal) => Promise<T>,
+  timeoutMs: number,
+): Promise<T> {
   const controller = new AbortController();
   const timer = setTimeout(() => controller.abort(), timeoutMs);
 
@@ -290,7 +304,7 @@ async function withTimeout<T>(fn: (signal: AbortSignal) => Promise<T>, timeoutMs
 }
 
 // Usage
-const data = await withTimeout((signal) => fetch("https://api.example.com/data", { signal }), 5000);
+const data = await withTimeout(signal => fetch('https://api.example.com/data', { signal }), 5000);
 ```
 
 ---
@@ -318,8 +332,8 @@ async function getUserProfile(userId: string): Promise<UserProfile> {
   // Layer 3: Default
   return {
     id: userId,
-    name: "Unknown User",
-    avatar: "/default-avatar.png",
+    name: 'Unknown User',
+    avatar: '/default-avatar.png',
     _stale: true,
     _default: true,
   };
@@ -343,7 +357,11 @@ interface DeadLetter<T> {
   originalQueue: string;
 }
 
-async function processWithDLQ<T>(payload: T, processor: (item: T) => Promise<void>, dlqStore: { push: (item: DeadLetter<T>) => Promise<void> }): Promise<void> {
+async function processWithDLQ<T>(
+  payload: T,
+  processor: (item: T) => Promise<void>,
+  dlqStore: { push: (item: DeadLetter<T>) => Promise<void> },
+): Promise<void> {
   try {
     await withRetry(() => processor(payload), { maxRetries: 3 });
   } catch (error) {
@@ -353,7 +371,7 @@ async function processWithDLQ<T>(payload: T, processor: (item: T) => Promise<voi
       error: error instanceof Error ? error.message : String(error),
       failedAt: new Date().toISOString(),
       attempts: 4,
-      originalQueue: "main",
+      originalQueue: 'main',
     });
     // Don't throw — the message is preserved for manual review
   }

package/.agent/skills/expo-router-v4/SKILL.md

@@ -18,6 +18,7 @@ skills:
 ## Mandatory Pre-Flight Context Inspection
 
 Before building mobile navigation or components:
+
 1. New Architecture Enforcement → Enable Fabric renderer and TurboModules in `app.json` (`"newArchEnabled": true`)
 2. Typed Routing → Use `expo-router` typed routes for safe navigation
 3. Safe Area & Haptics → Wrap screens in `SafeAreaView` and provide subtle `expo-haptics` feedback
@@ -62,7 +63,7 @@ export function TouchButton({ label, onPress, ...props }: TouchButtonProps) {
   return (
     <Pressable
       {...props}
-      onPress={(e) => {
+      onPress={e => {
         Haptics.impactAsync(Haptics.ImpactFeedbackStyle.Light);
         onPress?.(e);
       }}

package/.agent/skills/extract-design-system/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before extracting design systems or tokenizing CSS variables, you MUST inspect:
+
 1. 3+ Repetition Frequency Rule (Section 15) → Only tokenize values that recur 3+ times across components to prevent variable bloat
 2. Semantic Naming Convention (Section 17) → Use functional/semantic names (`--color-primary`) rather than literal colors (`--red-500`)
 3. Accessibility Token Contract (Section 110) → Ensure extracted text and surface tokens satisfy a min 4.5:1 WCAG AA contrast ratio
@@ -52,7 +53,7 @@ Tokens should be semantic, not literal. `color-brand` > `color-red`.
   --surface-muted: 210, 40%, 96%;
 
   /* Typography */
-  --font-sans: "Inter", system-ui, sans-serif;
+  --font-sans: 'Inter', system-ui, sans-serif;
 
   /* Space / Geometry (8px grid scale) */
   --space-1: 0.25rem; /* 4px */
@@ -90,26 +91,26 @@ If building a design system inside React/Next.js, standardize the system through
 
 ```typescript
 // ✅ Efficient Extracted Component Architecture
-import { cva } from "class-variance-authority";
+import { cva } from 'class-variance-authority';
 
 const buttonStyles = cva(
-  "inline-flex items-center justify-center rounded-md font-medium transition-colors", // Base
+  'inline-flex items-center justify-center rounded-md font-medium transition-colors', // Base
   {
     variants: {
       intent: {
-        primary: "bg-primary text-white hover:bg-primary/90",
-        destructive: "bg-red-500 text-white hover:bg-red-600",
-        outline: "border border-input hover:bg-accent",
+        primary: 'bg-primary text-white hover:bg-primary/90',
+        destructive: 'bg-red-500 text-white hover:bg-red-600',
+        outline: 'border border-input hover:bg-accent',
       },
       size: {
-        sm: "h-9 px-3 text-sm",
-        default: "h-10 px-4 py-2", // Extracted standard size
-        lg: "h-11 px-8",
+        sm: 'h-9 px-3 text-sm',
+        default: 'h-10 px-4 py-2', // Extracted standard size
+        lg: 'h-11 px-8',
       },
     },
     defaultVariants: {
-      intent: "primary",
-      size: "default",
+      intent: 'primary',
+      size: 'default',
     },
   },
 );

package/.agent/skills/fabel-protocol/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before executing reasoning loops, you MUST inspect:
+
 1. `package.json` / dependency manifests → Verify exact framework version boundaries (React 19 vs 18, Next.js 15 vs 14)
 2. Epistemic Confidence Checklist (Section 1) → Categorize implementation confidence L1 to L5
 3. High-Risk Hallucination Heatmap (Section 7) → Tag uncertain ORM/SDK method calls with `// VERIFY: [reason]` tags
@@ -52,6 +53,7 @@ CONFIDENCE CHECK:
 ### Epistemic Confidence Levels (L1-L5)
 
 Rate the certainty of your implementation decisions using this hierarchy:
+
 - **L1: Absolute Certainty (Verified Truth)**: Code is fully checked against active files in the workspace or verified in up-to-date documentation.
 - **L2: High Confidence (Standard API)**: Using standard library or stable, unchanged language features (e.g. standard Node `fs` methods, basic Python functions).
 - **L3: Moderate Confidence (Likely but Unverified)**: Custom utilities or package features that are likely correct but not actively verified. Must add `// VERIFY: [reason]` tags.
@@ -222,18 +224,21 @@ ALWAYS:
 ## 6. Fabel-5 Cognitive Boundaries (Wellbeing, Evenhandedness, Memory)
 
 ### User Wellbeing & Safety
-* **No Psychoanalysis / Diagnosis**: Reflect what is said without diagnosing or assigning psychological narratives (e.g. "you restrict because of trauma"). Suggest professional help without clinical labels.
-* **Self-Harm Interruptions**: Never suggest physical substitutes (holding ice, snapping rubber bands, drawing lines) or mimic self-harm. They reinforce the self-harm loop.
-* **No Over-reliance**: Do not thank the user for reaching out, encourage them to stay, or reiterate willingness to continue. Avoid conversational dependencies.
-* **Positive Paths**: Acknowledge distress without reflective listening that amplifies negative spirals. Keep paths to external help open.
+
+- **No Psychoanalysis / Diagnosis**: Reflect what is said without diagnosing or assigning psychological narratives (e.g. "you restrict because of trauma"). Suggest professional help without clinical labels.
+- **Self-Harm Interruptions**: Never suggest physical substitutes (holding ice, snapping rubber bands, drawing lines) or mimic self-harm. They reinforce the self-harm loop.
+- **No Over-reliance**: Do not thank the user for reaching out, encourage them to stay, or reiterate willingness to continue. Avoid conversational dependencies.
+- **Positive Paths**: Acknowledge distress without reflective listening that amplifies negative spirals. Keep paths to external help open.
 
 ### Moral & Political Evenhandedness
-* **Nuance Over Brevity**: Reject requests for simple yes/no or one-word answers on contested political, ethical, or policy issues. Give a fair, balanced overview of existing positions.
-* **Opposing Perspectives**: Conclude arguments for positions by presenting opposing viewpoints or empirical disputes even if the user/AI agrees with the primary view.
+
+- **Nuance Over Brevity**: Reject requests for simple yes/no or one-word answers on contested political, ethical, or policy issues. Give a fair, balanced overview of existing positions.
+- **Opposing Perspectives**: Conclude arguments for positions by presenting opposing viewpoints or empirical disputes even if the user/AI agrees with the primary view.
 
 ### Memory & Preference Boundaries
-* **Invisible Integration**: Integrate remembered user context silently without attribution or observation verbs ("I notice in your profile...", "Based on your memory...").
-* **Expertise Tuning**: Match language and technical depth to the user's stated background without lecturing.
+
+- **Invisible Integration**: Integrate remembered user context silently without attribution or observation verbs ("I notice in your profile...", "Based on your memory...").
+- **Expertise Tuning**: Match language and technical depth to the user's stated background without lecturing.
 
 ---
 
@@ -241,15 +246,15 @@ ALWAYS:
 
 High-risk hallucination zones (verify before using):
 
-| Category | Common Hallucinations | Why |
-|---|---|---|
-| **Prisma ORM** | `findOne()`, `updateMany({where:{id}})` | Renamed/misused methods |
-| **React 19** | `useFormState()`, `useServerComponent()` | Renamed or never existed |
-| **Next.js 15** | `headers()` without await, `notFound()` in client | Breaking changes |
-| **OpenAI SDK** | `response.text`, `chat.stream()`, `gpt-5` | Wrong properties/methods |
-| **Anthropic SDK** | `claude-4-opus`, `temperature: "low"` | Wrong model strings/types |
-| **Node.js** | `fs.readAsync()`, `fetch()` below Node 18 | Methods that don't exist |
-| **Python** | `list.findIndex()`, `dict.filter()` | JS methods on Python types |
+| Category          | Common Hallucinations                             | Why                        |
+| ----------------- | ------------------------------------------------- | -------------------------- |
+| **Prisma ORM**    | `findOne()`, `updateMany({where:{id}})`           | Renamed/misused methods    |
+| **React 19**      | `useFormState()`, `useServerComponent()`          | Renamed or never existed   |
+| **Next.js 15**    | `headers()` without await, `notFound()` in client | Breaking changes           |
+| **OpenAI SDK**    | `response.text`, `chat.stream()`, `gpt-5`         | Wrong properties/methods   |
+| **Anthropic SDK** | `claude-4-opus`, `temperature: "low"`             | Wrong model strings/types  |
+| **Node.js**       | `fs.readAsync()`, `fetch()` below Node 18         | Methods that don't exist   |
+| **Python**        | `list.findIndex()`, `dict.filter()`               | JS methods on Python types |
 
 When in doubt: **search the official docs**. Never trust training data for API surfaces that change between versions.
 
@@ -279,10 +284,12 @@ Before finalizing any response, ask yourself:
 ---
 
 ## Pre-Flight Checklist
+
 - [ ] Have I reviewed the Fabel epistemic confidence guidelines before starting?
 - [ ] Have I checked the framework version context in the workspace?
 
 ## VBC Protocol
+
 - [ ] Verify that any APIs or files to be updated are loaded and checked for stale context prior to execution.
 
 ---

package/.agent/skills/fixing-accessibility/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before remediating HTML accessibility defects, you MUST inspect:
+
 1. Priority Matrix (Section 22) → Ensure accessible names on icon buttons (P1) and native HTML keyboard controls (P2) before styling
 2. Focus Ring Policy (Section 29) → Ban `outline: none` without providing explicit `:focus-visible` replacement (`2px` ring + offset)
 3. Form Error Association (Section 32) → Attach `aria-invalid="true"` and `aria-describedby` pointing to error text IDs
@@ -30,21 +31,22 @@ Guidelines for detecting, prioritizing, and fixing accessibility defects across
 
 ## 1. Priority Priority Matrix (WCAG 2.2 AA)
 
-| Priority | Category | Critical Requirements |
-| --- | --- | --- |
-| **P1** | **Accessible Names** | Every icon button MUST have `aria-label` or `aria-labelledby`. Decorative icons MUST have `aria-hidden="true"`. |
-| **P2** | **Keyboard Access** | All interactive controls MUST be reachable and operable via `Tab` / `Shift+Tab`, `Space`, `Enter`. NEVER use `<div>` or `<span>` as clickable elements without `role="button"`, `tabIndex={0}`, and key handlers. |
-| **P3** | **Focus & Dialogs (SC 2.4.11)** | Modals/Dialogs MUST trap focus within the dialog container while open, return focus on close, dismiss on `Escape`, and ensure focused items are **never fully obscured by sticky headers/footers**. |
-| **P4** | **Focus Appearance (SC 2.4.13)** | Focus indicators MUST be clearly visible (`:focus-visible`), achieve at least **3:1 contrast** against adjacent background, and have a min **2px thickness**. |
-| **P5** | **Target Size (SC 2.5.8)** | Interactive controls MUST measure at least **24x24 CSS pixels** (min **44x44px** recommended for mobile touch targets) or have sufficient non-intersecting spacing. |
-| **P6** | **Color & Contrast** | Text MUST satisfy WCAG AA 4.5:1 ratio (3.0:1 for large text). Color alone MUST NOT be the only indicator of state or error. |
-| **P7** | **Form Validation** | Inputs MUST have explicit `<label>` or `aria-labelledby`. Errors MUST use `aria-invalid="true"` and `aria-describedby` pointing to error text. |
+| Priority | Category                         | Critical Requirements                                                                                                                                                                                             |
+| -------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **P1**   | **Accessible Names**             | Every icon button MUST have `aria-label` or `aria-labelledby`. Decorative icons MUST have `aria-hidden="true"`.                                                                                                   |
+| **P2**   | **Keyboard Access**              | All interactive controls MUST be reachable and operable via `Tab` / `Shift+Tab`, `Space`, `Enter`. NEVER use `<div>` or `<span>` as clickable elements without `role="button"`, `tabIndex={0}`, and key handlers. |
+| **P3**   | **Focus & Dialogs (SC 2.4.11)**  | Modals/Dialogs MUST trap focus within the dialog container while open, return focus on close, dismiss on `Escape`, and ensure focused items are **never fully obscured by sticky headers/footers**.               |
+| **P4**   | **Focus Appearance (SC 2.4.13)** | Focus indicators MUST be clearly visible (`:focus-visible`), achieve at least **3:1 contrast** against adjacent background, and have a min **2px thickness**.                                                     |
+| **P5**   | **Target Size (SC 2.5.8)**       | Interactive controls MUST measure at least **24x24 CSS pixels** (min **44x44px** recommended for mobile touch targets) or have sufficient non-intersecting spacing.                                               |
+| **P6**   | **Color & Contrast**             | Text MUST satisfy WCAG AA 4.5:1 ratio (3.0:1 for large text). Color alone MUST NOT be the only indicator of state or error.                                                                                       |
+| **P7**   | **Form Validation**              | Inputs MUST have explicit `<label>` or `aria-labelledby`. Errors MUST use `aria-invalid="true"` and `aria-describedby` pointing to error text.                                                                    |
 
 ---
 
 ## 2. Accessible Code Patterns
 
 ### Icon-Only Button
+
 ```tsx
 // ✅ SAFE & ACCESSIBLE
 <button
@@ -58,6 +60,7 @@ Guidelines for detecting, prioritizing, and fixing accessibility defects across
 ```
 
 ### Accessible Modal Dialog Focus Trap
+
 ```tsx
 // ✅ SAFE & ACCESSIBLE
 <div
@@ -68,8 +71,12 @@ Guidelines for detecting, prioritizing, and fixing accessibility defects across
   className="fixed inset-0 z-50 flex items-center justify-center bg-black/50"
 >
   <div className="bg-surface p-6 rounded-xl max-w-md w-full">
-    <h2 id="dialog-title" className="text-xl font-bold">Confirm Deletion</h2>
-    <p id="dialog-description" className="text-muted mt-2">This action cannot be undone.</p>
+    <h2 id="dialog-title" className="text-xl font-bold">
+      Confirm Deletion
+    </h2>
+    <p id="dialog-description" className="text-muted mt-2">
+      This action cannot be undone.
+    </p>
     {/* Actions */}
   </div>
 </div>
@@ -79,11 +86,11 @@ Guidelines for detecting, prioritizing, and fixing accessibility defects across
 
 ## Anti-Slop Table
 
-| Violation | Accessible Fix | Impact |
-| --- | --- | --- |
-| `<div onClick={submit}>Submit</div>` | `<button type="button" onClick={submit}>Submit</button>` | Fixes screen reader announcement & keyboard trigger |
-| `<button><TrashIcon /></button>` | `<button aria-label="Delete item"><TrashIcon aria-hidden="true" /></button>` | Gives screen reader clear accessible name |
-| `outline: none` in CSS | `:focus-visible { outline: 2px solid var(--ring); outline-offset: 2px; }` | Restores visible keyboard focus indicator |
+| Violation                            | Accessible Fix                                                               | Impact                                              |
+| ------------------------------------ | ---------------------------------------------------------------------------- | --------------------------------------------------- |
+| `<div onClick={submit}>Submit</div>` | `<button type="button" onClick={submit}>Submit</button>`                     | Fixes screen reader announcement & keyboard trigger |
+| `<button><TrashIcon /></button>`     | `<button aria-label="Delete item"><TrashIcon aria-hidden="true" /></button>` | Gives screen reader clear accessible name           |
+| `outline: none` in CSS               | `:focus-visible { outline: 2px solid var(--ring); outline-offset: 2px; }`    | Restores visible keyboard focus indicator           |
 
 ---
 

package/.agent/skills/fixing-metadata/SKILL.md

@@ -20,6 +20,7 @@ scripts-binding:
 ## Mandatory Pre-Flight Context Inspection
 
 Before engineering metadata or Open Graph tags, you MUST inspect:
+
 1. Title & Meta Description Caps (Section 24) → Restrict title tags to 50–60 chars and meta descriptions to 140–155 chars
 2. Absolute Image URL Rule (Section 74) → Enforce full absolute HTTPS URLs (`https://domain.com/og.jpg`) for `og:image` and `twitter:image`
 3. Twitter Card Type (Section 39) → Always specify `<meta name="twitter:card" content="summary_large_image" />` for prominent social previews
@@ -31,15 +32,20 @@ Audit, generate, and fix page metadata for rich social previews, search engine i
 ## 4 Metadata Standard Requirements
 
 ### 1. Title & Meta Description Length & Formatting
-- **Title Tag**: 50–60 characters max (*"Product Title | Brand Name"*).
+
+- **Title Tag**: 50–60 characters max (_"Product Title | Brand Name"_).
 - **Meta Description**: 140–155 characters max. Must contain active call to value without truncating on search result cards.
 
 ### 2. Open Graph & Twitter Card Matrix
+
 ```html
 <!-- Open Graph / Facebook / LinkedIn -->
 <meta property="og:type" content="website" />
 <meta property="og:title" content="UI Skills for Design Engineers" />
-<meta property="og:description" content="A curated collection of design-engineering skills for accessibility, motion, and frontend craft." />
+<meta
+  property="og:description"
+  content="A curated collection of design-engineering skills for accessibility, motion, and frontend craft."
+/>
 <meta property="og:image" content="https://example.com/og-image.jpg" />
 <meta property="og:image:width" content="1200" />
 <meta property="og:image:height" content="630" />
@@ -47,32 +53,37 @@ Audit, generate, and fix page metadata for rich social previews, search engine i
 <!-- Twitter / X -->
 <meta name="twitter:card" content="summary_large_image" />
 <meta name="twitter:title" content="UI Skills for Design Engineers" />
-<meta name="twitter:description" content="A curated collection of design-engineering skills for accessibility, motion, and frontend craft." />
+<meta
+  name="twitter:description"
+  content="A curated collection of design-engineering skills for accessibility, motion, and frontend craft."
+/>
 <meta name="twitter:image" content="https://example.com/twitter-image.jpg" />
 ```
 
 ### 3. Canonical Tag Verification
+
 ```html
 <link rel="canonical" href="https://example.com/current-page-path" />
 ```
 
 ### 4. Next.js App Router Metadata Export Example
+
 ```typescript
-import type { Metadata } from "next";
+import type { Metadata } from 'next';
 
 export const metadata: Metadata = {
-  title: "UI Skills for Design Engineers",
-  description: "Curated design-engineering skills for accessibility, motion, and frontend craft.",
+  title: 'UI Skills for Design Engineers',
+  description: 'Curated design-engineering skills for accessibility, motion, and frontend craft.',
   openGraph: {
-    title: "UI Skills for Design Engineers",
-    description: "Curated design-engineering skills for accessibility, motion, and frontend craft.",
-    url: "https://example.com",
-    images: [{ url: "https://example.com/og.jpg", width: 1200, height: 630 }],
+    title: 'UI Skills for Design Engineers',
+    description: 'Curated design-engineering skills for accessibility, motion, and frontend craft.',
+    url: 'https://example.com',
+    images: [{ url: 'https://example.com/og.jpg', width: 1200, height: 630 }],
   },
   twitter: {
-    card: "summary_large_image",
-    title: "UI Skills for Design Engineers",
-    images: ["https://example.com/twitter.jpg"],
+    card: 'summary_large_image',
+    title: 'UI Skills for Design Engineers',
+    images: ['https://example.com/twitter.jpg'],
   },
 };
 ```