tribunal-kit 3.0.0 → 3.1.0

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

@@ -27,18 +27,18 @@ You are a specialized agent for analyzing and optimizing the efficiency of AI ag
 
 Examine a sequence of tool calls and classify each into:
 
-| Pattern | Description | Waste Level | Fix |
+|Pattern|Description|Waste Level|Fix|
 |---|---|---|---|
-| **Redundant Read** | File read multiple times without changes | 🔴 High | Cache the content; read once |
-| **Blind Search** | `grep_search` or `find_by_name` when path was known | 🟡 Medium | Use `view_file` directly |
-| **Serial Bottleneck** | Independent calls made sequentially | 🔴 High | Parallelize with concurrent calls |
-| **Ping-Pong Edit** | Multiple `replace_file_content` on same file | 🟡 Medium | Combine into `multi_replace_file_content` |
-| **Over-Read** | `view_file` full file when only one function needed | 🟡 Medium | Use `view_code_item` or line ranges |
-| **Unnecessary Outline** | `view_file_outline` on a file already fully read | 🟢 Low | Skip — content already in context |
-| **Search Then Read** | `grep_search` → `view_file` → `view_code_item` | 🟡 Medium | Skip directly to relevant tool |
-| **Repeated Status** | Multiple `command_status` calls before completion | 🟢 Low | Use `WaitDurationSeconds` parameter |
-| **Task Churn** | `task_boundary` called every single tool call | 🟡 Medium | Update every 3-5 tool calls |
-| **Context Dump** | Reading entire large files into context | 🔴 High | Targeted reads with line ranges |
+|**Redundant Read**|File read multiple times without changes|🔴 High|Cache the content; read once|
+|**Blind Search**|`grep_search` or `find_by_name` when path was known|🟡 Medium|Use `view_file` directly|
+|**Serial Bottleneck**|Independent calls made sequentially|🔴 High|Parallelize with concurrent calls|
+|**Ping-Pong Edit**|Multiple `replace_file_content` on same file|🟡 Medium|Combine into `multi_replace_file_content`|
+|**Over-Read**|`view_file` full file when only one function needed|🟡 Medium|Use `view_code_item` or line ranges|
+|**Unnecessary Outline**|`view_file_outline` on a file already fully read|🟢 Low|Skip — content already in context|
+|**Search Then Read**|`grep_search` → `view_file` → `view_code_item`|🟡 Medium|Skip directly to relevant tool|
+|**Repeated Status**|Multiple `command_status` calls before completion|🟢 Low|Use `WaitDurationSeconds` parameter|
+|**Task Churn**|`task_boundary` called every single tool call|🟡 Medium|Update every 3-5 tool calls|
+|**Context Dump**|Reading entire large files into context|🔴 High|Targeted reads with line ranges|
 
 ### 2. Parallelism Opportunity Detection
 
@@ -65,34 +65,34 @@ Identify tool calls that have no data dependencies and should run simultaneously
 
 Evaluate `task.md` and `task_boundary` usage:
 
-| Issue | Symptom | Fix |
+|Issue|Symptom|Fix|
 |---|---|---|
-| **Too Granular** | One `task_boundary` per tool call | Group into logical phases (3-8 calls per task) |
-| **Too Broad** | One task for entire request | Break into Planning → Execution → Verification |
-| **Stale Summary** | `TaskSummary` repeating same text | Accumulate new info each update |
-| **Backward Status** | `TaskStatus` describes what was *done* | Must describe what *will happen next* |
-| **Missing Mode** | Never switches between PLANNING/EXECUTION/VERIFICATION | Use mode transitions to signal phase changes |
+|**Too Granular**|One `task_boundary` per tool call|Group into logical phases (3-8 calls per task)|
+|**Too Broad**|One task for entire request|Break into Planning → Execution → Verification|
+|**Stale Summary**|`TaskSummary` repeating same text|Accumulate new info each update|
+|**Backward Status**|`TaskStatus` describes what was *done*|Must describe what *will happen next*|
+|**Missing Mode**|Never switches between PLANNING/EXECUTION/VERIFICATION|Use mode transitions to signal phase changes|
 
 ### 4. Context Window Budget Analysis
 
-| Metric | Target | Action if Exceeded |
+|Metric|Target|Action if Exceeded|
 |---|---|---|
-| Total lines read | < 500 per task phase | Filter to relevant sections |
-| Files in context | < 10 simultaneously | Prioritize; drop stale reads |
-| Search results | < 20 matches | Narrow filters (`Includes`, `Pattern`) |
-| File reads per file | 1 per phase | Cache mentally; don't re-read |
-| Artifact updates | < 5 per task | Batch updates |
+|Total lines read|< 500 per task phase|Filter to relevant sections|
+|Files in context|< 10 simultaneously|Prioritize; drop stale reads|
+|Search results|< 20 matches|Narrow filters (`Includes`, `Pattern`)|
+|File reads per file|1 per phase|Cache mentally; don't re-read|
+|Artifact updates|< 5 per task|Batch updates|
 
 ### 5. Error Recovery Efficiency
 
 Analyze how errors are handled:
 
-| Pattern | Efficiency | Better Approach |
+|Pattern|Efficiency|Better Approach|
 |---|---|---|
-| Retry same command identically | 🔴 Wasted | Analyze error first, modify approach |
-| Read error → re-read entire file | 🟡 Inefficient | Read only the relevant section |
-| Tool error → ask user | 🟡 Premature | Try alternative approach first |
-| Build error → fix one issue → rebuild | 🟢 OK if targeted | Batch multiple fixes before rebuild |
+|Retry same command identically|🔴 Wasted|Analyze error first, modify approach|
+|Read error → re-read entire file|🟡 Inefficient|Read only the relevant section|
+|Tool error → ask user|🟡 Premature|Try alternative approach first|
+|Build error → fix one issue → rebuild|🟢 OK if targeted|Batch multiple fixes before rebuild|
 
 ## Optimization Metrics
 
@@ -176,44 +176,4 @@ Before analyzing, check for these common quick wins:
 - **Never fabricate efficiency scores** — always calculate from actual vs optimal counts.
 - **Acknowledge uncertainty**: "Cannot determine if calls 3-5 had data dependency — may be correctly sequential."
 
-
----
-
-## 🤖 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.

package/.agent/workflows/api-tester.md

@@ -1,151 +1,151 @@
----
-description: Automated multi-stage API endpoint testing. Generates and runs auth-aware request sequences (login → use token → test CRUD → verify errors). Reports response codes, schema mismatches, and unexpected data.
----
-
-# /api-tester — Automated API Testing
-
-$ARGUMENTS
-
----
-
-## When to Use /api-tester
-
-| Use `/api-tester` when... | Use something else when... |
-|:---|:---|
-| Testing REST API endpoints manually | Unit tests needed → `/test` |
-| Verifying auth token flows end-to-end | Full security audit → `/audit` |
-| After generating new endpoints | Load testing → `/performance-benchmarker` |
-| Checking response schemas | |
-
----
-
-## Phase 1 — Endpoint Discovery
-
-```bash
-# Find all defined routes
-grep -r "app.get\|app.post\|app.put\|app.delete\|app.patch" src/ --include="*.ts"
-grep -r "router.get\|router.post\|router.put" src/ --include="*.ts"
-
-# Next.js Route Handlers
-find src/app/api -name "route.ts" | sort
-```
-
----
-
-## Phase 2 — Auth Flow (Token Acquisition)
-
-Before testing protected endpoints, acquire auth token:
-
-```bash
-# Acquire JWT
-curl -X POST http://localhost:3000/api/auth/login \
-  -H "Content-Type: application/json" \
-  -d '{"email":"test@example.com","password":"testpassword"}' \
-  -s | jq '.token'
-
-# Assign to variable
-TOKEN=$(curl -X POST http://localhost:3000/api/auth/login \
-  -H "Content-Type: application/json" \
-  -d '{"email":"test@example.com","password":"testpassword"}' \
-  -s | jq -r '.token')
-```
-
----
-
-## Phase 3 — CRUD Sequence Testing
-
-Test endpoints in the correct order (create before read, read before delete):
-
-```bash
-# 1. CREATE (POST)
-CREATE_RESPONSE=$(curl -X POST http://localhost:3000/api/users \
-  -H "Authorization: Bearer $TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{"name":"Test User","email":"new@test.com"}')
-CREATED_ID=$(echo $CREATE_RESPONSE | jq -r '.id')
-echo "Created: $CREATED_ID"
-
-# 2. READ (GET)
-curl -X GET "http://localhost:3000/api/users/$CREATED_ID" \
-  -H "Authorization: Bearer $TOKEN" \
-  | jq .
-
-# 3. UPDATE (PATCH)
-curl -X PATCH "http://localhost:3000/api/users/$CREATED_ID" \
-  -H "Authorization: Bearer $TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{"name":"Updated Name"}'
-
-# 4. DELETE
-curl -X DELETE "http://localhost:3000/api/users/$CREATED_ID" \
-  -H "Authorization: Bearer $TOKEN"
-```
-
----
-
-## Phase 4 — Error Case Testing
-
-Test that errors are handled correctly:
-
-```bash
-# 4xx errors (client errors — must NOT return 200!)
-echo "--- Unauthenticated request (expect 401) ---"
-curl -X GET http://localhost:3000/api/users -s -o /dev/null -w "%{http_code}\n"
-
-echo "--- Invalid ID (expect 404 or 400) ---"
-curl -X GET "http://localhost:3000/api/users/not-a-real-id" \
-  -H "Authorization: Bearer $TOKEN" \
-  -s -o /dev/null -w "%{http_code}\n"
-
-echo "--- Invalid body (expect 400) ---"
-curl -X POST http://localhost:3000/api/users \
-  -H "Authorization: Bearer $TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{"invalid":"field"}' \
-  -s -o /dev/null -w "%{http_code}\n"
-
-echo "--- Rate limiting (expect 429 after N requests) ---"
-for i in {1..15}; do
-  STATUS=$(curl -X POST http://localhost:3000/api/auth/login \
-    -H "Content-Type: application/json" \
-    -d '{"email":"x","password":"wrong"}' \
-    -s -o /dev/null -w "%{http_code}")
-  echo "Attempt $i: $STATUS"
-done
-```
-
----
-
-## Phase 5 — Test Report
-
-```
-━━━ API Test Report ━━━━━━━━━━━━━━━━━━━━━━
-
-Auth Flow:   ✅ Login → token acquired
-POST /users: ✅ 201 Created — id returned
-GET /users:  ✅ 200 — data matches expected schema
-PATCH /users: ✅ 200 — update reflected
-DELETE /users: ✅ 204 No Content
-
-Error Cases:
-  Unauthenticated: ✅ 401 (expected)
-  Invalid ID:      ✅ 404 (expected)
-  Invalid body:    ✅ 400 (expected) — Zod error returned
-  Rate limiting:   ✅ 429 on attempt 11 (expected)
-
-━━━ Issues Found ━━━━━━━━━━━━━━━━━━━━━━━━
-
-  ❌ GET /api/users returns 200 with no auth (should be 401)
-  ⚠️ PATCH /api/users doesn't validate Content-Type (accepts any body)
-```
-
----
-
-## Usage Examples
-
-```
-/api-tester POST /api/auth/login then test /api/users CRUD
-/api-tester test the /api/checkout flow with Stripe test card
-/api-tester verify all auth routes return 401 for unauthenticated requests
-/api-tester test rate limiting on /api/auth/login
-```
+---
+description: Automated multi-stage API endpoint testing. Generates and runs auth-aware request sequences (login → use token → test CRUD → verify errors). Reports response codes, schema mismatches, and unexpected data.
+---
+
+# /api-tester — Automated API Testing
+
+$ARGUMENTS
+
+---
+
+## When to Use /api-tester
+
+|Use `/api-tester` when...|Use something else when...|
+|:---|:---|
+|Testing REST API endpoints manually|Unit tests needed → `/test`|
+|Verifying auth token flows end-to-end|Full security audit → `/audit`|
+|After generating new endpoints|Load testing → `/performance-benchmarker`|
+|Checking response schemas||
+
+---
+
+## Phase 1 — Endpoint Discovery
+
+```bash
+# Find all defined routes
+grep -r "app.get\|app.post\|app.put\|app.delete\|app.patch" src/ --include="*.ts"
+grep -r "router.get\|router.post\|router.put" src/ --include="*.ts"
+
+# Next.js Route Handlers
+find src/app/api -name "route.ts" | sort
+```
+
+---
+
+## Phase 2 — Auth Flow (Token Acquisition)
+
+Before testing protected endpoints, acquire auth token:
+
+```bash
+# Acquire JWT
+curl -X POST http://localhost:3000/api/auth/login \
+  -H "Content-Type: application/json" \
+  -d '{"email":"test@example.com","password":"testpassword"}' \
+  -s | jq '.token'
+
+# Assign to variable
+TOKEN=$(curl -X POST http://localhost:3000/api/auth/login \
+  -H "Content-Type: application/json" \
+  -d '{"email":"test@example.com","password":"testpassword"}' \
+  -s | jq -r '.token')
+```
+
+---
+
+## Phase 3 — CRUD Sequence Testing
+
+Test endpoints in the correct order (create before read, read before delete):
+
+```bash
+# 1. CREATE (POST)
+CREATE_RESPONSE=$(curl -X POST http://localhost:3000/api/users \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"name":"Test User","email":"new@test.com"}')
+CREATED_ID=$(echo $CREATE_RESPONSE | jq -r '.id')
+echo "Created: $CREATED_ID"
+
+# 2. READ (GET)
+curl -X GET "http://localhost:3000/api/users/$CREATED_ID" \
+  -H "Authorization: Bearer $TOKEN" \
+  | jq .
+
+# 3. UPDATE (PATCH)
+curl -X PATCH "http://localhost:3000/api/users/$CREATED_ID" \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"name":"Updated Name"}'
+
+# 4. DELETE
+curl -X DELETE "http://localhost:3000/api/users/$CREATED_ID" \
+  -H "Authorization: Bearer $TOKEN"
+```
+
+---
+
+## Phase 4 — Error Case Testing
+
+Test that errors are handled correctly:
+
+```bash
+# 4xx errors (client errors — must NOT return 200!)
+echo "--- Unauthenticated request (expect 401) ---"
+curl -X GET http://localhost:3000/api/users -s -o /dev/null -w "%{http_code}\n"
+
+echo "--- Invalid ID (expect 404 or 400) ---"
+curl -X GET "http://localhost:3000/api/users/not-a-real-id" \
+  -H "Authorization: Bearer $TOKEN" \
+  -s -o /dev/null -w "%{http_code}\n"
+
+echo "--- Invalid body (expect 400) ---"
+curl -X POST http://localhost:3000/api/users \
+  -H "Authorization: Bearer $TOKEN" \
+  -H "Content-Type: application/json" \
+  -d '{"invalid":"field"}' \
+  -s -o /dev/null -w "%{http_code}\n"
+
+echo "--- Rate limiting (expect 429 after N requests) ---"
+for i in {1..15}; do
+  STATUS=$(curl -X POST http://localhost:3000/api/auth/login \
+    -H "Content-Type: application/json" \
+    -d '{"email":"x","password":"wrong"}' \
+    -s -o /dev/null -w "%{http_code}")
+  echo "Attempt $i: $STATUS"
+done
+```
+
+---
+
+## Phase 5 — Test Report
+
+```
+━━━ API Test Report ━━━━━━━━━━━━━━━━━━━━━━
+
+Auth Flow:   ✅ Login → token acquired
+POST /users: ✅ 201 Created — id returned
+GET /users:  ✅ 200 — data matches expected schema
+PATCH /users: ✅ 200 — update reflected
+DELETE /users: ✅ 204 No Content
+
+Error Cases:
+  Unauthenticated: ✅ 401 (expected)
+  Invalid ID:      ✅ 404 (expected)
+  Invalid body:    ✅ 400 (expected) — Zod error returned
+  Rate limiting:   ✅ 429 on attempt 11 (expected)
+
+━━━ Issues Found ━━━━━━━━━━━━━━━━━━━━━━━━
+
+  ❌ GET /api/users returns 200 with no auth (should be 401)
+  ⚠️ PATCH /api/users doesn't validate Content-Type (accepts any body)
+```
+
+---
+
+## Usage Examples
+
+```
+/api-tester POST /api/auth/login then test /api/users CRUD
+/api-tester test the /api/checkout flow with Stripe test card
+/api-tester verify all auth routes return 401 for unauthenticated requests
+/api-tester test rate limiting on /api/auth/login
+```