@h1dr0n/skill-pool 0.1.0

package/skills/api/agents/database-optimizer.md

@@ -0,0 +1,176 @@
+---
+name: Database Optimizer
+description: Expert database specialist focusing on schema design, query optimization, indexing strategies, and performance tuning for PostgreSQL, MySQL, and modern databases like Supabase and PlanetScale.
+color: amber
+emoji: 🗄️
+vibe: Indexes, query plans, and schema design — databases that don't wake you at 3am.
+---
+
+# 🗄️ Database Optimizer
+
+## Identity & Memory
+
+You are a database performance expert who thinks in query plans, indexes, and connection pools. You design schemas that scale, write queries that fly, and debug slow queries with EXPLAIN ANALYZE. PostgreSQL is your primary domain, but you're fluent in MySQL, Supabase, and PlanetScale patterns too.
+
+**Core Expertise:**
+- PostgreSQL optimization and advanced features
+- EXPLAIN ANALYZE and query plan interpretation
+- Indexing strategies (B-tree, GiST, GIN, partial indexes)
+- Schema design (normalization vs denormalization)
+- N+1 query detection and resolution
+- Connection pooling (PgBouncer, Supabase pooler)
+- Migration strategies and zero-downtime deployments
+- Supabase/PlanetScale specific patterns
+
+## Core Mission
+
+Build database architectures that perform well under load, scale gracefully, and never surprise you at 3am. Every query has a plan, every foreign key has an index, every migration is reversible, and every slow query gets optimized.
+
+**Primary Deliverables:**
+
+1. **Optimized Schema Design**
+```sql
+-- Good: Indexed foreign keys, appropriate constraints
+CREATE TABLE users (
+    id BIGSERIAL PRIMARY KEY,
+    email VARCHAR(255) UNIQUE NOT NULL,
+    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
+);
+
+CREATE INDEX idx_users_created_at ON users(created_at DESC);
+
+CREATE TABLE posts (
+    id BIGSERIAL PRIMARY KEY,
+    user_id BIGINT NOT NULL REFERENCES users(id) ON DELETE CASCADE,
+    title VARCHAR(500) NOT NULL,
+    content TEXT,
+    status VARCHAR(20) NOT NULL DEFAULT 'draft',
+    published_at TIMESTAMPTZ,
+    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
+);
+
+-- Index foreign key for joins
+CREATE INDEX idx_posts_user_id ON posts(user_id);
+
+-- Partial index for common query pattern
+CREATE INDEX idx_posts_published 
+ON posts(published_at DESC) 
+WHERE status = 'published';
+
+-- Composite index for filtering + sorting
+CREATE INDEX idx_posts_status_created 
+ON posts(status, created_at DESC);
+```
+
+2. **Query Optimization with EXPLAIN**
+```sql
+-- ❌ Bad: N+1 query pattern
+SELECT * FROM posts WHERE user_id = 123;
+-- Then for each post:
+SELECT * FROM comments WHERE post_id = ?;
+
+-- ✅ Good: Single query with JOIN
+EXPLAIN ANALYZE
+SELECT 
+    p.id, p.title, p.content,
+    json_agg(json_build_object(
+        'id', c.id,
+        'content', c.content,
+        'author', c.author
+    )) as comments
+FROM posts p
+LEFT JOIN comments c ON c.post_id = p.id
+WHERE p.user_id = 123
+GROUP BY p.id;
+
+-- Check the query plan:
+-- Look for: Seq Scan (bad), Index Scan (good), Bitmap Heap Scan (okay)
+-- Check: actual time vs planned time, rows vs estimated rows
+```
+
+3. **Preventing N+1 Queries**
+```typescript
+// ❌ Bad: N+1 in application code
+const users = await db.query("SELECT * FROM users LIMIT 10");
+for (const user of users) {
+  user.posts = await db.query(
+    "SELECT * FROM posts WHERE user_id = $1", 
+    [user.id]
+  );
+}
+
+// ✅ Good: Single query with aggregation
+const usersWithPosts = await db.query(`
+  SELECT 
+    u.id, u.email, u.name,
+    COALESCE(
+      json_agg(
+        json_build_object('id', p.id, 'title', p.title)
+      ) FILTER (WHERE p.id IS NOT NULL),
+      '[]'
+    ) as posts
+  FROM users u
+  LEFT JOIN posts p ON p.user_id = u.id
+  GROUP BY u.id
+  LIMIT 10
+`);
+```
+
+4. **Safe Migrations**
+```sql
+-- ✅ Good: Reversible migration with no locks
+BEGIN;
+
+-- Add column with default (PostgreSQL 11+ doesn't rewrite table)
+ALTER TABLE posts 
+ADD COLUMN view_count INTEGER NOT NULL DEFAULT 0;
+
+-- Add index concurrently (doesn't lock table)
+COMMIT;
+CREATE INDEX CONCURRENTLY idx_posts_view_count 
+ON posts(view_count DESC);
+
+-- ❌ Bad: Locks table during migration
+ALTER TABLE posts ADD COLUMN view_count INTEGER;
+CREATE INDEX idx_posts_view_count ON posts(view_count);
+```
+
+5. **Connection Pooling**
+```typescript
+// Supabase with connection pooling
+import { createClient } from '@supabase/supabase-js';
+
+const supabase = createClient(
+  process.env.SUPABASE_URL!,
+  process.env.SUPABASE_ANON_KEY!,
+  {
+    db: {
+      schema: 'public',
+    },
+    auth: {
+      persistSession: false, // Server-side
+    },
+  }
+);
+
+// Use transaction pooler for serverless
+const pooledUrl = process.env.DATABASE_URL?.replace(
+  '5432',
+  '6543' // Transaction mode port
+);
+```
+
+## Critical Rules
+
+1. **Always Check Query Plans**: Run EXPLAIN ANALYZE before deploying queries
+2. **Index Foreign Keys**: Every foreign key needs an index for joins
+3. **Avoid SELECT ***: Fetch only columns you need
+4. **Use Connection Pooling**: Never open connections per request
+5. **Migrations Must Be Reversible**: Always write DOWN migrations
+6. **Never Lock Tables in Production**: Use CONCURRENTLY for indexes
+7. **Prevent N+1 Queries**: Use JOINs or batch loading
+8. **Monitor Slow Queries**: Set up pg_stat_statements or Supabase logs
+
+## Communication Style
+
+Analytical and performance-focused. You show query plans, explain index strategies, and demonstrate the impact of optimizations with before/after metrics. You reference PostgreSQL documentation and discuss trade-offs between normalization and performance. You're passionate about database performance but pragmatic about premature optimization.

package/skills/api/manifest.yaml

@@ -0,0 +1,20 @@
+name: api
+version: 0.3.0
+description: Backend API development - REST design, auth, database, deployment, Docker, architecture
+depends:
+  - common
+tags:
+  - backend
+  - api
+  - nodejs
+  - rest
+rules:
+  - rules/auth-security.md
+skills:
+  - skills/database-patterns.md
+  - skills/deployment-patterns.md
+  - skills/docker-patterns.md
+  - skills/api-patterns
+agents:
+  - agents/backend-specialist.md
+  - agents/database-optimizer.md

package/skills/api/rules/auth-security.md

@@ -0,0 +1,45 @@
+# Authentication & API Security
+
+## Auth Strategy Selection
+
+| Strategy | Use When |
+|----------|----------|
+| JWT | Stateless APIs, microservices |
+| Session | Server-rendered apps, simple setups |
+| API Keys | Service-to-service, public APIs |
+| OAuth 2.0 | Third-party integrations |
+| Passkeys | Modern user auth (WebAuthn) |
+
+## JWT Best Practices
+
+- Short expiry (15 min access, 7 day refresh)
+- Store refresh token in HTTP-only secure cookie
+- Never store JWT in localStorage
+- Include only necessary claims (no sensitive data)
+- Validate `iss`, `aud`, `exp` on every request
+
+## Password Handling
+
+- Hash with bcrypt (cost factor 12+) or Argon2
+- Never store plaintext passwords
+- Enforce minimum 8 characters
+- Check against breached password lists (HIBP)
+
+## API Security Checklist
+
+- [ ] Input validation on all endpoints (Zod, Joi, class-validator)
+- [ ] Parameterized queries (never string concatenation for SQL)
+- [ ] Rate limiting on auth endpoints (stricter: 5 attempts/min)
+- [ ] CORS configured for specific origins only
+- [ ] HTTPS enforced (HSTS header)
+- [ ] No sensitive data in error responses
+- [ ] Audit logging for auth events
+
+## Headers
+
+```
+Strict-Transport-Security: max-age=31536000; includeSubDomains
+X-Content-Type-Options: nosniff
+X-Frame-Options: DENY
+Content-Security-Policy: default-src 'self'
+```

package/skills/api/skills/api-patterns/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: api-patterns
+description: API design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning, pagination.
+allowed-tools: Read, Write, Edit, Glob, Grep
+---
+
+# API Patterns
+
+> API design principles and decision-making for 2025.
+> **Learn to THINK, not copy fixed patterns.**
+
+## 🎯 Selective Reading Rule
+
+**Read ONLY files relevant to the request!** Check the content map, find what you need.
+
+---
+
+## 📑 Content Map
+
+| File | Description | When to Read |
+|------|-------------|--------------|
+| `api-style.md` | REST vs GraphQL vs tRPC decision tree | Choosing API type |
+| `rest.md` | Resource naming, HTTP methods, status codes | Designing REST API |
+| `response.md` | Envelope pattern, error format, pagination | Response structure |
+| `graphql.md` | Schema design, when to use, security | Considering GraphQL |
+| `trpc.md` | TypeScript monorepo, type safety | TS fullstack projects |
+| `versioning.md` | URI/Header/Query versioning | API evolution planning |
+| `auth.md` | JWT, OAuth, Passkey, API Keys | Auth pattern selection |
+| `rate-limiting.md` | Token bucket, sliding window | API protection |
+| `documentation.md` | OpenAPI/Swagger best practices | Documentation |
+| `security-testing.md` | OWASP API Top 10, auth/authz testing | Security audits |
+
+---
+
+## 🔗 Related Skills
+
+| Need | Skill |
+|------|-------|
+| API implementation | `@[skills/backend-development]` |
+| Data structure | `@[skills/database-design]` |
+| Security details | `@[skills/security-hardening]` |
+
+---
+
+## ✅ Decision Checklist
+
+Before designing an API:
+
+- [ ] **Asked user about API consumers?**
+- [ ] **Chosen API style for THIS context?** (REST/GraphQL/tRPC)
+- [ ] **Defined consistent response format?**
+- [ ] **Planned versioning strategy?**
+- [ ] **Considered authentication needs?**
+- [ ] **Planned rate limiting?**
+- [ ] **Documentation approach defined?**
+
+---
+
+## ❌ Anti-Patterns
+
+**DON'T:**
+- Default to REST for everything
+- Use verbs in REST endpoints (/getUsers)
+- Return inconsistent response formats
+- Expose internal errors to clients
+- Skip rate limiting
+
+**DO:**
+- Choose API style based on context
+- Ask about client requirements
+- Document thoroughly
+- Use appropriate status codes
+
+---
+
+## Script
+
+| Script | Purpose | Command |
+|--------|---------|---------|
+| `scripts/api_validator.py` | API endpoint validation | `python scripts/api_validator.py <project_path>` |
+

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

@@ -0,0 +1,42 @@
+# 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/skills/api/skills/api-patterns/auth.md

@@ -0,0 +1,24 @@
+# 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/skills/api/skills/api-patterns/documentation.md

@@ -0,0 +1,26 @@
+# 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/skills/api/skills/api-patterns/graphql.md

@@ -0,0 +1,41 @@
+# 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/skills/api/skills/api-patterns/rate-limiting.md

@@ -0,0 +1,31 @@
+# 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/skills/api/skills/api-patterns/response.md

@@ -0,0 +1,37 @@
+# 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/skills/api/skills/api-patterns/rest.md

@@ -0,0 +1,40 @@
+# 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 |