tribunal-kit 7.0.0 → 9.0.0

package/.agent/skills/building-native-ui/SKILL.md

@@ -2,8 +2,8 @@
 name: building-native-ui
 description: Cross-platform Native UI mastery (React Native / Expo). Building seamless, 60fps mobile interfaces, handling safe areas, navigation architectures (Expo Router), native modules, gestures/animations (Reanimated), and platform-specific styling. Use when building React Native or Expo mobile apps.
 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:
   - mobile-design
   - react-specialist
@@ -25,6 +25,12 @@ Before building React Native / Expo UI components, you MUST inspect:
 2. Virtualized List Rendering (Section 130) → Use `FlashList` (Shopify) or `FlatList` with `estimatedItemSize` instead of `ScrollView` for large lists
 3. Native Thread Animations (Section 99) → Use `react-native-reanimated` with `useSharedValue` to keep animations off the JS bridge thread
 
+
+## Activation Boundaries
+
+- **Activate when:** Operating in tasks requiring Cross-platform Native UI mastery (React Native / Expo). Building seamless, 60fps mobile interfaces, handling safe areas, navigation architectures (Expo Router), native modules, gestures/animations (Reanimated), and platform-specific styling. Use when building React Native or Expo mobile apps..
+- **DO NOT activate when:** The task falls strictly outside building-native-ui domain or belongs to a different dedicated specialist.
+
 ## Hallucination Traps (Read First)
 
 - ❌ `SafeAreaView` wrapping everything -> ✅ Use `SafeAreaProvider` + `useSafeAreaInsets()` for granular control
@@ -34,8 +40,6 @@ Before building React Native / Expo UI components, you MUST inspect:
 
 ---
 
-# Building Native UI — React Native & Expo Mastery
-
 A mobile app isn't a website confined to a small screen.
 60 FPS is not a goal; it is a rigid requirement. The JS thread is a fragile bottleneck.
 
@@ -181,69 +185,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?
@@ -252,8 +204,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/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.