tribunal-kit 7.0.0 → 9.0.0

package/.agent/skills/taste-skill/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: taste-skill
 description: Senior UI/UX frontend skill that enforces anti-slop design decisions, motion quality, visual rhythm, micro-craft, and architectural discipline.
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - better-ui
   - impeccable
@@ -27,6 +27,12 @@ Before rendering UI components, you MUST inspect:
 
 Enforce senior-level design taste, anti-slop constraints, and visual craft across every component.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Senior UI/UX frontend skill that enforces anti-slop design decisions, motion quality, visual rhythm, micro-craft, and architectural discipline..
+- **DO NOT activate when:** The task falls strictly outside taste-skill domain or belongs to a different dedicated specialist.
+
 ---
 
 ## The 5 Rules of Design Taste
@@ -59,28 +65,25 @@ Enforce senior-level design taste, anti-slop constraints, and visual craft acros
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🏛️ Tribunal Verification & Guardrails
 
-1. **Defaulting to Plain Templates**: Producing boring, unstyled HTML buttons with zero hover/active states.
-2. **Ignoring Dark Mode Depth**: Leaving card backgrounds flat black (`#000000`) without surface lightness progression.
-
----
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Active reviewers: `frontend-reviewer` · `ui-ux-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.
 
 ### ✅ Pre-Flight Self-Audit
-
 ```
-✅ Are generic purple gradients and glowing borders completely avoided?
-✅ Is text length bounded to 65ch max width for body paragraphs?
-✅ Do interactive elements feature tactile press feedback (`scale(0.97)`)?
+✅ 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.

package/.agent/skills/tdd-workflow/SKILL.md

@@ -2,8 +2,8 @@
 name: tdd-workflow
 description: Test-Driven Development (TDD) mastery. Red-Green-Refactor cycles, behavior-driven design (BDD), strict mutation coverage, test doubles (mocks/stubs/spies), and avoiding test-induced design damage. Use when building complex algorithms, deep business logic, or strictly regulated systems.
 tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - testing-patterns
   - clean-code
@@ -21,23 +21,66 @@ scripts-binding:
 
 Before implementing feature logic or writing unit tests, you MUST inspect:
 
-1. Red-Green-Refactor Cycle (Section 25) → Write failing test FIRST (Red) → minimal passing code SECOND (Green) → cleanup THIRD (Refactor)
-2. Behavior-First Assertion Rule (Section 36) → Assert public contract results (GIVEN/WHEN/THEN); ban asserting internal private fields or state
-3. IO Boundary-Only Mocking (Section 50) → Mock ONLY un-owned external boundaries (DB IO, network APIs); ban mocking domain entities or pure utils
+1. Red-Green-Refactor Cycle → Write failing test FIRST (Red) → minimal passing code SECOND (Green) → cleanup THIRD (Refactor)
+2. Behavior-First Assertion Rule → Assert public contract results (GIVEN/WHEN/THEN); ban asserting internal private fields or private state
+3. I/O Boundary-Only Mocking → Mock ONLY un-owned external boundaries (database I/O, network fetch); ban mocking pure domain utilities or internal classes
+4. Fast Deterministic Test Runner → Tests must execute in memory in < 100ms per file; avoid unneeded sleep delays or live network connections
 
-# TDD Workflow — Red-Green-Refactor Mastery
+## Activation Boundaries
+
+- **Activate when:** Developing new algorithms, complex business logic, financial calculations, state machine transitions, and fixing bugs via regression reproduction.
+- **DO NOT activate when:** Writing disposable prototype scripts, pure visual CSS layouts, or static documentation.
+
+## 2026 TDD & Verification Invariants
+
+1. **Bug Fix Regression Test First**:
+   Never fix a bug directly in production code. First write a test reproducing the exact failure case (Red), then apply the minimal fix (Green).
+2. **Deterministic Time & Clocks**:
+   Never use real `Date.now()` or `setTimeout()` in unit tests. Use fake timers (`vi.useFakeTimers()` or `jest.useFakeTimers()`) for instant, deterministic clock control.
+3. **Property-Based Testing Integration**:
+   For complex parsing or serialization algorithms, complement example-based unit tests with generative property-based tests (e.g. `fast-check` / `hypothesis`).
+
+## Hallucination Traps (Read First)
+
+- ❌ Writing tests after all code is written → ✅ Write the test first to prove the test actually fails
+- ❌ Testing implementation details (e.g. testing private methods) → ✅ Test public interface behavior
+- ❌ Mocking what you own → ✅ Use real domain objects in tests; mock only external network/DB I/O
+- ❌ Writing 5 assertions testing 5 unrelated things in one test → ✅ One logical behavior per test
+
+## The Iron Law of TDD
+
+```
+NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+```
+
+Write code before the test? **Delete it. Start over.**
+No exceptions:
+- Don't keep it as "reference"
+- Don't "adapt" it while writing tests
+- Delete means delete. Implement fresh from tests.
+
+## Anti-Rationalization Table
 
-Build features and fixes one slice at a time using strict Test-Driven Development (TDD) discipline.
+| Thought | Reality |
+|---------|---------|
+| "This is simple, I'll write tests after" | Simple tasks develop subtle edge cases. Write the test first. |
+| "I know the implementation already" | Knowing it makes writing the failing test take 30 seconds. Write it. |
+| "I'll just keep the code as a reference" | Keeping it biases your tests to match your bugs. Delete it. |
+| "Mocking the whole service is faster" | Mocking what you own tests your mocks, not your software. |
 
 ---
 
 ## The 3-Phase TDD Cycle
 
 ```
-[ 1. RED ]    Write a failing behavioral test for the minimal next requirement.
-                  ↓
-[ 2. GREEN ]  Write the simplest production code to make the test pass.
-                  ↓
+[ 1. RED ]      Write a failing behavioral test for the minimal next requirement.
+                    ↓
+[ VERIFY RED ]  Watch it fail for the expected reason (mandatory).
+                    ↓
+[ 2. GREEN ]    Write the simplest production code to make the test pass.
+                    ↓
+[ VERIFY GREEN] Run test suite and confirm 0 failures.
+                    ↓
 [ 3. REFACTOR ] Clean up code & duplicate logic while ensuring tests stay green.
 ```
 
@@ -71,28 +114,25 @@ expect(calculator.add(40, 2)).toBe(42);
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🏛️ Tribunal Verification & Guardrails
 
-1. **Writing Code First, Tests Later**: Generating 200 lines of implementation code and adding tests as an afterthought.
-2. **Fragile Mock Over-use**: Mocking every internal dependency, creating brittle tests that break during refactoring.
-
----
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Active reviewers: `test-engineer` · `logic-reviewer`**
+### ❌ 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.
 
 ### ✅ Pre-Flight Self-Audit
-
 ```
-✅ Was the failing test written and verified BEFORE writing implementation code?
-✅ Does the test assert external behavior rather than internal private state?
-✅ Are mocks restricted strictly to external IO boundaries?
+✅ 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.

package/.agent/skills/test-result-analyzer/SKILL.md

@@ -2,8 +2,8 @@
 name: test-result-analyzer
 description: Ingests test logs and identifies root causes across multiple failing test files. Provides actionable fix recommendations.
 tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - systematic-debugging
   - testing-patterns
@@ -25,10 +25,14 @@ Before analyzing failing test logs or output traces, you MUST inspect:
 2. Cluster Categorization Rule (Section 88) → Group failures by shared module/error type to resolve dozens of failures via single root fixes
 3. Literal Trace Extract Discipline (Section 257) → Quote exact Expected/Received values and line numbers strictly from actual logs; ban guessing assertion details
 
-# Test Result Analyzer Skill
-
 You are a specialist in analyzing test output — not writing tests, but _understanding why tests fail_. You turn walls of red error text into a prioritized action plan.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Ingests test logs and identifies root causes across multiple failing test files. Provides actionable fix recommendations..
+- **DO NOT activate when:** The task falls strictly outside test-result-analyzer domain or belongs to a different dedicated specialist.
+
 ## When to Activate
 
 - After a test run with multiple failures.
@@ -290,69 +294,17 @@ AI coding assistants often fall into specific bad habits when dealing with this
 
 ---
 
-**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.
-
----
-
-## 🤖 LLM-Specific Traps
-
-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.
-
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
+## 🏛️ Tribunal Verification & Guardrails
 
 **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.
 
 ### ✅ 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?
@@ -361,8 +313,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.

package/.agent/skills/testing-patterns/SKILL.md

@@ -2,8 +2,8 @@
 name: testing-patterns
 description: Testing mastery across stacks. Unit testing with Jest/Vitest/pytest, integration testing, E2E with Playwright, mocking strategies, test architecture (AAA, Given-When-Then), code coverage, snapshot testing, API testing, component testing with Testing Library, and TDD workflow. Use when writing tests, designing test architecture, or improving test coverage.
 tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - tdd-workflow
   - test-result-analyzer
@@ -25,7 +25,11 @@ Before writing unit, integration, or component tests, you MUST inspect:
 2. Accessibility-First Query Hierarchy (Section 343) → Query React components by `getByRole` or `getByLabelText`; ban default `getByTestId` queries
 3. Dependency Injection Over Global Mocks (Section 268) → Prefer constructor dependency injection over global `vi.mock()` to prevent cross-test state leakage
 
-# Testing Patterns — Cross-Stack Testing Mastery
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Testing mastery across stacks. Unit testing with Jest/Vitest/pytest, integration testing, E2E with Playwright, mocking strategies, test architecture (AAA, Given-When-Then), code coverage, snapshot testing, API testing, component testing with Testing Library, and TDD workflow. Use when writing tests, designing test architecture, or improving test coverage..
+- **DO NOT activate when:** The task falls strictly outside testing-patterns domain or belongs to a different dedicated specialist.
 
 ---
 
@@ -552,69 +556,17 @@ AI coding assistants often fall into specific bad habits when dealing with this
 
 ---
 
-**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.
-
----
-
-## 🤖 LLM-Specific Traps
-
-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.
-
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
+## 🏛️ Tribunal Verification & Guardrails
 
 **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.
 
 ### ✅ 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?
@@ -623,8 +575,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.

package/.agent/skills/thermo-nuclear-code-quality-review/SKILL.md

@@ -2,8 +2,8 @@
 name: thermo-nuclear-code-quality-review
 description: Run an extremely strict maintainability review for abstraction quality, giant files, spaghetti-condition growth, and architectural debt.
 tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - clean-code
   - codebase-design
@@ -25,10 +25,14 @@ Before performing ultra-strict maintainability code audits, you MUST inspect:
 2. Cyclomatic Nesting Limit (3 levels max) (Section 27) → Flag nested conditionals >3 levels deep; require early guard clause returns
 3. Direct Dependency Coupling Ban (Section 53) → Flag domain logic directly importing vendor SDKs or DB models instead of interface adapters
 
-# Thermo-Nuclear Code Quality Review — Zero-Tolerance Maintainability Audit
-
 Execute a ruthless, zero-tolerance code maintainability audit targeting abstraction leaks, file bloat, and spaghetti conditionals.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Run an extremely strict maintainability review for abstraction quality, giant files, spaghetti-condition growth, and architectural debt..
+- **DO NOT activate when:** The task falls strictly outside thermo-nuclear-code-quality-review domain or belongs to a different dedicated specialist.
+
 ---
 
 ## 5 Zero-Tolerance Audit Rules
@@ -71,28 +75,25 @@ function processOrder(order: Order) {
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🏛️ Tribunal Verification & Guardrails
 
-1. **Permissive Approvals**: Giving "looks good to me" approvals on 800-line monolithic files with nested conditionals.
-2. **Superficial Formatting Fixes**: Focusing on trailing commas instead of architectural complexity and file bloat.
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Active reviewers: `complexity-reviewer` · `logic-reviewer` · `type-safety`**
+### ❌ 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.
 
 ### ✅ Pre-Flight Self-Audit
-
 ```
-✅ Are all files under the 300-line size threshold?
-✅ Has cyclomatic nesting depth been reduced to $\le 3$ levels via guard clauses?
-✅ Are all magic numbers and status strings extracted into typed constants?
+✅ 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.

package/.agent/skills/thinking-protocol/SKILL.md

@@ -2,8 +2,8 @@
 name: thinking-protocol
 description: Tribunal Agent Kit thinking and cognitive reasoning rules. Helps agents structure their thoughts and follow protocols.
 tools: Read, Grep, Glob, Bash, Edit, Write
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - fabel-protocol
   - behavioral-modes
@@ -27,6 +27,12 @@ Before beginning any cognitive reasoning loop, you MUST inspect:
 
 Guidelines for structural reasoning and cognitive loop execution.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Tribunal Agent Kit thinking and cognitive reasoning rules. Helps agents structure their thoughts and follow protocols..
+- **DO NOT activate when:** The task falls strictly outside thinking-protocol domain or belongs to a different dedicated specialist.
+
 ## Pre-Flight Checklist
 
 Before generating any output or proposing code modifications:
@@ -40,3 +46,28 @@ Before completing a task, confirm:
 
 - Syntax, structure, and type safety constraints are met.
 - Relevant tests have been run and passed successfully.
+
+---
+
+## 🏛️ Tribunal Verification & Guardrails
+
+**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.
+
+### ✅ Pre-Flight Self-Audit
+```
+✅ 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.

package/.agent/skills/to-spring-or-not-to-spring/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: to-spring-or-not-to-spring
 description: Audit and decide when to use physics-based spring animations (stiffness, damping, mass) vs duration-based cubic-bezier easing curves.
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - motion-engineering
   - framer-motion-expert
@@ -27,6 +27,12 @@ Before selecting animation model (Spring vs Cubic-Bezier), you MUST inspect:
 
 Decide when to use physics-driven spring models (Framer Motion / Reanimated) vs duration-based cubic-bezier easing curves.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Audit and decide when to use physics-based spring animations (stiffness, damping, mass) vs duration-based cubic-bezier easing curves..
+- **DO NOT activate when:** The task falls strictly outside to-spring-or-not-to-spring domain or belongs to a different dedicated specialist.
+
 ---
 
 ## Spring vs Duration Decision Matrix
@@ -50,27 +56,25 @@ Decide when to use physics-driven spring models (Framer Motion / Reanimated) vs
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🏛️ Tribunal Verification & Guardrails
 
-1. **Bouncy Springs on Modals**: Adding low-damping bouncy springs to popovers or modals, making popovers wobble on screen.
-2. **Fixed Duration Springs**: Setting `duration: 0.5` alongside `type: "spring"` in Framer Motion, which overrides natural spring physics.
-
----
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Active reviewers: `motion-reviewer`**
+### ❌ 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.
 
 ### ✅ Pre-Flight Self-Audit
-
 ```
-✅ Are spring physics restricted to gestures, toggles, drag targets, and playful badges?
-✅ Are modals, dropdowns, and route transitions using deterministic cubic-bezier curves?
+✅ 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.

package/.agent/skills/transitions-dev/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: transitions-dev
 description: Production-ready CSS transition patterns for web apps with drop-in snippets for cards, modals, dropdowns, panels, and accordions.
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - better-ui
   - micro-interaction
@@ -27,6 +27,12 @@ Before implementing CSS transitions, you MUST inspect:
 
 Drop-in, hardware-accelerated CSS transition utility classes for modern web components.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Production-ready CSS transition patterns for web apps with drop-in snippets for cards, modals, dropdowns, panels, and accordions..
+- **DO NOT activate when:** The task falls strictly outside transitions-dev domain or belongs to a different dedicated specialist.
+
 ---
 
 ## 4 Production Snippets
@@ -97,27 +103,25 @@ Animate element height smoothly without hardcoding fixed pixel heights:
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🏛️ Tribunal Verification & Guardrails
 
-1. **Animating `height` directly**: Animating `height: 0` to `height: auto` in CSS (which fails in CSS). Use `grid-template-rows: 0fr -> 1fr`.
-2. **Missing `overflow: hidden`**: Forgetting `overflow: hidden` on accordion inner wrappers, causing content to spill out during collapse.
-
----
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Active reviewers: `frontend-reviewer` · `motion-reviewer`**
+### ❌ 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.
 
 ### ✅ Pre-Flight Self-Audit
-
 ```
-✅ Are accordions using `grid-template-rows: 0fr -> 1fr` for smooth height expansion?
-✅ Are modal enter/exit states scaling from `scale(0.96)` with opacity?
+✅ 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.