tribunal-kit 9.2.4 → 9.2.6

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

@@ -1,8 +1,8 @@
 ---
 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
+description: "Use when executing, coordinating, planning, or reviewing behavioral modes agent workflows, cognitive loops, and architecture standards."
+version: 6.0.0
+last-updated: 2026-09-29
 skills:
   - fabel-protocol
   - agentic-patterns
@@ -16,185 +16,255 @@ scripts-binding:
 
 # 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
+## Mandatory Pre-Flight Context Inspection
+Before reading, generating, or refactoring code in the `behavioral-modes` 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).
 
-_When:_ Something is broken and the root cause is unknown
 
-**Behavior:**
+## Activation Boundaries
+- **Activate when:** Use when executing, coordinating, planning, or reviewing behavioral modes agent workflows, cognitive loops, and architecture standards.
+- **DO NOT activate when:** The task falls outside the `behavioral-modes` domain or is managed by a different dedicated specialist agent.
 
-- 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
+## 🔁 Multi-Pass Execution Protocol
 
----
-
-### 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
-
----
+| Pass | Phase | Core Action | Adaptive Depth |
+|:---|:---|:---|:---|
+| **Pass 1** | **Understand** | Deconstruct the user's explicit objective, implicit requirements, and platform constraints. | Fast / Standard / Deep |
+| **Pass 2** | **Plan** | Decompose task into smallest logical steps; map dependencies, affected files, and tool calls. | Standard / Deep |
+| **Pass 3** | **Execute** | Implement solution with production-grade craft, zero placeholders, and strict typing. | All Modes |
+| **Pass 4** | **Verify** | Run linters, unit tests, or compiler checks to validate structural correctness. | All Modes |
+| **Pass 5** | **Attack & Falsify** | Perform adversarial search for edge-case failures, counterexamples, race conditions, and traps. | Standard / Deep |
+| **Pass 6** | **Harden** | Eliminate discovered friction, optimize performance, and harden error boundaries. | Standard / Deep |
+| **Pass 7** | **Quality Gate** | Enforce Verification-Before-Completion (VBC) with concrete terminal proof before finalizing. | All Modes |
 
-### 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
+---
+
+## 🛠️ 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]
+```
 
-## Mode Selection Rules
+## 🚨 Edge-Case & Failure Mode Matrix
 
-| 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  |
+| Scenario | Risk | Production Mitigation |
+|:---|:---|:---|
+| **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 |
 
----
 
-## 🤖 Mode Leakage Mitigation (Anti-Hallucination)
+## 🤖 LLM-Specific Traps Table
 
-LLMs naturally want to "help" by writing code immediately. **Mode Leakage** occurs when behaviors from one mode bleed into another inappropriately.
+| 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 |
 
-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."
 
----
+## 🏛️ Tribunal Verification & Guardrails
 
-## Output Format
+**Active Reviewers:** `orchestrator` · `agent-organizer` · `logic-reviewer`
+**Slash Command:** `/review` or `/tribunal-full`
 
-When this skill produces a recommendation or design decision, structure your output as:
+### 🔬 Evidence Standard (Tri-State Verification)
+Every finding, audit statement, or completion claim must classify its factual certainty:
+- **`[OBSERVED]`**: Directly confirmed in the codebase or verified via executed terminal command.
+- **`[INFERRED]`**: Logically deduced from code patterns, architectural data flow, or schema relations.
+- **`[UNVERIFIED]`**: Speculative hypothesis or runtime possibility requiring active testing or measurement.
 
+### ✅ Pre-Flight Self-Audit Checklist
 ```
-━━━ 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]
+✅ 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.