tribunal-kit 7.0.0 → 9.0.0

package/.agent/skills/codebase-design/SKILL.md

@@ -2,8 +2,8 @@
 name: codebase-design
 description: Guidance for designing deep modules with small interfaces and clean seams. Use when structuring a new module, refactoring complex codebases, or designing internal library boundaries.
 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:
   - architecture
   - clean-code
@@ -21,13 +21,28 @@ scripts-binding:
 
 Before designing module boundaries or internal libraries, you MUST inspect:
 
-1. Deep Module Ratio Rule (Section 25) → Create deep modules (small simple interface hiding heavy internal complexity); ban shallow 1-line wrapper functions
-2. Strict Information Hiding (Section 46) → Keep internal data structures and vendor clients strictly private (`#privateField`); ban leaking internal ORM/DB types in public APIs
-3. Policy vs Mechanism Separation (Section 53) → Separate generic execution mechanisms (SQL queries, HTTP fetches) from domain business policies (retry rules, validation)
+1. Deep Module Ratio Rule → Create deep modules (small simple interface hiding heavy internal complexity); ban shallow 1-line wrapper functions
+2. Strict Information Hiding → Keep internal data structures and vendor clients strictly private (`#privateField`); ban leaking internal ORM/DB entities in public APIs
+3. Ports & Adapters Isolation → Define abstract interfaces for external services (storage, payments, email); keep core business domain logic decoupled from vendor SDKs
+4. Policy vs Mechanism Separation → Separate generic execution mechanisms (SQL queries, HTTP fetches) from domain business policies (retry rules, pricing models)
 
-# Codebase Design — Deep Modules & Clean Seams
+## Activation Boundaries
+
+- **Activate when:** Structuring new software packages, refactoring monolithic files into modular boundaries, designing internal SDKs, and decoupling domain logic from third-party dependencies.
+- **DO NOT activate when:** Writing localized one-off utility helper functions or pure CSS styles.
+
+## 2026 Architecture & Module Invariants
 
-Architect software with **deep modules**: modules that hide immense internal complexity behind small, simple, intuitive interface seams.
+1. **Deep vs Shallow Ratio**: Aim for interfaces with ≤ 3 primary methods that encapsulate multi-step workflows. If a consumer must orchestrate 5 method calls in sequence, your module interface is too shallow.
+2. **Domain Model Immutability**: Return frozen or readonly representations (`Readonly<User>`) from module boundaries to prevent callers from mutating internal state without going through domain methods.
+3. **Seam Testing with Stubs**: When modules have clean seams, testing requires stubbing only the narrow boundary interface rather than mocking 15 internal methods.
+
+## Hallucination Traps (Read First)
+
+- ❌ Exposing Prisma/Mongoose documents directly to API callers → ✅ Map to domain DTOs at the module boundary
+- ❌ Creating "manager", "helper", or "util" classes with 40 unrelated methods → ✅ Group around cohesive bounded contexts
+- ❌ Passing 10 configuration flags to a function → ✅ Use sensible defaults and the builder or options pattern
+- ❌ Breaking a 50-line method into five 10-line shallow classes → ✅ Keep cohesive code together unless there is real reuse
 
 ---
 
@@ -72,29 +87,25 @@ class DeepUserStorage {
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🏛️ Tribunal Verification & Guardrails
 
-1. **Creating Anemic Shallow Wrappers**: Writing 1-line wrapper functions around third-party libraries that add zero abstraction value.
-2. **Leaking Internal Implementation Types**: Exporting low-level internal database types directly in public API interfaces.
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Slash command: `/review` or `/tribunal-backend`**
-**Active reviewers: `logic-reviewer` · `type-safety` · `complexity-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
-
 ```
-✅ Does the module expose a minimal interface while encapsulating internal complexity?
-✅ Are internal vendor data structures hidden behind clean domain seams?
-✅ Is policy separated cleanly from low-level mechanism?
+✅ 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/colorize/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: colorize
 description: Introduce strategic, harmonious, accessible color systems and OKLCH color palettes to visually flat or dull interfaces.
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - better-colors
   - baseline-ui
@@ -27,6 +27,12 @@ Before designing color systems or applying color palettes, you MUST inspect:
 
 Architect uniform, perceptually balanced color scales using the modern OKLCH color space for light and dark modes.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Introduce strategic, harmonious, accessible color systems and OKLCH color palettes to visually flat or dull interfaces..
+- **DO NOT activate when:** The task falls strictly outside colorize domain or belongs to a different dedicated specialist.
+
 ---
 
 ## 4 Color System Principles
@@ -64,28 +70,25 @@ Never use random red/green/yellow hex codes. Maintain matching chroma and lightn
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🏛️ Tribunal Verification & Guardrails
 
-1. **Random Hex Colors**: Scattering `#3b82f6` or `#ef4444` directly in component files without CSS variables.
-2. **Ignoring Wide-Gamut Displays**: Failing to provide fallback colors for browsers without Display P3 support.
-
----
+**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 colors declared via CSS variables in the OKLCH color space?
-✅ Does the color distribution strictly honor the 60-30-10 budget?
-✅ Do status colors maintain uniform perceptual lightness ($L \approx 0.60$ - $0.72$)?
+✅ 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/compact-landing/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: compact-landing
 description: Build compact, premium landing pages with clear CTA hierarchy, quiet typography, restrained visual noise, and high conversion flow.
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - landing-page
   - quieter
@@ -27,6 +27,12 @@ Before engineering compact landing pages, you MUST inspect:
 
 Build tight, ultra-focused, high-converting landing pages that deliver value quickly without unnecessary multi-scroll filler.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Build compact, premium landing pages with clear CTA hierarchy, quiet typography, restrained visual noise, and high conversion flow..
+- **DO NOT activate when:** The task falls strictly outside compact-landing domain or belongs to a different dedicated specialist.
+
 ---
 
 ## 4 Compact Landing Rules
@@ -57,28 +63,25 @@ Build tight, ultra-focused, high-converting landing pages that deliver value qui
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🏛️ Tribunal Verification & Guardrails
 
-1. **Adding 10 Scroll Sections**: Padding out compact landing pages with generic boilerplate feature grids and stock FAQs when a tight 3-section layout was requested.
-2. **Multiple Competing CTAs**: Adding 4 different buttons in the hero section. Keep 1 primary action button.
-
----
+**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
-
 ```
-✅ Does the hero section fit comfortably inside a 1080p desktop viewport without scrolling?
-✅ Is heading font size restrained and balanced (`text-wrap: balance`)?
-✅ Is the page limited to max 4 tight sections?
+✅ 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/company-logos/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: company-logos
 description: Social proof rows, logo grids, customer carousels, and trust badges layout rules for balanced visual weight and responsive alignment.
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - baseline-ui
   - landing-page
@@ -27,6 +27,12 @@ Before designing logo grids or trust rows, you MUST inspect:
 
 Architect balanced, optically aligned logo rows and trust grids that communicate credibility without visual clutter.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Social proof rows, logo grids, customer carousels, and trust badges layout rules for balanced visual weight and responsive alignment..
+- **DO NOT activate when:** The task falls strictly outside company-logos domain or belongs to a different dedicated specialist.
+
 ---
 
 ## 4 Logo Layout Rules
@@ -61,28 +67,25 @@ Logos vary wildly in aspect ratio (e.g. square logos vs wide wordmarks).
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🏛️ Tribunal Verification & Guardrails
 
-1. **Unfiltered Raw Logos**: Rendering original multi-colored SVG logos next to each other, creating a messy mismatched visual strip.
-2. **Missing Grayscale / Opacity**: Displaying bright saturated company logos that steal attention away from the hero CTA.
-
----
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Active reviewers: `frontend-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 all logos converted to monochromatic `currentColor` or uniform grayscale?
-✅ Are logo heights normalized optically (`max-height: 28px - 32px`)?
-✅ Is generous gap spacing (`2.5rem` - `4rem`) provided between brand marks?
+✅ 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/config-validator/SKILL.md

@@ -2,8 +2,8 @@
 name: config-validator
 description: Configuration validation and workspace self-auditing mastery. Verifying .agent directory integrity, checking JSON schemas, resolving broken pointers to missing scripts/skills, validating environment states, and enforcing configuration constraints before execution. Use when loading settings, modifying manifests, or diagnosing system configuration rot.
 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:
   - lint-and-validate
   - backend-security-expert
@@ -25,6 +25,12 @@ Before parsing or mutating configuration files or environment variables, you MUS
 2. Referential Integrity Audit (Section 60) → Audit referenced assets (scripts, SKILL.md, workflow paths) for physical existence before execution
 3. Atomic File Writes (Section 111) → Write updated configs to `.tmp` files and perform OS atomic rename to prevent file corruption during crashes
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Configuration validation and workspace self-auditing mastery. Verifying .agent directory integrity, checking JSON schemas, resolving broken pointers to missing scripts/skills, validating environment states, and enforcing configuration constraints before execution. Use when loading settings, modifying manifests, or diagnosing system configuration rot..
+- **DO NOT activate when:** The task falls strictly outside config-validator domain or belongs to a different dedicated specialist.
+
 ## Hallucination Traps (Read First)
 
 - ❌ Silently using default values for missing config -> ✅ Fail fast with a clear error message naming the missing field
@@ -33,8 +39,6 @@ Before parsing or mutating configuration files or environment variables, you MUS
 
 ---
 
-# Config Validator — System Integrity Mastery
-
 ---
 
 ## 1. Fail Fast, Fail Loudly
@@ -144,69 +148,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?
@@ -215,8 +167,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/containerization-pro/SKILL.md

@@ -2,8 +2,8 @@
 name: containerization-pro
 description: Production-grade containerization mastery. Multi-stage Dockerfiles for Node.js/Python/Rust/Go, image hardening (non-root, distroless, read-only FS), BuildKit layer caching, multi-platform builds (docker buildx), Docker Compose for local dev, container security scanning (Trivy/Grype), and AWS ECR workflows. Use when containerizing applications, optimizing Docker builds, or setting up container registries.
 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:
   - devops-engineer
   - cicd-pro
@@ -25,6 +25,12 @@ Before writing Dockerfiles or containerizing applications, you MUST inspect:
 2. Non-Root Security User (Section 81) → Create and switch to a dedicated non-root user (`USER appuser`) in the final runtime stage
 3. Deterministic Dependency Installation (Section 19) → Use `npm ci --omit=dev` (or language lockfile equivalent); ban un-pinned `npm install`
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Production-grade containerization mastery. Multi-stage Dockerfiles for Node.js/Python/Rust/Go, image hardening (non-root, distroless, read-only FS), BuildKit layer caching, multi-platform builds (docker buildx), Docker Compose for local dev, container security scanning (Trivy/Grype), and AWS ECR workflows. Use when containerizing applications, optimizing Docker builds, or setting up container registries..
+- **DO NOT activate when:** The task falls strictly outside containerization-pro domain or belongs to a different dedicated specialist.
+
 ## Hallucination Traps (Read First)
 
 - ❌ `FROM node:22` → ✅ `FROM node:22-alpine` (1GB+ vs ~150MB). Always use slim/alpine variants.
@@ -36,8 +42,6 @@ Before writing Dockerfiles or containerizing applications, you MUST inspect:
 
 ---
 
-# Containerization Pro — Production-Grade Docker Mastery
-
 ## 1. The .dockerignore (Write This First)
 
 ```
@@ -429,36 +433,25 @@ jobs:
 
 ---
 
-## 🤖 LLM-Specific Traps
-
-1. **`FROM node:latest`**: Never use `latest` tag in production Dockerfiles. Tags are mutable. Pin to a specific version (`node:22.3.0-alpine`).
-2. **Missing HEALTHCHECK**: Orchestrators (ECS, Kubernetes) use HEALTHCHECK to know when a container is ready. Without it, traffic is sent before the app is ready.
-3. **Secrets as build args**: `ARG SECRET_KEY` bakes secrets into the image history. Use `--secret` flag with BuildKit or runtime environment variables.
-4. **`docker-compose up` in production**: Docker Compose is for development. Use ECS, Kubernetes, or similar for production.
-5. **Wrong COPY source path**: `COPY --from=builder` paths are relative to the builder WORKDIR. Always verify the exact output path.
-
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
+## 🏛️ Tribunal Verification & Guardrails
 
 **Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor` · `devops-engineer`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
-### ✅ Pre-Flight Self-Audit
+### ❌ 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
 ```
-✅ Does the Dockerfile use a non-root user?
-✅ Is there a .dockerignore file?
-✅ Is the final stage minimal (alpine/distroless, no build tools)?
-✅ Are secrets passed as runtime env vars, not build args?
-✅ Is there a HEALTHCHECK instruction?
-✅ Are image tags pinned (not :latest)?
-✅ Is multi-stage build used for compiled/built artifacts?
+✅ 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 Dockerfile correct because it "looks valid."
-- ✅ **Required**: Run `docker build .` successfully AND `docker run` the image to verify the health endpoint responds before declaring complete.
+- ❌ **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/context-engineering-pro/SKILL.md

@@ -2,8 +2,8 @@
 name: context-engineering-pro
 description: Production-grade context window engineering, RAG chunking, system prompt sandboxing, and token budget management for 2026-2027 AI applications.
 tools: Read, Grep, Glob, Edit, Write
-version: 3.0.0
-last-updated: 2026-08-05
+version: 4.0.0
+last-updated: 2026-09-07
 script: .agent/scripts/prompt_compiler.js
 scripts-binding:
   - .agent/scripts/prompt_compiler.js
@@ -24,6 +24,12 @@ Before engineering prompts, RAG chunking, or context brokers:
 2. System Prompt Isolation → Ensure user context is enclosed within explicit XML delimiters (`<user_provided_context>`)
 3. Verification-Before-Completion → Test prompt outputs against zero-token compilers (`prompt_compiler.js`)
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Production-grade context window engineering, RAG chunking, system prompt sandboxing, and token budget management for 2026-2027 AI applications..
+- **DO NOT activate when:** The task falls strictly outside context-engineering-pro domain or belongs to a different dedicated specialist.
+
 ## Core Context Engineering Architecture
 
 ### 1. XML Delimiter Sandboxing (OWASP Injection Defense)
@@ -64,7 +70,27 @@ constraints:
 output_format: json_only
 ```
 
-## 🛑 Verification-Before-Completion (VBC) Protocol
+---
+
+## 🏛️ 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?
+```
 
-- Verify system prompts pass OWASP LLM Top 10 prompt injection tests.
-- Measure context density and token savings before finalizing prompt templates.
+### 🛑 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/create-design-md/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: create-design-md
 description: Create or update a DESIGN.md from an existing product repository or public website, with evidence-based design tokens and guidance. Use when asked to document an interface's design language, reconstruct its visual system, extract design tokens, or give coding agents persistent UI context.
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - baseline-ui
   - better-ui
@@ -27,6 +27,12 @@ Before extracting design tokens or authoring `DESIGN.md`, you MUST inspect:
 
 Generate or update an authoritative `DESIGN.md` file for a product repository or website by extracting verified design tokens, components, and layout guidance.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Create or update a DESIGN.md from an existing product repository or public website, with evidence-based design tokens and guidance. Use when asked to document an interface's design language, reconstruct its visual system, extract design tokens, or give coding agents persistent UI context..
+- **DO NOT activate when:** The task falls strictly outside create-design-md domain or belongs to a different dedicated specialist.
+
 ---
 
 ## 1. Operating Modes
@@ -99,23 +105,25 @@ Output must strictly adhere to the following schema structure:
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🏛️ Tribunal Verification & Guardrails
 
-1. **Modifying Product Source**: Changing source files during design document generation. `create-design-md` is strictly read-only on product code.
-2. **Inventing Token Names**: Creating fake token names not present in the codebase.
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
+### ❌ 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 base all documented tokens on verified codebase or computed style evidence?
-✅ Is the generated DESIGN.md saved at the root of the target project?
-✅ Does the document follow the standardized 5-section schema contract?
+✅ 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
-
-Validate `DESIGN.md` against existing CSS variables to ensure zero token mismatches.
+**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.