tribunal-kit 2.4.6 → 3.1.0

package/.agent/skills/api-security-auditor/SKILL.md

@@ -1,75 +1,143 @@
----
-name: api-security-auditor
-description: API Security Expert focusing on REST, GraphQL, and RPC layers. Detects and prevents BOLA/IDOR, enforces rate limiting, and guarantees input sanitization.
-allowed-tools: Read, Write, Edit, Glob, Grep
-version: 1.0.0
-last-updated: 2026-03-30
-applies-to-model: claude-3-7-sonnet, gemini-2.5-pro
----
-
-# API Security Auditor
-
-You are a strict API Security Auditor acting purely in the defense of the backend architecture. Your job is to prevent vulnerabilities before they are merged into the application.
-
-## Core Directives
-
-1. **Authorization at the Object Level (BOLA/IDOR):**
-   - NEVER assume that an authenticated user is authorized to access a specific resource.
-   - For every database query involving an ID, you must explicitly check if the requesting user `ID` matches the resource's `owner_id` or that the user has an `Admin` claim.
-
-2. **Input Validation & Sanitization:**
-   - Every single API boundary must have a strict schema validation layer (e.g., Zod, Joi, or Pydantic).
-   - Reject arbitrary payloads. Do not accept `{ ...request.body }` dynamically into database ORMs. Extract explicitly required fields.
-
-3. **Rate Limiting & Abuse Prevention:**
-   - Require rate-limit policies on all public, unauthorized endpoints (especially `/login`, `/register`, `/reset-password`).
-   - Standardize error responses. Do not leak stack traces or internal database column names via 500 errors. Return generic 400/401/403/404 messages.
-
-## Execution
-Whenever you design, write, or review backend API routes, implicitly verify:
-- *"Is this route checking role authorization?"*
-- *"Is the parameter mapped cleanly?"*
-- *"Can this be recursively requested 10,000 times a second?"*
-If any answer leaves the system vulnerable, halt generation and rewrite the code safely.
+---
+name: api-security-auditor
+description: API Security auditing mastery. Rate limiting architecture, API key management, payload validation, IDOR (Insecure Direct Object Reference) prevention, mass assignment flaws, GraphQL security, and server-side mitigations. Use when building external APIs, B2B services, or reviewing endpoint security.
+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
+---
+
+# API Security Auditor — Endpoint Hardening Mastery
+
+---
+
+## Insecure Direct Object Reference (IDOR)
+
+IDOR occurs when an application provides direct access to objects based on user-supplied input without authorization checks.
 
+```typescript
+// ❌ VULNERABLE: Trusting the requested ID blindly
+app.get("/api/receipts/:id", async (req, res) => {
+  const receipt = await db.receipts.findById(req.params.id);
+  res.json(receipt); // Attack: Increment ID to view others' receipts
+});
+
+// ✅ SAFE: Verifying ownership
+app.get("/api/receipts/:id", async (req, res) => {
+  const receipt = await db.receipts.findById(req.params.id);
+  if (!receipt) return res.status(404).send();
+
+  // Explicit tenancy check
+  if (receipt.userId !== req.user.id && req.user.role !== "admin") {
+    return res.status(403).json({ error: "Access denied" });
+  }
+
+  res.json(receipt);
+});
+
+// ✅ BEST: Using UUIDv4/CUID/NanoID instead of sequential integers
+// Attackers cannot guess standard UUIDs, heavily mitigating IDOR risks.
+```
 
 ---
 
-## 🤖 LLM-Specific Traps
+## Mass Assignment (Overposting)
+
+Occurs when web frameworks automatically bind HTTP request parameters to application models without filtering.
+
+```typescript
+// ❌ VULNERABLE: Direct object binding
+app.put("/api/users/:id", async (req, res) => {
+  // Attack: req.body = { name: "Bob", role: "admin", isPaid: true }
+  await db.users.update({ id: req.params.id }, req.body);
+  res.send("Updated");
+});
 
-AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:
+// ✅ SAFE: Explicit property selection (DTOs)
+app.put("/api/users/:id", async (req, res) => {
+  // Only extract explicitly allowed fields
+  const { name, email, bio } = req.body;
+  const safeData = { name, email, bio };
 
-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.
+  await db.users.update({ id: req.params.id }, safeData);
+  res.send("Updated");
+});
+
+// ✅ BEST: Validation libraries (Zod, Joi) handling stripping
+const UpdateUserSchema = z.object({
+  name: z.string().min(2),
+  email: z.string().email(),
+}).strict(); // `.strict()` throws if "role" or "isPaid" is passed
+```
 
 ---
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
+## Rate Limiting Architecture
 
-**Slash command: `/review` or `/tribunal-full`**
-**Active reviewers: `logic-reviewer` · `security-auditor`**
+```typescript
+// Basic Rate Limiting (Express)
+import rateLimit from "express-rate-limit";
+import RedisStore from "rate-limit-redis";
 
-### ❌ Forbidden AI Tropes
+// Global baseline limit
+export const globalLimiter = rateLimit({
+  store: new RedisStore({ client: redisClient }),
+  windowMs: 15 * 60 * 1000, // 15 min
+  max: 100, // Limit each IP to 100 reqs per window
+  standardHeaders: true, // Return rate limit info in the `RateLimit-*` headers
+});
 
-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.
+// Aggressive endpoint-specific limit (Login, Password Reset)
+export const authLimiter = rateLimit({
+  store: new RedisStore({ client: redisClient }),
+  windowMs: 60 * 60 * 1000, // 1 Hour
+  max: 5, // 5 login attempts per IP per hour
+  message: "Too many login attempts, please try again later"
+});
 
-### ✅ Pre-Flight Self-Audit
+// ❌ HALLUCINATION TRAP: In-memory rate limiting across multiple server pods
+// If you use basic memory stores in a load-balanced environment (K8s, ECS),
+// an attacker has `limit * num_pods` attempts. Always use a centralized store (Redis).
+```
+
+---
+
+## API Key Management
 
-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?
+Best Practices for issuance and storage:
+1. Format: Prefix keys to identify them and allow secret scanners to find them easily.
+   - Example: `pk_live_8a9b...` (Stripe pattern).
+2. Storage: NEVER store plaintext API keys in the DB.
+   - Hash them using SHA-256 (not bcrypt, because API keys are high entropy/long).
+   - Only show the user the plaintext key ONCE upon creation.
+3. Transport: API keys must only be accepted via Headers, never in Query Params.
+   - `Authorization: Bearer pk_live_123`
+   - Query params are logged in server access logs and browser histories.
 ```
 
-### 🛑 Verification-Before-Completion (VBC) Protocol
+---
+
+## GraphQL Security Vectors
+
+```typescript
+// GraphQL introduces unique DoS vectors not found in REST
+
+// 1. Query Depth Limiting (Prevent nested joins crushing the DB)
+// User -> Posts -> Comments -> Author -> Posts -> Comments...
+import depthLimit from 'graphql-depth-limit';
+app.use('/graphql', graphqlHTTP({ validationRules: [depthLimit(5)] }));
+
+// 2. Query Cost Analysis
+// Prevent attackers from requesting 100,000 items in a single query
+// Implement cursor pagination and enforce `first: 100` limits.
 
-**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.
+// 3. Introspection Disabled in Production
+// Introspection allows attackers to download your entire schema.
+const server = new ApolloServer({
+  schema,
+  introspection: process.env.NODE_ENV !== 'production'
+});
+```
+
+---

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

@@ -2,16 +2,13 @@
 name: app-builder
 description: Main application building orchestrator. Creates full-stack applications from natural language requests. Determines project type, selects tech stack, coordinates agents.
 allowed-tools: Read, Write, Edit, Glob, Grep
-version: 1.0.0
-last-updated: 2026-03-12
+version: 3.1.0
+last-updated: 2026-04-06
 applies-to-model: gemini-2.5-pro, claude-3-7-sonnet
 ---
 
 # App Builder — Application Orchestrator
 
-> Building a full application is a coordination problem, not a coding problem.
-> Coordinate the experts. Keep the boundaries clean.
-
 ---
 
 ## When This Skill Activates
@@ -53,16 +50,15 @@ Wait for answers. Stack decisions depend on these answers.
 
 ## Phase 2 — Stack Selection
 
-| App Type | Frontend | Backend | Database |
-|---|---|---|---|
-| Content / marketing site | Next.js | Next.js API routes | PostgreSQL (if dynamic) |
-| SaaS web app | Next.js | Next.js API routes / Fastify | PostgreSQL + Redis |
-| Mobile app (cross-platform) | React Native (Expo) | Node.js API | PostgreSQL |
-| Internal dashboard / admin | Next.js | Next.js API routes | Existing |
-| Real-time (chat, collaboration) | Next.js | Fastify + WebSockets | PostgreSQL + Redis |
-| Data-heavy API | — | FastAPI (Python) | PostgreSQL |
-| AI assistant / RAG app | Next.js (streaming) | Fastify + LLM SDK | PostgreSQL + pgvector |
-| Edge-global, latency-critical | Next.js | Hono (Cloudflare Workers) | Turso / Cloudflare KV |
+|App Type|Frontend|Backend|Database|
+|Content / marketing site|Next.js|Next.js API routes|PostgreSQL (if dynamic)|
+|SaaS web app|Next.js|Next.js API routes / Fastify|PostgreSQL + Redis|
+|Mobile app (cross-platform)|React Native (Expo)|Node.js API|PostgreSQL|
+|Internal dashboard / admin|Next.js|Next.js API routes|Existing|
+|Real-time (chat, collaboration)|Next.js|Fastify + WebSockets|PostgreSQL + Redis|
+|Data-heavy API|—|FastAPI (Python)|PostgreSQL|
+|AI assistant / RAG app|Next.js (streaming)|Fastify + LLM SDK|PostgreSQL + pgvector|
+|Edge-global, latency-critical|Next.js|Hono (Cloudflare Workers)|Turso / Cloudflare KV|
 
 **If unclear:** Next.js + PostgreSQL covers 80% of use cases and is the safest default for web apps.
 
@@ -181,58 +177,338 @@ Report the URL to the user.
 
 ## Template Index
 
-| Template | Path | When to Use |
-|---|---|---|
-| Next.js Full-Stack | `templates/nextjs-app/` | Web app with API routes |
-| React Native | `templates/react-native-app/` | Cross-platform mobile |
-| API Only | `templates/api-only/` | Backend service, no UI |
+|Template|Path|When to Use|
+|Next.js Full-Stack|`templates/nextjs-app/`|Web app with API routes|
+|React Native|`templates/react-native-app/`|Cross-platform mobile|
+|API Only|`templates/api-only/`|Backend service, no UI|
+
+---
+
+---
+
+## 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.
 
 ---
 
-## Output Format
+## 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
+```
+
+---
 
-When this skill produces a recommendation or design decision, structure your output as:
+## 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
 
 ```
-━━━ App Builder Recommendation ━━━━━━━━━━━━━━━━
-Decision:    [what was chosen / proposed]
-Rationale:   [why — one concise line]
-Trade-offs:  [what is consciously accepted]
-Next action: [concrete next step for the user]
-─────────────────────────────────────────────────
-Pre-Flight:  ✅ All checks passed
-             or ❌ [blocking item that must be resolved first]
+1. Tokenize user request
+2. Extract keywords
+3. Determine project type
+4. Detect missing information → forward to conversation-manager
+5. Suggest tech stack
 ```
 
+---
+
+## Project Scaffolding
+
+---
+
+### 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
+```
 
 ---
 
-## 🏛️ Tribunal Integration (Anti-Hallucination)
+### Structure Principles
 
-**Slash command: `/create`**
-**Active reviewers: `orchestrator` · `project-planner`**
+|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|
 
-### ❌ Forbidden AI Tropes in App Building
+---
+
+### Core Files
 
-1. **Skipping Constraints** — immediately starting to generate code without asking the user about their constraints and audience.
-2. **Building the Whole App at Once** — attempting to generate 50 files in a single turn.
-3. **Out-of-Order Execution** — writing frontend components before the API or DB schema is actually designed.
-4. **Magic Dependencies** — assuming packages are installed without updating `package.json`.
-5. **Ignoring Boundaries** — mismatching the API response format between the server and the frontend client.
+|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|
 
-### ✅ Pre-Flight Self-Audit
+---
 
-Review these questions before orchestrating a full app build:
+### Path Aliases (tsconfig.json)
+
+```json
+{
+  "compilerOptions": {
+    "paths": {
+      "@/*": ["./src/*"],
+      "@/features/*": ["./src/features/*"],
+      "@/shared/*": ["./src/shared/*"],
+      "@/server/*": ["./src/server/*"]
+    }
+  }
+}
 ```
-✅ Did I ask the clarifying questions regarding constraints and target audience?
-✅ Is my generated plan broken into modular, sequenced steps (DB -> API -> UI)?
-✅ Have I explicitly defined the API contracts so the frontend and backend match?
-✅ Did I correctly track which dependencies need to be installed?
-✅ Am I verifying integration at each boundary before moving to the next layer?
+
+---
+
+### 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/`|
+
+---
+
+## 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
 ```
 
-### 🛑 Verification-Before-Completion (VBC) Protocol
+### Alternative Options
 
-**CRITICAL:** You must follow a strict "evidence-based closeout" state machine.
-- ❌ **Forbidden:** Declaring an application architecture or full-stack integration complete without verifying the seams.
-- ✅ **Required:** You are explicitly forbidden from completing an app build or integration phase without providing **concrete terminal evidence** (e.g., successful local dev server start logs, passing build logs, or successful API local test results).
+|Need|Default|Alternative|
+|------|---------|-------------|
+|Real-time|-|Supabase Realtime, Socket.io|
+|File storage|-|Cloudinary, S3|
+|Payment|Stripe|LemonSqueezy, Paddle|
+|Email|-|Resend, SendGrid|
+|Search|-|Algolia, Typesense|

package/.agent/skills/app-builder/templates/SKILL.md

@@ -6,28 +6,26 @@ allowed-tools: Read, Glob, Grep
 
 # Project Templates
 
-> Quick-start templates for scaffolding new projects.
-
 ---
 
 ## 🎯 Selective Reading Rule
 
 **Read ONLY the template matching user's project type!**
 
-| Template | Tech Stack | When to Use |
+|Template|Tech Stack|When to Use|
 |----------|------------|-------------|
-| [nextjs-fullstack](nextjs-fullstack/TEMPLATE.md) | Next.js + Prisma | Full-stack web app |
-| [nextjs-saas](nextjs-saas/TEMPLATE.md) | Next.js + Stripe | SaaS product |
-| [nextjs-static](nextjs-static/TEMPLATE.md) | Next.js + Framer | Landing page |
-| [express-api](express-api/TEMPLATE.md) | Express + JWT | REST API |
-| [python-fastapi](python-fastapi/TEMPLATE.md) | FastAPI | Python API |
-| [react-native-app](react-native-app/TEMPLATE.md) | Expo + Zustand | Mobile app |
-| [flutter-app](flutter-app/TEMPLATE.md) | Flutter + Riverpod | Cross-platform |
-| [electron-desktop](electron-desktop/TEMPLATE.md) | Electron + React | Desktop app |
-| [chrome-extension](chrome-extension/TEMPLATE.md) | Chrome MV3 | Browser extension |
-| [cli-tool](cli-tool/TEMPLATE.md) | Node.js + Commander | CLI app |
-| [monorepo-turborepo](monorepo-turborepo/TEMPLATE.md) | Turborepo + pnpm | Monorepo |
-| [astro-static](astro-static/TEMPLATE.md) | Astro + MDX | Blog / Docs |
+|[nextjs-fullstack](nextjs-fullstack/TEMPLATE.md)|Next.js + Prisma|Full-stack web app|
+|[nextjs-saas](nextjs-saas/TEMPLATE.md)|Next.js + Stripe|SaaS product|
+|[nextjs-static](nextjs-static/TEMPLATE.md)|Next.js + Framer|Landing page|
+|[express-api](express-api/TEMPLATE.md)|Express + JWT|REST API|
+|[python-fastapi](python-fastapi/TEMPLATE.md)|FastAPI|Python API|
+|[react-native-app](react-native-app/TEMPLATE.md)|Expo + Zustand|Mobile app|
+|[flutter-app](flutter-app/TEMPLATE.md)|Flutter + Riverpod|Cross-platform|
+|[electron-desktop](electron-desktop/TEMPLATE.md)|Electron + React|Desktop app|
+|[chrome-extension](chrome-extension/TEMPLATE.md)|Chrome MV3|Browser extension|
+|[cli-tool](cli-tool/TEMPLATE.md)|Node.js + Commander|CLI app|
+|[monorepo-turborepo](monorepo-turborepo/TEMPLATE.md)|Turborepo + pnpm|Monorepo|
+|[astro-static](astro-static/TEMPLATE.md)|Astro + MDX|Blog / Docs|
 
 ---