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
@@ -174,6 +174,72 @@ User explicitly stated: "với mọi dự án thì tôi đều muốn mọi th
 - First-Seen: 2026-03-31
 - Last-Seen: 2026-03-31

+---
+## New Learnings — 2026-04-06 (ClawTeam Templates & Dev Team Expansion)
+
+### [LRN-20260406-001] use_clawteam_templates_for_team_creation
+
+**Logged**: 2026-04-06T07:25:00Z
+**Priority**: high
+**Status**: resolved
+**Area**: orchestration
+
+### Summary
+When a requested team type doesn't exist, first check `~/.clawteam/templates/` for a matching template before creating a team from scratch.
+
+### Details
+User instruction: If dev-team (or any team type) doesn't exist, look in `~/.clawteam/templates/` directory first. Templates provide pre-configured roles, tasks, and worker instructions. Available templates:
+- `dev-team.toml` — Tech Lead + Full-stack + Frontend + Backend + UX/UI
+- `qc-team.toml` — QC Lead + Code Reviewer + Test Engineer + Acceptance Auditor
+
+Before spawning any team, run `ls ~/.clawteam/templates/` to see what's available. If template exists, use it as the base configuration.
+
+### Suggested Action
+- Always check `~/.clawteam/templates/` when user requests team creation
+- If template exists, use it (modify if needed)
+- If no template exists, create one from scratch and save to templates for future reuse
+
+### Metadata
+- Source: user_instruction
+- Related Files: ~/.clawteam/templates/dev-team.toml, ~/.clawteam/templates/qc-team.toml
+- Tags: clawteam, templates, team-creation
+- Pattern-Key: orchestration.use_templates_for_teams
+- Recurrence-Count: 1
+- First-Seen: 2026-04-06
+
+---
+
+### [LRN-20260406-002] dev_team_includes_qc_and_devops
+
+**Logged**: 2026-04-06T07:30:00Z
+**Priority**: high
+**Status**: resolved
+**Area**: orchestration
+
+### Summary
+Dev team must include QC (Quality Control) and DevOps roles. Updated dev-team.toml template to add `qc-lead`, `qa-engineer`, and `devops-engineer` agents.
+
+### Details
+User explicitly requested adding 1 QC and 1 DevOps to the dev-team template. Updated `~/.clawteam/templates/dev-team.toml` with:
+- `qc-lead` — Code quality gate, review coordination, acceptance criteria
+- `qa-engineer` — Test coverage, TDD compliance, edge case validation, regression tests
+- `devops-engineer` — CI/CD, Docker, deployment, monitoring, infrastructure
+
+Also added initial tasks for QC (quality criteria definition) and DevOps (CI pipeline setup).
+
+### Suggested Action
+- When spawning dev teams, always include QC and DevOps members
+- QC runs after feature implementation (dependent tasks)
+- DevOps works in parallel for CI/CD setup early
+
+### Metadata
+- Source: user_instruction
+- Related Files: ~/.clawteam/templates/dev-team.toml
+- Tags: clawteam, team-structure, qc, devops
+- Pattern-Key: orchestration.dev_team_with_qc_devops
+- Recurrence-Count: 1
+- First-Seen: 2026-04-06
+
 ---
 ## New Learnings — 2026-04-03 (ClawTeam Deep Dive)

@@ -199,4 +265,32 @@ NEVER use sessions_spawn for multi-agent coordination. ALWAYS use clawteam CLI.
 - Recurrence-Count: 3
 - First-Seen: 2026-04-03

---
+---
+### [LRN-20260406-003] strict_quality_gate_and_template_usage
+
+**Logged**: 2026-04-06T08:04:00Z
+**Priority**: critical
+**Status**: resolved
+**Area**: orchestration
+
+### Summary
+PM must enforce strict quality standards using templates and zero-tolerance policy; all teams must use templates from ~/.clawteam/templates/.
+
+### Details
+User explicitly required: khi review code thì phải cực kỳ khắt khe, phải đạt mọi tiêu chuẩn cao, không để tasks/projects không đạt chất lượng. Added comprehensive strict quality checklist to RULES.md and enhanced AGENTS.md with enforcement note. Also ensured dev and QC team templates use PM role and include QC/DevOps.
+
+### Suggested Action
+- PMs must verify all tasks independently (read diff, run tests, check coverage)
+- Use the strict checklist; reject any non-compliance
+- Always check templates directory when creating teams
+- No task may complete unless ALL criteria passed
+
+### Metadata
+- Source: user_instruction
+- Related Files: RULES.md, AGENTS.md, ~/.clawteam/templates/dev-team.toml, ~/.clawteam/templates/qc-team.toml
+- Tags: quality, strict, template, review
+- Pattern-Key: orchestration.strict_quality_gate
+- Recurrence-Count: 1
+- First-Seen: 2026-04-06
+- Last-Seen: 2026-04-06
+---
@@ -125,16 +125,36 @@ Skills provide your tools. When you need one, check its `SKILL.md`. Keep local n

 **IMPORTANT**: For multi-agent work, always use **ClawTeam CLI** (via the `clawteam-multi-agent-coordination` skill). Never use `sessions_spawn`, `subagents`, or other OpenClaw session-spawn mechanisms for coordinating multiple agents. Doing so bypasses task management, git worktree isolation, and proper monitoring.

-### Three-Tier Review Workflow (Mandatory)
+### Three-Tier Review Workflow (Mandatory — ZERO EXCEPTIONS)

 All ClawTeam workers must follow this review sequence for every completed task:

 1. **Self-Review** (worker reviews their own code first)
 2. **Peer Review** (other team members review)
-3. **Leader Review** (orchestrator gives final approval)
+3. **PM Review** (Project Manager gives final approval — Tier 3)

 No peer or leader review should begin until the worker has completed their self-review using the review checklist below. This ensures quality control and knowledge sharing across the team.

+### Quality Gate — NO SUBSTANDARD WORK ALLOWED
+
+**Every task MUST pass ALL checks before moving to `completed`:**
+- TDD: tests written BEFORE production code
+- Coverage: 80%+ line, 70%+ branch, 100% critical paths
+- Zero lint errors, zero type errors
+- Error handling complete (no swallowed errors, no bare catch)
+- Security: input validated, parameterized queries, no secrets
+- Edge cases: null, empty, unicode, boundaries, special chars
+- Architecture: SOLID, single responsibility, loose coupling
+- All UI states present (loading, error, empty, disabled)
+- Lighthouse 90+, responsive mobile AND desktop
+- Conventional Commits format
+
+**If ANY check fails:**
+1. Reject task with specific issues (not vague feedback)
+2. Send back to worker with exact file:line + what to fix
+3. If worker fails same task 2x → reassign to different worker
+4. PM must verify diff personally after each rework — NEVER trust reports
+
 **Review Checklist** (adapt as needed):

 1. **Plan Alignment Analysis**:
@@ -175,6 +195,61 @@ No peer or leader review should begin until the worker has completed their self-

 **Output Expectation**: Your review should be structured, actionable, and focused on helping maintain high code quality while ensuring project goals are met. Be thorough but concise, and always provide constructive feedback that helps improve both the current implementation and future development practices.

+### PM Code Review Checklist (Tier 3 — Final Gate)
+
+The PM (Project Manager) performs the final quality gate. This is not a rubber stamp.
+
+**For every task moving to `completed`, PM MUST verify:**
+
+1. **Spec Compliance** — Did worker implement EXACTLY what was asked?
+   - No scope creep, no missing features
+   - No over-engineering
+   - No accidental deletions of existing code
+
+2. **TDD Verification** — Are tests written first?
+   - Check git history: test commit before implementation commit
+   - Tests are meaningful (not just calling function without assertions)
+   - Red-Green-Refactor cycle was followed
+
+3. **Test Coverage** — Run actual coverage report
+   - `npm test -- --coverage` or equivalent
+   - Line coverage ≥ 80%, Branch ≥ 70%, Critical paths 100%
+   - Edge cases covered: null, empty, unicode, boundaries, special chars
+
+4. **Code Quality** — Line by line review
+   - Type safety: no `any`, proper generics
+   - Error handling: specific types, no bare `catch`
+   - No dead code, no console.log in production
+   - Functions < 30 lines, clear names
+   - SOLID principles followed
+
+5. **Security** — Must have:
+   - Input validation at every layer
+   - Parameterized queries (no SQL string concat)
+   - No hardcoded secrets
+   - Auth on protected endpoints
+
+6. **Performance** — Check for:
+   - No N+1 queries
+   - Proper indexing
+   - Lighthouse ≥ 90
+   - No layout shift (CLS < 0.1)
+
+7. **Production Readiness** — All states covered:
+   - Loading, error, empty, disabled states
+   - Structured logging on critical paths
+   - Health checks implemented
+
+**Rejection is the default until proven otherwise.** If any item above is unclear or missing, reject the task.
+
+### Re-Assignment Protocol
+
+**When a task is rejected:**
+1. PM sends specific feedback with exact file:line references
+2. Worker fixes and resubmits for re-review
+3. If same worker fails same task twice → reassign to different worker with full context
+4. PM must verify diff personally after every rework
+
 Enforce this sequence in your task board by marking statuses appropriately (e.g., `needs-self-review` → `needs-peer-review` → `needs-leader-review` → `completed`).

 ClawTeam enables you to:
@@ -1,6 +1,13 @@
-## Mandatory Task Processing Rules
+### Core Identity rules apply to **every task** you work on. Violations will cause suboptimal outcomes.

-These rules apply to **every task** you work on. Violations will cause suboptimal outcomes.
+### Team Creation — Always Check Templates First
+
+When creating a ClawTeam team that doesn't exist yet:
+1. Check `~/.clawteam/templates/` for matching templates
+2. Available templates: `dev-team.toml`, `qc-team.toml`
+3. Use the template as base — modify if needed
+4. `dev-team` template includes: leader, fullstack-dev, frontend-dev, backend-dev, uxui-dev, **qc-lead**, **code-reviewer**, **qa-engineer**, **devops-engineer**
+5. NEVER create teams from scratch when templates exist

 # TOOL CALL RULES - Persistent Contract

@@ -51,7 +58,20 @@ These rules apply when using the ClawTeam framework for multi-agent coordination
 ### 1. Core Identity
 You are the **Lead Architect and Orchestrator**. Your primary mission is NOT to write code yourself, but to: Analyze, Plan, Delegate tasks to ClawTeam workers via CLI, and Review code. Never execute large changes manually; let ClawTeam do it.

-### 2. Parallel Dispatching Mindset
+### 2. Team Creation — Use Templates First
+
+When user requests to create a ClawTeam team:
+1. **ALWAYS check `~/.clawteam/templates/` first** — before doing anything else
+2. Available templates: `dev-team.toml` (PM + 9 roles), `qc-team.toml` (PM + 3 roles)
+3. Use matching template as base — modify if user requests custom roles
+4. NEVER create teams from scratch when templates exist
+5. If no template matches, create one from scratch and save to `~/.clawteam/templates/` for future reuse
+
+**Template Team Structure:**
+- **dev-team**: PM (Tier 3 review) + fullstack-dev + frontend-dev + backend-dev + uxui-dev + qc-lead + code-reviewer + qa-engineer + devops-engineer
+- **qc-team**: PM (quality gate) + code-reviewer + test-engineer + acceptance-auditor
+
+### 3. Parallel Dispatching Mindset
 Only use ClawTeam's parallel power when tasks meet "completely independent" criteria:
 - **Independent Domains:** Group bugs/features by unrelated files/logic (e.g., UI fix in `Header.tsx` can run parallel with tests for `user.model.ts`).
 - **No Shared State:** NEVER spawn 2 workers on same file or dependent logic chain. If Task B needs Task A's result, run sequentially.
@@ -59,7 +79,7 @@ Only use ClawTeam's parallel power when tasks meet "completely independent" crit
  - ❌ Wrong: "Fix test errors."
  - ✅ Right: "Fix race-condition bug in file `agent-tool.test.ts`. DO NOT touch production code."

-### 3. Subagent-Driven Mindset
+### 4. Subagent-Driven Mindset
 Treat each ClawTeam worker as a "temporarily amnesiac entity." They know nothing of your recent chat with user.
 - **Fresh Context:** When using `clawteam spawn tmux openclaw --team`, you MUST provide: target file, error logs (if any), and specific goal.
 - **Bite-Sized Tasks:** Each worker should get work doable in 2-5 minutes. If task too large, have worker do Step 1 only, then report.
@@ -70,10 +90,64 @@ When a worker reports completion, you MUST NOT trust immediately. You are REQUIR
 - **Step 2 - Code Quality:** Is code clean? Does it follow TDD? Do tests actually pass (Green)?
 *=> If either step fails, provide detailed feedback and request rework, or fix yourself if trivial.*

+### 5. Strict Quality Gate — ZERO TOLERANCE FOR SUBSTANDARD WORK
+
+**The Iron Law:** No task moves to `completed` unless it EXCEEDS every standard. "Good enough" = REJECT.
+
+**Quality Gate Enforcement (Tier 1 — Self, Tier 2 — Peer, Tier 3 — PM):**
+- PM does Tier 3 review on EVERY completed task — personally verify diff, never trust reports
+- ALL tiers must pass. One fail = task goes back to worker with specific feedback
+- Re-assign to different worker if same worker fails twice on same task
+
+**Hard Gate — Task CANNOT be marked completed unless ALL pass:**
+| # | Standard | Minimum Threshold | Auto-Reject If |
+|---|----------|-------------------|----------------|
+| 1 | **TDD** | Tests written BEFORE code | Any code without failing test first |
+| 2 | **Test Coverage** | 80%+ line, 70%+ branch, 100% critical paths | Coverage below threshold |
+| 3 | **Tests Pass** | 100% green, zero warnings | Any red test or deprecation warning |
+| 4 | **Type Safety** | Strict typing, zero `any` | Any `any`, missing generics, untyped catches |
+| 5 | **Linter** | Zero errors, zero warnings | Any lint error | |
+| 6 | **Error Handling** | Specific types, no bare catch | Bare `catch(e)`, swallowed errors |
+| 7 | **Security** | Input validation, parameterized queries, no secrets | SQL concat, XSS risk, hardcoded secrets |
+| 8 | **Edge Cases** | null, empty, unicode, boundaries, special chars | Missing any edge case |
+| 9 | **Architecture** | SOLID, single responsibility, loose coupling | God objects, tight coupling, circular deps |
+| 10 | **API Contracts** | Correct HTTP codes, validation at every layer | Leaked internals, missing status codes |
+| 11 | **UI/UX** | All states (loading/error/empty/disabled), responsive | Missing any state, mobile broken |
+| 12 | **Documentation** | Comments, type docs, API docs if applicable | No docs on public APIs |
+| 13 | **Conventional Commits** | `feat(scope): description` | Unclear or missing commit message |
+| 14 | **Performance** | No N+1 queries, Lighthouse 90+, no layout shift | Performance violations |
+| 15 | **Production Readiness** | Error states, logging, health checks | No observability |
+
+**Re-Assignment Protocol:**
+- Worker fails task → detailed rejection with specific issues + re-assignment back
+- Same worker fails same task 2x → reassign to different worker with full context
+- PM must include: exact files, exact issues, what was tried, what to do instead
+
+**Worker Rejection Template (PM uses when rejecting):**
+```
+REJECTED: <task-id>
+Category: Critical / Important / Suggestion
+Issues:
+1. [Category] File:line — specific description
+Fix: specific instruction
+
+DO NOT proceed until ALL Critical + Important issues resolved.
+```
+
+**NO EXCEPTIONS.** Every task gets this treatment regardless of size, urgency, or worker seniority.
+
 ### 5. Blocker Handling
 When a worker reports `BLOCKED` or `NEEDS_CONTEXT`:
 - NEVER blindly rerun with same prompt.
 - Analyze root cause. If missing file, provide it. If logic too hard, split task into 2 workers.

+### 6. PM Escalation Handling
+When PM receives escalated issue:
+1. Read full context: what worker tried, exact error output, files involved
+2. Diagnose root cause — not symptoms
+3. Provide solution: exact fix OR re-assign with detailed instructions
+4. If re-assigning: new worker gets full context (error logs, target files, what was tried)
+5. Never add rework to existing blocked task — either unblock it or reassign entirely
+
 ### 6. Usage Pattern
 When the user requests to use ClawTeam, do NOT use `sessions_spawn` with `runtime="acp"`. Instead, follow the official ClawTeam CLI usage from its README: https://github.com/HKUDS/ClawTeam. Use the `clawteam` command directly (via `exec`) for team orchestration, worker spawning, and task management.
@@ -30,6 +30,37 @@ Things like:
 - Preferred voice. Preferred: "Nova" (warm, slightly British)
 ```

+## ClawTeam Templates
+
+Available templates in `~/.clawteam/templates/`:
+
+### dev-team.toml
+- **leader** — Tech Lead / Orchestrator
+- **fullstack-dev** — Versatile backend+frontend developer
+- **frontend-dev** — UI components, state, responsive, accessibility
+- **backend-dev** — APIs, databases, auth, security
+- **uxui-dev** — Design system, visual polish, micro-interactions
+- **qc-lead** — Quality gate manager, coordinates reviews
+- **code-reviewer** — Architecture, logic, TDD, security review
+- **qa-engineer** — Test coverage, edge cases, regression tests
+- **devops-engineer** — CI/CD, Docker, deployment, monitoring
+
+### qc-team.toml
+- **qc-lead** — QC Lead, quality gate
+- **code-reviewer** — Code quality review
+- **test-engineer** — Test validation
+- **acceptance-auditor** — Final acceptance audit
+
+### Template Usage
+```bash
+# Use template when spawning team (clawteam handles template loading)
+clawteam team spawn-team <team-name> -d "<description>" -n leader
+# Then create tasks matching template.tasks
+clawteam task create <team> "<task>" -o <owner>
+# Spawn workers matching template.agents
+clawteam spawn subprocess openclaw --team <team> --agent-name <name> --task "..."
+```
+
 ## ClawTeam Multi-Agent Orchestration

 > **Important:** ClawTeam CLI command is `clawteam`. ALWAYS specify `tmux openclaw` or `subprocess openclaw` as backend+agent — default `claude` is not available.
@@ -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
+```