tribunal-kit 9.0.2 → 9.2.3

package/.agents/skills/swiss-design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: swiss-design
-description: Use when International Typographic Style (Swiss Design) principles for web interfaces. Strict grid discipline, asymmetric layouts, bold typographic contrast, flush-left un-justified text, and mathematical negative space.
+description: "Use when International Typographic Style (Swiss Design) principles for web interfaces. Strict grid discipline, asymmetric layouts, bold typographic contrast, flush-left un-justified text, and mathematical negative space."
 version: 5.0.0
 last-updated: 2026-09-13
 skills:
@@ -15,42 +15,12 @@ scripts-binding:
 
 # Swiss Design — International Typographic Style for Web
 
-## Mandatory Pre-Flight Context Inspection
-
-Before generating, refactoring, or reviewing code in the `swiss-design` domain, inspect these 5 critical parameters:
-
-1. **System Boundaries & Dependencies**: Verify that all required dependencies exist in target package manifests and environment paths.
-2. **Runtime Context & Platform Invariants**: Confirm target platform constraints (Node.js, Browser, Mobile OS, Edge runtime) before applying APIs.
-3. **Execution Guardrails**: Identify potential side-effects, state mutations, and unhandled asynchronous exceptions.
-4. **Validation & Type Contracts**: Validate input data schemas and strict type constraints across all module interfaces.
-5. **Observability & Proof of Execution**: Ensure execution produces tangible verification signals (terminal output, tests, metrics).
-
-## Activation Boundaries
-
-- **Activate when:** Use when International Typographic Style (Swiss Design) principles for web interfaces. Strict grid discipline, asymmetric layouts, bold typographic contrast, flush-left un-justified text, and mathematical negative space.
-- **DO NOT activate when:** The task falls outside the `swiss-design` domain or is managed by a different dedicated specialist.
-
-## 🔁 Multi-Pass Execution Protocol
-
-Execute all non-trivial tasks through this 7-pass cognitive loop:
-
-| Pass | Phase | Core Action |
-|:---|:---|:---|
-| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. |
-| **Pass 2** | **Plan** | Decompose the task into smallest logical steps; map dependencies and required tool calls. |
-| **Pass 3** | **Execute** | Implement the solution with production-grade craft, zero placeholders, and strict typing. |
-| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. |
-| **Pass 5** | **Attack** | Perform an adversarial review searching for edge-case failures, race conditions, and traps. |
-| **Pass 6** | **Improve** | Eliminate discovered friction, optimize performance, and harden error boundaries. |
-| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. |
-
 ---
 
 ## 🛠️ Technical Architecture & Reference Recipes
 
 ---
 
-
 ---
 
 ## 4 Swiss Design Pillars
@@ -72,48 +42,3 @@ Execute all non-trivial tasks through this 7-pass cognitive loop:
 ### 4. Mathematical Numbering & Labels
 
 - Use small uppercase metadata badges (`SECTION 01 // OVERVIEW`) with tracking (`letter-spacing: 0.08em`) and monospace or tabular numbers (`font-variant-numeric: tabular-nums`).
-
----
-
-## 🚨 Edge-Case & Failure Mode Matrix
-
-| Scenario | Risk | Mitigation Strategy |
-|:---|:---|:---|
-| **Empty or Null Inputs** | Unhandled exception or unexpected rendering collapse | Enforce fallback guards, optional chaining, and explicit empty state handlers |
-| **Network Timeout / Latency** | Hanging operations or duplicate side-effects | Implement bounded abort controllers, exponential backoff, and idempotency keys |
-| **Concurrency / Race Conditions** | Stale state overwrite or inconsistent data mutations | Use atomic transactions, mutex locking, or cancel-on-resubmit controls |
-| **Invalid Schema / Malformed Payload** | Downstream runtime errors or security injection | Validate boundary payloads with Zod/Pydantic schemas prior to execution |
-| **Resource / Memory Saturation** | OOM errors, frame drops, or memory leaks | Clean up listeners, cancel active timers, and enforce pagination/virtualization |
-
----
-
-## 🤖 LLM-Specific Traps Table
-
-| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
-|:---|:---|:---|
-| **Uncontrolled Re-render Loop** | Mutating state inside render bodies or omitting hook dependencies | Wrap effects with explicit deps and isolate reactive derivations in useMemo |
-| **Accessibility Neglect** | Interactive <div> without role="button", tabIndex, or onKeyDown | Use semantic <button> or provide ARIA role, keyboard handlers, and focus ring |
-| **Layout Shift Flash** | Images/dynamic content without aspect-ratio or explicit dimensions | Enforce aspect-ratio or skeleton placeholders to guarantee zero CLS |
-
----
-
-## 🏛️ Tribunal Verification & Guardrails
-
-**Active Reviewers:** `frontend-reviewer` · `type-safety` · `ui-ux-auditor` · `complexity-reviewer`
-**Slash Command:** `/review` or `/tribunal-full`
-
-### ✅ Pre-Flight Self-Audit Checklist
-
-```
-✅ Are all component props strictly typed with zero implicit "any"?
-✅ Are responsive breakpoints, fluid typography, and optical balance verified?
-✅ Is accessibility (ARIA labels, keyboard focus, contrast) validated?
-✅ Are re-renders minimized and state lifecycles cleanly separated?
-✅ Did I verify all imported UI components and icon sets actually exist?
-```
-
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
-- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing test suites, compiler success, or equivalent operational proof) that your output works as intended.

package/.agents/skills/system-design-pro/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: system-design-pro
-description: Use when Industry-level system design mastery for interviews and production. The 6-step design framework, scale estimation (DAU→QPS→storage→bandwidth), core building blocks (load balancers L4/L7, CDN, caches, queues), database selection matrix, CAP Theorem applied, and reference designs for URL shortener, rate limiter, Twitter feed, distributed cache, and notification system. Use when designing systems for scale, conducting architecture reviews, or preparing system design discussions.
+description: "Use when Industry-level system design mastery for interviews and production. The 6-step design framework, scale estimation (DAU→QPS→storage→bandwidth), core building blocks (load balancers L4/L7, CDN, caches, queues), database selection matrix, CAP Theorem applied, and reference designs for URL shortener, rate limiter, Twitter feed, distributed cache, and notification system. Use when designing systems for scale, conducting architecture reviews, or preparing system design discussions."
 version: 5.0.0
 last-updated: 2026-09-13
 skills:
@@ -15,42 +15,12 @@ scripts-binding:
 
 # System Design Pro — Industry-Level Mastery
 
-## Mandatory Pre-Flight Context Inspection
-
-Before generating, refactoring, or reviewing code in the `system-design-pro` domain, inspect these 5 critical parameters:
-
-1. **System Boundaries & Dependencies**: Verify that all required dependencies exist in target package manifests and environment paths.
-2. **Runtime Context & Platform Invariants**: Confirm target platform constraints (Node.js, Browser, Mobile OS, Edge runtime) before applying APIs.
-3. **Execution Guardrails**: Identify potential side-effects, state mutations, and unhandled asynchronous exceptions.
-4. **Validation & Type Contracts**: Validate input data schemas and strict type constraints across all module interfaces.
-5. **Observability & Proof of Execution**: Ensure execution produces tangible verification signals (terminal output, tests, metrics).
-
-## Activation Boundaries
-
-- **Activate when:** Use when Industry-level system design mastery for interviews and production. The 6-step design framework, scale estimation (DAU→QPS→storage→bandwidth), core building blocks (load balancers L4/L7, CDN, caches, queues), database selection matrix, CAP Theorem applied, and reference designs for URL shortener, rate limiter, Twitter feed, distributed cache, and notification system. Use when designing systems for scale, conducting architecture reviews, or preparing system design discussions.
-- **DO NOT activate when:** The task falls outside the `system-design-pro` domain or is managed by a different dedicated specialist.
-
-## 🔁 Multi-Pass Execution Protocol
-
-Execute all non-trivial tasks through this 7-pass cognitive loop:
-
-| Pass | Phase | Core Action |
-|:---|:---|:---|
-| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. |
-| **Pass 2** | **Plan** | Decompose the task into smallest logical steps; map dependencies and required tool calls. |
-| **Pass 3** | **Execute** | Implement the solution with production-grade craft, zero placeholders, and strict typing. |
-| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. |
-| **Pass 5** | **Attack** | Perform an adversarial review searching for edge-case failures, race conditions, and traps. |
-| **Pass 6** | **Improve** | Eliminate discovered friction, optimize performance, and harden error boundaries. |
-| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. |
-
 ---
 
 ## 🛠️ Technical Architecture & Reference Recipes
 
 ---
 
-
 ## Hallucination Traps (Read First)
 
 - ❌ "Just use microservices" for <10K RPM → ✅ Microservices add operational complexity that kills small teams. Start monolith.
@@ -346,48 +316,3 @@ Failure handling:
   - Exponential backoff: 1s → 10s → 100s → dead letter
   - Alert on dead letter queue depth > threshold
 ```
-
----
-
-## 🚨 Edge-Case & Failure Mode Matrix
-
-| Scenario | Risk | Mitigation Strategy |
-|:---|:---|:---|
-| **Empty or Null Inputs** | Unhandled exception or unexpected rendering collapse | Enforce fallback guards, optional chaining, and explicit empty state handlers |
-| **Network Timeout / Latency** | Hanging operations or duplicate side-effects | Implement bounded abort controllers, exponential backoff, and idempotency keys |
-| **Concurrency / Race Conditions** | Stale state overwrite or inconsistent data mutations | Use atomic transactions, mutex locking, or cancel-on-resubmit controls |
-| **Invalid Schema / Malformed Payload** | Downstream runtime errors or security injection | Validate boundary payloads with Zod/Pydantic schemas prior to execution |
-| **Resource / Memory Saturation** | OOM errors, frame drops, or memory leaks | Clean up listeners, cancel active timers, and enforce pagination/virtualization |
-
----
-
-## 🤖 LLM-Specific Traps Table
-
-| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
-|:---|:---|:---|
-| **Hallucinated Tool Capabilities** | Assuming an external library or CLI command exists without verification | Run a verification check or verify package.json before referencing tools |
-| **Premature Completion Claim** | Declaring a task finished because code was generated without verification | Execute tests, linters, or terminal commands to provide concrete proof |
-| **Context Bloat Dumping** | Pasting entire multi-thousand-line files into prompt context | Extract targeted excerpts, symbols, and signatures to preserve tokens |
-
----
-
-## 🏛️ Tribunal Verification & Guardrails
-
-**Active Reviewers:** `orchestrator` · `agent-organizer` · `logic-reviewer`
-**Slash Command:** `/review` or `/tribunal-full`
-
-### ✅ Pre-Flight Self-Audit Checklist
-
-```
-✅ Did I deconstruct the root objective before proposing architecture?
-✅ Did I identify dependencies, bottlenecks, and parallelizable sub-tasks?
-✅ Did I avoid over-engineering and select the simplest effective pattern?
-✅ Did I verify assumptions with concrete file reads instead of speculation?
-✅ Did I establish measurable verification criteria before completion?
-```
-
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
-- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing test suites, compiler success, or equivalent operational proof) that your output works as intended.

package/.agents/skills/systematic-debugging/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: systematic-debugging
-description: Use when Systematic debugging framework. Root-cause isolation, 4-phase methodology, hypothesis testing, log tracing, avoiding shotgun-surgery, memory allocation analysis, and empirical evidence gathering. Use when debugging complex, highly-coupled, or elusive bugs across mixed execution environments.
+description: "Use when Systematic debugging framework. Root-cause isolation, 4-phase methodology, hypothesis testing, log tracing, avoiding shotgun-surgery, memory allocation analysis, and empirical evidence gathering. Use when debugging complex, highly-coupled, or elusive bugs across mixed execution environments."
 version: 5.0.0
 last-updated: 2026-09-13
 skills:
@@ -16,42 +16,12 @@ scripts-binding:
 
 # Systematic Debugging — Root Cause Mastery
 
-## Mandatory Pre-Flight Context Inspection
-
-Before generating, refactoring, or reviewing code in the `systematic-debugging` domain, inspect these 5 critical parameters:
-
-1. **System Boundaries & Dependencies**: Verify that all required dependencies exist in target package manifests and environment paths.
-2. **Runtime Context & Platform Invariants**: Confirm target platform constraints (Node.js, Browser, Mobile OS, Edge runtime) before applying APIs.
-3. **Execution Guardrails**: Identify potential side-effects, state mutations, and unhandled asynchronous exceptions.
-4. **Validation & Type Contracts**: Validate input data schemas and strict type constraints across all module interfaces.
-5. **Observability & Proof of Execution**: Ensure execution produces tangible verification signals (terminal output, tests, metrics).
-
-## Activation Boundaries
-
-- **Activate when:** Use when Systematic debugging framework. Root-cause isolation, 4-phase methodology, hypothesis testing, log tracing, avoiding shotgun-surgery, memory allocation analysis, and empirical evidence gathering. Use when debugging complex, highly-coupled, or elusive bugs across mixed execution environments.
-- **DO NOT activate when:** The task falls outside the `systematic-debugging` domain or is managed by a different dedicated specialist.
-
-## 🔁 Multi-Pass Execution Protocol
-
-Execute all non-trivial tasks through this 7-pass cognitive loop:
-
-| Pass | Phase | Core Action |
-|:---|:---|:---|
-| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. |
-| **Pass 2** | **Plan** | Decompose the task into smallest logical steps; map dependencies and required tool calls. |
-| **Pass 3** | **Execute** | Implement the solution with production-grade craft, zero placeholders, and strict typing. |
-| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. |
-| **Pass 5** | **Attack** | Perform an adversarial review searching for edge-case failures, race conditions, and traps. |
-| **Pass 6** | **Improve** | Eliminate discovered friction, optimize performance, and harden error boundaries. |
-| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. |
-
 ---
 
 ## 🛠️ Technical Architecture & Reference Recipes
 
 ---
 
-
 ## Hallucination Traps (Read First)
 
 - ❌ Changing multiple things at once to fix a bug -> ✅ Change ONE variable at a time; multiple changes make it impossible to identify the fix
@@ -97,6 +67,7 @@ Never jump straight into modifying code when a bug is reported.
 ## 2. Specialized Diagnostic Techniques
 
 When debugging intricate or elusive bugs, reference these specialized technique guides:
+
 - **Root Cause Tracing (`./root-cause-tracing.md`):** Trace backwards up the call stack to identify where invalid data originated, rather than fixing where the error appears.
 - **Condition-Based Waiting (`./condition-based-waiting.md`):** Eliminate flaky tests and timing bugs by waiting for specific deterministic state conditions instead of arbitrary `setTimeout` or `sleep` calls.
 - **Defense in Depth (`./defense-in-depth.md`):** Add validation and runtime assertions at multiple component boundaries.
@@ -151,48 +122,3 @@ Do not skim. Stack traces tell the exact sequence of destruction.
 1. **Top line:** The final fatal blow (e.g., `TypeError: Cannot read properties of undefined (reading 'map')`).
 2. **First Application Function:** Scroll down past `node_modules` and framework internals. Find the absolute top-most function call that YOU wrote (e.g., `at UserList (src/components/UserList.tsx:45)`).
 3. **The Parameter Conclusion:** Therefore, line 45 invoked `.map` on a variable that was `undefined`. Why did the parent layer pass `undefined` instead of `[]`?
-
----
-
-## 🚨 Edge-Case & Failure Mode Matrix
-
-| Scenario | Risk | Mitigation Strategy |
-|:---|:---|:---|
-| **Empty or Null Inputs** | Unhandled exception or unexpected rendering collapse | Enforce fallback guards, optional chaining, and explicit empty state handlers |
-| **Network Timeout / Latency** | Hanging operations or duplicate side-effects | Implement bounded abort controllers, exponential backoff, and idempotency keys |
-| **Concurrency / Race Conditions** | Stale state overwrite or inconsistent data mutations | Use atomic transactions, mutex locking, or cancel-on-resubmit controls |
-| **Invalid Schema / Malformed Payload** | Downstream runtime errors or security injection | Validate boundary payloads with Zod/Pydantic schemas prior to execution |
-| **Resource / Memory Saturation** | OOM errors, frame drops, or memory leaks | Clean up listeners, cancel active timers, and enforce pagination/virtualization |
-
----
-
-## 🤖 LLM-Specific Traps Table
-
-| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
-|:---|:---|:---|
-| **Hallucinated Tool Capabilities** | Assuming an external library or CLI command exists without verification | Run a verification check or verify package.json before referencing tools |
-| **Premature Completion Claim** | Declaring a task finished because code was generated without verification | Execute tests, linters, or terminal commands to provide concrete proof |
-| **Context Bloat Dumping** | Pasting entire multi-thousand-line files into prompt context | Extract targeted excerpts, symbols, and signatures to preserve tokens |
-
----
-
-## 🏛️ Tribunal Verification & Guardrails
-
-**Active Reviewers:** `orchestrator` · `agent-organizer` · `logic-reviewer`
-**Slash Command:** `/review` or `/tribunal-full`
-
-### ✅ Pre-Flight Self-Audit Checklist
-
-```
-✅ Did I deconstruct the root objective before proposing architecture?
-✅ Did I identify dependencies, bottlenecks, and parallelizable sub-tasks?
-✅ Did I avoid over-engineering and select the simplest effective pattern?
-✅ Did I verify assumptions with concrete file reads instead of speculation?
-✅ Did I establish measurable verification criteria before completion?
-```
-
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
-- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing test suites, compiler success, or equivalent operational proof) that your output works as intended.

package/.agents/skills/systematic-debugging/condition-based-waiting.md

@@ -22,12 +22,14 @@ digraph when_to_use {
 ```
 
 **Use when:**
+
 - Tests have arbitrary delays (`setTimeout`, `sleep`, `time.sleep()`)
 - Tests are flaky (pass sometimes, fail under load)
 - Tests timeout when run in parallel
 - Waiting for async operations to complete
 
 **Don't use when:**
+
 - Testing actual timing behavior (debounce, throttle intervals)
 - Always document WHY if using arbitrary timeout
 
@@ -47,22 +49,23 @@ expect(result).toBeDefined();
 
 ## Quick Patterns
 
-| Scenario | Pattern |
-|----------|---------|
-| Wait for event | `waitFor(() => events.find(e => e.type === 'DONE'))` |
-| Wait for state | `waitFor(() => machine.state === 'ready')` |
-| Wait for count | `waitFor(() => items.length >= 5)` |
-| Wait for file | `waitFor(() => fs.existsSync(path))` |
-| Complex condition | `waitFor(() => obj.ready && obj.value > 10)` |
+| Scenario          | Pattern                                              |
+| ----------------- | ---------------------------------------------------- |
+| Wait for event    | `waitFor(() => events.find(e => e.type === 'DONE'))` |
+| Wait for state    | `waitFor(() => machine.state === 'ready')`           |
+| Wait for count    | `waitFor(() => items.length >= 5)`                   |
+| Wait for file     | `waitFor(() => fs.existsSync(path))`                 |
+| Complex condition | `waitFor(() => obj.ready && obj.value > 10)`         |
 
 ## Implementation
 
 Generic polling function:
+
 ```typescript
 async function waitFor<T>(
   condition: () => T | undefined | null | false,
   description: string,
-  timeoutMs = 5000
+  timeoutMs = 5000,
 ): Promise<T> {
   const startTime = Date.now();
 
@@ -97,11 +100,12 @@ See `condition-based-waiting-example.ts` in this directory for complete implemen
 ```typescript
 // Tool ticks every 100ms - need 2 ticks to verify partial output
 await waitForEvent(manager, 'TOOL_STARTED'); // First: wait for condition
-await new Promise(r => setTimeout(r, 200));   // Then: wait for timed behavior
+await new Promise(r => setTimeout(r, 200)); // Then: wait for timed behavior
 // 200ms = 2 ticks at 100ms intervals - documented and justified
 ```
 
 **Requirements:**
+
 1. First wait for triggering condition
 2. Based on known timing (not guessing)
 3. Comment explaining WHY
@@ -109,6 +113,7 @@ await new Promise(r => setTimeout(r, 200));   // Then: wait for timed behavior
 ## Real-World Impact
 
 From debugging session (2025-10-03):
+
 - Fixed 15 flaky tests across 3 files
 - Pass rate: 60% → 100%
 - Execution time: 40% faster

package/.agents/skills/systematic-debugging/defense-in-depth.md

@@ -12,6 +12,7 @@ Single validation: "We fixed the bug"
 Multiple layers: "We made the bug impossible"
 
 Different layers catch different cases:
+
 - Entry validation catches most bugs
 - Business logic catches edge cases
 - Environment guards prevent context-specific dangers
@@ -20,6 +21,7 @@ Different layers catch different cases:
 ## The Four Layers
 
 ### Layer 1: Entry Point Validation
+
 **Purpose:** Reject obviously invalid input at API boundary
 
 ```typescript
@@ -38,6 +40,7 @@ function createProject(name: string, workingDirectory: string) {
 ```
 
 ### Layer 2: Business Logic Validation
+
 **Purpose:** Ensure data makes sense for this operation
 
 ```typescript
@@ -50,6 +53,7 @@ function initializeWorkspace(projectDir: string, sessionId: string) {
 ```
 
 ### Layer 3: Environment Guards
+
 **Purpose:** Prevent dangerous operations in specific contexts
 
 ```typescript
@@ -60,9 +64,7 @@ async function gitInit(directory: string) {
     const tmpDir = normalize(resolve(tmpdir()));
 
     if (!normalized.startsWith(tmpDir)) {
-      throw new Error(
-        `Refusing git init outside temp dir during tests: ${directory}`
-      );
+      throw new Error(`Refusing git init outside temp dir during tests: ${directory}`);
     }
   }
   // ... proceed
@@ -70,6 +72,7 @@ async function gitInit(directory: string) {
 ```
 
 ### Layer 4: Debug Instrumentation
+
 **Purpose:** Capture context for forensics
 
 ```typescript
@@ -98,12 +101,14 @@ When you find a bug:
 Bug: Empty `projectDir` caused `git init` in source code
 
 **Data flow:**
+
 1. Test setup → empty string
 2. `Project.create(name, '')`
 3. `WorkspaceManager.createWorkspace('')`
 4. `git init` runs in `process.cwd()`
 
 **Four layers added:**
+
 - Layer 1: `Project.create()` validates not empty/exists/writable
 - Layer 2: `WorkspaceManager` validates projectDir not empty
 - Layer 3: `WorktreeManager` refuses git init outside tmpdir in tests
@@ -114,6 +119,7 @@ Bug: Empty `projectDir` caused `git init` in source code
 ## Key Insight
 
 All four layers were necessary. During testing, each layer caught bugs the others missed:
+
 - Different code paths bypassed entry validation
 - Mocks bypassed business logic checks
 - Edge cases on different platforms needed environment guards

package/.agents/skills/systematic-debugging/root-cause-tracing.md

@@ -24,6 +24,7 @@ digraph when_to_use {
 ```
 
 **Use when:**
+
 - Error happens deep in execution (not at entry point)
 - Stack trace shows long call chain
 - Unclear where invalid data originated
@@ -32,17 +33,21 @@ digraph when_to_use {
 ## The Tracing Process
 
 ### 1. Observe the Symptom
+
 ```
 Error: git init failed in ~/project/packages/core
 ```
 
 ### 2. Find Immediate Cause
+
 **What code directly causes this?**
+
 ```typescript
 await execFileAsync('git', ['init'], { cwd: projectDir });
 ```
 
 ### 3. Ask: What Called This?
+
 ```typescript
 WorktreeManager.createSessionWorktree(projectDir, sessionId)
   → called by Session.initializeWorkspace()
@@ -51,13 +56,17 @@ WorktreeManager.createSessionWorktree(projectDir, sessionId)
 ```
 
 ### 4. Keep Tracing Up
+
 **What value was passed?**
+
 - `projectDir = ''` (empty string!)
 - Empty string as `cwd` resolves to `process.cwd()`
 - That's the source code directory!
 
 ### 5. Find Original Trigger
+
 **Where did empty string come from?**
+
 ```typescript
 const context = setupCoreTest(); // Returns { tempDir: '' }
 Project.create('name', context.tempDir); // Accessed before beforeEach!
@@ -85,11 +94,13 @@ async function gitInit(directory: string) {
 **Critical:** Use `console.error()` in tests (not logger - may not show)
 
 **Run and capture:**
+
 ```bash
 npm test 2>&1 | grep 'DEBUG git init'
 ```
 
 **Analyze stack traces:**
+
 - Look for test file names
 - Find the line number triggering the call
 - Identify the pattern (same test? same parameter?)
@@ -111,6 +122,7 @@ Runs tests one-by-one, stops at first polluter. See script for usage.
 **Symptom:** `.git` created in `packages/core/` (source code)
 
 **Trace chain:**
+
 1. `git init` runs in `process.cwd()` ← empty cwd parameter
 2. WorktreeManager called with empty projectDir
 3. Session.create() passed empty string
@@ -122,6 +134,7 @@ Runs tests one-by-one, stops at first polluter. See script for usage.
 **Fix:** Made tempDir a getter that throws if accessed before beforeEach
 
 **Also added defense-in-depth:**
+
 - Layer 1: Project.create() validates directory
 - Layer 2: WorkspaceManager validates not empty
 - Layer 3: NODE_ENV guard refuses git init outside tmpdir
@@ -163,6 +176,7 @@ digraph principle {
 ## Real-World Impact
 
 From debugging session (2025-10-03):
+
 - Found root cause through 5-level trace
 - Fixed at source (getter validation)
 - Added 4 layers of defense

package/.agents/skills/tailwind-patterns/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: tailwind-patterns
-description: Use when Tailwind CSS v4+ mastery. CSS-first configuration, @theme directive, container queries, scroll-driven animations, logical properties, clamp(), fluid typography, responsive design, dark mode, custom variants, component extraction, and performance optimization. Use when styling with Tailwind, building design systems, or optimizing CSS output.
+description: "Use when Tailwind CSS v4+ mastery. CSS-first configuration, @theme directive, container queries, scroll-driven animations, logical properties, clamp(), fluid typography, responsive design, dark mode, custom variants, component extraction, and performance optimization. Use when styling with Tailwind, building design systems, or optimizing CSS output."
 version: 5.0.0
 last-updated: 2026-09-13
 skills:
@@ -15,42 +15,12 @@ scripts-binding:
 
 # Tailwind CSS v4+ — CSS-First Mastery
 
-## Mandatory Pre-Flight Context Inspection
-
-Before generating, refactoring, or reviewing code in the `tailwind-patterns` domain, inspect these 5 critical parameters:
-
-1. **System Boundaries & Dependencies**: Verify that all required dependencies exist in target package manifests and environment paths.
-2. **Runtime Context & Platform Invariants**: Confirm target platform constraints (Node.js, Browser, Mobile OS, Edge runtime) before applying APIs.
-3. **Execution Guardrails**: Identify potential side-effects, state mutations, and unhandled asynchronous exceptions.
-4. **Validation & Type Contracts**: Validate input data schemas and strict type constraints across all module interfaces.
-5. **Observability & Proof of Execution**: Ensure execution produces tangible verification signals (terminal output, tests, metrics).
-
-## Activation Boundaries
-
-- **Activate when:** Use when Tailwind CSS v4+ mastery. CSS-first configuration, @theme directive, container queries, scroll-driven animations, logical properties, clamp(), fluid typography, responsive design, dark mode, custom variants, component extraction, and performance optimization. Use when styling with Tailwind, building design systems, or optimizing CSS output.
-- **DO NOT activate when:** The task falls outside the `tailwind-patterns` domain or is managed by a different dedicated specialist.
-
-## 🔁 Multi-Pass Execution Protocol
-
-Execute all non-trivial tasks through this 7-pass cognitive loop:
-
-| Pass | Phase | Core Action |
-|:---|:---|:---|
-| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. |
-| **Pass 2** | **Plan** | Decompose the task into smallest logical steps; map dependencies and required tool calls. |
-| **Pass 3** | **Execute** | Implement the solution with production-grade craft, zero placeholders, and strict typing. |
-| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. |
-| **Pass 5** | **Attack** | Perform an adversarial review searching for edge-case failures, race conditions, and traps. |
-| **Pass 6** | **Improve** | Eliminate discovered friction, optimize performance, and harden error boundaries. |
-| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. |
-
 ---
 
 ## 🛠️ Technical Architecture & Reference Recipes
 
 ---
 
-
 ---
 
 ## v4 Configuration (CSS-First)
@@ -611,48 +581,3 @@ Execute all non-trivial tasks through this 7-pass cognitive loop:
   Accessible button
 </button>
 ```
-
----
-
-## 🚨 Edge-Case & Failure Mode Matrix
-
-| Scenario | Risk | Mitigation Strategy |
-|:---|:---|:---|
-| **Empty or Null Inputs** | Unhandled exception or unexpected rendering collapse | Enforce fallback guards, optional chaining, and explicit empty state handlers |
-| **Network Timeout / Latency** | Hanging operations or duplicate side-effects | Implement bounded abort controllers, exponential backoff, and idempotency keys |
-| **Concurrency / Race Conditions** | Stale state overwrite or inconsistent data mutations | Use atomic transactions, mutex locking, or cancel-on-resubmit controls |
-| **Invalid Schema / Malformed Payload** | Downstream runtime errors or security injection | Validate boundary payloads with Zod/Pydantic schemas prior to execution |
-| **Resource / Memory Saturation** | OOM errors, frame drops, or memory leaks | Clean up listeners, cancel active timers, and enforce pagination/virtualization |
-
----
-
-## 🤖 LLM-Specific Traps Table
-
-| Anti-Pattern | What AI Commonly Does Wrong | What Is Actually Correct |
-|:---|:---|:---|
-| **Uncontrolled Re-render Loop** | Mutating state inside render bodies or omitting hook dependencies | Wrap effects with explicit deps and isolate reactive derivations in useMemo |
-| **Accessibility Neglect** | Interactive <div> without role="button", tabIndex, or onKeyDown | Use semantic <button> or provide ARIA role, keyboard handlers, and focus ring |
-| **Layout Shift Flash** | Images/dynamic content without aspect-ratio or explicit dimensions | Enforce aspect-ratio or skeleton placeholders to guarantee zero CLS |
-
----
-
-## 🏛️ Tribunal Verification & Guardrails
-
-**Active Reviewers:** `frontend-reviewer` · `type-safety` · `ui-ux-auditor` · `complexity-reviewer`
-**Slash Command:** `/review` or `/tribunal-full`
-
-### ✅ Pre-Flight Self-Audit Checklist
-
-```
-✅ Are all component props strictly typed with zero implicit "any"?
-✅ Are responsive breakpoints, fluid typography, and optical balance verified?
-✅ Is accessibility (ARIA labels, keyboard focus, contrast) validated?
-✅ Are re-renders minimized and state lifecycles cleanly separated?
-✅ Did I verify all imported UI components and icon sets actually exist?
-```
-
-### 🛑 Verification-Before-Completion (VBC) Protocol
-
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-- ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
-- ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing test suites, compiler success, or equivalent operational proof) that your output works as intended.