tribunal-kit 8.0.0 → 9.0.0

package/.agent/skills/cicd-pro/SKILL.md

@@ -2,8 +2,8 @@
 name: cicd-pro
 description: Enterprise-grade CI/CD mastery. Golden Path - GitHub Actions + Docker + AWS ECS. 3-stage pipeline architecture (Validate→Build→Deploy), OIDC-based AWS auth (no static secrets), Blue/Green and Canary deployment with ECS, environment promotion gates (dev→staging→production), rollback playbooks, Slack notifications, and reusable workflow patterns. Use when designing or implementing production CI/CD pipelines.
 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:
   - containerization-pro
   - cloud-architect
@@ -25,6 +25,12 @@ Before designing CI/CD workflows or deployment scripts, you MUST inspect:
 2. OIDC Authentication Protocol (Section 20) → Use OIDC (`id-token: write` permission) for AWS/cloud credentials; ban static access keys in secrets
 3. Production Promotion Gates (Section 21) → Enforce environment promotion gates (`staging` → `production` with manual reviewers) before deploying
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Enterprise-grade CI/CD mastery. Golden Path - GitHub Actions + Docker + AWS ECS. 3-stage pipeline architecture (Validate→Build→Deploy), OIDC-based AWS auth (no static secrets), Blue/Green and Canary deployment with ECS, environment promotion gates (dev→staging→production), rollback playbooks, Slack notifications, and reusable workflow patterns. Use when designing or implementing production CI/CD pipelines..
+- **DO NOT activate when:** The task falls strictly outside cicd-pro domain or belongs to a different dedicated specialist.
+
 ## Hallucination Traps (Read First)
 
 - ❌ Missing `concurrency:` block → ✅ Without it, parallel deploys collide and corrupt production state
@@ -36,8 +42,6 @@ Before designing CI/CD workflows or deployment scripts, you MUST inspect:
 
 ---
 
-# CI/CD Pro — Enterprise Pipeline Mastery
-
 ## 1. The 3-Stage Pipeline Model
 
 ```
@@ -419,36 +423,25 @@ resource "github_repository_environment" "production" {
 
 ---
 
-## 🤖 LLM-Specific Traps
-
-1. **No `concurrency:` block**: Without it, two deploys can run simultaneously, causing task definition conflicts in ECS and corrupted deployments.
-2. **Deploying without a stability wait**: `wait-for-service-stability: true` is critical. Without it, the pipeline reports success while ECS is still starting containers.
-3. **Hardcoded task definition revisions**: Never hardcode `:1` or `:latest` in ECS deploy steps. Always fetch the current revision dynamically with `describe-task-definition`.
-4. **Missing Slack failure notification**: Success notifications alone create false security. Always add `if: failure()` Slack step.
-5. **Using `needs.job.result` incorrectly**: `needs.build.outputs.image` only works if `build` job has `outputs:` defined. Verify the output name matches exactly.
-
----
-
-## 🏛️ 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 workflow have a concurrency: block?
-✅ Is AWS auth using OIDC (id-token: write permission)?
-✅ Does staging gate exist before production?
-✅ Is production environment configured with required reviewers?
-✅ Is there a rollback strategy documented and tested?
-✅ Does the Slack notification cover BOTH success AND failure cases?
-✅ Is wait-for-service-stability: true set on the ECS deploy step?
+✅ 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 pipeline correct because the YAML is syntactically valid.
-- ✅ **Required**: A real GitHub Actions run must succeed (green checkmarks across all stages) before the pipeline is declared production-ready.
+- ❌ **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/clarify/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: clarify
 description: Improve UX microcopy, label optimization, error messages, and cognitive clarity. Use when text in a UI is confusing, wordy, ambiguous, or unhelpful.
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - distill
   - shape
@@ -27,6 +27,12 @@ Before optimizing UI text or error messages, you MUST inspect:
 
 Optimize user interface text, button labels, error messaging, and helper copy for maximum clarity and minimum cognitive friction.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Improve UX microcopy, label optimization, error messages, and cognitive clarity. Use when text in a UI is confusing, wordy, ambiguous, or unhelpful..
+- **DO NOT activate when:** The task falls strictly outside clarify domain or belongs to a different dedicated specialist.
+
 ---
 
 ## 4 UX Copy Rules
@@ -62,28 +68,25 @@ Optimize user interface text, button labels, error messaging, and helper copy fo
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🏛️ Tribunal Verification & Guardrails
 
-1. **Generic OK/Cancel Modals**: Writing modal dialogs with generic "OK" buttons that obscure the action consequence.
-2. **Snarky or Overly Clever Copy**: Using cute or humorous error messages when users are frustrated by a failure.
-
----
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Active reviewers: `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 every button start with an explicit action verb?
-✅ Do error messages clearly instruct the user how to resolve the issue?
-✅ Is passive corporate jargon completely eliminated?
+✅ 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/clean-code/SKILL.md

@@ -2,8 +2,8 @@
 name: clean-code
 description: Clean code mastery. Naming conventions, function design, DRY vs WET, SOLID principles with code examples, refactoring patterns, code smells detection, error handling philosophy, comments that add value, and the art of simplicity. Use when reviewing code quality, refactoring, or establishing coding standards.
 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:
   - codebase-design
   - code-review-checklist
@@ -24,16 +24,27 @@ Before refactoring code or evaluating clean code standards, you MUST inspect:
 1. Intent-Revealing Naming (Section 25) → Name variables/functions to reveal explicit intent; ban cryptic abbreviations (`d`, `proc`, `u`)
 2. Single-Purpose Functions (Section 95) → Ensure functions perform 1 single task; extract sub-operations if function exceeds ~30 lines
 3. Guard Clause Early Returns (Section 344) → Flatten nested logic (>3 levels) using guard clauses and fail-fast early returns
+4. Algorithmic Complexity & Lookups → Prefer `Set` / `Map` for O(1) membership lookups instead of repeated O(N) array scans
+
+## Activation Boundaries
+
+- **Activate when:** Refactoring existing codebases, establishing code quality standards, designing function boundaries, eliminating code smells, and writing logic-bearing business modules.
+- **DO NOT activate when:** Writing quick disposable test fixtures, raw low-level binary protocol buffers, or machine-generated artifacts where human maintainability is not an invariant.
+
+## 2026 Code Performance & Logic Invariants
+
+1. **Fail-Fast Early Returns**: Flatten nested conditionals (`if ... else if ... else`). Return or throw immediately on validation failure.
+2. **O(1) Data Structures**: Replace repeated `array.find()` or `array.includes()` in loops with `Set.has()` or `Map.get()`.
+3. **Cyclomatic Complexity Cap**: No single function may exceed cyclomatic complexity > 10. Split multi-branch operations into dedicated strategy handlers.
+4. **Pure Core, Imperative Shell**: Keep business calculations pure and deterministic; push network I/O, file access, and mutation to the boundaries.
+5. **Typed Error Hierarchy**: Never throw raw strings or generic `Error`. Throw domain-specific error classes containing structured metadata (`code`, `retryable`, `context`).
 
 ## Hallucination Traps (Read First)
 
 - ❌ Over-abstracting code that is used in only one place -> ✅ Don't DRY single-use code; premature abstraction is worse than duplication
 - ❌ Adding comments that restate what the code does -> ✅ Comments explain WHY, not WHAT; the code explains what
 - ❌ Creating utility functions for trivial one-liners -> ✅ Inline is clearer when the operation is self-documenting
-
----
-
-# Clean Code — The Art of Readable Software
+- ❌ Using `array.find()` inside an `array.filter()` loop (O(N²)) -> ✅ Index into a `Map` first (O(N))
 
 ---
 
@@ -379,69 +390,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?
@@ -450,8 +409,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/cloud-architect/SKILL.md

@@ -2,8 +2,8 @@
 name: cloud-architect
 description: Production AWS cloud architecture mastery. Service selection (ECS Fargate vs Lambda vs EC2, RDS vs Aurora vs DynamoDB), Terraform IaC patterns with HCL examples, VPC networking design, IAM least privilege, Secrets Manager, CloudWatch observability, cost optimization, and multi-environment AWS Organizations strategy. Golden Path - AWS. Use when architecting cloud infrastructure, writing Terraform, or making AWS service selection decisions.
 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:
   - cicd-pro
   - devops-engineer
@@ -25,6 +25,12 @@ Before architecting AWS cloud infrastructure or writing Terraform HCL, you MUST
 2. Private Subnet Application Placement (Section 23) → Place application compute (ECS, Lambda) strictly in private subnets; only ALB and NAT Gateway live in public subnets
 3. Secrets Manager Secret Injection (Section 21) → Reference secret ARNs from AWS Secrets Manager in ECS task definitions; ban plaintext environment variables for passwords/tokens
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Production AWS cloud architecture mastery. Service selection (ECS Fargate vs Lambda vs EC2, RDS vs Aurora vs DynamoDB), Terraform IaC patterns with HCL examples, VPC networking design, IAM least privilege, Secrets Manager, CloudWatch observability, cost optimization, and multi-environment AWS Organizations strategy. Golden Path - AWS. Use when architecting cloud infrastructure, writing Terraform, or making AWS service selection decisions..
+- **DO NOT activate when:** The task falls strictly outside cloud-architect domain or belongs to a different dedicated specialist.
+
 ## Hallucination Traps (Read First)
 
 - ❌ Confusing availability zones with regions → ✅ `us-east-1` is a region. `us-east-1a` is an AZ within that region. Multi-AZ ≠ multi-region.
@@ -36,8 +42,6 @@ Before architecting AWS cloud infrastructure or writing Terraform HCL, you MUST
 
 ---
 
-# Cloud Architect — Production AWS Mastery
-
 ## 1. Service Selection Matrix
 
 ### Compute
@@ -416,36 +420,25 @@ terraform {
 
 ---
 
-## 🤖 LLM-Specific Traps
-
-1. **Omitting `data.aws_caller_identity.current.account_id`**: Never hardcode AWS account IDs in Terraform. Use the data source.
-2. **Lambda for database-heavy operations**: Lambda's ephemeral compute model means each invocation opens a new DB connection. Use RDS Proxy for Lambda → RDS patterns.
-3. **Ignoring NAT Gateway costs**: NAT Gateways cost ~$32/month + $0.045/GB. For staging, a single NAT Gateway is fine. For production, one per AZ for HA.
-4. **Security groups as firewalls**: Security groups are stateful. NACLs are stateless. Never use NACLs as your primary defense layer — security groups are the right tool.
-5. **Missing `lifecycle { ignore_changes }` on ECS services**: Without this, Terraform fights with your CI/CD pipeline over the running task definition revision.
-
----
-
-## 🏛️ Tribunal Integration (Anti-Hallucination)
+## 🏛️ Tribunal Verification & Guardrails
 
 **Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor` · `cloud-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
 ```
-✅ Are all secrets stored in Secrets Manager (not plaintext env vars)?
-✅ Are application servers in private subnets?
-✅ Are IAM policies scoped to specific resources (no wildcard Resource: "*")?
-✅ Is Terraform state stored in S3 with DynamoDB locking?
-✅ Are CloudWatch alarms defined for error rates AND latency?
-✅ Is auto-rollback configured on the ECS service circuit breaker?
-✅ Are hardcoded account IDs / region strings replaced with data sources?
+✅ 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 Terraform configuration correct because it "looks right."
-- ✅ **Required**: Run `terraform plan` with zero unexpected changes AND `terraform apply` successfully completes before marking infrastructure work as done.
+- ❌ **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/cobejs/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: cobejs
 description: Build lightweight, hardware-accelerated 3D interactive animated globes and web orbs using Cobe WebGL.
-version: 3.0.0
-last-updated: 2026-07-30
+version: 4.0.0
+last-updated: 2026-09-07
 skills:
   - 60fps-animation
   - motion-engineering
@@ -27,6 +27,12 @@ Before building WebGL 3D globe components with Cobe, you MUST inspect:
 
 Integrate ultra-fast, 5KB WebGL interactive globes for landing page hero sections and interactive location maps.
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Build lightweight, hardware-accelerated 3D interactive animated globes and web orbs using Cobe WebGL..
+- **DO NOT activate when:** The task falls strictly outside cobejs domain or belongs to a different dedicated specialist.
+
 ---
 
 ## Cobe Canvas Setup Recipe (React)
@@ -77,27 +83,25 @@ export function InteractiveGlobe() {
 
 ---
 
-## 🤖 LLM-Specific Traps
+## 🏛️ Tribunal Verification & Guardrails
 
-1. **Forgetting Canvas Destroy Cleanup**: Failing to call `globe.destroy()` on component unmount, causing WebGL context leaks.
-2. **Missing `aspectRatio: 1`**: Failing to constrain aspect ratio, causing globe canvas stretching.
-
----
+**Slash command: `/review` or `/tribunal-full`**
+**Active reviewers: `logic-reviewer` · `security-auditor`**
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
-
-**Active reviewers: `frontend-reviewer` · `performance-optimizer`**
+### ❌ 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
-
 ```
-✅ Is `globe.destroy()` invoked in the unmount cleanup function?
-✅ Is `devicePixelRatio` set to match high-DPI screens without GPU slowdown?
+✅ 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/code-review-checklist/SKILL.md

@@ -2,8 +2,8 @@
 name: code-review-checklist
 description: Code review guidelines covering code quality, security, and best practices.
 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
   - lint-and-validate
@@ -25,7 +25,11 @@ Before performing code reviews or writing PR comments, you MUST inspect:
 2. Context Window Discipline (Section 120) → Quote concise 1-3 line snippets with line numbers; ban pasting massive blocks of unchanged code
 3. Anti-Nitpicking Rule (Section 130) → Delegate syntax/formatting formatting checks to linters (`eslint`/Prettier); focus reviews on logic and security
 
-# Code Review Standards
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Code review guidelines covering code quality, security, and best practices..
+- **DO NOT activate when:** The task falls strictly outside code-review-checklist domain or belongs to a different dedicated specialist.
 
 ---
 
@@ -182,69 +186,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?
@@ -253,8 +205,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/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.