tribunal-kit 9.2.4 → 9.2.5

package/.agent/skills/improve-codebase-architecture/SKILL.md

@@ -1,48 +1,48 @@
----
-name: improve-codebase-architecture
-description: "Use when Scans a codebase for deepening opportunities, architectural bottlenecks, tight coupling, and produces a prioritized visual improvement roadmap."
-version: 5.0.0
-last-updated: 2026-09-13
-skills:
-  - codebase-design
-  - clean-code
-  - architecture
-tools: Read, Grep, Glob, Bash, Edit, Write
-scripts-binding:
-  - .agent/scripts/lint_runner.js
-  - .agent/scripts/verify_all.js
----
-
-# Improve Codebase Architecture — Architectural Audit & Refactoring
-
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
----
-
-## 4 Audit Steps
-
-### 1. Dependency Graph Inspection
-
-- Map import relationships across modules. Identify circular dependencies (`A -> B -> C -> A`) and break them by introducing event buses or interface abstractions.
-
-### 2. Monolithic Controller Detection
-
-- Flag files exceeding 500 lines of code containing mixed concerns (database queries, HTTP response handling, email sending, data validation).
-
-### 3. Interface Shrinking (Deepening Modules)
-
-- Audit public exports. Convert large multi-parameter interfaces into thin, single-responsibility contracts.
-
-### 4. Prioritized Architectural Roadmap Output
-
-Output audit findings in a clear prioritized Markdown table:
-
-| Impact Level         | Architectural Issue                              | Proposed Seam / Refactor                          |
-| -------------------- | ------------------------------------------------ | ------------------------------------------------- |
-| 🔴 **High Impact**   | Direct DB queries inside React Server Components | Extract Repository layer pattern                  |
-| 🟠 **Medium Impact** | Circular import between Auth and User modules    | Introduce `EventBus` for user registration events |
-| 🟡 **Low Impact**    | Hardcoded API base URLs across 12 files          | Centralize in typed `ConfigService`               |
+---
+name: improve-codebase-architecture
+description: "Use when Scans a codebase for deepening opportunities, architectural bottlenecks, tight coupling, and produces a prioritized visual improvement roadmap."
+version: 5.0.0
+last-updated: 2026-09-13
+skills:
+  - codebase-design
+  - clean-code
+  - architecture
+tools: Read, Grep, Glob, Bash, Edit, Write
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/verify_all.js
+---
+
+# Improve Codebase Architecture — Architectural Audit & Refactoring
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
+
+---
+
+## 4 Audit Steps
+
+### 1. Dependency Graph Inspection
+
+- Map import relationships across modules. Identify circular dependencies (`A -> B -> C -> A`) and break them by introducing event buses or interface abstractions.
+
+### 2. Monolithic Controller Detection
+
+- Flag files exceeding 500 lines of code containing mixed concerns (database queries, HTTP response handling, email sending, data validation).
+
+### 3. Interface Shrinking (Deepening Modules)
+
+- Audit public exports. Convert large multi-parameter interfaces into thin, single-responsibility contracts.
+
+### 4. Prioritized Architectural Roadmap Output
+
+Output audit findings in a clear prioritized Markdown table:
+
+| Impact Level         | Architectural Issue                              | Proposed Seam / Refactor                          |
+| -------------------- | ------------------------------------------------ | ------------------------------------------------- |
+| 🔴 **High Impact**   | Direct DB queries inside React Server Components | Extract Repository layer pattern                  |
+| 🟠 **Medium Impact** | Circular import between Auth and User modules    | Introduce `EventBus` for user registration events |
+| 🟡 **Low Impact**    | Hardcoded API base URLs across 12 files          | Centralize in typed `ConfigService`               |

package/.agent/skills/improve-ui/SKILL.md

@@ -1,70 +1,70 @@
----
-name: improve-ui
-description: "Use when Audit an existing product surface against its own design evidence, identify verified UI problems, and write self-contained implementation plans for another agent. Strictly read-only on product source. Use when asked to review, refine, improve, or clean up an interface without replacing its identity."
-version: 5.0.0
-last-updated: 2026-09-13
-skills:
-  - better-ui
-  - baseline-ui
-  - create-design-md
-tools: Read, Grep, Glob, Bash, Edit, Write
-scripts-binding:
-  - .agent/scripts/lint_runner.js
-  - .agent/scripts/verify_all.js
----
-
-# Improve UI — Evidence-Based UI Audit & Implementation Planning
-
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
----
-
----
-
-## 1. Operating Rules & Boundaries
-
-- **Strictly Read-Only on Product Source**: Never modify product source files (`src/`, `components/`, `app/`) during an `improve-ui` audit session.
-- **Output Artifacts Only**: Create plans under `design-plans/` or return an actionable implementation plan to the user.
-- **Respect Product Identity**: Preserve existing component architecture, routing, and product identity.
-
----
-
-## 2. The 4-Phase Audit Protocol
-
-### Phase 1: Surface Selection & Path Tracing
-
-1. Focus on one deployable application and one coherent surface family (e.g. `Dashboard / Overview`).
-2. Trace the path from route layout $\rightarrow$ page composition $\rightarrow$ shared UI primitives $\rightarrow$ tokens/CSS variables.
-
-### Phase 2: Design Language Reconstruction
-
-1. Inspect `DESIGN.md`, `index.css`, Tailwind tokens, or custom properties.
-2. Record active background tokens, typography roles, spatial rules, and border/shadow contracts.
-
-### Phase 3: Proof-Gated Defect Verification
-
-Before reporting a finding, require 3 explicit proofs:
-
-- **Observation**: Exact code line or rendered element showing the discrepancy.
-- **Basis**: Violation of documented design token or 8px grid baseline.
-- **Consequence**: Measurable degradation of visual hierarchy, readability, or interaction response.
-
-### Phase 4: Implementation Plan Generation
-
-Write a self-contained plan specifying:
-
-- Files to modify
-- Exact CSS/JSX diffs
-- Verification steps (browser preview, contrast check, visual alignment)
-
----
-
-## Anti-Slop Table
-
-| Audit Pattern                  | Evidence-Based Rule                           | Rationale                        |
-| ------------------------------ | --------------------------------------------- | -------------------------------- |
-| Rewriting entire components    | Targeted visual diff plan                     | Preserves business logic & state |
-| Guessing design tokens         | Citing verified `var(--...)` declarations     | Ensures token adherence          |
-| Speculative visual preferences | Reporting only verified WCAG/token violations | Prevents arbitrary churn         |
+---
+name: improve-ui
+description: "Use when Audit an existing product surface against its own design evidence, identify verified UI problems, and write self-contained implementation plans for another agent. Strictly read-only on product source. Use when asked to review, refine, improve, or clean up an interface without replacing its identity."
+version: 5.0.0
+last-updated: 2026-09-13
+skills:
+  - better-ui
+  - baseline-ui
+  - create-design-md
+tools: Read, Grep, Glob, Bash, Edit, Write
+scripts-binding:
+  - .agent/scripts/lint_runner.js
+  - .agent/scripts/verify_all.js
+---
+
+# Improve UI — Evidence-Based UI Audit & Implementation Planning
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+---
+
+---
+
+## 1. Operating Rules & Boundaries
+
+- **Strictly Read-Only on Product Source**: Never modify product source files (`src/`, `components/`, `app/`) during an `improve-ui` audit session.
+- **Output Artifacts Only**: Create plans under `design-plans/` or return an actionable implementation plan to the user.
+- **Respect Product Identity**: Preserve existing component architecture, routing, and product identity.
+
+---
+
+## 2. The 4-Phase Audit Protocol
+
+### Phase 1: Surface Selection & Path Tracing
+
+1. Focus on one deployable application and one coherent surface family (e.g. `Dashboard / Overview`).
+2. Trace the path from route layout $\rightarrow$ page composition $\rightarrow$ shared UI primitives $\rightarrow$ tokens/CSS variables.
+
+### Phase 2: Design Language Reconstruction
+
+1. Inspect `DESIGN.md`, `index.css`, Tailwind tokens, or custom properties.
+2. Record active background tokens, typography roles, spatial rules, and border/shadow contracts.
+
+### Phase 3: Proof-Gated Defect Verification
+
+Before reporting a finding, require 3 explicit proofs:
+
+- **Observation**: Exact code line or rendered element showing the discrepancy.
+- **Basis**: Violation of documented design token or 8px grid baseline.
+- **Consequence**: Measurable degradation of visual hierarchy, readability, or interaction response.
+
+### Phase 4: Implementation Plan Generation
+
+Write a self-contained plan specifying:
+
+- Files to modify
+- Exact CSS/JSX diffs
+- Verification steps (browser preview, contrast check, visual alignment)
+
+---
+
+## Anti-Slop Table
+
+| Audit Pattern                  | Evidence-Based Rule                           | Rationale                        |
+| ------------------------------ | --------------------------------------------- | -------------------------------- |
+| Rewriting entire components    | Targeted visual diff plan                     | Preserves business logic & state |
+| Guessing design tokens         | Citing verified `var(--...)` declarations     | Ensures token adherence          |
+| Speculative visual preferences | Reporting only verified WCAG/token violations | Prevents arbitrary churn         |

package/.agent/skills/intelligent-routing/SKILL.md

@@ -1,204 +1,204 @@
----
-name: intelligent-routing
-description: "Use when LLM Intent Processing and Gateway Routing mastery. Request classification hierarchies, function routing, confidence scoring, fallback cascades, zero-shot vs few-shot classification patterns, and identifying specialized skills for delegation. Use when parsing raw user input to determine the architectural path of execution."
-version: 5.0.0
-last-updated: 2026-09-13
-skills:
-  - fabel-protocol
-  - agentic-patterns
-  - behavioral-modes
-tools: Read, Grep, Glob, Bash, Edit, Write
-scripts-binding:
-  - .agent/scripts/verify_all.js
-  - .agent/scripts/lint_runner.js
----
-
-# Intelligent Routing v4 — Self-Describing Skill Graph
-
----
-
-## 🛠️ Technical Architecture & Reference Recipes
-
-## Hallucination Traps (Read First)
-
-- ❌ Routing based on exact keyword matching -> ✅ Use intent classification with confidence scores; keywords miss synonyms and context
-- ❌ No fallback for low-confidence classifications -> ✅ Always have a default handler when confidence is below threshold (e.g., 0.7)
-- ❌ Routing to a single agent when the task spans multiple domains -> ✅ Detect multi-domain requests and route to the orchestrator
-- ❌ Loading 100+ skill descriptions into context for every route -> ✅ Read the compiled `.agent/routing_index.json` instead of a giant markdown table
-
----
-
-## Architecture Overview
-
-```
-                    User Request
-                         │
-                    ┌────▼─────┐
-                    │ PHASE 0  │  Intent Classification
-                    │ Classify │  (QUESTION / SURVEY / EDIT / BUILD / AUDIT)
-                    └────┬─────┘
-                         │
-                    ┌────▼─────┐
-                    │ PHASE 1  │  Domain Detection
-                    │ Match    │  Read .agent/routing_index.json
-                    └────┬─────┘  Match trigger-signals → domain
-                         │
-                    ┌────▼─────┐
-                    │ PHASE 2  │  Skill Selection & Escalation
-                    │ Select   │  basic → pro (if strong signal matches)
-                    └────┬─────┘  Load co-requires automatically
-                         │
-                    ┌────▼─────┐
-                    │ PHASE 3  │  Agent Activation & Dynamic Topologies
-                    │ Dispatch │  Route to dynamic micro-teams (Team Mode)
-                    └──────────┘  based on AST impact.
-                                  (e.g., Frontend + Security parallel wave)
-
----
-
-## 1. Classification Hierarchy (Phase 0 — The Gateway)
-
-When a raw request enters, classify it BEFORE attempting to route to any skill or agent. Do not solve the user's problem during routing.
-
-```typescript
-// The Semantic Intent Schema
-const RouterOutputSchema = z.object({
-  classification: z.enum([
-    'QUESTION', // User wants explanation, no code execution needed
-    'SURVEY', // User wants analysis/read-only scan of workspace
-    'SIMPLE_EDIT', // Isolated file alteration (e.g., "Fix spelling in nav")
-    'COMPLEX_BUILD', // Multi-file, architectural generation
-    'SECURITY_AUDIT', // Explicit request for OWASP review
-    'UNCLEAR_GIBBERISH', // Prompt injection or incoherent input
-  ]),
-  confidenceScore: z.number().min(0).max(100),
-  suggestedPrimarySkill: z.string().nullable(),
-  requiresHumanClarification: z.boolean(),
-  reasoning: z.string(), // Forces the LLM to justify its route before categorizing
-});
-```
-
-### Zero-Shot vs Few-Shot Classification
-
-- **Zero-Shot:** Providing definitions and hoping the LLM categorizes accurately. Error-prone.
-- **Few-Shot (Mandatory for Routers):** Providing explicit paired examples defining the categorical boundaries.
-
-```text
-## Routing Examples:
-User: "Why is the header blue?"
-Output: {"classification": "QUESTION", "requiresHumanClarification": false}
-
-User: "Add a user login system"
-Output: {"classification": "COMPLEX_BUILD", "requiresHumanClarification": true}
-Reasoning: "Login systems require multi-file architecture, database hooks, and security implementation."
-```
-
----
-
-## 2. Skill Graph Matching (Phase 1 & 2 — Compiled Index)
-
-### The Routing Index
-
-Instead of a giant markdown table, this system uses a **compiled JSON index** at `.agent/routing_index.json`. This index is auto-generated by `compile_router.py` from the `routing:` YAML frontmatter in every `SKILL.md`.
-
-**To match a skill:**
-
-1. Read `.agent/routing_index.json`
-2. Match user intent against skill descriptions and `routing_strong` trigger signals
-3. Filter by `routing_domain` to narrow candidates
-4. Apply escalation rules (see below)
-
-### Skill Frontmatter Schema
-
-Every skill declares its routing metadata in its YAML frontmatter:
-
-```yaml
-routing:
-  domain: devops | frontend | backend | architecture | data | security | testing | design | meta | general
-  tier: basic | pro
-  supersedes: <skill-name> # "I replace this basic skill for advanced use"
-  co-requires: [<skill>, ...] # "Load these alongside me"
-  conflicts-with: [<skill>, ...] # "Don't load both"
-  trigger-signals:
-    strong: [keyword1, keyword2] # High-confidence activation triggers
-    weak: [keyword3, keyword4] # Low-confidence, need additional context
-  confidence-boost: <number> # How much to boost score when strong signal matches
-```
-
-### Escalation Rules (basic → pro)
-
-When a user's request contains **strong trigger signals** that match a `tier: pro` skill:
-
-```
-1. Check if any tier:pro skill's strong signals match the request
-2. If YES and the pro skill has `supersedes: <basic-skill>`:
-   → Load the pro skill INSTEAD of the basic one
-   → Example: "OIDC GitHub Actions" → git-pro (supersedes github-operations)
-3. If YES and the pro skill has `co-requires`:
-   → Also load the co-required skills
-   → Example: cicd-pro co-requires [containerization-pro, cloud-architect]
-```
-
-### Conflict Resolution
-
-When multiple skills match:
-
-```
-Priority order:
-1. Exact strong signal match > weak signal match
-2. tier:pro > tier:basic (when both match)
-3. Specific domain > general domain
-4. If a pro skill `supersedes` a basic skill, drop the basic skill
-5. If two skills have `conflicts-with` each other, pick the one with higher signal match count
-```
-
----
-
-## 3. Fallback Cascades & Ambiguity
-
-The AI will encounter prompts it does not understand. The Router is the _only_ place where it is safe to halt and ask immediately.
-
-**The Socratic Yield Rule:**
-If the `confidenceScore` of a categorization is `< 85`, the router MUST yield back to the user with a clarifying question instead of guessing the intent.
-
-_User:_ "Fix the thing."
-_Router Action (Incorrect):_ Assume they mean standard linter execution and run scripts.
-_Router Action (Correct):_ Halt. "Which file or feature are you referring to?"
-
----
-
-## 4. Bounding the Exploder Pattern
-
-Certain requests sound simple but require massive execution matrices (The "Exploder" pattern).
-_User:_ "Translate my entire app to French."
-
-The Router must recognize execution scales. If an execution requires touching >10 files, the Router must switch the system into `PLANNING_MODE` to generate an itinerary, rather than attempting an outright sequential execution.
-
----
-
-## 5. Domain Overlap Disambiguation
-
-When keywords belong to multiple domains, use these explicit rules:
-
-| Signal Combination                   | Route To                                           | NOT                  |
-| ------------------------------------ | -------------------------------------------------- | -------------------- |
-| Docker + AWS/ECR/Terraform           | `cloud-engineer`                                   | `devops-engineer`    |
-| Docker alone (local dev)             | `devops-engineer`                                  | `cloud-engineer`     |
-| Git + OIDC/monorepo/semantic-release | `git-pro` (via system-architect or cloud-engineer) | `github-operations`  |
-| Git + basic branching/commits        | `github-operations`                                | `git-pro`            |
-| CI/CD + AWS ECS + deploy             | `cloud-engineer` (loads cicd-pro)                  | `devops-engineer`    |
-| CI/CD + general GitHub Actions       | `devops-engineer`                                  | `cloud-engineer`     |
-| System design + scale + capacity     | `system-architect`                                 | `backend-specialist` |
-| Architecture + code patterns         | `backend-specialist`                               | `system-architect`   |
-
----
-
-## 6. Regenerating the Index
-
-When new skills are added or existing frontmatter is modified, the index regenerates automatically.
-
-
-## 7. Dynamic Sub-Agent Delegation (Team Mode)
-
-The router MUST NOT dump files into a static 3-wave pipeline. Instead, it must selectively route tasks to micro-teams (Team Mode) based on file impact and topological graph dependencies. 
-- Example: If the AST diff impacts `db/schema.prisma` and `src/components/User.tsx`, the router spawns a `database-architect` sub-agent and a `frontend-specialist` sub-agent in a parallel DAG wave, instead of running the entire 28-reviewer gauntlet on both files.
+---
+name: intelligent-routing
+description: "Use when LLM Intent Processing and Gateway Routing mastery. Request classification hierarchies, function routing, confidence scoring, fallback cascades, zero-shot vs few-shot classification patterns, and identifying specialized skills for delegation. Use when parsing raw user input to determine the architectural path of execution."
+version: 5.0.0
+last-updated: 2026-09-13
+skills:
+  - fabel-protocol
+  - agentic-patterns
+  - behavioral-modes
+tools: Read, Grep, Glob, Bash, Edit, Write
+scripts-binding:
+  - .agent/scripts/verify_all.js
+  - .agent/scripts/lint_runner.js
+---
+
+# Intelligent Routing v4 — Self-Describing Skill Graph
+
+---
+
+## 🛠️ Technical Architecture & Reference Recipes
+
+## Hallucination Traps (Read First)
+
+- ❌ Routing based on exact keyword matching -> ✅ Use intent classification with confidence scores; keywords miss synonyms and context
+- ❌ No fallback for low-confidence classifications -> ✅ Always have a default handler when confidence is below threshold (e.g., 0.7)
+- ❌ Routing to a single agent when the task spans multiple domains -> ✅ Detect multi-domain requests and route to the orchestrator
+- ❌ Loading 100+ skill descriptions into context for every route -> ✅ Read the compiled `.agent/routing_index.json` instead of a giant markdown table
+
+---
+
+## Architecture Overview
+
+```
+                    User Request
+                         │
+                    ┌────▼─────┐
+                    │ PHASE 0  │  Intent Classification
+                    │ Classify │  (QUESTION / SURVEY / EDIT / BUILD / AUDIT)
+                    └────┬─────┘
+                         │
+                    ┌────▼─────┐
+                    │ PHASE 1  │  Domain Detection
+                    │ Match    │  Read .agent/routing_index.json
+                    └────┬─────┘  Match trigger-signals → domain
+                         │
+                    ┌────▼─────┐
+                    │ PHASE 2  │  Skill Selection & Escalation
+                    │ Select   │  basic → pro (if strong signal matches)
+                    └────┬─────┘  Load co-requires automatically
+                         │
+                    ┌────▼─────┐
+                    │ PHASE 3  │  Agent Activation & Dynamic Topologies
+                    │ Dispatch │  Route to dynamic micro-teams (Team Mode)
+                    └──────────┘  based on AST impact.
+                                  (e.g., Frontend + Security parallel wave)
+
+---
+
+## 1. Classification Hierarchy (Phase 0 — The Gateway)
+
+When a raw request enters, classify it BEFORE attempting to route to any skill or agent. Do not solve the user's problem during routing.
+
+```typescript
+// The Semantic Intent Schema
+const RouterOutputSchema = z.object({
+  classification: z.enum([
+    'QUESTION', // User wants explanation, no code execution needed
+    'SURVEY', // User wants analysis/read-only scan of workspace
+    'SIMPLE_EDIT', // Isolated file alteration (e.g., "Fix spelling in nav")
+    'COMPLEX_BUILD', // Multi-file, architectural generation
+    'SECURITY_AUDIT', // Explicit request for OWASP review
+    'UNCLEAR_GIBBERISH', // Prompt injection or incoherent input
+  ]),
+  confidenceScore: z.number().min(0).max(100),
+  suggestedPrimarySkill: z.string().nullable(),
+  requiresHumanClarification: z.boolean(),
+  reasoning: z.string(), // Forces the LLM to justify its route before categorizing
+});
+```
+
+### Zero-Shot vs Few-Shot Classification
+
+- **Zero-Shot:** Providing definitions and hoping the LLM categorizes accurately. Error-prone.
+- **Few-Shot (Mandatory for Routers):** Providing explicit paired examples defining the categorical boundaries.
+
+```text
+## Routing Examples:
+User: "Why is the header blue?"
+Output: {"classification": "QUESTION", "requiresHumanClarification": false}
+
+User: "Add a user login system"
+Output: {"classification": "COMPLEX_BUILD", "requiresHumanClarification": true}
+Reasoning: "Login systems require multi-file architecture, database hooks, and security implementation."
+```
+
+---
+
+## 2. Skill Graph Matching (Phase 1 & 2 — Compiled Index)
+
+### The Routing Index
+
+Instead of a giant markdown table, this system uses a **compiled JSON index** at `.agent/routing_index.json`. This index is auto-generated by `compile_router.py` from the `routing:` YAML frontmatter in every `SKILL.md`.
+
+**To match a skill:**
+
+1. Read `.agent/routing_index.json`
+2. Match user intent against skill descriptions and `routing_strong` trigger signals
+3. Filter by `routing_domain` to narrow candidates
+4. Apply escalation rules (see below)
+
+### Skill Frontmatter Schema
+
+Every skill declares its routing metadata in its YAML frontmatter:
+
+```yaml
+routing:
+  domain: devops | frontend | backend | architecture | data | security | testing | design | meta | general
+  tier: basic | pro
+  supersedes: <skill-name> # "I replace this basic skill for advanced use"
+  co-requires: [<skill>, ...] # "Load these alongside me"
+  conflicts-with: [<skill>, ...] # "Don't load both"
+  trigger-signals:
+    strong: [keyword1, keyword2] # High-confidence activation triggers
+    weak: [keyword3, keyword4] # Low-confidence, need additional context
+  confidence-boost: <number> # How much to boost score when strong signal matches
+```
+
+### Escalation Rules (basic → pro)
+
+When a user's request contains **strong trigger signals** that match a `tier: pro` skill:
+
+```
+1. Check if any tier:pro skill's strong signals match the request
+2. If YES and the pro skill has `supersedes: <basic-skill>`:
+   → Load the pro skill INSTEAD of the basic one
+   → Example: "OIDC GitHub Actions" → git-pro (supersedes github-operations)
+3. If YES and the pro skill has `co-requires`:
+   → Also load the co-required skills
+   → Example: cicd-pro co-requires [containerization-pro, cloud-architect]
+```
+
+### Conflict Resolution
+
+When multiple skills match:
+
+```
+Priority order:
+1. Exact strong signal match > weak signal match
+2. tier:pro > tier:basic (when both match)
+3. Specific domain > general domain
+4. If a pro skill `supersedes` a basic skill, drop the basic skill
+5. If two skills have `conflicts-with` each other, pick the one with higher signal match count
+```
+
+---
+
+## 3. Fallback Cascades & Ambiguity
+
+The AI will encounter prompts it does not understand. The Router is the _only_ place where it is safe to halt and ask immediately.
+
+**The Socratic Yield Rule:**
+If the `confidenceScore` of a categorization is `< 85`, the router MUST yield back to the user with a clarifying question instead of guessing the intent.
+
+_User:_ "Fix the thing."
+_Router Action (Incorrect):_ Assume they mean standard linter execution and run scripts.
+_Router Action (Correct):_ Halt. "Which file or feature are you referring to?"
+
+---
+
+## 4. Bounding the Exploder Pattern
+
+Certain requests sound simple but require massive execution matrices (The "Exploder" pattern).
+_User:_ "Translate my entire app to French."
+
+The Router must recognize execution scales. If an execution requires touching >10 files, the Router must switch the system into `PLANNING_MODE` to generate an itinerary, rather than attempting an outright sequential execution.
+
+---
+
+## 5. Domain Overlap Disambiguation
+
+When keywords belong to multiple domains, use these explicit rules:
+
+| Signal Combination                   | Route To                                           | NOT                  |
+| ------------------------------------ | -------------------------------------------------- | -------------------- |
+| Docker + AWS/ECR/Terraform           | `cloud-engineer`                                   | `devops-engineer`    |
+| Docker alone (local dev)             | `devops-engineer`                                  | `cloud-engineer`     |
+| Git + OIDC/monorepo/semantic-release | `git-pro` (via system-architect or cloud-engineer) | `github-operations`  |
+| Git + basic branching/commits        | `github-operations`                                | `git-pro`            |
+| CI/CD + AWS ECS + deploy             | `cloud-engineer` (loads cicd-pro)                  | `devops-engineer`    |
+| CI/CD + general GitHub Actions       | `devops-engineer`                                  | `cloud-engineer`     |
+| System design + scale + capacity     | `system-architect`                                 | `backend-specialist` |
+| Architecture + code patterns         | `backend-specialist`                               | `system-architect`   |
+
+---
+
+## 6. Regenerating the Index
+
+When new skills are added or existing frontmatter is modified, the index regenerates automatically.
+
+
+## 7. Dynamic Sub-Agent Delegation (Team Mode)
+
+The router MUST NOT dump files into a static 3-wave pipeline. Instead, it must selectively route tasks to micro-teams (Team Mode) based on file impact and topological graph dependencies. 
+- Example: If the AST diff impacts `db/schema.prisma` and `src/components/User.tsx`, the router spawns a `database-architect` sub-agent and a `frontend-specialist` sub-agent in a parallel DAG wave, instead of running the entire 28-reviewer gauntlet on both files.