compact-agent 1.1.0

package/resources/ecc/agents/tdd-guide.md

@@ -0,0 +1,93 @@
+---
+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.
+allowedTools:
+  - read
+  - write
+  - shell
+---
+
+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/resources/ecc/commands/add-language-rules.md

@@ -0,0 +1,39 @@
+---
+name: add-language-rules
+description: Workflow command scaffold for add-language-rules in everything-claude-code.
+allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
+---
+
+# /add-language-rules
+
+Use this workflow when working on **add-language-rules** in `everything-claude-code`.
+
+## Goal
+
+Adds a new programming language to the rules system, including coding style, hooks, patterns, security, and testing guidelines.
+
+## Common Files
+
+- `rules/*/coding-style.md`
+- `rules/*/hooks.md`
+- `rules/*/patterns.md`
+- `rules/*/security.md`
+- `rules/*/testing.md`
+
+## Suggested Sequence
+
+1. Understand the current state and failure mode before editing.
+2. Make the smallest coherent change that satisfies the workflow goal.
+3. Run the most relevant verification for touched files.
+4. Summarize what changed and what still needs review.
+
+## Typical Commit Signals
+
+- Create a new directory under rules/{language}/
+- Add coding-style.md, hooks.md, patterns.md, security.md, and testing.md files with language-specific content
+- Optionally reference or link to related skills
+
+## Notes
+
+- Treat this as a scaffold, not a hard-coded script.
+- Update the command if the workflow evolves materially.

package/resources/ecc/commands/database-migration.md

@@ -0,0 +1,36 @@
+---
+name: database-migration
+description: Workflow command scaffold for database-migration in everything-claude-code.
+allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
+---
+
+# /database-migration
+
+Use this workflow when working on **database-migration** in `everything-claude-code`.
+
+## Goal
+
+Database schema changes with migration files
+
+## Common Files
+
+- `**/schema.*`
+- `migrations/*`
+
+## Suggested Sequence
+
+1. Understand the current state and failure mode before editing.
+2. Make the smallest coherent change that satisfies the workflow goal.
+3. Run the most relevant verification for touched files.
+4. Summarize what changed and what still needs review.
+
+## Typical Commit Signals
+
+- Create migration file
+- Update schema definitions
+- Generate/update types
+
+## Notes
+
+- Treat this as a scaffold, not a hard-coded script.
+- Update the command if the workflow evolves materially.

package/resources/ecc/commands/feature-development.md

@@ -0,0 +1,38 @@
+---
+name: feature-development
+description: Workflow command scaffold for feature-development in everything-claude-code.
+allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
+---
+
+# /feature-development
+
+Use this workflow when working on **feature-development** in `everything-claude-code`.
+
+## Goal
+
+Standard feature implementation workflow
+
+## Common Files
+
+- `manifests/*`
+- `schemas/*`
+- `**/*.test.*`
+- `**/api/**`
+
+## Suggested Sequence
+
+1. Understand the current state and failure mode before editing.
+2. Make the smallest coherent change that satisfies the workflow goal.
+3. Run the most relevant verification for touched files.
+4. Summarize what changed and what still needs review.
+
+## Typical Commit Signals
+
+- Add feature implementation
+- Add tests for feature
+- Update documentation
+
+## Notes
+
+- Treat this as a scaffold, not a hard-coded script.
+- Update the command if the workflow evolves materially.

package/resources/ecc/prompts/build-fix.prompt.md

@@ -0,0 +1,47 @@
+---
+agent: agent
+description: Systematically diagnose and fix build errors, type errors, or failing CI
+---
+
+# Build Error Resolution
+
+Work through the error systematically. Fix root causes — do not suppress warnings or skip checks.
+
+## Process
+
+### 1. Capture the full error
+Paste or describe the complete error output (not just the last line). Include:
+- Error message and stack trace
+- File and line number if shown
+- Build tool and command that failed
+
+### 2. Categorize the error
+
+| Category | Signals |
+|----------|---------|
+| **Type error** | `Type X is not assignable to Y`, `Property does not exist` |
+| **Import/module** | `Cannot find module`, `does not provide an export` |
+| **Syntax** | `Unexpected token`, `Expected ;` |
+| **Dependency** | `peer dep conflict`, `missing package`, `version mismatch` |
+| **Environment** | `command not found`, `ENOENT`, missing env var |
+| **Test failure** | `expected X but received Y`, assertion failure |
+| **Lint** | `ESLint`, `no-unused-vars`, `no-console` |
+
+### 3. Fix strategy
+
+- **Type errors** — fix the type, do not cast to `any` or `unknown` unless truly unavoidable.
+- **Import errors** — verify the export exists; check for circular dependencies.
+- **Dependency errors** — update lockfile, reconcile peer dep versions, do not delete `node_modules` as a first step.
+- **Test failures** — fix the implementation if behavior is wrong; fix the test only if the test itself is incorrect.
+- **Lint errors** — fix the code, do not add `// eslint-disable` unless the rule is genuinely inapplicable and you document why.
+
+### 4. Verify the fix
+After applying a fix, run the build/test command again. Confirm the specific error is resolved and no new errors were introduced.
+
+### 5. Check for related issues
+A single root cause often produces multiple error messages. After fixing, scan for similar patterns elsewhere in the codebase.
+
+## Rules
+- Never use `--no-verify` to skip hooks.
+- Never suppress type errors with `@ts-ignore` without a comment explaining why.
+- Never delete lock files without understanding why they are conflicting.

package/resources/ecc/prompts/code-review.prompt.md

@@ -0,0 +1,56 @@
+---
+agent: agent
+description: Comprehensive code quality and security review of the selected code or recent changes
+---
+
+# Code Review
+
+Review the selected code (or the current diff if nothing is selected) across four dimensions. Only report issues you are **confident about** — flag uncertainty explicitly rather than guessing.
+
+## Dimensions
+
+### 1. Security (CRITICAL — block ship if found)
+- Hardcoded secrets, tokens, API keys, passwords
+- Missing input validation or sanitization at system boundaries
+- SQL/NoSQL injection risk (string interpolation in queries)
+- XSS risk (unsanitized HTML output)
+- Auth/authz checks missing or client-side only
+- Sensitive data in logs or error messages exposed to clients
+- Missing rate limiting on public endpoints
+
+### 2. Code Quality (HIGH)
+- Mutation of existing state instead of creating new objects
+- Functions over 50 lines or files over 800 lines
+- Nesting deeper than 4 levels
+- Duplicated logic that should be extracted
+- Misleading or non-descriptive names
+
+### 3. Error Handling (HIGH)
+- Silently swallowed errors (`catch {}`, empty catch blocks)
+- Missing error handling at async boundaries
+- Errors returned but not checked by callers
+- User-facing error messages leaking internal details
+
+### 4. Test Coverage (MEDIUM)
+- Missing tests for new logic
+- Tests that only test happy paths (missing error/edge cases)
+- Assertions that always pass
+
+## Output Format
+
+For each issue found:
+
+```
+**[CRITICAL|HIGH|MEDIUM|LOW]** — [File:Line if known]
+Issue: [What is wrong]
+Fix: [Concrete suggestion]
+```
+
+End with a summary:
+```
+## Summary
+- Critical: N
+- High: N
+- Medium: N
+- Approved to ship: yes / no (fix CRITICAL and HIGH first)
+```

package/resources/ecc/prompts/plan.prompt.md

@@ -0,0 +1,52 @@
+---
+agent: agent
+description: Create a phased implementation plan before writing any code
+---
+
+# Implementation Planner
+
+Before writing any code for this feature/task, produce a structured plan.
+
+## Steps
+
+1. **Clarify the goal** — restate the requirement in one sentence; flag any ambiguities.
+2. **Research first** — identify existing utilities, libraries, or patterns in the codebase that can be reused. Do not reinvent what already exists.
+3. **Identify dependencies** — list external packages, APIs, environment variables, or database changes needed.
+4. **Break into phases** — structure work as ordered phases, each independently shippable:
+   - Phase 1: Core data model / schema changes
+   - Phase 2: Business logic + unit tests
+   - Phase 3: API / integration layer + integration tests
+   - Phase 4: UI / consumer layer + E2E tests
+5. **Identify risks** — note anything that could block progress or cause regressions.
+6. **Define done** — list the exact acceptance criteria (tests passing, coverage ≥ 80%, no lint errors, docs updated).
+
+## Output Format
+
+```
+## Goal
+[One-sentence summary]
+
+## Reuse Opportunities
+- [Existing utility/pattern]
+
+## Dependencies
+- [Package / API / env var]
+
+## Phases
+### Phase 1 — [Name]
+- [ ] Task A
+- [ ] Task B
+
+### Phase 2 — [Name]
+...
+
+## Risks
+- [Risk and mitigation]
+
+## Definition of Done
+- [ ] All tests pass (≥80% coverage)
+- [ ] No new lint errors
+- [ ] Docs updated if public API changed
+```
+
+Apply ECC coding standards throughout: immutable patterns, small focused files, explicit error handling.

package/resources/ecc/prompts/refactor.prompt.md

@@ -0,0 +1,50 @@
+---
+agent: agent
+description: Clean up dead code, reduce duplication, and simplify structure without changing behavior
+---
+
+# Refactor & Cleanup
+
+Improve the internal structure of the selected code without changing its observable behavior. All tests must pass before and after.
+
+## Before Starting
+- [ ] Confirm the test suite is passing.
+- [ ] Note the current coverage baseline.
+- [ ] Identify the scope: single function, file, or module?
+
+## Refactoring Targets
+
+### Dead Code Removal
+- Unused variables, imports, functions, and exports
+- Commented-out code blocks (delete, don't leave as comments)
+- Feature flags that are permanently enabled/disabled
+- Unreachable branches
+
+### Duplication Reduction
+- Repeated logic that can be extracted into a shared utility
+- Copy-pasted blocks differing only in a parameter (extract with that parameter)
+- Inline constants that appear in multiple places (extract to named constants)
+
+### Structure Improvements
+- Functions over 50 lines → break into smaller, named steps
+- Files over 800 lines → extract cohesive sub-modules
+- Nesting deeper than 4 levels → extract early-return guards or helper functions
+- Mixed concerns in one function → split into focused single-responsibility functions
+
+### Naming
+- Rename variables/functions whose names don't match their behavior
+- Replace magic numbers and strings with named constants
+- Align naming with the domain language used elsewhere in the codebase
+
+## Constraints
+- **No behavior changes** — refactoring is purely structural.
+- **One concern at a time** — do not mix refactoring with feature work or bug fixes.
+- **Keep tests green** — run the suite after each meaningful change.
+- **Don't add abstractions preemptively** — extract only what has already proven to be duplicated (rule of three).
+
+## Output
+After refactoring, summarize:
+- What was removed (dead code, duplication)
+- What was extracted (new utilities, constants)
+- What was renamed and why
+- Coverage before / after (should not decrease)

package/resources/ecc/prompts/security-review.prompt.md

@@ -0,0 +1,70 @@
+---
+agent: agent
+description: Deep security analysis — OWASP Top 10, secrets, auth, injection, and dependency risks
+---
+
+# Security Review
+
+Perform a thorough security analysis of the selected code or current branch changes.
+
+## Checklist
+
+### Secrets & Configuration
+- [ ] No hardcoded API keys, tokens, passwords, or private keys anywhere in source
+- [ ] All secrets loaded from environment variables or a secret manager
+- [ ] Required env vars validated at startup (fail fast if missing)
+- [ ] `.env` files excluded from version control
+
+### Input Validation & Injection
+- [ ] All user inputs validated and sanitized before use
+- [ ] Parameterized queries for every database operation (no string interpolation)
+- [ ] HTML output escaped or sanitized (XSS prevention)
+- [ ] File path inputs sanitized (path traversal prevention)
+- [ ] Command inputs sanitized (command injection prevention)
+
+### Authentication & Authorization
+- [ ] Auth checks enforced server-side — never trust client-supplied user IDs or roles
+- [ ] Session tokens are sufficiently random and expire appropriately
+- [ ] Sensitive operations protected by authz checks, not just authn
+- [ ] CSRF protection enabled for state-changing endpoints
+
+### Data Exposure
+- [ ] Error responses scrubbed of stack traces, internal paths, and sensitive data
+- [ ] Logs do not contain PII, tokens, or passwords
+- [ ] Sensitive fields excluded from API responses (no over-fetching)
+- [ ] Appropriate HTTP security headers set
+
+### Dependencies
+- [ ] No known vulnerable packages (run `npm audit` / `pip-audit` / `cargo audit`)
+- [ ] Dependency versions pinned or locked
+- [ ] No unused dependencies that increase attack surface
+
+### Infrastructure (if applicable)
+- [ ] Rate limiting on all public endpoints
+- [ ] HTTPS enforced; no HTTP fallback in production
+- [ ] Principle of least privilege for service accounts and IAM roles
+
+## Response Protocol
+
+If a **CRITICAL** issue is found:
+1. Stop and report immediately.
+2. Do not ship until fixed.
+3. Rotate any exposed secrets.
+4. Scan the rest of the codebase for similar patterns.
+
+## Output Format
+
+```
+## Findings
+
+**[CRITICAL|HIGH|MEDIUM|LOW]** — [category]
+Location: [file:line if known]
+Issue: [what is wrong and why it is dangerous]
+Fix: [concrete remediation]
+
+## Summary
+- Critical: N
+- High: N
+- Medium: N
+- Safe to ship: yes / no
+```

package/resources/ecc/prompts/tdd.prompt.md

@@ -0,0 +1,47 @@
+---
+agent: agent
+description: Test-driven development cycle — write the test first, then implement
+---
+
+# TDD Workflow
+
+Follow the RED → GREEN → IMPROVE cycle strictly. Do not write implementation code before a failing test exists.
+
+## Cycle
+
+### 1. RED — Write the failing test
+- Write a test that describes the desired behavior.
+- Run it. It **must fail** before continuing.
+- Use Arrange-Act-Assert structure.
+- Name tests descriptively: `returns empty array when no items match filter`, not `test itemFilter`.
+
+### 2. GREEN — Minimal implementation
+- Write the **minimum** code needed to make the test pass.
+- Do not over-engineer at this stage.
+- Run the test again — it **must pass**.
+
+### 3. IMPROVE — Refactor
+- Clean up duplication, naming, structure.
+- Keep all tests passing after each change.
+- Check coverage: target **≥ 80%**.
+
+## Test Layer Checklist
+
+- [ ] **Unit** — pure functions, utilities, isolated components
+- [ ] **Integration** — API endpoints, database operations, service boundaries
+- [ ] **E2E** — at least one critical user flow covered
+
+## Quality Gates
+
+Before marking the feature done:
+- [ ] All tests pass
+- [ ] Coverage ≥ 80%
+- [ ] No skipped/commented-out tests
+- [ ] Edge cases covered: empty input, nulls, boundary values, error paths
+
+## Anti-patterns to Avoid
+
+- Writing implementation before tests
+- Testing implementation details instead of behavior
+- Mocking too deeply (prefer integration tests over excessive mocks)
+- Assertions that always pass (`expect(true).toBe(true)`)

package/resources/ecc/rules/common-agents.md

@@ -0,0 +1,53 @@
+---
+description: "Agent orchestration: available agents, parallel execution, multi-perspective analysis"
+alwaysApply: true
+---
+# Agent Orchestration
+
+## Available Agents
+
+Located in `~/.claude/agents/`:
+
+| Agent | Purpose | When to Use |
+|-------|---------|-------------|
+| planner | Implementation planning | Complex features, refactoring |
+| architect | System design | Architectural decisions |
+| tdd-guide | Test-driven development | New features, bug fixes |
+| code-reviewer | Code review | After writing code |
+| security-reviewer | Security analysis | Before commits |
+| build-error-resolver | Fix build errors | When build fails |
+| e2e-runner | E2E testing | Critical user flows |
+| refactor-cleaner | Dead code cleanup | Code maintenance |
+| doc-updater | Documentation | Updating docs |
+
+## Immediate Agent Usage
+
+No user prompt needed:
+1. Complex feature requests - Use **planner** agent
+2. Code just written/modified - Use **code-reviewer** agent
+3. Bug fix or new feature - Use **tdd-guide** agent
+4. Architectural decision - Use **architect** agent
+
+## Parallel Task Execution
+
+ALWAYS use parallel Task execution for independent operations:
+
+```markdown
+# GOOD: Parallel execution
+Launch 3 agents in parallel:
+1. Agent 1: Security analysis of auth module
+2. Agent 2: Performance review of cache system
+3. Agent 3: Type checking of utilities
+
+# BAD: Sequential when unnecessary
+First agent 1, then agent 2, then agent 3
+```
+
+## Multi-Perspective Analysis
+
+For complex problems, use split role sub-agents:
+- Factual reviewer
+- Senior engineer
+- Security expert
+- Consistency reviewer
+- Redundancy checker

package/resources/ecc/rules/common-coding-style.md

@@ -0,0 +1,52 @@
+---
+description: "ECC coding style: immutability, file organization, error handling, validation"
+alwaysApply: true
+---
+# Coding Style
+
+## Immutability (CRITICAL)
+
+ALWAYS create new objects, NEVER mutate existing ones:
+
+```
+// Pseudocode
+WRONG:  modify(original, field, value) → changes original in-place
+CORRECT: update(original, field, value) → returns new copy with change
+```
+
+Rationale: Immutable data prevents hidden side effects, makes debugging easier, and enables safe concurrency.
+
+## File Organization
+
+MANY SMALL FILES > FEW LARGE FILES:
+- High cohesion, low coupling
+- 200-400 lines typical, 800 max
+- Extract utilities from large modules
+- Organize by feature/domain, not by type
+
+## Error Handling
+
+ALWAYS handle errors comprehensively:
+- Handle errors explicitly at every level
+- Provide user-friendly error messages in UI-facing code
+- Log detailed error context on the server side
+- Never silently swallow errors
+
+## Input Validation
+
+ALWAYS validate at system boundaries:
+- Validate all user input before processing
+- Use schema-based validation where available
+- Fail fast with clear error messages
+- Never trust external data (API responses, user input, file content)
+
+## Code Quality Checklist
+
+Before marking work complete:
+- [ ] Code is readable and well-named
+- [ ] Functions are small (<50 lines)
+- [ ] Files are focused (<800 lines)
+- [ ] No deep nesting (>4 levels)
+- [ ] Proper error handling
+- [ ] No hardcoded values (use constants or config)
+- [ ] No mutation (immutable patterns used)

package/resources/ecc/rules/common-development-workflow.md

@@ -0,0 +1,33 @@
+---
+description: "Development workflow: plan, TDD, review, commit pipeline"
+alwaysApply: true
+---
+# Development Workflow
+
+> This rule extends the git workflow rule with the full feature development process that happens before git operations.
+
+The Feature Implementation Workflow describes the development pipeline: planning, TDD, code review, and then committing to git.
+
+## Feature Implementation Workflow
+
+1. **Plan First**
+   - Use **planner** agent to create implementation plan
+   - Identify dependencies and risks
+   - Break down into phases
+
+2. **TDD Approach**
+   - Use **tdd-guide** agent
+   - Write tests first (RED)
+   - Implement to pass tests (GREEN)
+   - Refactor (IMPROVE)
+   - Verify 80%+ coverage
+
+3. **Code Review**
+   - Use **code-reviewer** agent immediately after writing code
+   - Address CRITICAL and HIGH issues
+   - Fix MEDIUM issues when possible
+
+4. **Commit & Push**
+   - Detailed commit messages
+   - Follow conventional commits format
+   - See the git workflow rule for commit message format and PR process