tribunal-kit 3.0.0 → 3.1.0

package/.agent/workflows/ui-ux-pro-max.md

@@ -1,143 +1,122 @@
----
-description: Plan and implement cutting-edge advanced UI/UX. Creates distinctive, production-grade frontend interfaces with high design quality that avoid generic AI aesthetics — no purple gradients, no bento grids, no mesh backgrounds.
----
-
-# /ui-ux-pro-max — Advanced UI/UX Design
-
-$ARGUMENTS
-
----
-
-## When to Use /ui-ux-pro-max
-
-| Use `/ui-ux-pro-max` when... | Use instead when... |
-|:---|:---|
-| Building a visually distinctive interface | Functional-only component → `/generate` |
-| Design quality is the primary goal | Fast page needed → `/enhance` |
-| Creating from a design brief | Bug fix in UI → `/debug` |
-| Mobile + web parity required | |
-
----
-
-## Phase 1 — Design Intent (Mandatory)
-
-Answer these before any design work:
-
-```
-1. Who is the user? (developer tools feel different from consumer apps)
-2. What emotion should the interface evoke? (calm focus, urgent speed, playful delight)
-3. What is the ONE thing users do most? (hero interaction gets maximum design attention)
-4. What existing interfaces does the user love? (don't copy — understand the WHY)
-5. What makes this interface DIFFERENT from every competitor?
-```
-
----
-
-## Phase 2 — Design Identity
-
-Every interface built by /ui-ux-pro-max has a distinct visual identity:
-
-```
-Forbidden defaults (generic AI aesthetics):
-❌ Purple/violet as primary color
-❌ Left text / right image hero section
-❌ Mesh gradient backgrounds
-❌ Bento grid as the only layout
-❌ Emoji as icons
-❌ shadcn without explicit user request
-
-Distinctive alternatives:
-✅ Signal orange, acid green, warm slate, deep red — intentional palettes
-✅ Typographic-first hero sections
-✅ Grain textures, solid contrast, radial depth
-✅ Asymmetric or broken-grid layouts
-✅ SVG icons (lucide-react or custom)
-✅ Motion that communicates meaning (not decoration)
-```
-
----
-
-## Phase 3 — Interaction Craft
-
-Every interactive element has 4 states designed:
-
-```
-1. Default:  The base state
-2. Hover:    Indicates interactability (cursor change, subtle lift, color shift)
-3. Active:   Confirms click/press (scale down, darker, haptic feedback on mobile)
-4. Disabled: Communicates unavailability (reduced opacity, cursor change, tooltip why)
-```
-
-Micro-animations are required, not optional:
-
-```
-Entry animations:  elements fade/slide in on mount
-State transitions: smooth color + scale changes (150–200ms)
-Loading states:    skeleton screens, not spinners (skeleton shows shape)
-Error shake:       invalid form input shakes (4px left-right)
-Success pulse:     confirmed actions pulse green briefly
-```
-
----
-
-## Phase 4 — Implementation (Tribunal-Reviewed)
-
-All generated code runs through `/tribunal-frontend` including `accessibility-reviewer`:
-
-```
-WCAG 2.2 AA — Non-negotiable:
-□ Keyboard navigation complete and visible
-□ Screen reader semantics verified (role, label, live region)
-□ Color contrast 4.5:1 minimum on all text
-□ Focus indicator visible (outline: 2px solid, offset: 2px)
-□ Motion respects prefers-reduced-motion
-```
-
----
-
-## Phase 5 — Design Verification
-
-Before finalizing:
-
-```
-□ Open in mobile viewport (375px) — does it work?
-□ Open in dark mode — does it look intentional?
-□ Keyboard-navigate through the critical path — is it complete?
-□ Screenshot and ask: "Would I scroll past this on Dribbble?"
-□ Screen reader test with VoiceOver or NVDA
-```
-
----
-
-## Output Format
-
-```
-━━━ UI/UX Design ━━━━━━━━━━━━━━━━━━━━━━━━
-
-Design Identity: [1 sentence describing the visual intent]
-Primary action:  [what the user does most prominently]
-Color palette:   [specific hex values — not color names]
-Motion profile:  [subtle / moderate / expressive]
-
-━━━ Tribunal: Frontend + Accessibility ━━━━━━
-
-frontend-reviewer:    ✅ APPROVED
-accessibility-reviewer: [verdict]
-
-[Generated components]
-
-━━━ Human Gate ━━━━━━━━━━━━━━━━━━━━━━━━━
-Approve?  Y = write | N = discard | R = revise design direction
-```
-
----
-
-## Usage Examples
-
-```
-/ui-ux-pro-max design a SaaS dashboard for an analytics platform
-/ui-ux-pro-max redesign the checkout flow with better conversion UX
-/ui-ux-pro-max create an onboarding flow for a developer tool
-/ui-ux-pro-max design the landing page hero section with distinctive layout
-/ui-ux-pro-max create a data visualization dashboard with real-time updates
-```
+---
+description: Plan and implement cutting-edge advanced UI/UX. Creates distinctive, production-grade frontend interfaces with high design quality that avoid generic AI aesthetics — no purple gradients, no bento grids, no mesh backgrounds.
+---
+
+# /ui-ux-pro-max — Advanced UI/UX Design
+
+$ARGUMENTS
+
+---
+
+## When to Use /ui-ux-pro-max
+
+|Use `/ui-ux-pro-max` when...|Use instead when...|
+|:---|:---|
+|Building a visually distinctive interface|Functional-only component → `/generate`|
+|Design quality is the primary goal|Fast page needed → `/enhance`|
+|Creating from a design brief|Bug fix in UI → `/debug`|
+|Mobile + web parity required||
+
+---
+
+## Phase 1 — Design Intent (Mandatory)
+
+Answer these before any design work:
+
+```
+1. Who is the user? (developer tools feel different from consumer apps)
+2. What emotion should the interface evoke? (calm focus, urgent speed, playful delight)
+3. What is the ONE thing users do most? (hero interaction gets maximum design attention)
+4. What existing interfaces does the user love? (don't copy — understand the WHY)
+5. What makes this interface DIFFERENT from every competitor?
+```
+
+---
+
+## Phase 2 — Design Identity
+
+Every interface built by /ui-ux-pro-max has a distinct visual identity:
+
+```
+Forbidden defaults (generic AI aesthetics):
+❌ Purple/violet as primary color
+❌ Left text / right image hero section
+❌ Mesh gradient backgrounds
+❌ Bento grid as the only layout
+❌ Emoji as icons
+❌ shadcn without explicit user request
+
+Distinctive alternatives:
+✅ Signal orange, acid green, warm slate, deep red — intentional palettes
+✅ Typographic-first hero sections
+✅ Grain textures, solid contrast, radial depth
+✅ Asymmetric or broken-grid layouts
+✅ SVG icons (lucide-react or custom)
+✅ Motion that communicates meaning (not decoration)
+```
+
+---
+
+## Phase 3 — Interaction Craft
+
+Every interactive element has 4 states designed:
+
+```
+1. Default:  The base state
+2. Hover:    Indicates interactability (cursor change, subtle lift, color shift)
+3. Active:   Confirms click/press (scale down, darker, haptic feedback on mobile)
+4. Disabled: Communicates unavailability (reduced opacity, cursor change, tooltip why)
+```
+
+Micro-animations are required, not optional:
+
+```
+Entry animations:  elements fade/slide in on mount
+State transitions: smooth color + scale changes (150–200ms)
+Loading states:    skeleton screens, not spinners (skeleton shows shape)
+Error shake:       invalid form input shakes (4px left-right)
+Success pulse:     confirmed actions pulse green briefly
+```
+
+---
+
+## Phase 4 — Implementation (Tribunal-Reviewed)
+
+All generated code runs through `/tribunal-frontend` including `accessibility-reviewer`:
+
+```
+WCAG 2.2 AA — Non-negotiable:
+□ Keyboard navigation complete and visible
+□ Screen reader semantics verified (role, label, live region)
+□ Color contrast 4.5:1 minimum on all text
+□ Focus indicator visible (outline: 2px solid, offset: 2px)
+□ Motion respects prefers-reduced-motion
+```
+
+---
+
+## Phase 5 — Design Verification
+
+Before finalizing:
+
+```
+□ Open in mobile viewport (375px) — does it work?
+□ Open in dark mode — does it look intentional?
+□ Keyboard-navigate through the critical path — is it complete?
+□ Screenshot and ask: "Would I scroll past this on Dribbble?"
+□ Screen reader test with VoiceOver or NVDA
+```
+
+---
+
+---
+
+## Usage Examples
+
+```
+/ui-ux-pro-max design a SaaS dashboard for an analytics platform
+/ui-ux-pro-max redesign the checkout flow with better conversion UX
+/ui-ux-pro-max create an onboarding flow for a developer tool
+/ui-ux-pro-max design the landing page hero section with distinctive layout
+/ui-ux-pro-max create a data visualization dashboard with real-time updates
+```

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "tribunal-kit",
-    "version": "3.0.0",
+    "version": "3.1.0",
     "description": "Anti-Hallucination AI Agent Kit — 33 specialist agents, 25 slash commands, Swarm/Supervisor engine, and Tribunal review pipeline for Cursor, Windsurf, and Antigravity.",
     "keywords": [
         "ai",

package/.agent/skills/api-patterns/api-style.md

@@ -1,42 +0,0 @@
-# API Style Selection (2025)
-
-> REST vs GraphQL vs tRPC - Hangi durumda hangisi?
-
-## Decision Tree
-
-```
-Who are the API consumers?
-│
-├── Public API / Multiple platforms
-│   └── REST + OpenAPI (widest compatibility)
-│
-├── Complex data needs / Multiple frontends
-│   └── GraphQL (flexible queries)
-│
-├── TypeScript frontend + backend (monorepo)
-│   └── tRPC (end-to-end type safety)
-│
-├── Real-time / Event-driven
-│   └── WebSocket + AsyncAPI
-│
-└── Internal microservices
-    └── gRPC (performance) or REST (simplicity)
-```
-
-## Comparison
-
-| Factor | REST | GraphQL | tRPC |
-|--------|------|---------|------|
-| **Best for** | Public APIs | Complex apps | TS monorepos |
-| **Learning curve** | Low | Medium | Low (if TS) |
-| **Over/under fetching** | Common | Solved | Solved |
-| **Type safety** | Manual (OpenAPI) | Schema-based | Automatic |
-| **Caching** | HTTP native | Complex | Client-based |
-
-## Selection Questions
-
-1. Who are the API consumers?
-2. Is the frontend TypeScript?
-3. How complex are the data relationships?
-4. Is caching critical?
-5. Public or internal API?

package/.agent/skills/api-patterns/auth.md

@@ -1,24 +0,0 @@
-# Authentication Patterns
-
-> Choose auth pattern based on use case.
-
-## Selection Guide
-
-| Pattern | Best For |
-|---------|----------|
-| **JWT** | Stateless, microservices |
-| **Session** | Traditional web, simple |
-| **OAuth 2.0** | Third-party integration |
-| **API Keys** | Server-to-server, public APIs |
-| **Passkey** | Modern passwordless (2025+) |
-
-## JWT Principles
-
-```
-Important:
-├── Always verify signature
-├── Check expiration
-├── Include minimal claims
-├── Use short expiry + refresh tokens
-└── Never store sensitive data in JWT
-```

package/.agent/skills/api-patterns/documentation.md

@@ -1,26 +0,0 @@
-# API Documentation Principles
-
-> Good docs = happy developers = API adoption.
-
-## OpenAPI/Swagger Essentials
-
-```
-Include:
-├── All endpoints with examples
-├── Request/response schemas
-├── Authentication requirements
-├── Error response formats
-└── Rate limiting info
-```
-
-## Good Documentation Has
-
-```
-Essentials:
-├── Quick start / Getting started
-├── Authentication guide
-├── Complete API reference
-├── Error handling guide
-├── Code examples (multiple languages)
-└── Changelog
-```

package/.agent/skills/api-patterns/graphql.md

@@ -1,41 +0,0 @@
-# GraphQL Principles
-
-> Flexible queries for complex, interconnected data.
-
-## When to Use
-
-```
-✅ Good fit:
-├── Complex, interconnected data
-├── Multiple frontend platforms
-├── Clients need flexible queries
-├── Evolving data requirements
-└── Reducing over-fetching matters
-
-❌ Poor fit:
-├── Simple CRUD operations
-├── File upload heavy
-├── HTTP caching important
-└── Team unfamiliar with GraphQL
-```
-
-## Schema Design Principles
-
-```
-Principles:
-├── Think in graphs, not endpoints
-├── Design for evolvability (no versions)
-├── Use connections for pagination
-├── Be specific with types (not generic "data")
-└── Handle nullability thoughtfully
-```
-
-## Security Considerations
-
-```
-Protect against:
-├── Query depth attacks → Set max depth
-├── Query complexity → Calculate cost
-├── Batching abuse → Limit batch size
-├── Introspection → Disable in production
-```

package/.agent/skills/api-patterns/rate-limiting.md

@@ -1,31 +0,0 @@
-# Rate Limiting Principles
-
-> Protect your API from abuse and overload.
-
-## Why Rate Limit
-
-```
-Protect against:
-├── Brute force attacks
-├── Resource exhaustion
-├── Cost overruns (if pay-per-use)
-└── Unfair usage
-```
-
-## Strategy Selection
-
-| Type | How | When |
-|------|-----|------|
-| **Token bucket** | Burst allowed, refills over time | Most APIs |
-| **Sliding window** | Smooth distribution | Strict limits |
-| **Fixed window** | Simple counters per window | Basic needs |
-
-## Response Headers
-
-```
-Include in headers:
-├── X-RateLimit-Limit (max requests)
-├── X-RateLimit-Remaining (requests left)
-├── X-RateLimit-Reset (when limit resets)
-└── Return 429 when exceeded
-```

package/.agent/skills/api-patterns/response.md

@@ -1,37 +0,0 @@
-# Response Format Principles
-
-> Consistency is key - choose a format and stick to it.
-
-## Common Patterns
-
-```
-Choose one:
-├── Envelope pattern ({ success, data, error })
-├── Direct data (just return the resource)
-└── HAL/JSON:API (hypermedia)
-```
-
-## Error Response
-
-```
-Include:
-├── Error code (for programmatic handling)
-├── User message (for display)
-├── Details (for debugging, field-level errors)
-├── Request ID (for support)
-└── NOT internal details (security!)
-```
-
-## Pagination Types
-
-| Type | Best For | Trade-offs |
-|------|----------|------------|
-| **Offset** | Simple, jumpable | Performance on large datasets |
-| **Cursor** | Large datasets | Can't jump to page |
-| **Keyset** | Performance critical | Requires sortable key |
-
-### Selection Questions
-
-1. How large is the dataset?
-2. Do users need to jump to specific pages?
-3. Is data frequently changing?

package/.agent/skills/api-patterns/rest.md

@@ -1,40 +0,0 @@
-# REST Principles
-
-> Resource-based API design - nouns not verbs.
-
-## Resource Naming Rules
-
-```
-Principles:
-├── Use NOUNS, not verbs (resources, not actions)
-├── Use PLURAL forms (/users not /user)
-├── Use lowercase with hyphens (/user-profiles)
-├── Nest for relationships (/users/123/posts)
-└── Keep shallow (max 3 levels deep)
-```
-
-## HTTP Method Selection
-
-| Method | Purpose | Idempotent? | Body? |
-|--------|---------|-------------|-------|
-| **GET** | Read resource(s) | Yes | No |
-| **POST** | Create new resource | No | Yes |
-| **PUT** | Replace entire resource | Yes | Yes |
-| **PATCH** | Partial update | No | Yes |
-| **DELETE** | Remove resource | Yes | No |
-
-## Status Code Selection
-
-| Situation | Code | Why |
-|-----------|------|-----|
-| Success (read) | 200 | Standard success |
-| Created | 201 | New resource created |
-| No content | 204 | Success, nothing to return |
-| Bad request | 400 | Malformed request |
-| Unauthorized | 401 | Missing/invalid auth |
-| Forbidden | 403 | Valid auth, no permission |
-| Not found | 404 | Resource doesn't exist |
-| Conflict | 409 | State conflict (duplicate) |
-| Validation error | 422 | Valid syntax, invalid data |
-| Rate limited | 429 | Too many requests |
-| Server error | 500 | Our fault |

package/.agent/skills/api-patterns/security-testing.md

@@ -1,122 +0,0 @@
-# API Security Testing
-
-> Principles for testing API security. OWASP API Top 10, authentication, authorization testing.
-
----
-
-## OWASP API Security Top 10
-
-| Vulnerability | Test Focus |
-|---------------|------------|
-| **API1: BOLA** | Access other users' resources |
-| **API2: Broken Auth** | JWT, session, credentials |
-| **API3: Property Auth** | Mass assignment, data exposure |
-| **API4: Resource Consumption** | Rate limiting, DoS |
-| **API5: Function Auth** | Admin endpoints, role bypass |
-| **API6: Business Flow** | Logic abuse, automation |
-| **API7: SSRF** | Internal network access |
-| **API8: Misconfiguration** | Debug endpoints, CORS |
-| **API9: Inventory** | Shadow APIs, old versions |
-| **API10: Unsafe Consumption** | Third-party API trust |
-
----
-
-## Authentication Testing
-
-### JWT Testing
-
-| Check | What to Test |
-|-------|--------------|
-| Algorithm | None, algorithm confusion |
-| Secret | Weak secrets, brute force |
-| Claims | Expiration, issuer, audience |
-| Signature | Manipulation, key injection |
-
-### Session Testing
-
-| Check | What to Test |
-|-------|--------------|
-| Generation | Predictability |
-| Storage | Client-side security |
-| Expiration | Timeout enforcement |
-| Invalidation | Logout effectiveness |
-
----
-
-## Authorization Testing
-
-| Test Type | Approach |
-|-----------|----------|
-| **Horizontal** | Access peer users' data |
-| **Vertical** | Access higher privilege functions |
-| **Context** | Access outside allowed scope |
-
-### BOLA/IDOR Testing
-
-1. Identify resource IDs in requests
-2. Capture request with user A's session
-3. Replay with user B's session
-4. Check for unauthorized access
-
----
-
-## Input Validation Testing
-
-| Injection Type | Test Focus |
-|----------------|------------|
-| SQL | Query manipulation |
-| NoSQL | Document queries |
-| Command | System commands |
-| LDAP | Directory queries |
-
-**Approach:** Test all parameters, try type coercion, test boundaries, check error messages.
-
----
-
-## Rate Limiting Testing
-
-| Aspect | Check |
-|--------|-------|
-| Existence | Is there any limit? |
-| Bypass | Headers, IP rotation |
-| Scope | Per-user, per-IP, global |
-
-**Bypass techniques:** X-Forwarded-For, different HTTP methods, case variations, API versioning.
-
----
-
-## GraphQL Security
-
-| Test | Focus |
-|------|-------|
-| Introspection | Schema disclosure |
-| Batching | Query DoS |
-| Nesting | Depth-based DoS |
-| Authorization | Field-level access |
-
----
-
-## Security Testing Checklist
-
-**Authentication:**
-- [ ] Test for bypass
-- [ ] Check credential strength
-- [ ] Verify token security
-
-**Authorization:**
-- [ ] Test BOLA/IDOR
-- [ ] Check privilege escalation
-- [ ] Verify function access
-
-**Input:**
-- [ ] Test all parameters
-- [ ] Check for injection
-
-**Config:**
-- [ ] Check CORS
-- [ ] Verify headers
-- [ ] Test error handling
-
----
-
-> **Remember:** APIs are the backbone of modern apps. Test them like attackers will.

package/.agent/skills/api-patterns/trpc.md

@@ -1,41 +0,0 @@
-# tRPC Principles
-
-> End-to-end type safety for TypeScript monorepos.
-
-## When to Use
-
-```
-✅ Perfect fit:
-├── TypeScript on both ends
-├── Monorepo structure
-├── Internal tools
-├── Rapid development
-└── Type safety critical
-
-❌ Poor fit:
-├── Non-TypeScript clients
-├── Public API
-├── Need REST conventions
-└── Multiple language backends
-```
-
-## Key Benefits
-
-```
-Why tRPC:
-├── Zero schema maintenance
-├── End-to-end type inference
-├── IDE autocomplete across stack
-├── Instant API changes reflected
-└── No code generation step
-```
-
-## Integration Patterns
-
-```
-Common setups:
-├── Next.js + tRPC (most common)
-├── Monorepo with shared types
-├── Remix + tRPC
-└── Any TS frontend + backend
-```