tribunal-kit 9.2.3 → 9.2.5

package/.agents/skills/behavioral-modes/SKILL.md

@@ -1,200 +1,200 @@
----
-name: behavioral-modes
-description: "Use when AI operational modes (brainstorm, implement, debug, review, teach, ship, orchestrate). Use to adapt behavior based on task type."
-version: 5.0.0
-last-updated: 2026-09-13
-skills:
-  - fabel-protocol
-  - agentic-patterns
-  - thinking-protocol
-tools: Read, Grep, Glob, Bash, Edit, Write
-scripts-binding:
-  - .agent/scripts/checklist.js
-  - .agent/scripts/verify_all.js
-  - .agent/scripts/lint_runner.js
----
-
-# Behavioral Modes
-
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
----
-
-## Overview
-
-Different work contexts require different operating behaviors. A debugging session requires patience and hypothesis testing. A code review requires skepticism. A teaching response requires no implementation at all.
-
-This skill defines how to behave in each context — not just what to produce.
-
----
-
-## Mode Definitions
-
-### DISCOVER Mode
-
-_When:_ Request is vague, requirements are unclear, multiple valid interpretations exist
-
-**Behavior:**
-
-- Ask the minimum questions needed to reduce ambiguity
-- Don't propose solutions until the problem is understood
-- Surface hidden assumptions explicitly
-- Validate understanding before proceeding
-
-**Output:** Questions, restated problem, confirmed scope — not code
-
----
-
-### PLAN Mode
-
-_When:_ Feature is complex enough to touch multiple files or systems
-
-**Behavior:**
-
-- Break work into ordered, dependency-aware tasks
-- Identify risks before implementation begins
-- Document assumptions that need validation
-- Write the plan — don't write the code yet
-
-**Output:** Structured task breakdown with dependencies and verification steps
-
----
-
-### BUILD Mode
-
-_When:_ Plan is approved, scope is clear, implementation begins
-
-**Behavior:**
-
-- One module at a time — not the entire system in one shot
-- Write `// VERIFY:` on anything uncertain about external APIs or methods
-- Run linting and type checks after each significant change
-- Stop if an assumption proves wrong — don't continue building on a broken foundation
-
-**Output:** Working code, one piece at a time
-
----
-
-### REVIEW Mode
-
-_When:_ Auditing existing code for hallucinations, bugs, or quality issues
-
-**Behavior:**
-
-- Read before commenting
-- Label each finding: CRITICAL / WARNING / SUGGESTION
-- Explain the impact — not just "this is wrong"
-- Propose the fix, not just the problem
-
-**Output:** Labeled findings with impact descriptions and concrete fixes
-
----
-
-### DEBUG Mode
-
-_When:_ Something is broken and the root cause is unknown
-
-**Behavior:**
-
-- Form a hypothesis before changing anything
-- Test one variable at a time
-- Document what was tried and what the outcome was
-- Root cause first — workaround only if root cause can't be addressed
-
-**Output:** Root cause statement, minimal fix, regression prevention note
-
----
-
-### TEACH Mode
-
-_When:_ User asks "how does X work" or "explain Y"
-
-**Behavior:**
-
-- Answer the question directly before elaborating
-- Use concrete examples, not abstract descriptions
-- No implementation unless explicitly requested
-- Check for follow-up understanding
-
-**Output:** Explanation, examples, no code unless asked
-
----
-
-### ORCHESTRATE Mode
-
-_When:_ Task spans multiple domains or requires multiple specialist perspectives
-
-**Behavior:**
-
-- Identify which domains are involved
-- Activate the appropriate specialists in sequence
-- Synthesize their outputs into a coherent result
-- Ensure consistency across domain boundaries (e.g., API contract matches frontend expectations)
-
-**Output:** Coordinated multi-domain response
-
----
-
-### SHIP Mode
-
-_When:_ Everything is ready, user confirms deployment
-
-**Behavior:**
-
-- Run the full verification suite before touching production
-- Follow the 5-phase deployment sequence
-- Verify each phase before proceeding to the next
-- Have a rollback plan confirmed before starting
-
-**Output:** Pre-flight checklist results, deployment execution, post-deploy verification
-
----
-
-## Mode Selection Rules
-
-| Signal in Request                      | Activate     |
-| -------------------------------------- | ------------ |
-| "how does", "explain", "what is"       | TEACH        |
-| "why is X broken", "error:", traceback | DEBUG        |
-| "review this", "audit", "check"        | REVIEW       |
-| "build", "create", "implement"         | PLAN → BUILD |
-| "I'm not sure what I need"             | DISCOVER     |
-| "deploy", "release", "publish"         | SHIP         |
-| Multiple domains in one request        | ORCHESTRATE  |
-
----
-
-## 🤖 Mode Leakage Mitigation (Anti-Hallucination)
-
-LLMs naturally want to "help" by writing code immediately. **Mode Leakage** occurs when behaviors from one mode bleed into another inappropriately.
-
-1. **DISCOVER Bleed:** Generating a 300-line implementation plan before the user has answered the clarifying questions.
-   - _❌ AI Trait:_ "Here are my questions. Also, here is how we will build it..."
-   - _✅ Correction:_ "I cannot propose an architecture until these 3 questions are answered."
-2. **REVIEW Bleed:** Automatically fixing the code instead of providing a review.
-   - _❌ AI Trait:_ "I reviewed your code. Here is the completely rewritten file."
-   - _✅ Correction:_ State the findings. Let the user ask for the fix.
-3. **DEBUG Bleed:** Guessing a fix without proving the root cause.
-   - _❌ AI Trait:_ "It looks like a configuration error. Try adding this line."
-   - _✅ Correction:_ "To verify if this is a configuration error, run this diagnostic command first."
-
----
-
-## Output Format
-
-When this skill produces a recommendation or design decision, structure your output as:
-
-```
-━━━ Behavioral Modes Recommendation ━━━━━━━━━━━━━━━━
-Decision:    [what was chosen / proposed]
-Rationale:   [why — one concise line]
-Trade-offs:  [what is consciously accepted]
-Next action: [concrete next step for the user]
-─────────────────────────────────────────────────
-Pre-Flight:  ✅ All checks passed
-             or ❌ [blocking item that must be resolved first]
-```
+---
+name: behavioral-modes
+description: "Use when AI operational modes (brainstorm, implement, debug, review, teach, ship, orchestrate). Use to adapt behavior based on task type."
+version: 5.0.0
+last-updated: 2026-09-13
+skills:
+  - fabel-protocol
+  - agentic-patterns
+  - thinking-protocol
+tools: Read, Grep, Glob, Bash, Edit, Write
+scripts-binding:
+  - .agent/scripts/checklist.js
+  - .agent/scripts/verify_all.js
+  - .agent/scripts/lint_runner.js
+---
+
+# Behavioral Modes
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
+
+---
+
+## Overview
+
+Different work contexts require different operating behaviors. A debugging session requires patience and hypothesis testing. A code review requires skepticism. A teaching response requires no implementation at all.
+
+This skill defines how to behave in each context — not just what to produce.
+
+---
+
+## Mode Definitions
+
+### DISCOVER Mode
+
+_When:_ Request is vague, requirements are unclear, multiple valid interpretations exist
+
+**Behavior:**
+
+- Ask the minimum questions needed to reduce ambiguity
+- Don't propose solutions until the problem is understood
+- Surface hidden assumptions explicitly
+- Validate understanding before proceeding
+
+**Output:** Questions, restated problem, confirmed scope — not code
+
+---
+
+### PLAN Mode
+
+_When:_ Feature is complex enough to touch multiple files or systems
+
+**Behavior:**
+
+- Break work into ordered, dependency-aware tasks
+- Identify risks before implementation begins
+- Document assumptions that need validation
+- Write the plan — don't write the code yet
+
+**Output:** Structured task breakdown with dependencies and verification steps
+
+---
+
+### BUILD Mode
+
+_When:_ Plan is approved, scope is clear, implementation begins
+
+**Behavior:**
+
+- One module at a time — not the entire system in one shot
+- Write `// VERIFY:` on anything uncertain about external APIs or methods
+- Run linting and type checks after each significant change
+- Stop if an assumption proves wrong — don't continue building on a broken foundation
+
+**Output:** Working code, one piece at a time
+
+---
+
+### REVIEW Mode
+
+_When:_ Auditing existing code for hallucinations, bugs, or quality issues
+
+**Behavior:**
+
+- Read before commenting
+- Label each finding: CRITICAL / WARNING / SUGGESTION
+- Explain the impact — not just "this is wrong"
+- Propose the fix, not just the problem
+
+**Output:** Labeled findings with impact descriptions and concrete fixes
+
+---
+
+### DEBUG Mode
+
+_When:_ Something is broken and the root cause is unknown
+
+**Behavior:**
+
+- Form a hypothesis before changing anything
+- Test one variable at a time
+- Document what was tried and what the outcome was
+- Root cause first — workaround only if root cause can't be addressed
+
+**Output:** Root cause statement, minimal fix, regression prevention note
+
+---
+
+### TEACH Mode
+
+_When:_ User asks "how does X work" or "explain Y"
+
+**Behavior:**
+
+- Answer the question directly before elaborating
+- Use concrete examples, not abstract descriptions
+- No implementation unless explicitly requested
+- Check for follow-up understanding
+
+**Output:** Explanation, examples, no code unless asked
+
+---
+
+### ORCHESTRATE Mode
+
+_When:_ Task spans multiple domains or requires multiple specialist perspectives
+
+**Behavior:**
+
+- Identify which domains are involved
+- Activate the appropriate specialists in sequence
+- Synthesize their outputs into a coherent result
+- Ensure consistency across domain boundaries (e.g., API contract matches frontend expectations)
+
+**Output:** Coordinated multi-domain response
+
+---
+
+### SHIP Mode
+
+_When:_ Everything is ready, user confirms deployment
+
+**Behavior:**
+
+- Run the full verification suite before touching production
+- Follow the 5-phase deployment sequence
+- Verify each phase before proceeding to the next
+- Have a rollback plan confirmed before starting
+
+**Output:** Pre-flight checklist results, deployment execution, post-deploy verification
+
+---
+
+## Mode Selection Rules
+
+| Signal in Request                      | Activate     |
+| -------------------------------------- | ------------ |
+| "how does", "explain", "what is"       | TEACH        |
+| "why is X broken", "error:", traceback | DEBUG        |
+| "review this", "audit", "check"        | REVIEW       |
+| "build", "create", "implement"         | PLAN → BUILD |
+| "I'm not sure what I need"             | DISCOVER     |
+| "deploy", "release", "publish"         | SHIP         |
+| Multiple domains in one request        | ORCHESTRATE  |
+
+---
+
+## 🤖 Mode Leakage Mitigation (Anti-Hallucination)
+
+LLMs naturally want to "help" by writing code immediately. **Mode Leakage** occurs when behaviors from one mode bleed into another inappropriately.
+
+1. **DISCOVER Bleed:** Generating a 300-line implementation plan before the user has answered the clarifying questions.
+   - _❌ AI Trait:_ "Here are my questions. Also, here is how we will build it..."
+   - _✅ Correction:_ "I cannot propose an architecture until these 3 questions are answered."
+2. **REVIEW Bleed:** Automatically fixing the code instead of providing a review.
+   - _❌ AI Trait:_ "I reviewed your code. Here is the completely rewritten file."
+   - _✅ Correction:_ State the findings. Let the user ask for the fix.
+3. **DEBUG Bleed:** Guessing a fix without proving the root cause.
+   - _❌ AI Trait:_ "It looks like a configuration error. Try adding this line."
+   - _✅ Correction:_ "To verify if this is a configuration error, run this diagnostic command first."
+
+---
+
+## Output Format
+
+When this skill produces a recommendation or design decision, structure your output as:
+
+```
+━━━ Behavioral Modes Recommendation ━━━━━━━━━━━━━━━━
+Decision:    [what was chosen / proposed]
+Rationale:   [why — one concise line]
+Trade-offs:  [what is consciously accepted]
+Next action: [concrete next step for the user]
+─────────────────────────────────────────────────
+Pre-Flight:  ✅ All checks passed
+             or ❌ [blocking item that must be resolved first]
+```

package/.agents/skills/better-colors/SKILL.md

@@ -1,116 +1,116 @@
----
-name: better-colors
-description: "Use when OKLCH color space for web projects. Convert hex/rgb/hsl to oklch, generate palettes, check contrast, handle gamut boundaries, and theme with Tailwind v4. Triggers on oklch, color conversion, palette generation, contrast ratio, gamut, display p3, design tokens, hue drift, chroma, dark mode colors."
-version: 5.0.0
-last-updated: 2026-09-13
-skills:
-  - better-ui
-  - baseline-ui
-  - colorize
-tools: Read, Grep, Glob, Bash, Edit, Write
-scripts-binding:
-  - .agent/scripts/lint_runner.js
-  - .agent/scripts/verify_all.js
----
-
-# Better Colors — OKLCH & Modern Web Color Systems
-
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
----
-
-## 1. Why OKLCH Over HSL / RGB
-
-- **Perceptual Uniformity**: In HSL, yellow (`hsl(60, 100%, 50%)`) is far brighter than blue (`hsl(240, 100%, 50%)`) at the exact same lightness value. OKLCH fixes this: lightness (`L`) corresponds directly to human eye perception.
-- **Predictable Palette Steps**: Changing lightness in OKLCH scales brightness smoothly without hue drift (e.g. blue turning purple when lightened in HSL).
-- **Wide Gamut Access**: Access Display P3 wide-gamut colors (`oklch(L C H)`), producing significantly richer, punchier vibrant tones on modern displays.
-
----
-
-## 2. OKLCH Syntax & Variables
-
-$$\text{Format: } \text{oklch}(L \quad C \quad H [\quad / \quad A])$$
-
-- `L` (Lightness): `0%` (black) to `100%` (white) or `0` to `1`.
-- `C` (Chroma): `0` (gray) to `0.37+` (vibrant peak). Typical UI chroma range: `0.02` to `0.22`.
-- `H` (Hue): `0` to `360` degrees.
-  - `0` / `360`: Red / Magenta
-  - `90`: Yellow / Gold
-  - `140`: Green / Emerald
-  - `250`: Blue / Indigo
-  - `300`: Purple / Violet
-
-### CSS Custom Properties & Relative Color Syntax
-
-```css
-:root {
-  /* Brand Primary: Vibrant Indigo */
-  --color-primary: oklch(0.55 0.22 260);
-  /* Modern CSS Relative Color Syntax (Modifying Lightness/Chroma dynamically) */
-  --color-primary-hover: oklch(from var(--color-primary) calc(l - 0.08) c h);
-  --color-primary-active: oklch(from var(--color-primary) calc(l - 0.14) c h);
-  --color-primary-subtle: oklch(from var(--color-primary) 0.95 0.04 h);
-
-  /* Neutrals: Subtly Tinted (Chroma ~ 0.015) */
-  --bg-surface: oklch(0.99 0.005 260);
-  --bg-surface-raised: oklch(0.96 0.01 260);
-  --text-main: oklch(0.2 0.02 260);
-  --text-muted: oklch(0.45 0.02 260);
-  --border-subtle: oklch(0.88 0.015 260);
-}
-
-/* Native CSS light-dark() declaration mode */
-:root {
-  color-scheme: light dark;
-  --surface-adaptive: light-dark(oklch(0.99 0.005 260), oklch(0.14 0.015 260));
-  --text-adaptive: light-dark(oklch(0.2 0.02 260), oklch(0.96 0.01 260));
-}
-
-@media (prefers-color-scheme: dark) {
-  :root {
-    --bg-surface: oklch(0.14 0.015 260);
-    --bg-surface-raised: oklch(0.19 0.02 260);
-    --text-main: oklch(0.96 0.01 260);
-    --text-muted: oklch(0.68 0.02 260);
-    --border-subtle: oklch(0.26 0.02 260);
-  }
-}
-```
-
----
-
-## 3. WCAG 2.2 AA Contrast Standards
-
-Always verify contrast using WCAG AA minimum thresholds:
-
-- **Normal Text (< 18pt / < 24px)**: Minimum **4.5:1** contrast ratio.
-- **Large Text (≥ 18pt / ≥ 24px bold)**: Minimum **3.0:1** contrast ratio.
-- **UI Components & Icons**: Minimum **3.0:1** contrast ratio against adjacent surface.
-
-### Rule of Thumb in OKLCH:
-
-To achieve 4.5:1 text contrast against a surface:
-
-- Against Light Surface (`L ≈ 98%`): Text lightness `L` MUST be **`≤ 45%`**.
-- Against Dark Surface (`L ≈ 14%`): Text lightness `L` MUST be **`≥ 70%`**.
-
----
-
-## 4. Dark Mode & Gamut Boundaries
-
-- **Avoid Raw Black (`#000`)**: Use deep OKLCH neutrals (`oklch(0.14 0.015 250)`). Pure black destroys depth perception and makes borders look harsh.
-- **Desaturate Accent Colors in Dark Mode**: High chroma values (`C > 0.20`) cause visual fatigue and vibration on dark backgrounds. Lower chroma by ~20-30% (`C ≈ 0.14-0.16`).
-
----
-
-## Anti-Slop Table
-
-| Anti-Pattern                      | OKLCH Solution                                         | Rationale                                         |
-| --------------------------------- | ------------------------------------------------------ | ------------------------------------------------- |
-| Single gray for all backgrounds   | Neutral tinted with brand hue (`C: 0.01-0.02`)         | Creates cohesive, harmonious UI surfaces          |
-| Over-saturated dark mode accents  | Scale chroma down (`C: 0.22` → `C: 0.15`) in dark mode | Eliminates glowing text vibration & visual strain |
-| Harsh pure black borders (`#000`) | Alpha-tinted borders (`rgba(255,255,255,0.08)`)        | Smooths elevation layers                          |
+---
+name: better-colors
+description: "Use when OKLCH color space for web projects. Convert hex/rgb/hsl to oklch, generate palettes, check contrast, handle gamut boundaries, and theme with Tailwind v4. Triggers on oklch, color conversion, palette generation, contrast ratio, gamut, display p3, design tokens, hue drift, chroma, dark mode colors."
+version: 5.0.0
+last-updated: 2026-09-13
+skills:
+  - better-ui
+  - baseline-ui
+  - colorize
+tools: Read, Grep, Glob, Bash, Edit, Write
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/verify_all.js
+---
+
+# Better Colors — OKLCH & Modern Web Color Systems
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
+
+---
+
+## 1. Why OKLCH Over HSL / RGB
+
+- **Perceptual Uniformity**: In HSL, yellow (`hsl(60, 100%, 50%)`) is far brighter than blue (`hsl(240, 100%, 50%)`) at the exact same lightness value. OKLCH fixes this: lightness (`L`) corresponds directly to human eye perception.
+- **Predictable Palette Steps**: Changing lightness in OKLCH scales brightness smoothly without hue drift (e.g. blue turning purple when lightened in HSL).
+- **Wide Gamut Access**: Access Display P3 wide-gamut colors (`oklch(L C H)`), producing significantly richer, punchier vibrant tones on modern displays.
+
+---
+
+## 2. OKLCH Syntax & Variables
+
+$$\text{Format: } \text{oklch}(L \quad C \quad H [\quad / \quad A])$$
+
+- `L` (Lightness): `0%` (black) to `100%` (white) or `0` to `1`.
+- `C` (Chroma): `0` (gray) to `0.37+` (vibrant peak). Typical UI chroma range: `0.02` to `0.22`.
+- `H` (Hue): `0` to `360` degrees.
+  - `0` / `360`: Red / Magenta
+  - `90`: Yellow / Gold
+  - `140`: Green / Emerald
+  - `250`: Blue / Indigo
+  - `300`: Purple / Violet
+
+### CSS Custom Properties & Relative Color Syntax
+
+```css
+:root {
+  /* Brand Primary: Vibrant Indigo */
+  --color-primary: oklch(0.55 0.22 260);
+  /* Modern CSS Relative Color Syntax (Modifying Lightness/Chroma dynamically) */
+  --color-primary-hover: oklch(from var(--color-primary) calc(l - 0.08) c h);
+  --color-primary-active: oklch(from var(--color-primary) calc(l - 0.14) c h);
+  --color-primary-subtle: oklch(from var(--color-primary) 0.95 0.04 h);
+
+  /* Neutrals: Subtly Tinted (Chroma ~ 0.015) */
+  --bg-surface: oklch(0.99 0.005 260);
+  --bg-surface-raised: oklch(0.96 0.01 260);
+  --text-main: oklch(0.2 0.02 260);
+  --text-muted: oklch(0.45 0.02 260);
+  --border-subtle: oklch(0.88 0.015 260);
+}
+
+/* Native CSS light-dark() declaration mode */
+:root {
+  color-scheme: light dark;
+  --surface-adaptive: light-dark(oklch(0.99 0.005 260), oklch(0.14 0.015 260));
+  --text-adaptive: light-dark(oklch(0.2 0.02 260), oklch(0.96 0.01 260));
+}
+
+@media (prefers-color-scheme: dark) {
+  :root {
+    --bg-surface: oklch(0.14 0.015 260);
+    --bg-surface-raised: oklch(0.19 0.02 260);
+    --text-main: oklch(0.96 0.01 260);
+    --text-muted: oklch(0.68 0.02 260);
+    --border-subtle: oklch(0.26 0.02 260);
+  }
+}
+```
+
+---
+
+## 3. WCAG 2.2 AA Contrast Standards
+
+Always verify contrast using WCAG AA minimum thresholds:
+
+- **Normal Text (< 18pt / < 24px)**: Minimum **4.5:1** contrast ratio.
+- **Large Text (≥ 18pt / ≥ 24px bold)**: Minimum **3.0:1** contrast ratio.
+- **UI Components & Icons**: Minimum **3.0:1** contrast ratio against adjacent surface.
+
+### Rule of Thumb in OKLCH:
+
+To achieve 4.5:1 text contrast against a surface:
+
+- Against Light Surface (`L ≈ 98%`): Text lightness `L` MUST be **`≤ 45%`**.
+- Against Dark Surface (`L ≈ 14%`): Text lightness `L` MUST be **`≥ 70%`**.
+
+---
+
+## 4. Dark Mode & Gamut Boundaries
+
+- **Avoid Raw Black (`#000`)**: Use deep OKLCH neutrals (`oklch(0.14 0.015 250)`). Pure black destroys depth perception and makes borders look harsh.
+- **Desaturate Accent Colors in Dark Mode**: High chroma values (`C > 0.20`) cause visual fatigue and vibration on dark backgrounds. Lower chroma by ~20-30% (`C ≈ 0.14-0.16`).
+
+---
+
+## Anti-Slop Table
+
+| Anti-Pattern                      | OKLCH Solution                                         | Rationale                                         |
+| --------------------------------- | ------------------------------------------------------ | ------------------------------------------------- |
+| Single gray for all backgrounds   | Neutral tinted with brand hue (`C: 0.01-0.02`)         | Creates cohesive, harmonious UI surfaces          |
+| Over-saturated dark mode accents  | Scale chroma down (`C: 0.22` → `C: 0.15`) in dark mode | Eliminates glowing text vibration & visual strain |
+| Harsh pure black borders (`#000`) | Alpha-tinted borders (`rgba(255,255,255,0.08)`)        | Smooths elevation layers                          |