tribunal-kit 3.0.0 → 4.0.0

package/.agent/skills/devops-incident-responder/SKILL.md

@@ -1,113 +1,87 @@
----
-name: devops-incident-responder
-description: Production incident response mastery. MTTR (Mean Time to Recovery) reduction, blameless post-mortems, rapid triaging, halting systemic cascading failures, isolating problematic deployments, and evidence-based forensic analysis. Use when stabilizing broken systems, fighting active production fires, or conducting root-cause post-mortems.
-allowed-tools: Read, Write, Edit, Glob, Grep
-version: 2.0.0
-last-updated: 2026-04-02
-applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
----
-
-# Incident Responder — Production Stabilization Mastery
-
-> Time is blood. The goal of an incident response is Mitigation first, Resolution second.
-> DO NOT investigate the root cause while the building is burning. Put out the fire (Rollback), then investigate the ashes.
-
----
-
-## 1. The Prime Directive (Stop the Bleeding)
-
-When an outage is declared (e.g., 502 Bad Gateway across the entire primary cluster), do not ask the developer to check the database logs to figure out why the code crashed.
-
-**Immediate Action Pipeline:**
-1. **Identify the Trigger:** What changed in the last 15 minutes? (90% of outages are caused by deployments).
-2. **Revert the Change:** Execute the emergency rollback pipeline instantly. Revert the Git commit, swap the Docker tag, or disable the Feature Flag.
-3. **Verify Stabilization:** Ensure metrics return to healthy thresholds.
-4. **Communicate:** "Mitigation complete. Services restored. Root cause investigation underway."
-
----
-
-## 2. Isolating Cascading Failures
-
-A cascading failure occurs when Service A dies, causing Service B to overload with retries, which kills Service B, which kills the database.
-
-**The Circuit Breaker Protocol:**
-If a downstream dependency is dead, sever it immediately to save the rest of the ecosystem.
-
-```javascript
-// ❌ VULNERABLE: Infinite Retry Death Spiral
-async function fetchUser(id) {
-  while(true) {
-    try { return await api.get(`/user/${id}`); }
-    catch { await sleep(100); } // Hundreds of containers doing this will execute a DDoSing attack on the API
-  }
-}
-
-// ✅ RESILIENT: Circuit Breaking / Fallbacks
-const breaker = new CircuitBreaker(fetchUser, {
-  errorThresholdPercentage: 50, // If 50% of requests fail...
-  resetTimeout: 30000           // Open the circuit (stop sending requests) for 30s
-});
-
-breaker.fallback(() => ({ id: "cached-user", status: "degraded" }));
-```
-
-**Heavy Mitigation Tactics:**
-- **Shed Load:** Aggressively drop non-critical traffic (e.g., disable background syncs, temporarily ban aggressive scraping IPs).
-- **Scale Out (Band-Aid):** If the memory leak is crashing nodes every 10 minutes, scale the nodes up 3x to buy yourself 30 minutes of runway to find the actual bug.
-
----
-
-## 3. The Investigative Triage Routine
-
-Once the bleeding is stopped (or if you are investigating a non-fatal anomaly), follow the data strictly:
-
-1. **Metrics (The "What"):** Look at the Dashboards. Did latency spike? Did CPU pin at 100%? Did Database active connections max out?
-2. **Traces (The "Where"):** Look at OpenTelemetry/Datadog traces. Which specific microservice is the bottleneck?
-3. **Logs (The "Why"):** Query the centralized logs (Splunk/Elastic/CloudWatch) exactly around the timestamp the trace spiked.
-
----
-
-## 4. The Blameless Post-Mortem
-
-Incident response does not end when the system recovers. It ends when the system is architected to survive the same failure tomorrow automatically.
-
-**A Professional Post-Mortem Must Include:**
-1. **The Timeline:** Chronological factual representation of the event to the minute.
-2. **Root Cause Analysis (The 5 Whys):**
-   - *Why did the site go down?* DB exhausted connections.
-   - *Why did it exhaust?* The new background worker didn't pool connections.
-   - *Why did the worker deploy?* It bypassed CI tests for speed.
-3. **Action Items:** Tangible Jira tickets preventing recurrence (e.g., "Implement PgBouncer connection limits", "Enforce CI checks block on all branches").
-
----
-
-## 🤖 LLM-Specific Traps (Incident Response)
-
-1. **Investigating the Fire:** Identifying a crash and immediately demanding the user rewrite the deeply nested API logic while the site remains completely offline to customers. Always prescribe an instant Rollback first.
-2. **Shotgun Reboots:** Telling the user to just restart all the servers blindly. This destroys all volatile memory evidence (Heap Dumps, core dumps) required to actually solve the root cause.
-3. **Restart Loops:** The AI identifies an OOM (Out Of Memory) crash and writes a bash loop to infinitely restart the system every time it crashes, actively masking the fatal memory leak from architectural review.
-4. **Ignoring Network Geometries:** Trying to debug an API failure for 20 minutes by analyzing Node.js code, while totally forgetting to check if the AWS Security Group / Firewall simply blocked the port.
-5. **Assuming Code is Flawless:** Recommending complex database re-indexing strategies because queries got slow, without recognizing that the recent Git Commit deployed an N+1 query loop. Assume recent deployments are guilty until proven innocent.
-6. **No Circuit Breakers:** Fixing a timeout bug by suggesting the user increase the global HTTP timeout from 10s to 60s, guaranteeing the entire thread pool becomes exhausted instantly during the next network fluctuation.
-7. **The Blame Game:** Writing analysis reports that focus heavily on the individual developer who pushed the bad code, rather than identifying the systemic CI/CD pipeline failure that *allowed* the bad code to merge.
-8. **Logging in Production:** Advising the user to `console.log` massive payloads to track an error in production environments, massively polluting logs and potentially leaking PII compliance data.
-9. **Tunnel Vision:** Debugging Application A intensely, failing to realize Application A failed because the underlying global Redis cache failed completely, affecting all services simultaneously. Focus on shared infrastructure metrics first.
-10. **The Unverifiable Fix:** Proposing an intricate solution and skipping the final critical step: "How will we prove this actually fixed the problem under load?". Deploy without telemetry monitoring is flying blind.
-
----
-
-## 🏛️ Tribunal Integration
-
-### ✅ Pre-Flight Self-Audit
-```
-✅ Was immediate Mitigation/Rollback explicitly ordered prior to initiating Root Cause Analysis?
-✅ Did I enforce strategies to break cascading failures (e.g., Circuit Breakers, load shedding)?
-✅ Are diagnostic analyses tracing specific metrics to explicit log anomalies?
-✅ Ensure that system reboots did not intentionally destroy critical volatile diagnostic evidence.
-✅ Have recent deployments/git-commits been flagged as the primary initial vector of suspicion?
-✅ Did I avoid masking problems by extending timeout thresholds, opting instead to fix blocking execution?
-✅ Is the incident Post-Mortem methodology completely focused on systemic flaws rather than human error?
-✅ Were cross-service infrastructure layers (DBs, Redis, Load Balancers) cleared before deep-diving into local code?
-✅ Has an action item been established verifying how future iterations of this failure will be programmatically blocked?
-✅ Are there explicit mechanisms checking for PII leakage before increasing diagnostic logging verbosity in production?
-```
+---
+name: devops-incident-responder
+description: Production incident response mastery. MTTR (Mean Time to Recovery) reduction, blameless post-mortems, rapid triaging, halting systemic cascading failures, isolating problematic deployments, and evidence-based forensic analysis. Use when stabilizing broken systems, fighting active production fires, or conducting root-cause post-mortems.
+allowed-tools: Read, Write, Edit, Glob, Grep
+version: 2.0.0
+last-updated: 2026-04-02
+applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
+---
+
+## Hallucination Traps (Read First)
+- ❌ Changing code during an active incident -> ✅ STABILIZE first (rollback, feature flag, traffic shift), investigate AFTER
+- ❌ Assigning blame in post-mortems -> ✅ Blameless post-mortems focus on systemic causes, not individual errors
+- ❌ Skipping the 'what went well' section -> ✅ Understanding what prevented worse outcomes is as valuable as the root cause
+
+---
+
+
+# Incident Responder — Production Stabilization Mastery
+
+---
+
+## 1. The Prime Directive (Stop the Bleeding)
+
+When an outage is declared (e.g., 502 Bad Gateway across the entire primary cluster), do not ask the developer to check the database logs to figure out why the code crashed.
+
+**Immediate Action Pipeline:**
+1. **Identify the Trigger:** What changed in the last 15 minutes? (90% of outages are caused by deployments).
+2. **Revert the Change:** Execute the emergency rollback pipeline instantly. Revert the Git commit, swap the Docker tag, or disable the Feature Flag.
+3. **Verify Stabilization:** Ensure metrics return to healthy thresholds.
+4. **Communicate:** "Mitigation complete. Services restored. Root cause investigation underway."
+
+---
+
+## 2. Isolating Cascading Failures
+
+A cascading failure occurs when Service A dies, causing Service B to overload with retries, which kills Service B, which kills the database.
+
+**The Circuit Breaker Protocol:**
+If a downstream dependency is dead, sever it immediately to save the rest of the ecosystem.
+
+```javascript
+// ❌ VULNERABLE: Infinite Retry Death Spiral
+async function fetchUser(id) {
+  while(true) {
+    try { return await api.get(`/user/${id}`); }
+    catch { await sleep(100); } // Hundreds of containers doing this will execute a DDoSing attack on the API
+  }
+}
+
+// ✅ RESILIENT: Circuit Breaking / Fallbacks
+const breaker = new CircuitBreaker(fetchUser, {
+  errorThresholdPercentage: 50, // If 50% of requests fail...
+  resetTimeout: 30000           // Open the circuit (stop sending requests) for 30s
+});
+
+breaker.fallback(() => ({ id: "cached-user", status: "degraded" }));
+```
+
+**Heavy Mitigation Tactics:**
+- **Shed Load:** Aggressively drop non-critical traffic (e.g., disable background syncs, temporarily ban aggressive scraping IPs).
+- **Scale Out (Band-Aid):** If the memory leak is crashing nodes every 10 minutes, scale the nodes up 3x to buy yourself 30 minutes of runway to find the actual bug.
+
+---
+
+## 3. The Investigative Triage Routine
+
+Once the bleeding is stopped (or if you are investigating a non-fatal anomaly), follow the data strictly:
+
+1. **Metrics (The "What"):** Look at the Dashboards. Did latency spike? Did CPU pin at 100%? Did Database active connections max out?
+2. **Traces (The "Where"):** Look at OpenTelemetry/Datadog traces. Which specific microservice is the bottleneck?
+3. **Logs (The "Why"):** Query the centralized logs (Splunk/Elastic/CloudWatch) exactly around the timestamp the trace spiked.
+
+---
+
+## 4. The Blameless Post-Mortem
+
+Incident response does not end when the system recovers. It ends when the system is architected to survive the same failure tomorrow automatically.
+
+**A Professional Post-Mortem Must Include:**
+1. **The Timeline:** Chronological factual representation of the event to the minute.
+2. **Root Cause Analysis (The 5 Whys):**
+   - *Why did the site go down?* DB exhausted connections.
+   - *Why did it exhaust?* The new background worker didn't pool connections.
+   - *Why did the worker deploy?* It bypassed CI tests for speed.
+3. **Action Items:** Tangible Jira tickets preventing recurrence (e.g., "Implement PgBouncer connection limits", "Enforce CI checks block on all branches").
+
+---

package/.agent/skills/doc.md

@@ -1,6 +1,6 @@
 # Antigravity Skills
 
-> **Guide to creating and using Skills in the Antigravity Kit**
+**Guide to creating and using Skills in the Antigravity Kit**
 
 ---
 
@@ -16,9 +16,9 @@ While Antigravity's base models (like Gemini) are powerful generalists, they don
 
 Skills are folder-based packages. You can define these scopes based on your needs:
 
-| Scope         | Path                              | Description                          |
-| ------------- | --------------------------------- | ------------------------------------ |
-| **Workspace** | `<workspace-root>/.agent/skills/` | Available only in a specific project |
+|Scope|Path|Description|
+|-------------|---------------------------------|------------------------------------|
+|**Workspace**|`<workspace-root>/.agent/skills/`|Available only in a specific project|
 
 ### Skill Directory Structure
 
@@ -68,7 +68,7 @@ When reviewing code, follow these steps:
 - Suggest alternatives when possible
 ```
 
-> **Note**: The `SKILL.md` file contains metadata (name, description) at the top, followed by the instructions. The agent will only read the metadata and load the full instructions only when needed.
+**Note**: The `SKILL.md` file contains metadata (name, description) at the top, followed by the instructions. The agent will only read the metadata and load the full instructions only when needed.
 
 ### Try it out
 

package/.agent/skills/documentation-templates/SKILL.md

@@ -7,22 +7,27 @@ last-updated: 2026-03-12
 applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
 ---
 
-# Documentation Standards
+## Hallucination Traps (Read First)
+- ❌ Writing documentation that only AI-generated code can understand -> ✅ Docs are for HUMANS; use clear language and real examples
+- ❌ Documenting implementation details instead of behavior -> ✅ Document WHAT it does and WHY, not HOW (code shows how)
+- ❌ Skipping the 'Quick Start' section -> ✅ The first 30 seconds of a README determine if someone uses your project
+
+---
 
-> Documentation is a product. It has users. Those users are often future-you,
-> three months from now, having completely forgotten how this works.
+
+# Documentation Standards
 
 ---
 
 ## Documentation Types and Their Audiences
 
-| Type | Audience | Goal |
+|Type|Audience|Goal|
 |---|---|---|
-| README | New developer joining the project | "Get me running in 10 minutes" |
-| API docs | External integrator or frontend dev | "Tell me exactly what I can call and what I'll get back" |
-| Architecture decision (ADR) | Future engineer inheriting the codebase | "Tell me why it works this way, not just how" |
-| Code comment | Reviewer, maintainer | "Explain the non-obvious; skip the obvious" |
-| Runbook | On-call engineer at 2am | "Tell me what to do, not what to think about" |
+|README|New developer joining the project|"Get me running in 10 minutes"|
+|API docs|External integrator or frontend dev|"Tell me exactly what I can call and what I'll get back"|
+|Architecture decision (ADR)|Future engineer inheriting the codebase|"Tell me why it works this way, not just how"|
+|Code comment|Reviewer, maintainer|"Explain the non-obvious; skip the obvious"|
+|Runbook|On-call engineer at 2am|"Tell me what to do, not what to think about"|
 
 ---
 
@@ -31,13 +36,13 @@ applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
 The Tribunal Agent Kit supports 5 standard Agent Design Kit (ADK) base patterns. 
 To build a skill using a robust, tested agent behavior model, add `pattern: [pattern-name]` to the YAML frontmatter of your `SKILL.md`.
 
-| Pattern | Value | When to use |
+|Pattern|Value|When to use|
 |---|---|---|
-| **Inversion** | `pattern: inversion` | Forces the agent to interview the user (Socratic Gate) before acting. |
-| **Reviewer** | `pattern: reviewer` | Evaluates artifacts against a checklist and severity levels. |
-| **Tool Wrapper** | `pattern: tool-wrapper` | Strictly executes external CLI tools via provided documentation without guessing. |
-| **Generator** | `pattern: generator` | Produces structured output (docs, boilerplate) by filling a rigid template. |
-| **Pipeline** | `pattern: pipeline` | Executes sequential tasks with strict halting gates between steps. |
+|**Inversion**|`pattern: inversion`|Forces the agent to interview the user (Socratic Gate) before acting.|
+|**Reviewer**|`pattern: reviewer`|Evaluates artifacts against a checklist and severity levels.|
+|**Tool Wrapper**|`pattern: tool-wrapper`|Strictly executes external CLI tools via provided documentation without guessing.|
+|**Generator**|`pattern: generator`|Produces structured output (docs, boilerplate) by filling a rigid template.|
+|**Pipeline**|`pattern: pipeline`|Executes sequential tasks with strict halting gates between steps.|
 
 *Templates defining the specific rules for these patterns live in `.agent/patterns/`.*
 
@@ -79,10 +84,10 @@ src/
 
 ## Environment Variables
 
-| Variable | Required | Description |
+|Variable|Required|Description|
 |---|---|---|
-| DATABASE_URL | Yes | PostgreSQL connection string |
-| JWT_SECRET | Yes | Secret for signing JWTs |
+|DATABASE_URL|Yes|PostgreSQL connection string|
+|JWT_SECRET|Yes|Secret for signing JWTs|
 
 ## Running Tests
 
@@ -118,11 +123,11 @@ Creates a new user account.
 
 **Responses**
 
-| Status | Meaning | Body |
+|Status|Meaning|Body|
 |---|---|---|
-| 201 | User created | `{ data: User }` |
-| 400 | Validation failed | `{ error: string, details: string[] }` |
-| 409 | Email already exists | `{ error: string }` |
+|201|User created|`{ data: User }`|
+|400|Validation failed|`{ error: string, details: string[] }`|
+|409|Email already exists|`{ error: string }`|
 
 **Example**
 \`\`\`bash
@@ -221,45 +226,4 @@ VBC status:  PENDING → VERIFIED
 Evidence:    [link to terminal output, test result, or file diff]
 ```
 
-
-
----
-
-## 🤖 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)
-
-**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?
-✅ 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.