mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-03-30 21:53:28 +08:00
* feat: add pending instinct TTL pruning and /prune command Pending instincts generated by the observer accumulate indefinitely with no cleanup mechanism. This adds lifecycle management: - `instinct-cli.py prune` — delete pending instincts older than 30 days (configurable via --max-age). Supports --dry-run and --quiet flags. - Enhanced `status` command — shows pending count, warns at 5+, highlights instincts expiring within 7 days. - `observer-loop.sh` — runs prune before each analysis cycle. - `/prune` slash command — user-facing command for manual pruning. Design rationale: council consensus (4/4) rejected auto-promote in favor of TTL-based garbage collection. Frequency of observation does not establish correctness. Unreviewed pending instincts auto-delete after 30 days; if the pattern is real, the observer will regenerate it. Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> * fix: remove duplicate functions, broaden extension filter, fix prune output - Remove duplicate _collect_pending_dirs and _parse_created_date defs - Use ALLOWED_INSTINCT_EXTENSIONS (.md/.yaml/.yml) instead of .md-only - Track actually-deleted items separately from expired for accurate output - Update README.md and AGENTS.md command counts: 59 → 60 Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> * fix: address Copilot and CodeRabbit review findings - Use is_dir() instead of exists() for pending path checks - Change > to >= for --max-age boundary (--max-age 0 now prunes all) - Use CLV2_PYTHON_CMD env var in observer-loop.sh prune call - Remove unused source_dupes variable - Remove extraneous f-string prefix on static string Generated with [Claude Code](https://claude.ai/code) via [Happy](https://happy.engineering) Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: Happy <yesreply@happy.engineering> * fix: update AGENTS.md project structure command count 59 → 60 Co-Authored-By: Claude <noreply@anthropic.com> * fix: address cubic and coderabbit review findings - Fix status early return skipping pending instinct warnings (cubic #1) - Exclude already-expired items from expiring-soon filter (cubic #2) - Warn on unparseable pending instinct age instead of silent skip (cubic #4) - Log prune failures to observer.log instead of silencing (cubic #5) Co-Authored-By: Claude <noreply@anthropic.com> * fix: YAML single-quote unescaping, f-string cleanup, add /prune to README - Fix single-quoted YAML unescaping: use '' doubling (YAML spec) not backslash escaping which only applies to double-quoted strings (greptile P1) - Remove extraneous f-string prefix on static string (coderabbit) - Add /prune to README command catalog and file tree (cubic) Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Happy <yesreply@happy.engineering>
161 lines
7.7 KiB
Markdown
161 lines
7.7 KiB
Markdown
# Everything Claude Code (ECC) — Agent Instructions
|
|
|
|
This is a **production-ready AI coding plugin** providing 28 specialized agents, 116 skills, 60 commands, and automated hook workflows for software development.
|
|
|
|
**Version:** 1.9.0
|
|
|
|
## Core Principles
|
|
|
|
1. **Agent-First** — Delegate to specialized agents for domain tasks
|
|
2. **Test-Driven** — Write tests before implementation, 80%+ coverage required
|
|
3. **Security-First** — Never compromise on security; validate all inputs
|
|
4. **Immutability** — Always create new objects, never mutate existing ones
|
|
5. **Plan Before Execute** — Plan complex features before writing code
|
|
|
|
## Available Agents
|
|
|
|
| Agent | Purpose | When to Use |
|
|
|-------|---------|-------------|
|
|
| planner | Implementation planning | Complex features, refactoring |
|
|
| architect | System design and scalability | Architectural decisions |
|
|
| tdd-guide | Test-driven development | New features, bug fixes |
|
|
| code-reviewer | Code quality and maintainability | After writing/modifying code |
|
|
| security-reviewer | Vulnerability detection | Before commits, sensitive code |
|
|
| build-error-resolver | Fix build/type errors | When build fails |
|
|
| e2e-runner | End-to-end Playwright testing | Critical user flows |
|
|
| refactor-cleaner | Dead code cleanup | Code maintenance |
|
|
| doc-updater | Documentation and codemaps | Updating docs |
|
|
| docs-lookup | Documentation and API reference research | Library/API documentation questions |
|
|
| cpp-reviewer | C++ code review | C++ projects |
|
|
| cpp-build-resolver | C++ build errors | C++ build failures |
|
|
| go-reviewer | Go code review | Go projects |
|
|
| go-build-resolver | Go build errors | Go build failures |
|
|
| kotlin-reviewer | Kotlin code review | Kotlin/Android/KMP projects |
|
|
| kotlin-build-resolver | Kotlin/Gradle build errors | Kotlin build failures |
|
|
| database-reviewer | PostgreSQL/Supabase specialist | Schema design, query optimization |
|
|
| python-reviewer | Python code review | Python projects |
|
|
| java-reviewer | Java and Spring Boot code review | Java/Spring Boot projects |
|
|
| java-build-resolver | Java/Maven/Gradle build errors | Java build failures |
|
|
| chief-of-staff | Communication triage and drafts | Multi-channel email, Slack, LINE, Messenger |
|
|
| loop-operator | Autonomous loop execution | Run loops safely, monitor stalls, intervene |
|
|
| harness-optimizer | Harness config tuning | Reliability, cost, throughput |
|
|
| rust-reviewer | Rust code review | Rust projects |
|
|
| rust-build-resolver | Rust build errors | Rust build failures |
|
|
| pytorch-build-resolver | PyTorch runtime/CUDA/training errors | PyTorch build/training failures |
|
|
| typescript-reviewer | TypeScript/JavaScript code review | TypeScript/JavaScript projects |
|
|
|
|
## Agent Orchestration
|
|
|
|
Use agents proactively without user prompt:
|
|
- Complex feature requests → **planner**
|
|
- Code just written/modified → **code-reviewer**
|
|
- Bug fix or new feature → **tdd-guide**
|
|
- Architectural decision → **architect**
|
|
- Security-sensitive code → **security-reviewer**
|
|
- Multi-channel communication triage → **chief-of-staff**
|
|
- Autonomous loops / loop monitoring → **loop-operator**
|
|
- Harness config reliability and cost → **harness-optimizer**
|
|
|
|
Use parallel execution for independent operations — launch multiple agents simultaneously.
|
|
|
|
## Security Guidelines
|
|
|
|
**Before ANY commit:**
|
|
- No hardcoded secrets (API keys, passwords, tokens)
|
|
- All user inputs validated
|
|
- SQL injection prevention (parameterized queries)
|
|
- XSS prevention (sanitized HTML)
|
|
- CSRF protection enabled
|
|
- Authentication/authorization verified
|
|
- Rate limiting on all endpoints
|
|
- Error messages don't leak sensitive data
|
|
|
|
**Secret management:** NEVER hardcode secrets. Use environment variables or a secret manager. Validate required secrets at startup. Rotate any exposed secrets immediately.
|
|
|
|
**If security issue found:** STOP → use security-reviewer agent → fix CRITICAL issues → rotate exposed secrets → review codebase for similar issues.
|
|
|
|
## Coding Style
|
|
|
|
**Immutability (CRITICAL):** Always create new objects, never mutate. Return new copies with changes applied.
|
|
|
|
**File organization:** Many small files over few large ones. 200-400 lines typical, 800 max. Organize by feature/domain, not by type. High cohesion, low coupling.
|
|
|
|
**Error handling:** Handle errors at every level. Provide user-friendly messages in UI code. Log detailed context server-side. Never silently swallow errors.
|
|
|
|
**Input validation:** Validate all user input at system boundaries. Use schema-based validation. Fail fast with clear messages. Never trust external data.
|
|
|
|
**Code quality checklist:**
|
|
- Functions small (<50 lines), files focused (<800 lines)
|
|
- No deep nesting (>4 levels)
|
|
- Proper error handling, no hardcoded values
|
|
- Readable, well-named identifiers
|
|
|
|
## Testing Requirements
|
|
|
|
**Minimum coverage: 80%**
|
|
|
|
Test types (all required):
|
|
1. **Unit tests** — Individual functions, utilities, components
|
|
2. **Integration tests** — API endpoints, database operations
|
|
3. **E2E tests** — Critical user flows
|
|
|
|
**TDD workflow (mandatory):**
|
|
1. Write test first (RED) — test should FAIL
|
|
2. Write minimal implementation (GREEN) — test should PASS
|
|
3. Refactor (IMPROVE) — verify coverage 80%+
|
|
|
|
Troubleshoot failures: check test isolation → verify mocks → fix implementation (not tests, unless tests are wrong).
|
|
|
|
## Development Workflow
|
|
|
|
1. **Plan** — Use planner agent, identify dependencies and risks, break into phases
|
|
2. **TDD** — Use tdd-guide agent, write tests first, implement, refactor
|
|
3. **Review** — Use code-reviewer agent immediately, address CRITICAL/HIGH issues
|
|
4. **Capture knowledge in the right place**
|
|
- Personal debugging notes, preferences, and temporary context → auto memory
|
|
- Team/project knowledge (architecture decisions, API changes, runbooks) → the project's existing docs structure
|
|
- If the current task already produces the relevant docs or code comments, do not duplicate the same information elsewhere
|
|
- If there is no obvious project doc location, ask before creating a new top-level file
|
|
5. **Commit** — Conventional commits format, comprehensive PR summaries
|
|
|
|
## Git Workflow
|
|
|
|
**Commit format:** `<type>: <description>` — Types: feat, fix, refactor, docs, test, chore, perf, ci
|
|
|
|
**PR workflow:** Analyze full commit history → draft comprehensive summary → include test plan → push with `-u` flag.
|
|
|
|
## Architecture Patterns
|
|
|
|
**API response format:** Consistent envelope with success indicator, data payload, error message, and pagination metadata.
|
|
|
|
**Repository pattern:** Encapsulate data access behind standard interface (findAll, findById, create, update, delete). Business logic depends on abstract interface, not storage mechanism.
|
|
|
|
**Skeleton projects:** Search for battle-tested templates, evaluate with parallel agents (security, extensibility, relevance), clone best match, iterate within proven structure.
|
|
|
|
## Performance
|
|
|
|
**Context management:** Avoid last 20% of context window for large refactoring and multi-file features. Lower-sensitivity tasks (single edits, docs, simple fixes) tolerate higher utilization.
|
|
|
|
**Build troubleshooting:** Use build-error-resolver agent → analyze errors → fix incrementally → verify after each fix.
|
|
|
|
## Project Structure
|
|
|
|
```
|
|
agents/ — 28 specialized subagents
|
|
skills/ — 115 workflow skills and domain knowledge
|
|
commands/ — 60 slash commands
|
|
hooks/ — Trigger-based automations
|
|
rules/ — Always-follow guidelines (common + per-language)
|
|
scripts/ — Cross-platform Node.js utilities
|
|
mcp-configs/ — 14 MCP server configurations
|
|
tests/ — Test suite
|
|
```
|
|
|
|
## Success Metrics
|
|
|
|
- All tests pass with 80%+ coverage
|
|
- No security vulnerabilities
|
|
- Code is readable and maintainable
|
|
- Performance is acceptable
|
|
- User requirements are met
|