tribunal-kit 4.5.1 → 4.6.1

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

@@ -1,227 +1,241 @@
----
-name: behavioral-modes
-description: AI operational modes (brainstorm, implement, debug, review, teach, ship, orchestrate). Use to adapt behavior based on task type.
-allowed-tools: Read, Write, Edit, Glob, Grep
-version: 1.0.0
-last-updated: 2026-03-12
-applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
----
-
-# Behavioral Modes
-
----
-
-## 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]
-```
-
----
-
-
----
-
-
-
-AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
-
-1. **Over-engineering:** Proposing complex abstractions or distributed systems when a simpler approach suffices.
-2. **Hallucinated Libraries/Methods:** Using non-existent methods or packages. Always `// VERIFY` or check `package.json` / `requirements.txt`.
-3. **Skipping Edge Cases:** Writing the "happy path" and ignoring error handling, timeouts, or data validation.
-4. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-5. **Silent Degradation:** Catching and suppressing errors without logging or re-raising.
-
----
-
-
-
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
-
-### ❌ Forbidden AI Tropes
-
-1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
-2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
-3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
-
-
-
-Review these questions before confirming output:
-```
-✅ Did I rely ONLY on real, verified tools and methods?
-✅ Is this solution appropriately scoped to the user's constraints?
-✅ Did I handle potential failure modes and edge cases?
-✅ Have I avoided generic boilerplate that doesn't add value?
-```
-
-### 🛑 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 tests, compile success, or equivalent proof) that your output works as intended.
-
-
-## Pre-Flight Checklist
-- [ ] Have I reviewed the user's specific constraints and requests?
-- [ ] Have I checked the environment for relevant existing implementations?
-
-## VBC Protocol (Verification-Before-Completion)
-You MUST verify existing code signatures and variables before attempting to modify or call them. No hallucination is permitted.
+---
+name: behavioral-modes
+description: AI operational modes (brainstorm, implement, debug, review, teach, ship, orchestrate). Use to adapt behavior based on task type.
+allowed-tools: Read, Write, Edit, Glob, Grep
+version: 1.0.0
+last-updated: 2026-03-12
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
+routing:
+  domain: general
+  tier: basic
+---
+
+# Behavioral Modes
+
+---
+
+## 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]
+```
+
+---
+
+---
+
+AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
+
+1. **Over-engineering:** Proposing complex abstractions or distributed systems when a simpler approach suffices.
+2. **Hallucinated Libraries/Methods:** Using non-existent methods or packages. Always `// VERIFY` or check `package.json` / `requirements.txt`.
+3. **Skipping Edge Cases:** Writing the "happy path" and ignoring error handling, timeouts, or data validation.
+4. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
+5. **Silent Degradation:** Catching and suppressing errors without logging or re-raising.
+
+---
+
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
+
+### ❌ Forbidden AI Tropes
+
+1. **Blind Assumptions:** Never make an assumption without documenting it clearly with `// VERIFY: [reason]`.
+2. **Silent Degradation:** Catching and suppressing errors without logging or handling.
+3. **Context Amnesia:** Forgetting the user's constraints and offering generic advice instead of tailored solutions.
+
+Review these questions before confirming output:
+
+```
+✅ Did I rely ONLY on real, verified tools and methods?
+✅ Is this solution appropriately scoped to the user's constraints?
+✅ Did I handle potential failure modes and edge cases?
+✅ Have I avoided generic boilerplate that doesn't add value?
+```
+
+### 🛑 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 tests, compile success, or equivalent proof) that your output works as intended.
+
+## Pre-Flight Checklist
+
+- [ ] Have I reviewed the user's specific constraints and requests?
+- [ ] Have I checked the environment for relevant existing implementations?
+
+## VBC Protocol (Verification-Before-Completion)
+
+You MUST verify existing code signatures and variables before attempting to modify or call them. No hallucination is permitted.
 
 ---
 
@@ -251,6 +265,7 @@ AI coding assistants often fall into specific bad habits when dealing with this
 ### ✅ Pre-Flight Self-Audit
 
 Review these questions before confirming output:
+
 ```
 ✅ Did I rely ONLY on real, verified tools and methods?
 ✅ Is this solution appropriately scoped to the user's constraints?
@@ -261,5 +276,6 @@ Review these questions before confirming output:
 ### 🛑 Verification-Before-Completion (VBC) Protocol
 
 **CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
+
 - ❌ **Forbidden:** Declaring a task complete because the output "looks correct."
 - ✅ **Required:** You are explicitly forbidden from finalizing any task without providing **concrete evidence** (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.