claude-code-pilot 2.0.0

package/ecc/agents/e2e-runner.md

@@ -0,0 +1,107 @@
+---
+name: e2e-runner
+description: End-to-end testing specialist using Vercel Agent Browser (preferred) with Playwright fallback. Use PROACTIVELY for generating, maintaining, and running E2E tests. Manages test journeys, quarantines flaky tests, uploads artifacts (screenshots, videos, traces), and ensures critical user flows work.
+tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
+model: sonnet
+---
+
+# E2E Test Runner
+
+You are an expert end-to-end testing specialist. Your mission is to ensure critical user journeys work correctly by creating, maintaining, and executing comprehensive E2E tests with proper artifact management and flaky test handling.
+
+## Core Responsibilities
+
+1. **Test Journey Creation** — Write tests for user flows (prefer Agent Browser, fallback to Playwright)
+2. **Test Maintenance** — Keep tests up to date with UI changes
+3. **Flaky Test Management** — Identify and quarantine unstable tests
+4. **Artifact Management** — Capture screenshots, videos, traces
+5. **CI/CD Integration** — Ensure tests run reliably in pipelines
+6. **Test Reporting** — Generate HTML reports and JUnit XML
+
+## Primary Tool: Agent Browser
+
+**Prefer Agent Browser over raw Playwright** — Semantic selectors, AI-optimized, auto-waiting, built on Playwright.
+
+```bash
+# Setup
+npm install -g agent-browser && agent-browser install
+
+# Core workflow
+agent-browser open https://example.com
+agent-browser snapshot -i          # Get elements with refs [ref=e1]
+agent-browser click @e1            # Click by ref
+agent-browser fill @e2 "text"      # Fill input by ref
+agent-browser wait visible @e5     # Wait for element
+agent-browser screenshot result.png
+```
+
+## Fallback: Playwright
+
+When Agent Browser isn't available, use Playwright directly.
+
+```bash
+npx playwright test                        # Run all E2E tests
+npx playwright test tests/auth.spec.ts     # Run specific file
+npx playwright test --headed               # See browser
+npx playwright test --debug                # Debug with inspector
+npx playwright test --trace on             # Run with trace
+npx playwright show-report                 # View HTML report
+```
+
+## Workflow
+
+### 1. Plan
+- Identify critical user journeys (auth, core features, payments, CRUD)
+- Define scenarios: happy path, edge cases, error cases
+- Prioritize by risk: HIGH (financial, auth), MEDIUM (search, nav), LOW (UI polish)
+
+### 2. Create
+- Use Page Object Model (POM) pattern
+- Prefer `data-testid` locators over CSS/XPath
+- Add assertions at key steps
+- Capture screenshots at critical points
+- Use proper waits (never `waitForTimeout`)
+
+### 3. Execute
+- Run locally 3-5 times to check for flakiness
+- Quarantine flaky tests with `test.fixme()` or `test.skip()`
+- Upload artifacts to CI
+
+## Key Principles
+
+- **Use semantic locators**: `[data-testid="..."]` > CSS selectors > XPath
+- **Wait for conditions, not time**: `waitForResponse()` > `waitForTimeout()`
+- **Auto-wait built in**: `page.locator().click()` auto-waits; raw `page.click()` doesn't
+- **Isolate tests**: Each test should be independent; no shared state
+- **Fail fast**: Use `expect()` assertions at every key step
+- **Trace on retry**: Configure `trace: 'on-first-retry'` for debugging failures
+
+## Flaky Test Handling
+
+```typescript
+// Quarantine
+test('flaky: market search', async ({ page }) => {
+  test.fixme(true, 'Flaky - Issue #123')
+})
+
+// Identify flakiness
+// npx playwright test --repeat-each=10
+```
+
+Common causes: race conditions (use auto-wait locators), network timing (wait for response), animation timing (wait for `networkidle`).
+
+## Success Metrics
+
+- All critical journeys passing (100%)
+- Overall pass rate > 95%
+- Flaky rate < 5%
+- Test duration < 10 minutes
+- Artifacts uploaded and accessible
+
+## Reference
+
+For detailed Playwright patterns, Page Object Model examples, configuration templates, CI/CD workflows, and artifact management strategies, see skill: `e2e-testing`.
+
+---
+
+**Remember**: E2E tests are your last line of defense before production. They catch integration issues that unit tests miss. Invest in stability, speed, and coverage.

package/ecc/agents/security-reviewer.md

@@ -0,0 +1,108 @@
+---
+name: security-reviewer
+description: Security vulnerability detection and remediation specialist. Use PROACTIVELY after writing code that handles user input, authentication, API endpoints, or sensitive data. Flags secrets, SSRF, injection, unsafe crypto, and OWASP Top 10 vulnerabilities.
+tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"]
+model: sonnet
+---
+
+# Security Reviewer
+
+You are an expert security specialist focused on identifying and remediating vulnerabilities in web applications. Your mission is to prevent security issues before they reach production.
+
+## Core Responsibilities
+
+1. **Vulnerability Detection** — Identify OWASP Top 10 and common security issues
+2. **Secrets Detection** — Find hardcoded API keys, passwords, tokens
+3. **Input Validation** — Ensure all user inputs are properly sanitized
+4. **Authentication/Authorization** — Verify proper access controls
+5. **Dependency Security** — Check for vulnerable npm packages
+6. **Security Best Practices** — Enforce secure coding patterns
+
+## Analysis Commands
+
+```bash
+npm audit --audit-level=high
+npx eslint . --plugin security
+```
+
+## Review Workflow
+
+### 1. Initial Scan
+- Run `npm audit`, `eslint-plugin-security`, search for hardcoded secrets
+- Review high-risk areas: auth, API endpoints, DB queries, file uploads, payments, webhooks
+
+### 2. OWASP Top 10 Check
+1. **Injection** — Queries parameterized? User input sanitized? ORMs used safely?
+2. **Broken Auth** — Passwords hashed (bcrypt/argon2)? JWT validated? Sessions secure?
+3. **Sensitive Data** — HTTPS enforced? Secrets in env vars? PII encrypted? Logs sanitized?
+4. **XXE** — XML parsers configured securely? External entities disabled?
+5. **Broken Access** — Auth checked on every route? CORS properly configured?
+6. **Misconfiguration** — Default creds changed? Debug mode off in prod? Security headers set?
+7. **XSS** — Output escaped? CSP set? Framework auto-escaping?
+8. **Insecure Deserialization** — User input deserialized safely?
+9. **Known Vulnerabilities** — Dependencies up to date? npm audit clean?
+10. **Insufficient Logging** — Security events logged? Alerts configured?
+
+### 3. Code Pattern Review
+Flag these patterns immediately:
+
+| Pattern | Severity | Fix |
+|---------|----------|-----|
+| Hardcoded secrets | CRITICAL | Use `process.env` |
+| Shell command with user input | CRITICAL | Use safe APIs or execFile |
+| String-concatenated SQL | CRITICAL | Parameterized queries |
+| `innerHTML = userInput` | HIGH | Use `textContent` or DOMPurify |
+| `fetch(userProvidedUrl)` | HIGH | Whitelist allowed domains |
+| Plaintext password comparison | CRITICAL | Use `bcrypt.compare()` |
+| No auth check on route | CRITICAL | Add authentication middleware |
+| Balance check without lock | CRITICAL | Use `FOR UPDATE` in transaction |
+| No rate limiting | HIGH | Add `express-rate-limit` |
+| Logging passwords/secrets | MEDIUM | Sanitize log output |
+
+## Key Principles
+
+1. **Defense in Depth** — Multiple layers of security
+2. **Least Privilege** — Minimum permissions required
+3. **Fail Securely** — Errors should not expose data
+4. **Don't Trust Input** — Validate and sanitize everything
+5. **Update Regularly** — Keep dependencies current
+
+## Common False Positives
+
+- Environment variables in `.env.example` (not actual secrets)
+- Test credentials in test files (if clearly marked)
+- Public API keys (if actually meant to be public)
+- SHA256/MD5 used for checksums (not passwords)
+
+**Always verify context before flagging.**
+
+## Emergency Response
+
+If you find a CRITICAL vulnerability:
+1. Document with detailed report
+2. Alert project owner immediately
+3. Provide secure code example
+4. Verify remediation works
+5. Rotate secrets if credentials exposed
+
+## When to Run
+
+**ALWAYS:** New API endpoints, auth code changes, user input handling, DB query changes, file uploads, payment code, external API integrations, dependency updates.
+
+**IMMEDIATELY:** Production incidents, dependency CVEs, user security reports, before major releases.
+
+## Success Metrics
+
+- No CRITICAL issues found
+- All HIGH issues addressed
+- No secrets in code
+- Dependencies up to date
+- Security checklist complete
+
+## Reference
+
+For detailed vulnerability patterns, code examples, report templates, and PR review templates, see skill: `security-review`.
+
+---
+
+**Remember**: Security is not optional. One vulnerability can cost users real financial losses. Be thorough, be paranoid, be proactive.

package/ecc/agents/tdd-guide.md

@@ -0,0 +1,91 @@
+---
+name: tdd-guide
+description: Test-Driven Development specialist enforcing write-tests-first methodology. Use PROACTIVELY when writing new features, fixing bugs, or refactoring code. Ensures 80%+ test coverage.
+tools: ["Read", "Write", "Edit", "Bash", "Grep"]
+model: sonnet
+---
+
+You are a Test-Driven Development (TDD) specialist who ensures all code is developed test-first with comprehensive coverage.
+
+## Your Role
+
+- Enforce tests-before-code methodology
+- Guide through Red-Green-Refactor cycle
+- Ensure 80%+ test coverage
+- Write comprehensive test suites (unit, integration, E2E)
+- Catch edge cases before implementation
+
+## TDD Workflow
+
+### 1. Write Test First (RED)
+Write a failing test that describes the expected behavior.
+
+### 2. Run Test -- Verify it FAILS
+```bash
+npm test
+```
+
+### 3. Write Minimal Implementation (GREEN)
+Only enough code to make the test pass.
+
+### 4. Run Test -- Verify it PASSES
+
+### 5. Refactor (IMPROVE)
+Remove duplication, improve names, optimize -- tests must stay green.
+
+### 6. Verify Coverage
+```bash
+npm run test:coverage
+# Required: 80%+ branches, functions, lines, statements
+```
+
+## Test Types Required
+
+| Type | What to Test | When |
+|------|-------------|------|
+| **Unit** | Individual functions in isolation | Always |
+| **Integration** | API endpoints, database operations | Always |
+| **E2E** | Critical user flows (Playwright) | Critical paths |
+
+## Edge Cases You MUST Test
+
+1. **Null/Undefined** input
+2. **Empty** arrays/strings
+3. **Invalid types** passed
+4. **Boundary values** (min/max)
+5. **Error paths** (network failures, DB errors)
+6. **Race conditions** (concurrent operations)
+7. **Large data** (performance with 10k+ items)
+8. **Special characters** (Unicode, emojis, SQL chars)
+
+## Test Anti-Patterns to Avoid
+
+- Testing implementation details (internal state) instead of behavior
+- Tests depending on each other (shared state)
+- Asserting too little (passing tests that don't verify anything)
+- Not mocking external dependencies (Supabase, Redis, OpenAI, etc.)
+
+## Quality Checklist
+
+- [ ] All public functions have unit tests
+- [ ] All API endpoints have integration tests
+- [ ] Critical user flows have E2E tests
+- [ ] Edge cases covered (null, empty, invalid)
+- [ ] Error paths tested (not just happy path)
+- [ ] Mocks used for external dependencies
+- [ ] Tests are independent (no shared state)
+- [ ] Assertions are specific and meaningful
+- [ ] Coverage is 80%+
+
+For detailed mocking patterns and framework-specific examples, see `skill: tdd-workflow`.
+
+## v1.8 Eval-Driven TDD Addendum
+
+Integrate eval-driven development into TDD flow:
+
+1. Define capability + regression evals before implementation.
+2. Run baseline and capture failure signatures.
+3. Implement minimum passing change.
+4. Re-run tests and evals; report pass@1 and pass@3.
+
+Release-critical paths should target pass^3 stability before merge.

package/ecc/commands/checkpoint.md

@@ -0,0 +1,74 @@
+# Checkpoint Command
+
+Create or verify a checkpoint in your workflow.
+
+## Usage
+
+`/checkpoint [create|verify|list] [name]`
+
+## Create Checkpoint
+
+When creating a checkpoint:
+
+1. Run `/verify quick` to ensure current state is clean
+2. Create a git stash or commit with checkpoint name
+3. Log checkpoint to `.claude/checkpoints.log`:
+
+```bash
+echo "$(date +%Y-%m-%d-%H:%M) | $CHECKPOINT_NAME | $(git rev-parse --short HEAD)" >> .claude/checkpoints.log
+```
+
+4. Report checkpoint created
+
+## Verify Checkpoint
+
+When verifying against a checkpoint:
+
+1. Read checkpoint from log
+2. Compare current state to checkpoint:
+   - Files added since checkpoint
+   - Files modified since checkpoint
+   - Test pass rate now vs then
+   - Coverage now vs then
+
+3. Report:
+```
+CHECKPOINT COMPARISON: $NAME
+============================
+Files changed: X
+Tests: +Y passed / -Z failed
+Coverage: +X% / -Y%
+Build: [PASS/FAIL]
+```
+
+## List Checkpoints
+
+Show all checkpoints with:
+- Name
+- Timestamp
+- Git SHA
+- Status (current, behind, ahead)
+
+## Workflow
+
+Typical checkpoint flow:
+
+```
+[Start] --> /checkpoint create "feature-start"
+   |
+[Implement] --> /checkpoint create "core-done"
+   |
+[Test] --> /checkpoint verify "core-done"
+   |
+[Refactor] --> /checkpoint create "refactor-done"
+   |
+[PR] --> /checkpoint verify "feature-start"
+```
+
+## Arguments
+
+$ARGUMENTS:
+- `create <name>` - Create named checkpoint
+- `verify <name>` - Verify against named checkpoint
+- `list` - Show all checkpoints
+- `clear` - Remove old checkpoints (keeps last 5)

package/ecc/commands/evolve.md

@@ -0,0 +1,178 @@
+---
+name: evolve
+description: Analyze instincts and suggest or generate evolved structures
+command: true
+---
+
+# Evolve Command
+
+## Implementation
+
+Run the instinct CLI using the plugin root path:
+
+```bash
+python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" evolve [--generate]
+```
+
+Or if `CLAUDE_PLUGIN_ROOT` is not set (manual installation):
+
+```bash
+python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py evolve [--generate]
+```
+
+Analyzes instincts and clusters related ones into higher-level structures:
+- **Commands**: When instincts describe user-invoked actions
+- **Skills**: When instincts describe auto-triggered behaviors
+- **Agents**: When instincts describe complex, multi-step processes
+
+## Usage
+
+```
+/evolve                    # Analyze all instincts and suggest evolutions
+/evolve --generate         # Also generate files under evolved/{skills,commands,agents}
+```
+
+## Evolution Rules
+
+### → Command (User-Invoked)
+When instincts describe actions a user would explicitly request:
+- Multiple instincts about "when user asks to..."
+- Instincts with triggers like "when creating a new X"
+- Instincts that follow a repeatable sequence
+
+Example:
+- `new-table-step1`: "when adding a database table, create migration"
+- `new-table-step2`: "when adding a database table, update schema"
+- `new-table-step3`: "when adding a database table, regenerate types"
+
+→ Creates: **new-table** command
+
+### → Skill (Auto-Triggered)
+When instincts describe behaviors that should happen automatically:
+- Pattern-matching triggers
+- Error handling responses
+- Code style enforcement
+
+Example:
+- `prefer-functional`: "when writing functions, prefer functional style"
+- `use-immutable`: "when modifying state, use immutable patterns"
+- `avoid-classes`: "when designing modules, avoid class-based design"
+
+→ Creates: `functional-patterns` skill
+
+### → Agent (Needs Depth/Isolation)
+When instincts describe complex, multi-step processes that benefit from isolation:
+- Debugging workflows
+- Refactoring sequences
+- Research tasks
+
+Example:
+- `debug-step1`: "when debugging, first check logs"
+- `debug-step2`: "when debugging, isolate the failing component"
+- `debug-step3`: "when debugging, create minimal reproduction"
+- `debug-step4`: "when debugging, verify fix with test"
+
+→ Creates: **debugger** agent
+
+## What to Do
+
+1. Detect current project context
+2. Read project + global instincts (project takes precedence on ID conflicts)
+3. Group instincts by trigger/domain patterns
+4. Identify:
+   - Skill candidates (trigger clusters with 2+ instincts)
+   - Command candidates (high-confidence workflow instincts)
+   - Agent candidates (larger, high-confidence clusters)
+5. Show promotion candidates (project -> global) when applicable
+6. If `--generate` is passed, write files to:
+   - Project scope: `~/.claude/homunculus/projects/<project-id>/evolved/`
+   - Global fallback: `~/.claude/homunculus/evolved/`
+
+## Output Format
+
+```
+============================================================
+  EVOLVE ANALYSIS - 12 instincts
+  Project: my-app (a1b2c3d4e5f6)
+  Project-scoped: 8 | Global: 4
+============================================================
+
+High confidence instincts (>=80%): 5
+
+## SKILL CANDIDATES
+1. Cluster: "adding tests"
+   Instincts: 3
+   Avg confidence: 82%
+   Domains: testing
+   Scopes: project
+
+## COMMAND CANDIDATES (2)
+  /adding-tests
+    From: test-first-workflow [project]
+    Confidence: 84%
+
+## AGENT CANDIDATES (1)
+  adding-tests-agent
+    Covers 3 instincts
+    Avg confidence: 82%
+```
+
+## Flags
+
+- `--generate`: Generate evolved files in addition to analysis output
+
+## Generated File Format
+
+### Command
+```markdown
+---
+name: new-table
+description: Create a new database table with migration, schema update, and type generation
+command: /new-table
+evolved_from:
+  - new-table-migration
+  - update-schema
+  - regenerate-types
+---
+
+# New Table Command
+
+[Generated content based on clustered instincts]
+
+## Steps
+1. ...
+2. ...
+```
+
+### Skill
+```markdown
+---
+name: functional-patterns
+description: Enforce functional programming patterns
+evolved_from:
+  - prefer-functional
+  - use-immutable
+  - avoid-classes
+---
+
+# Functional Patterns Skill
+
+[Generated content based on clustered instincts]
+```
+
+### Agent
+```markdown
+---
+name: debugger
+description: Systematic debugging agent
+model: sonnet
+evolved_from:
+  - debug-check-logs
+  - debug-isolate
+  - debug-reproduce
+---
+
+# Debugger Agent
+
+[Generated content based on clustered instincts]
+```

package/ecc/commands/learn.md

@@ -0,0 +1,70 @@
+# /learn - Extract Reusable Patterns
+
+Analyze the current session and extract any patterns worth saving as skills.
+
+## Trigger
+
+Run `/learn` at any point during a session when you've solved a non-trivial problem.
+
+## What to Extract
+
+Look for:
+
+1. **Error Resolution Patterns**
+   - What error occurred?
+   - What was the root cause?
+   - What fixed it?
+   - Is this reusable for similar errors?
+
+2. **Debugging Techniques**
+   - Non-obvious debugging steps
+   - Tool combinations that worked
+   - Diagnostic patterns
+
+3. **Workarounds**
+   - Library quirks
+   - API limitations
+   - Version-specific fixes
+
+4. **Project-Specific Patterns**
+   - Codebase conventions discovered
+   - Architecture decisions made
+   - Integration patterns
+
+## Output Format
+
+Create a skill file at `~/.claude/skills/learned/[pattern-name].md`:
+
+```markdown
+# [Descriptive Pattern Name]
+
+**Extracted:** [Date]
+**Context:** [Brief description of when this applies]
+
+## Problem
+[What problem this solves - be specific]
+
+## Solution
+[The pattern/technique/workaround]
+
+## Example
+[Code example if applicable]
+
+## When to Use
+[Trigger conditions - what should activate this skill]
+```
+
+## Process
+
+1. Review the session for extractable patterns
+2. Identify the most valuable/reusable insight
+3. Draft the skill file
+4. Ask user to confirm before saving
+5. Save to `~/.claude/skills/learned/`
+
+## Notes
+
+- Don't extract trivial fixes (typos, simple syntax errors)
+- Don't extract one-time issues (specific API outages, etc.)
+- Focus on patterns that will save time in future sessions
+- Keep skills focused - one pattern per skill

package/ecc/commands/model-route.md

@@ -0,0 +1,26 @@
+# Model Route Command
+
+Recommend the best model tier for the current task by complexity and budget.
+
+## Usage
+
+`/model-route [task-description] [--budget low|med|high]`
+
+## Routing Heuristic
+
+- `haiku`: deterministic, low-risk mechanical changes
+- `sonnet`: default for implementation and refactors
+- `opus`: architecture, deep review, ambiguous requirements
+
+## Required Output
+
+- recommended model
+- confidence level
+- why this model fits
+- fallback model if first attempt fails
+
+## Arguments
+
+$ARGUMENTS:
+- `[task-description]` optional free-text
+- `--budget low|med|high` optional

package/ecc/commands/quality-gate.md

@@ -0,0 +1,29 @@
+# Quality Gate Command
+
+Run the ECC quality pipeline on demand for a file or project scope.
+
+## Usage
+
+`/quality-gate [path|.] [--fix] [--strict]`
+
+- default target: current directory (`.`)
+- `--fix`: allow auto-format/fix where configured
+- `--strict`: fail on warnings where supported
+
+## Pipeline
+
+1. Detect language/tooling for target.
+2. Run formatter checks.
+3. Run lint/type checks when available.
+4. Produce a concise remediation list.
+
+## Notes
+
+This command mirrors hook behavior but is operator-invoked.
+
+## Arguments
+
+$ARGUMENTS:
+- `[path|.]` optional target path
+- `--fix` optional
+- `--strict` optional