feat: add more skills (from everything-claude-code), config (rules, agents, tools, learning), add new 2 tempalte for dev-team and qc-team

2026-04-06 15:38:01 +07:00
parent 9c80fd3e8f
commit c4c881bba2
22 changed files with 2296 additions and 51 deletions
@@ -0,0 +1,148 @@
+---
+name: api-design
+description: REST API design patterns — resource naming, pagination (cursor/offset), error response format, versioning, idempotency, HATEOAS. Use when designing new APIs, reviewing existing ones, or standardizing API conventions.
+---
+
+# API Design Patterns
+
+Based on ECC api-design skill.
+
+## RESTful Resource Naming
+
+### Good
+```
+GET    /users           # List users
+POST   /users           # Create user
+GET    /users/:id       # Get user
+PUT    /users/:id       # Replace user
+PATCH  /users/:id       # Update user (partial)
+DELETE /users/:id       # Delete user
+
+GET    /users/:id/posts          # User's posts
+POST   /users/:id/posts          # Create post for user
+GET    /users/:id/posts/:postId  # Specific post by user
+```
+
+### Bad
+```
+GET    /getUser           # Action-based (wrong)
+POST   /createUser        # Verb-based (wrong)
+GET    /posts?userId=123  # Flat when nested makes sense
+```
+
+### Rules
+- **Nouns for resources**, verbs for HTTP methods
+- **Plural nouns** for collections: `/users`, not `/user`
+- **Nested resources** for parent-child: `/users/:id/posts`
+- **Hyphens** for multi-word resource names: `/blog-posts`, not `/blogPosts`
+- **Lowercase** only, no trailing slashes
+
+## HTTP Status Codes
+
+| Code | When to Use |
+|------|------------|
+| 200 | Successful GET, PUT, PATCH |
+| 201 | Successful POST (created) — include Location header |
+| 204 | Successful DELETE — no response body |
+| 400 | Invalid request format, missing required fields |
+| 401 | Authentication required or failed |
+| 403 | Authenticated but not authorized |
+| 404 | Resource not found |
+| 409 | Conflict (duplicate, version mismatch) |
+| 422 | Valid JSON but business rule violation |
+| 429 | Rate limit exceeded |
+| 500 | Unexpected server error — always log the real cause |
+
+## Error Response Format
+
+```json
+{
+  "error": {
+    "code": "VALIDATION_ERROR",
+    "message": "Invalid request parameters",
+    "details": [
+      {
+        "field": "email",
+        "message": "Must be a valid email address"
+      }
+    ],
+    "request_id": "req_abc123"
+  }
+}
+```
+
+### Error codes to use consistently
+- `VALIDATION_ERROR` — input validation failed
+- `NOT_FOUND` — resource doesn't exist
+- `UNAUTHORIZED` — auth missing or expired
+- `FORBIDDEN` — lacks permission
+- `RATE_LIMITED` — too many requests
+- `CONFLICT` — duplicate or version mismatch
+- `INTERNAL_ERROR` — unexpected server failure
+
+## Pagination
+
+### Cursor-based (RECOMMENDED for large datasets)
+```json
+{
+  "data": [...],
+  "pagination": {
+    "next_cursor": "eyJpZCI6MTAwfQ==",
+    "has_more": true,
+    "limit": 20
+  }
+}
+```
+
+### Offset-based (acceptable for small datasets)
+```json
+{
+  "data": [...],
+  "pagination": {
+    "total": 500,
+    "page": 2,
+    "per_page": 20,
+    "total_pages": 25
+  }
+}
+```
+
+## API Versioning
+
+### URL path versioning (simplest)
+```
+/api/v1/users
+/api/v2/users
+```
+
+### Header versioning (cleaner)
+```
+Accept: application/vnd.api+json; version=1
+```
+
+## Idempotency
+
+- **GET, PUT, DELETE** are naturally idempotent
+- **POST** needs idempotency for safety:
+  - Accept `Idempotency-Key` header
+  - Store hash of request + result
+  - Return cached result if same key received again
+
+## Rate Limiting
+
+```
+X-RateLimit-Limit: 1000
+X-RateLimit-Remaining: 999
+X-RateLimit-Reset: 1625097600
+```
+
+## Checklist
+
+- [ ] Resources use plural nouns
+- [ ] HTTP methods match CRUD operations
+- [ ] Consistent error response format
+- [ ] Pagination on all list endpoints
+- [ ] Rate limiting on public endpoints
+- [ ] Authentication on protected endpoints
+- [ ] API documentation (OpenAPI/Swagger)
+- [ ] Backward compatibility for version changes
@@ -0,0 +1,91 @@
+---
+name: autonomous-loops
+description: Autonomous loop patterns for AI agents — sequential pipelines, retry loops, DAG orchestration. Use when building self-correcting workflows or multi-step automation.
+---
+
+# Autonomous Loop Patterns
+
+Based on ECC autonomous-loops skill.
+
+## Pattern 1: Sequential Pipeline
+
+Run steps A → B → C → D, each depending on the previous.
+
+```python
+result = step_a(input)
+result = step_b(result)
+result = step_c(result)
+output = step_d(result)
+```
+
+**When to use**: Linear data processing, ETL, content generation pipeline.
+
+**Key**: Each step validates its output before passing to next.
+
+## Pattern 2: Retry with Self-Correction
+
+Run task, check result, if fails → diagnose → fix → retry → max N times.
+
+```
+MAX_RETRIES = 3
+for attempt in range(MAX_RETRIES):
+    result = run_task()
+    errors = validate(result)
+    if not errors:
+        break
+    fix_errors(errors)  # Self-correct based on validation
+else:
+    raise Exception(f"Failed after {MAX_RETRIES} attempts")
+```
+
+**When to use**: Code generation with validation, test fixing, migration scripts.
+
+**Key**: The fix step must be SPECIFIC — generic retries don't work.
+
+## Pattern 3: DAG Orchestration
+
+Tasks with dependencies forming a Directed Acyclic Graph.
+- Independent tasks run in parallel
+- Dependent tasks wait for prerequisites
+
+```
+A ──→ B ───→ D
+  ──→ C ──→
+```
+
+**When to use**: Multi-agent coordination, build pipelines, complex deployments.
+
+**Key**: Detect cycles in dependency graph before execution.
+
+## Pattern 4: Observer Loop
+
+Continuous monitoring with alert-on-change.
+
+```
+while running:
+    state = observe()
+    if state != expected:
+        alert(state)
+        adapt()
+    sleep(check_interval)
+```
+
+**When to use**: CI monitoring, resource monitoring, system health.
+
+**Key**: Avoid tight loops — add backoff, throttling.
+
+## Observer Reliability
+
+- **Memory explosion fix**: Use tail sampling (keep last N observations)
+- **Throttling**: Rate-limit checks to avoid token waste
+- **Lazy start**: Begin observations only after setup complete
+- **Re-entrancy guard**: Don't start loop if already running
+
+## Best Practices
+
+1. Always have a MAX_RETRIES or timeout
+2. Log every iteration for audit
+3. Make errors SPECIFIC so fix step can act
+4. Don't retry the same prompt — adapt it
+5. For DAGs: validate no cycles before start
+6. For observers: throttle, don't poll aggressively
@@ -0,0 +1,86 @@
+---
+name: code-quality-gate
+description: Pre-commit and pre-merge code quality enforcement — lint, type-check, test, security scan, coverage threshold. Use when setting up CI gates, pre-commit hooks, or quality checks.
+---
+
+# Code Quality Gate
+
+Combines patterns from ECC plankton-code-quality + AGENTS.md review standards.
+
+## Gate Structure
+
+### Level 1: Pre-Commit (Fast)
+- Lint (ESLint, ruff, golangci-lint)
+- Format check (Prettier, black, gofmt)
+- Type check (tsc, mypy)
+- No console.log / print statements
+
+### Level 2: Pre-Test (Medium)
+- Unit tests
+- Static analysis / code quality scan
+- Dependency security audit
+- Build succeeds
+
+### Level 3: Pre-Merge (Comprehensive)
+- All tests pass (unit + integration + E2E)
+- Code coverage meets threshold (> 80%)
+- Security scan passes (no Critical/High CVEs)
+- 3-tier review completed (self → peer → leader)
+- No merge conflicts
+- Documentation updated
+
+## Implementation
+
+### Pre-commit Hook (using pre-commit framework)
+```yaml
+# .pre-commit-config.yaml
+repos:
+  - repo: https://github.com/pre-commit/mirrors-eslint
+    hooks: [id: eslint]
+  - repo: https://github.com/charliermarsh/ruff-pre-commit
+    hooks: [id: ruff]
+  - repo: https://github.com/golangci/golangci-lint
+    hooks: [id: golangci-lint]
+```
+
+### CI Gate Script
+```bash
+#!/bin/bash
+set -e
+echo "=== Quality Gate ==="
+echo "1. Lint..."
+npm run lint || { echo "FAIL: Lint"; exit 1; }
+
+echo "2. Type check..."
+npm run typecheck || { echo "FAIL: Type check"; exit 1; }
+
+echo "3. Unit tests..."
+npm test -- --coverage --coverageThreshold='{"global":{"lines":80}}' || { echo "FAIL: Tests"; exit 1; }
+
+echo "4. Security audit..."
+npm audit --audit-level=high || { echo "WARN: Security audit"; }
+
+echo "5. Build..."
+npm run build || { echo "FAIL: Build"; exit 1; }
+
+echo "=== All gates passed ==="
+```
+
+## Quality Metrics to Track
+
+| Metric | Target | Fail if |
+|--------|--------|---------|
+| Test coverage (lines) | > 80% | < 70% |
+| Test coverage (branches) | > 70% | < 50% |
+| Critical paths coverage | 100% | Any missing |
+| Lint errors | 0 | > 0 |
+| Type errors | 0 | > 0 |
+| Security vulns (Critical/High) | 0 | > 0 |
+| Build time | < 5 min | > 10 min |
+
+## Review Integration
+
+Quality gate must pass BEFORE review can start.
+- Self-review: Gate passes + manual checklist
+- Peer review: Self-review confirmed + peer reads diff
+- Leader review: Both reviews pass + leader approves
@@ -0,0 +1,55 @@
+---
+name: cost-aware-llm-pipeline
+description: Cost optimization for AI development pipelines — model routing, budget tracking, token optimization. Use when managing multi-step AI workflows, reducing API costs, or selecting models for tasks.
+---
+
+# Cost-Aware LLM Pipeline
+
+Based on ECC cost-aware-llm-pipeline patterns.
+
+## Model Selection Strategy
+
+Match model capability to task complexity:
+
+| Task Type | Model Tier | Examples |
+|-----------|-----------|----------|
+| Simple (summarize, classify, format) | Small/Fast | Claude Haiku, GPT-4o-mini |
+| Medium (code fixes, analysis, rewrite) | Mid | Claude Sonnet, GPT-4o |
+| Complex (architecture, debugging, planning) | High | Claude Opus, GPT-4o, Gemini Pro |
+| Creative (design, brainstorming) | Variable | Depends on breadth needed |
+
+## Token Optimization Techniques
+
+1. **Trim system prompts**: Remove redundant instructions. Keep only task-specific rules.
+2. **Compress context**: Use summaries instead of full files. Skip irrelevant code.
+3. **Background processes**: Run long tasks (test suites, builds) async. Don't waste tokens waiting.
+4. **Chunk large files**: Read only relevant sections with offset/limit.
+5. **Avoid loops**: Don't poll in a loop. Use proper timeouts and wait mechanisms.
+
+## Budget Tracking
+
+```bash
+# Check session cost (if available)
+session_status
+
+# Monitor token usage
+# Track: input_tokens, output_tokens, cost_cents
+```
+
+## Cost Reduction Rules
+
+- Use the cheapest model that still works
+- Batch similar requests together
+- Cache responses when possible
+- Avoid regenerating the same output
+- Set explicit max_tokens for generation
+- Use structured output (JSON) to reduce retries
+- Prefer targeted file reads over broad "read everything"
+
+## Pipeline Design
+
+When building multi-step AI workflows:
+1. Step 1: Plan/analyze with mid-tier model
+2. Step 2: Implement with appropriate model for code
+3. Step 3: Verify/test with cheapest model
+4. Step 4: Review with high-tier model only if needed
@@ -0,0 +1,116 @@
+---
+name: database-migrations
+description: Database migration patterns for Prisma, Drizzle, Django, SQLAlchemy, Go migrations. Use when: schema changes, adding columns/tables/indexes, data migrations, rollback strategies.
+---
+
+# Database Migration Patterns
+
+Based on ECC database-migrations skill.
+
+## Universal Rules
+
+1. **Every migration is reversible** — always write DOWN (rollback) migration
+2. **Deploy in phases** when possible:
+   - Phase 1: Add new column/table (non-breaking)
+   - Phase 2: Backfill data / dual-write
+   - Phase 3: Switch reads to new schema
+   - Phase 4: Remove old column/table
+3. **Never drop data in a migration** without explicit user confirmation
+4. **Test migrations** against a copy of production data
+5. **Index new columns** that will be queried frequently
+6. **Add NOT NULL with DEFAULT** when adding columns to existing tables
+
+## Migration Strategy by Framework
+
+### Prisma (TypeScript)
+```bash
+npx prisma migrate dev --name add_user_role
+```
+- Edit schema.prisma → generate migration → review → apply
+- Always check the generated SQL
+
+### Drizzle (TypeScript)
+```bash
+npx drizzle-kit generate:pg --name add_user_role
+```
+- Migration files are TypeScript
+- Easier to review and modify than raw SQL
+
+### Django (Python)
+```bash
+python manage.py makemigrations
+python manage.py migrate
+python manage.py showmigrations
+```
+- Django auto-detects changes
+- For data migrations: use RunPython
+- For complex operations: use migrations.RunSQL
+
+### SQLAlchemy (Python)
+```bash
+alembic revision --autogenerate -m "add_user_role"
+alembic upgrade head
+```
+- Review auto-generated migrations carefully
+- Add missing operations manually
+
+### Go (goose, golang-migrate)
+```bash
+goose create add_user_role sql
+# or
+migrate create -ext sql -dir migrations -seq add_user_role
+```
+- SQL files: up and down
+- Explicit and reviewable
+
+## Data Migration Patterns
+
+### Adding a NOT NULL column with default
+```sql
+-- Safe: existing rows get default value
+ALTER TABLE users ADD COLUMN role VARCHAR(50) NOT NULL DEFAULT 'user';
+-- Then optionally remove default
+ALTER TABLE users ALTER COLUMN role DROP DEFAULT;
+```
+
+### Adding an index
+```sql
+-- Use CONCURRENTLY in production (PostgreSQL)
+CREATE INDEX CONCURRENTLY idx_users_email ON users(email);
+```
+
+### Renaming a column (zero-downtime)
+1. Add new column
+2. Deploy code that writes to both columns
+3. Backfill data from old to new
+4. Switch reads to new column
+5. Remove old column
+
+### Backfill patterns
+```sql
+-- Batch to avoid locking
+UPDATE users SET status = 'active'
+WHERE id IN (
+  SELECT id FROM users WHERE status = 'pending'
+  LIMIT 10000
+);
+```
+
+## Rollback Testing
+
+Before deploying:
+1. Apply migration on staging
+2. Roll it back
+3. Verify data integrity
+4. Re-apply to confirm idempotent
+
+## Checklist
+
+- [ ] Migration file created with descriptive name
+- [ ] DOWN migration written and tested
+- [ ] Migration tested on staging DB
+- [ ] Indexes added for new query columns
+- [ ] NOT NULL columns have DEFAULT values
+- [ ] No raw DROP TABLE (use CASCADE with caution)
+- [ ] Data migrations are idempotent
+- [ ] Migration runs within acceptable time (< 5 min for online)
@@ -0,0 +1,137 @@
+---
+name: deployment-patterns
+description: CI/CD pipeline patterns, Docker containerization, health checks, blue-green deployment, canary releases, rollback strategies. Use when setting up deployment pipelines, containerizing apps, or planning release strategies.
+---
+
+# Deployment Patterns
+
+Based on ECC deployment-patterns skill.
+
+## CI/CD Pipeline Structure
+
+```
+lint → test → build → security-scan → staging-deploy → e2e-test → prod-deploy
+```
+
+### Essential Steps
+1. **Lint**: Code style, static analysis
+2. **Test**: Unit + integration tests
+3. **Build**: Docker image, compile
+4. **Security**: Dependency scan, SAST
+5. **Staging**: Deploy to staging environment
+6. **E2E**: Run end-to-end tests on staging
+7. **Production**: Deploy to production (with rollback plan)
+
+## Health Checks
+
+### Liveness Probe (Am I alive?)
+```yaml
+livenessProbe:
+  httpGet:
+    path: /healthz
+    port: 8080
+  initialDelaySeconds: 3
+  periodSeconds: 10
+```
+
+### Readiness Probe (Am I ready to serve?)
+```yaml
+readinessProbe:
+  httpGet:
+    path: /ready
+    port: 8080
+  initialDelaySeconds: 5
+  periodSeconds: 10
+```
+
+## Deployment Strategies
+
+### Blue-Green (Zero Downtime)
+1. Run current version on "blue"
+2. Deploy new version to "green"
+3. Test green thoroughly
+4. Switch DNS/load-balancer to green
+5. Keep blue for rollback
+
+### Canary (Gradual Rollout)
+1. Deploy to small % of users (5%)
+2. Monitor error rates, latency
+3. If OK → increase to 25%, then 50%, then 100%
+4. If problems → rollback immediately
+
+### Rolling (Default for Kubernetes)
+- Replace pods one by one
+- Built-in to Kubernetes
+- Can have mixed versions briefly
+
+## Docker Patterns
+
+### Multi-Stage Build
+```dockerfile
+FROM node:20-alpine AS builder
+COPY . .
+RUN npm ci --production=false
+RUN npm run build
+
+FROM node:20-alpine AS runtime
+COPY --from=builder /app/dist ./dist
+COPY --from=builder /app/package.json ./
+RUN npm ci --only=production
+EXPOSE 3000
+CMD ["node", "dist/main.js"]
+```
+
+### Docker Compose
+
+```yaml
+services:
+  app:
+    build: .
+    ports: ["3000:3000"]
+    depends_on: [db, redis]
+    healthcheck:
+      test: ["CMD", "curl", "-f", "http://localhost:3000/healthz"]
+  db:
+    image: postgres:16
+    volumes: [pgdata:/var/lib/postgresql/data]
+    environment:
+      POSTGRES_PASSWORD: ${DB_PASSWORD}
+```
+
+## Rollback Strategy
+
+### Pre-deployment checklist
+- [ ] Health checks configured
+- [ ] Logs being captured
+- [ ] Metrics dashboards ready
+- [ ] Rollback procedure documented
+- [ ] Last known good version tagged
+
+### Quick rollback commands
+```bash
+# Kubernetes
+kubectl rollout undo deployment/app
+
+# Docker Compose
+docker compose down && docker compose up -d --no-build  # use previous image
+
+# Nginx
+ln -sfn /var/www/blue /var/www/current && nginx -s reload
+```
+
+## Environment Configuration
+
+- Use environment variables for all config
+- No hardcoded secrets, URLs, ports
+- Separate configs: dev, staging, production
+- Use .env files for local, vault/K8s secrets for production
+
+## Checklist
+
+- [ ] CI pipeline covers lint → test → build → scan → deploy
+- [ ] Health checks (liveness + readiness) defined
+- [ ] Deployment strategy chosen (blue-green, canary, rolling)
+- [ ] Rollback procedure tested
+- [ ] Environment variables managed securely
+- [ ] Docker image is multi-stage (small final image)
+- [ ] Logs structured (JSON format with correlation IDs)
@@ -0,0 +1,184 @@
+---
+name: docker-patterns
+description: Docker and Docker Compose best practices — multi-stage builds, networking, volumes, container security, optimization. Use when writing Dockerfiles, docker-compose.yml, or containerizing applications.
+---
+
+# Docker Patterns
+
+Based on ECC docker-patterns skill.
+
+## Dockerfile Best Practices
+
+### Pin base image versions
+```dockerfile
+# Good
+FROM node:20.11.0-alpine3.19
+
+# Bad — version changes can break builds
+FROM node:latest
+```
+
+### Multi-Stage Builds for minimal images
+```dockerfile
+# Stage 1: Build
+FROM golang:1.22-bookworm AS builder
+WORKDIR /app
+COPY go.mod go.sum ./
+RUN go mod download
+COPY . .
+RUN CGO_ENABLED=0 go build -o myapp -ldflags="-s -w"
+
+# Stage 2: Runtime (small image)
+FROM scratch
+COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/
+COPY --from=builder /app/myapp /myapp
+USER 1000
+CMD ["/myapp"]
+```
+
+### Layer caching optimization
+```dockerfile
+# Copy dependency files first, install, then copy rest
+COPY package.json package-lock.json ./
+RUN npm ci --production=false
+COPY . .
+```
+
+### .dockerignore
+```
+node_modules/
+.git/
+.env
+dist/
+*.log
+__pycache__
+*.pyc
+```
+
+## Docker Compose Patterns
+
+### Production-ready compose
+```yaml
+name: myapp
+services:
+  app:
+    image: myapp:${APP_VERSION:-latest}
+    restart: unless-stopped
+    environment:
+      DATABASE_URL: postgresql://${DB_USER}:${DB_PASSWORD}@db:5432/myapp
+      NODE_ENV: production
+    depends_on:
+      db:
+        condition: service_healthy
+    healthcheck:
+      test: ["CMD", "wget", "--spider", "http://localhost:3000/healthz"]
+      interval: 30s
+      timeout: 10s
+      retries: 3
+    networks: [app-net]
+    deploy:
+      resources:
+        limits:
+          memory: 512M
+          cpus: "0.5"
+
+  db:
+    image: postgres:16-alpine
+    volumes:
+      - pgdata:/var/lib/postgresql/data
+    environment:
+      POSTGRES_DB: myapp
+      POSTGRES_USER: ${DB_USER}
+      POSTGRES_PASSWORD: ${DB_PASSWORD}
+    healthcheck:
+      test: ["CMD-SHELL", "pg_isready -U ${DB_USER}"]
+      interval: 10s
+      timeout: 5s
+      retries: 5
+
+networks:
+  app-net:
+    driver: bridge
+
+volumes:
+  pgdata:
+```
+
+## Container Security
+
+### Run as non-root
+```dockerfile
+RUN addgroup -S appgroup && adduser -S appuser -G appgroup
+USER appuser
+```
+
+### No sensitive data in images
+- Never COPY .env files
+- Never hardcode credentials in Dockerfile
+- Use docker secrets, env vars at runtime
+
+### Minimize attack surface
+- Use Alpine or distroless base images
+- Remove build tools from final image (multi-stage)
+- Only expose needed ports
+
+### Scan images
+```bash
+# Scan for vulnerabilities
+docker scout cve myapp:latest
+
+# Scan Dockerfile for issues
+hadolint Dockerfile
+```
+
+## Networking
+
+### Service-to-service communication
+```yaml
+# Compose: services can reach each other by name
+# app can reach db at hostname "db" on port 5432
+```
+
+### Isolating networks
+```yaml
+networks:
+  frontend:  # Public-facing services
+  backend:   # DB, cache (not exposed to outside)
+```
+
+## Volumes
+
+### Named volumes (data persistence)
+```yaml
+volumes:
+  - pgdata:/var/lib/postgresql/data  # Persisted data
+  - redis-data:/data
+```
+
+### Bind mounts (development)
+```yaml
+volumes:
+  - ./src:/app/src:ro  # Read-only code mount
+  - /data:/app/logs    # Log output
+```
+
+## Optimization Tips
+
+1. **Smallest base image**: `scratch` > `alpine` > `slim` > `full`
+2. **Layer count**: Fewer layers = smaller image
+3. **COPY order**: Dependencies first, then application code
+4. **Combined RUN commands**: `RUN apt-get update && apt-get install -y x && rm -rf /var/lib/apt/lists/*`
+5. **Multi-stage**: Build tools in builder, runtime only in final
+6. **Distroless for Go/Rust**: `FROM scratch` with just the binary
+
+## Checklist
+
+- [ ] Base image pinned to specific version
+- [ ] Multi-stage build for production
+- [ ] Non-root user
+- [ ] .dockerignore complete
+- [ ] Health checks configured
+- [ ] No secrets in image
+- [ ] Minimal base image
+- [ ] Volumes for persistent data
+- [ ] Network isolation
@@ -0,0 +1,119 @@
+---
+name: e2e-testing
+description: End-to-end testing strategy using Playwright or similar frameworks. Covers critical user journeys, visual regression, and cross-browser testing. Use when setting up E2E tests, writing E2E suites, or troubleshooting E2E failures.
+---
+
+# E2E Testing Skill
+
+Based on ECC e2e-testing and Playwright patterns.
+
+## When to Use
+
+- Setting up E2E tests for a project
+- Writing E2E test scenarios
+- Fixing flaky E2E tests
+- User requests E2E test implementation
+
+## Strategy
+
+### What to Test E2E
+
+Test CRITICAL user journeys only. Not every function. E2E is slow and expensive.
+
+Prioritize:
+1. User signup and login flow
+2. Core feature: the ONE thing this app is built for
+3. Payment / checkout (if applicable)
+4. Key data creation, reading, update, deletion
+5. Error flow: what happens when things break
+
+### What NOT to Test E2E
+
+- Individual functions (unit tests)
+- Internal API contracts (integration tests)
+- UI component rendering (component tests)
+- Edge cases that are hard to trigger (unit tests)
+
+## Setup Pattern
+
+### Playwright (Recommended)
+
+```typescript
+// tests/e2e/login.spec.ts
+import { test, expect } from '@playwright/test';
+
+test.describe('Authentication', () => {
+  test('user can login with valid credentials', async ({ page }) => {
+    await page.goto('/login');
+    await page.fill('[name="email"]', 'user@example.com');
+    await page.fill('[name="password"]', 'correct-password');
+    await page.click('button[type="submit"]');
+    await expect(page).toHaveURL('/dashboard');
+  });
+
+  test('login fails with wrong password', async ({ page }) => {
+    await page.goto('/login');
+    await page.fill('[name="email"]', 'user@example.com');
+    await page.fill('[name="password"]', 'wrong');
+    await page.click('button[type="submit"]');
+    await expect(page.locator('[data-testid="error"]')).toBeVisible();
+  });
+});
+```
+
+### Page Object Model (For Complex Apps)
+
+```typescript
+// tests/e2e/pages/LoginPage.ts
+export class LoginPage {
+  constructor(private page: Page) {}
+
+  async goto() { await this.page.goto('/login'); }
+  async fillEmail(email: string) { await this.page.fill('[name="email"]', email); }
+  async fillPassword(password: string) { await this.page.fill('[name="password"]', password); }
+  async submit() { await this.page.click('button[type="submit"]'); }
+  async getError() { return this.page.locator('[data-testid="error"]'); }
+}
+```
+
+## Best Practices
+
+1. **Independent tests**: Each test starts fresh (no shared state)
+2. **Deterministic**: No flaky timing; use proper waits, not sleep
+3. **Readable**: Test names describe behavior, not implementation
+4. **Fast**: Parallelize when possible; limit browser contexts
+5. **Data isolation**: Use test fixtures, not production data
+6. **Screenshots on failure**: Configure in playwright.config.ts
+
+```typescript
+// playwright.config.ts
+export default defineConfig({
+  use: {
+    screenshot: 'only-on-failure',
+    trace: 'retain-on-failure',
+  },
+  fullyParallel: true,
+  retries: process.env.CI ? 2 : 0,
+});
+```
+
+## Common Anti-Patterns
+
+- Testing every possible input combination (do unit tests instead)
+- Hard-coded sleep/waitFixed (use proper waits on DOM conditions)
+- Shared test data between tests (creates flakiness)
+- Testing implementation details instead of user behavior
+- Too many E2E tests (aim for 20-30 covering critical flows max)
+
+## Report Format
+
+```
+## E2E Test Report
+Tests: X pass / Y fail / Z skipped
+Critical flows covered: [list]
+Flaky tests detected: [list or "none"]
+Screenshots saved: [path or "none"]
+Browser: Chromium/Firefox/WebKit (version)
+
+Status: All critical flows verified / Issues found: [list]
+```
@@ -0,0 +1,80 @@
+---
+name: iterative-retrieval
+description: Progressive context retrieval for AI agents — start broad, then narrow. Use when working with large codebases, debugging complex issues, or when initial search was insufficient.
+---
+
+# Iterative Retrieval Pattern
+
+Based on ECC iterative-retrieval skill.
+
+## The Problem
+
+AI agents working with large codebases often retrieve too much (wasting tokens) or too little (missing context). Iterative retrieval solves this by refining context progressively.
+
+## The Pattern
+
+### Iteration 1: Broad Scan
+- Get high-level structure: directory listing, file names
+- Identify relevant files/directories
+- Read entry points and interfaces
+
+### Iteration 2: Targeted Deep Dive
+- Read specific files identified in Iteration 1
+- Focus on functions/classes relevant to the task
+- Map data flow and dependencies
+
+### Iteration 3: Context Enrichment
+- Read test files for expected behavior
+- Read related code that was discovered
+- Check git history for recent changes
+
+### Iteration 4: Resolution
+- Synthesize all findings
+- Identify the exact issue or solution
+- Implement with full context
+
+## When to Use
+
+- First attempt didn't find the root cause
+- Bug involves multiple files/modules
+- Need to understand a feature before modifying it
+- Large function or file (need selective reading)
+- Dependency chain spans many layers
+
+## Techniques
+
+### Use offset/limit for large files
+Don't read entire 2000-line files. Read relevant sections:
+```
+read file.ts offset=50 limit=100  # Read lines 50-150
+```
+
+### Use grep to find patterns first
+```bash
+grep -rn "function_name" src/        # Find where defined
+grep -rn "import.*module" src/       # Find usage
+git log --oneline -10 -- path/       # Recent changes
+```
+
+### Build a mental map
+After each iteration, update your understanding:
+- What files are relevant?
+- What is the data flow?
+- Where is the issue likely to be?
+- What am I still missing?
+
+## Avoiding Token Waste
+
+- Stop iterating when you have enough context to act
+- Don't read files that aren't directly relevant
+- Use targeted searches instead of broad reads
+- Summarize findings to reduce context in next iteration
+- Use read file with offset/limit for large files
+
+## Exit Criteria
+
+Stop iterating when:
+1. You understand the code flow relevant to your task
+2. You've identified the exact location of the issue
+3. You have enough context to implement a solution
+4. Additional reading won't change your approach
@@ -0,0 +1,75 @@
+---
+name: search-first
+description: Research-before-coding workflow. Search web, docs, and codebase before writing code. Use when: unfamiliar tech, library selection, API design, solving errors you haven't seen, architecture decisions.
+---
+
+# Search-First Workflow
+
+Based on ECC search-first skill. Research BEFORE implementation decisions.
+
+## When to Use This Flow
+
+Before starting ANY new feature, library integration, or architecture decision, follow this flow.
+
+## The Flow
+
+### 1. Understand the Problem
+- Read requirements fully
+- Identify unknowns or assumptions
+- List what you NEED to know vs what's nice to know
+
+### 2. Search Existing Codebase First
+```bash
+# Search for similar implementations
+grep -rn "pattern" src/
+# Check existing dependencies
+cat package.json | grep "search_term"
+cat pyproject.toml
+cat go.mod
+# Check existing tests for patterns
+grep -rn "describe" **/tests/  # or equivalent
+```
+
+### 3. Search Documentation
+- Official docs first
+- API reference
+- Migration guides (if upgrading)
+- GitHub issues (known problems, workarounds)
+
+### 4. Search Web
+```
+query examples:
+- "[library] best practices 2024 2025"
+- "[library] equivalent of [other_library] pattern"
+- "[framework] common pitfalls"
+- "[tech] performance optimization patterns"
+```
+
+### 5. Synthesize Findings
+- Compare 2-3 approaches
+- Document trade-offs
+- Select the BEST approach with reasoning
+- Note any caveats or gotchas discovered
+
+### 6. Design THEN Implement
+- Write brief design doc if complex
+- Get approval if needed
+- THEN start coding
+
+## Anti-Patterns to Avoid
+
+- Jumping straight into code without research
+- Using outdated patterns (check dates)
+- Choosing first library without comparing alternatives
+- Skipping codebase search (reinventing existing solutions)
+- Ignoring migration notes (breaking changes)
+
+## Research Checklist
+
+Before coding:
+- [ ] Searched codebase for existing patterns?
+- [ ] Read official docs for version being used?
+- [ ] Compared at least 2 approaches/libraries?
+- [ ] Read recent GitHub issues for known problems?
+- [ ] Verified compatibility with existing dependencies?
+- [ ] Checked performance benchmarks if relevant?
@@ -0,0 +1,93 @@
+---
+name: security-review
+description: Security audit for code — scan for vulnerabilities, hardcoded secrets, input validation issues, injection risks, auth misconfigurations. Use when reviewing code, before merge, or on request.
+---
+
+# Security Review Skill
+
+Based on ECC AgentShield patterns + OWASP Top 10.
+
+## When to Use
+
+- Before merging any code
+- Code review step
+- User explicitly requests security scan
+- Adding auth or handling sensitive data
+
+## Scan Checklist
+
+### 1. Secrets Detection
+- Hardcoded API keys, passwords, tokens, connection strings
+- `.env` files committed (check `.gitignore`)
+- AWS credentials, JWT secrets, OAuth client secrets
+- Search patterns: `password\s*=\s*["']`, `api_key\s*=\s*["']`, `secret\s*=\s*["']`
+
+### 2. Input Validation
+- ALL user input validated before use
+- No raw string concatenation for SQL
+- HTML output escaped (XSS prevention)
+- File path traversal prevention
+- File upload type and size validation
+
+### 3. Authentication & Authorization
+- Protected endpoints require auth
+- Role-based access control enforced server-side
+- JWT tokens validated (expiration, signature)
+- Session security (HttpOnly, Secure, SameSite)
+- No privilege escalation paths
+
+### 4. Data Protection
+- Sensitive data encrypted at rest
+- TLS in transit
+- PII not logged
+- Password hashing (bcrypt, argon2 — NOT md5, sha1)
+
+### 5. Infrastructure
+- HTTPS enforced
+- CORS configured (not wildcard)
+- Rate limiting on public endpoints
+- Security headers (CSP, HSTS, X-Frame-Options)
+- Dependencies scanned for CVEs
+
+## Execution
+
+```bash
+# Quick scan for secrets
+grep -rn --include='*.py' --include='*.ts' --include='*.js' --include='*.go' \
+  -E '(password|secret|api_key|token)\s*=\s*["\x27][^$\{]' app/ tests/
+
+# Check .gitignore
+cat .gitignore | grep -E '\.env|credentials|secrets'
+
+# Check dependencies for CVEs
+npm audit        # Node.js
+pip audit         # Python
+go list -m all -json | nancy check  # Go
+
+# Check for common injection patterns
+grep -rn 'exec\(|eval\(|system(' app/
+grep -rn 'SELECT.*' + app/   # SQL concatenation
+grep -rn 'innerHTML\s*=' app/   # XSS
+```
+
+## Report Format
+
+```
+## Security Review: [Project/Task]
+**Overall Risk**: Low / Medium / High / Critical
+
+### Critical (must fix before deploy):
+1. [Issue] at [file:line] — [recommendation]
+
+### High (should fix):
+1. [Issue] — [recommendation]
+
+### Medium (recommended):
+1. [Issue] — [recommendation]
+
+### Verified Safe:
+- [List: input validation, auth enforcement, no hardcoded secrets, etc.]
+
+### Dependencies:
+- Vulnerabilities found: X (Critical: Y, High: Z)
+```
@@ -0,0 +1,83 @@
+---
+name: strategic-compact
+description: Systematic context compaction for AI agents — reduce conversation history while preserving critical information. Use when conversation is long, context window is tight, or before handing off to another agent.
+---
+
+# Strategic Compaction
+
+Based on ECC strategic-compact skill.
+
+## When to Compact
+
+- Conversation history exceeds 50% of context window
+- Handing off to another agent (need condensed context)
+- Long debugging session with many iterations
+- Starting a new phase of work after long exploration
+- Before spawning sub-agents (they get context via handoff)
+
+## Compaction Strategy
+
+### What to KEEP (high priority)
+- User instructions and requirements
+- Key decisions made and why
+- Architecture/design choices
+- Current state of work (what's done, what's next)
+- Open questions and blockers
+- File paths and code snippets that are actively being worked on
+
+### What to REMOVE (low priority)
+- Intermediate debugging steps that led nowhere
+- Multiple attempts that were superseded
+- Raw tool output that's been summarized
+- Conversational filler
+- Explored alternatives that were rejected (keep only the final decision)
+- Old scratch work
+
+### What to SUMMARIZE (medium priority, replace with brief summary)
+- Long chain of reasoning → "Investigated X, found Y, decided Z because..."
+- Multiple file reads → "Read 15 files in src/, key ones are A, B, C"
+- Test output iterations → "Fixed 3 test failures: details in git log"
+- API exploration → "Researched 3 libraries, chose X because..."
+
+## Compaction Output Format
+
+```
+## Context Summary — [date/time]
+
+### Project: [name]
+**Current goal**: [what are we working on right now]
+**Status**: [where we are]
+
+### Key decisions:
+1. [Decision] because [reason]
+2. [Decision] because [reason]
+
+### Current state:
+- Done: [completed items]
+- In progress: [what's being worked on]
+- Next: [what comes after]
+- Blocked by: [if any]
+
+### Relevant files:
+- [path/to/file]: [brief description of role]
+- [path/to/file]: [brief description of role]
+
+### Open questions:
+- [question]? — [status: answered/pending/needs-input]
+
+### Code context (brief snippets if critical):
+- [key function signature or interface definition]
+```
+
+## Techniques
+
+### Before Compacting
+1. Write down everything important in a summary file
+2. Commit if possible (git provides history)
+3. Update any tracking files (MEMORY.md, memory/daily)
+
+### After Compacting
+1. Verify the summary has all key info
+2. Check that the next step is clear
+3. Ensure file paths and key names are preserved
+4. Test if you can continue work from the summary alone
@@ -0,0 +1,93 @@
+---
+name: verification-loop
+description: Systematic verification before claiming completion — run tests, check coverage, verify edge cases, inspect CI. Use when about to mark a task done, before merge, or when user asks "is it ready?"
+---
+
+# Verification Loop Skill
+
+Based on ECC verification-loop + verification-before-completion patterns.
+
+## When to Use
+
+- Before claiming any task is complete
+- Before merge or PR
+- User asks "is it ready?" or "có ổn chưa?"
+- After fixing a bug
+
+## Loop Steps
+
+### 1. Run Tests
+```bash
+npm test          # or your test command
+pytest tests/     # Python
+go test ./...     # Go
+```
+If ANY test fails — FIX first, do NOT claim done.
+
+### 2. Check Coverage
+```bash
+npm run coverage  # or equivalent
+```
+Thresholds:
+- Line coverage: > 80%
+- Branch coverage: > 70%
+- Critical paths: 100% (auth, payments, data mutations)
+
+### 3. Verify Edge Cases
+For each input or parameter:
+- null / None / undefined
+- Empty string, empty array, empty object
+- Maximum allowed length/value
+- Minimum allowed length/value
+- Special characters
+- Boundary values (just above, just below limit)
+
+### 4. Check for Regressions
+```bash
+git diff --name-only HEAD~1  # or relevant range
+```
+Verify changes don't break existing functionality. Run full test suite.
+
+### 5. Lint and Type Check
+```bash
+npm run lint && npm run typecheck  # TypeScript
+ruff check . && mypy .              # Python
+golangci-lint run                    # Go
+```
+
+### 6. Review the Diff
+```bash
+git diff
+```
+Read every changed line. Verify:
+- No accidental deletions
+- No debug code left (print, console.log, debugger)
+- No commented-out code
+- No TODO without ticket reference
+- Code matches what was asked
+
+### 7. Build Check
+```bash
+npm run build    # or equivalent
+```
+Must succeed with zero errors.
+
+## Decision
+
+If ALL steps pass — safe to mark complete.
+If ANY step fails — list issues, fix, re-run loop.
+
+## Report Template
+
+```
+## Verification: [Task/Feature]
+Tests: X/X pass (previously Y/Z)
+Coverage: X% line (threshold: 80%), Y% branch (threshold: 70%)
+Lint: clean / X warnings / X errors
+Build: success / failed with [details]
+Edge cases: all covered / gaps: [list]
+Regressions: none / [list with test names]
+Diff review: clean / issues: [list]
+
+Status: READY / NOT READY
+```