tribunal-kit 2.4.6 → 3.1.0

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
-```

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

@@ -1,22 +0,0 @@
-# Versioning Strategies
-
-> Plan for API evolution from day one.
-
-## Decision Factors
-
-| Strategy | Implementation | Trade-offs |
-|----------|---------------|------------|
-| **URI** | /v1/users | Clear, easy caching |
-| **Header** | Accept-Version: 1 | Cleaner URLs, harder discovery |
-| **Query** | ?version=1 | Easy to add, messy |
-| **None** | Evolve carefully | Best for internal, risky for public |
-
-## Versioning Philosophy
-
-```
-Consider:
-├── Public API? → Version in URI
-├── Internal only? → May not need versioning
-├── GraphQL? → Typically no versions (evolve schema)
-├── tRPC? → Types enforce compatibility
-```

package/.agent/skills/app-builder/agent-coordination.md

@@ -1,71 +0,0 @@
-# Agent Coordination
-
-> How App Builder orchestrates specialist agents.
-
-## Agent Pipeline
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│                   APP BUILDER (Orchestrator)                 │
-└─────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────┐
-│                     PROJECT PLANNER                          │
-│  • Task breakdown                                            │
-│  • Dependency graph                                          │
-│  • File structure planning                                   │
-│  • Create {task-slug}.md in project root (MANDATORY)             │
-└─────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────┐
-│              CHECKPOINT: PLAN VERIFICATION                   │
-│  🔴 VERIFY: Does {task-slug}.md exist in project root?       │
-│  🔴 If NO → STOP → Create plan file first                    │
-│  🔴 If YES → Proceed to specialist agents                    │
-└─────────────────────────────────────────────────────────────┘
-                              │
-          ┌───────────────────┼───────────────────┐
-          ▼                   ▼                   ▼
-┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
-│ DATABASE        │ │ BACKEND         │ │ FRONTEND        │
-│ ARCHITECT       │ │ SPECIALIST      │ │ SPECIALIST      │
-│                 │ │                 │ │                 │
-│ • Schema design │ │ • API routes    │ │ • Components    │
-│ • Migrations    │ │ • Controllers   │ │ • Pages         │
-│ • Seed data     │ │ • Middleware    │ │ • Styling       │
-└─────────────────┘ └─────────────────┘ └─────────────────┘
-          │                   │                   │
-          └───────────────────┼───────────────────┘
-                              ▼
-┌─────────────────────────────────────────────────────────────┐
-│                 PARALLEL PHASE (Optional)                    │
-│  • Security Auditor → Vulnerability check                   │
-│  • Test Engineer → Unit tests                               │
-│  • Performance Optimizer → Bundle analysis                  │
-└─────────────────────────────────────────────────────────────┘
-                              │
-                              ▼
-┌─────────────────────────────────────────────────────────────┐
-│                     DEVOPS ENGINEER                          │
-│  • Environment setup                                         │
-│  • Preview deployment                                        │
-│  • Health check                                              │
-└─────────────────────────────────────────────────────────────┘
-```
-
-## Execution Order
-
-| Phase | Agent(s) | Parallel? | Prerequisite | CHECKPOINT |
-|-------|----------|-----------|--------------|------------|
-| 0 | Socratic Gate | ❌ | - | ✅ Ask 3 questions |
-| 1 | Project Planner | ❌ | Questions answered | ✅ **PLAN.md created** |
-| 1.5 | **PLAN VERIFICATION** | ❌ | PLAN.md exists | ✅ **File exists in root** |
-| 2 | Database Architect | ❌ | Plan ready | Schema defined |
-| 3 | Backend Specialist | ❌ | Schema ready | API routes created |
-| 4 | Frontend Specialist | ✅ | API ready (partial) | UI components ready |
-| 5 | Security Auditor, Test Engineer | ✅ | Code ready | Tests & audit pass |
-| 6 | DevOps Engineer | ❌ | All code ready | Deployment ready |
-
-> 🔴 **CRITICAL:** Phase 1.5 is MANDATORY. No specialist agents proceed without PLAN.md verification.

package/.agent/skills/app-builder/feature-building.md

@@ -1,53 +0,0 @@
-# Feature Building
-
-> How to analyze and implement new features.
-
-## Feature Analysis
-
-```
-Request: "add payment system"
-
-Analysis:
-├── Required Changes:
-│   ├── Database: orders, payments tables
-│   ├── Backend: /api/checkout, /api/webhooks/stripe
-│   ├── Frontend: CheckoutForm, PaymentSuccess
-│   └── Config: Stripe API keys
-│
-├── Dependencies:
-│   ├── stripe package
-│   └── Existing user authentication
-│
-└── Estimated Time: 15-20 minutes
-```
-
-## Iterative Enhancement Process
-
-```
-1. Analyze existing project
-2. Create change plan
-3. Present plan to user
-4. Get approval
-5. Apply changes
-6. Test
-7. Show preview
-```
-
-## Error Handling
-
-| Error Type | Solution Strategy |
-|------------|-------------------|
-| TypeScript Error | Fix type, add missing import |
-| Missing Dependency | Run npm install |
-| Port Conflict | Suggest alternative port |
-| Database Error | Check migration, validate connection |
-
-## Recovery Strategy
-
-```
-1. Detect error
-2. Try automatic fix
-3. If failed, report to user
-4. Suggest alternative
-5. Rollback if necessary
-```

package/.agent/skills/app-builder/project-detection.md

@@ -1,34 +0,0 @@
-# Project Type Detection
-
-> Analyze user requests to determine project type and template.
-
-## Keyword Matrix
-
-| Keywords | Project Type | Template |
-|----------|--------------|----------|
-| blog, post, article | Blog | astro-static |
-| e-commerce, product, cart, payment | E-commerce | nextjs-saas |
-| dashboard, panel, management | Admin Dashboard | nextjs-fullstack |
-| api, backend, service, rest | API Service | express-api |
-| python, fastapi, django | Python API | python-fastapi |
-| mobile, android, ios, react native | Mobile App (RN) | react-native-app |
-| flutter, dart | Mobile App (Flutter) | flutter-app |
-| portfolio, personal, cv | Portfolio | nextjs-static |
-| crm, customer, sales | CRM | nextjs-fullstack |
-| saas, subscription, stripe | SaaS | nextjs-saas |
-| landing, promotional, marketing | Landing Page | nextjs-static |
-| docs, documentation | Documentation | astro-static |
-| extension, plugin, chrome | Browser Extension | chrome-extension |
-| desktop, electron | Desktop App | electron-desktop |
-| cli, command line, terminal | CLI Tool | cli-tool |
-| monorepo, workspace | Monorepo | monorepo-turborepo |
-
-## Detection Process
-
-```
-1. Tokenize user request
-2. Extract keywords
-3. Determine project type
-4. Detect missing information → forward to conversation-manager
-5. Suggest tech stack
-```

package/.agent/skills/app-builder/scaffolding.md

@@ -1,118 +0,0 @@
-# Project Scaffolding
-
-> Directory structure and core files for new projects.
-
----
-
-## Next.js Full-Stack Structure (2025 Optimized)
-
-```
-project-name/
-├── src/
-│   ├── app/                        # Routes only (thin layer)
-│   │   ├── layout.tsx
-│   │   ├── page.tsx
-│   │   ├── globals.css
-│   │   ├── (auth)/                 # Route group - auth pages
-│   │   │   ├── login/page.tsx
-│   │   │   └── register/page.tsx
-│   │   ├── (dashboard)/            # Route group - dashboard layout
-│   │   │   ├── layout.tsx
-│   │   │   └── page.tsx
-│   │   └── api/
-│   │       └── [resource]/route.ts
-│   │
-│   ├── features/                   # Feature-based modules
-│   │   ├── auth/
-│   │   │   ├── components/
-│   │   │   ├── hooks/
-│   │   │   ├── actions.ts          # Server Actions
-│   │   │   ├── queries.ts          # Data fetching
-│   │   │   └── types.ts
-│   │   ├── products/
-│   │   │   ├── components/
-│   │   │   ├── actions.ts
-│   │   │   └── queries.ts
-│   │   └── cart/
-│   │       └── ...
-│   │
-│   ├── shared/                     # Shared utilities
-│   │   ├── components/ui/          # Reusable UI components
-│   │   ├── lib/                    # Utils, helpers
-│   │   └── hooks/                  # Global hooks
-│   │
-│   └── server/                     # Server-only code
-│       ├── db/                     # Database client (Prisma)
-│       ├── auth/                   # Auth config
-│       └── services/               # External API integrations
-│
-├── prisma/
-│   ├── schema.prisma
-│   ├── migrations/
-│   └── seed.ts
-│
-├── public/
-├── .env.example
-├── .env.local
-├── package.json
-├── tailwind.config.ts
-├── tsconfig.json
-└── README.md
-```
-
----
-
-## Structure Principles
-
-| Principle | Implementation |
-|-----------|----------------|
-| **Feature isolation** | Each feature in `features/` with its own components, hooks, actions |
-| **Server/Client separation** | Server-only code in `server/`, prevents accidental client imports |
-| **Thin routes** | `app/` only for routing, logic lives in `features/` |
-| **Route groups** | `(groupName)/` for layout sharing without URL impact |
-| **Shared code** | `shared/` for truly reusable UI and utilities |
-
----
-
-## Core Files
-
-| File | Purpose |
-|------|---------|
-| `package.json` | Dependencies |
-| `tsconfig.json` | TypeScript + path aliases (`@/features/*`) |
-| `tailwind.config.ts` | Tailwind config |
-| `.env.example` | Environment template |
-| `README.md` | Project documentation |
-| `.gitignore` | Git ignore rules |
-| `prisma/schema.prisma` | Database schema |
-
----
-
-## Path Aliases (tsconfig.json)
-
-```json
-{
-  "compilerOptions": {
-    "paths": {
-      "@/*": ["./src/*"],
-      "@/features/*": ["./src/features/*"],
-      "@/shared/*": ["./src/shared/*"],
-      "@/server/*": ["./src/server/*"]
-    }
-  }
-}
-```
-
----
-
-## When to Use What
-
-| Need | Location |
-|------|----------|
-| New page/route | `app/(group)/page.tsx` |
-| Feature component | `features/[name]/components/` |
-| Server action | `features/[name]/actions.ts` |
-| Data fetching | `features/[name]/queries.ts` |
-| Reusable button/input | `shared/components/ui/` |
-| Database query | `server/db/` |
-| External API call | `server/services/` |

package/.agent/skills/app-builder/tech-stack.md

@@ -1,40 +0,0 @@
-# Tech Stack Selection (2026)
-
-> Default and alternative technology choices for web applications.
-
-## Default Stack (Web App - 2026)
-
-```yaml
-Frontend:
-  framework: Next.js 16 (Stable)
-  language: TypeScript 5.7+
-  styling: Tailwind CSS v4
-  state: React 19 Actions / Server Components
-  bundler: Turbopack (Stable for Dev)
-
-Backend:
-  runtime: Node.js 23
-  framework: Next.js API Routes / Hono (for Edge)
-  validation: Zod / TypeBox
-
-Database:
-  primary: PostgreSQL
-  orm: Prisma / Drizzle
-  hosting: Supabase / Neon
-
-Auth:
-  provider: Auth.js (v5) / Clerk
-
-Monorepo:
-  tool: Turborepo 2.0
-```
-
-## Alternative Options
-
-| Need | Default | Alternative |
-|------|---------|-------------|
-| Real-time | - | Supabase Realtime, Socket.io |
-| File storage | - | Cloudinary, S3 |
-| Payment | Stripe | LemonSqueezy, Paddle |
-| Email | - | Resend, SendGrid |
-| Search | - | Algolia, Typesense |