Untitled
Everything Claude Code - A Practical Guide#
A guide to the everything-claude-code repository, a comprehensive toolkit for getting the most out of Claude Code. This collection comes from an Anthropic hackathon winner with 10+ months of intensive daily use.
Quick Overview#
The repo is organized into these main components:
| Component | Purpose | When to Use |
|---|---|---|
| Commands | Quick slash-command workflows | Day-to-day tasks like /tdd, /plan, /code-review |
| Agents | Specialized subagents for delegation | Complex tasks needing focused expertise |
| Skills | Workflow definitions with domain knowledge | Framework-specific patterns, testing strategies |
| Rules | Always-follow guidelines | Enforce coding standards automatically |
| Hooks | Trigger-based automations | Automate linting, formatting, reminders |
| Contexts | Dynamic system prompt injection | Switch modes (dev, research, review) |
| MCP Configs | External tool integrations | Connect GitHub, Supabase, Vercel, etc. |
Installation#
Option 1: Claude Code Plugin (Recommended)#
bashOption 2: Manual Installation#
bashCommands (31 Available)#
Commands are slash-shortcuts that trigger specific workflows. They live in ~/.claude/commands/.
Most Useful Commands#
/plan - Planning & Architecture#
Use before starting any significant feature. Analyzes requirements and creates step-by-step implementation plans.
text/tdd - Test-Driven Development#
Enforces the RED → GREEN → REFACTOR cycle. Never writes implementation before tests.
textThe TDD cycle:
- Scaffold interfaces
- Write failing tests
- Verify tests fail for the right reasons
- Implement minimally to pass
- Confirm tests pass
- Refactor while keeping tests green
- Re-verify
- Check coverage (80% minimum)
/code-review - Code Review#
Analyzes code for issues, security concerns, and improvements.
text/refactor-clean - Refactoring#
Clean up and refactor code while maintaining functionality.
/e2e - End-to-End Testing#
Set up and run E2E tests with proper patterns.
/build-fix - Build Error Resolution#
Systematically diagnose and fix build failures.
Multi-Agent Commands#
These orchestrate multiple specialized agents working together:
/multi-plan- Coordinate planning across multiple services/multi-execute- Execute tasks across multiple codebases/multi-backend- Backend-specific multi-agent coordination/multi-frontend- Frontend-specific multi-agent coordination/orchestrate- General task orchestration
Utility Commands#
/checkpoint- Save current state/sessions- Manage sessions/verify- Verification processes/test-coverage- Check test coverage/update-docs- Update documentation/update-codemaps- Refresh code maps
Agents (13 Specialists)#
Agents are specialized subagents that handle focused tasks. They run in isolated contexts, preserving the main agent's context window.
When to Use Subagents#
Use subagents when:
- You need focused expertise (security review, architecture)
- The task would consume too much context
- You want parallel execution of independent tasks
Available Agents#
| Agent | Purpose | Example Use Case |
|---|---|---|
| Planner | Creates detailed implementation plans | Breaking down a complex feature |
| Architect | Reviews and designs system architecture | Designing a new service |
| Code Reviewer | Reviews code for quality and issues | PR reviews |
| Security Reviewer | Focuses on security vulnerabilities | Pre-deployment security audit |
| TDD Guide | Guides test-driven development | Learning/enforcing TDD |
| Build Error Resolver | Diagnoses build failures | Fixing CI failures |
| E2E Runner | Manages end-to-end testing | Setting up Playwright tests |
| Doc Updater | Updates documentation | Keeping docs in sync |
| Refactor Cleaner | Handles refactoring tasks | Large-scale refactors |
| Database Reviewer | Reviews database schemas/queries | Optimizing queries |
| Go Reviewer | Go-specific code review | Go projects |
| Go Build Resolver | Go build issues | Go compilation errors |
| Python Reviewer | Python-specific review | Python projects |
Example: Using the Planner Agent#
textThe planner will:
- Analyze requirements
- Review existing architecture
- Create phased implementation steps
- Identify risks and testing strategies
Skills (29 Workflows)#
Skills are detailed workflow definitions with domain knowledge. They tell Claude how to do things (vs rules which say what to do).
Core Skills#
tdd-workflow#
Complete TDD methodology including when to write tests, coverage targets, and anti-patterns to avoid.
coding-standards#
General code quality guidelines - file sizes, error handling, validation patterns.
verification-loop#
Ensures code meets requirements through systematic verification.
continuous-learning#
System for Claude to learn from patterns and improve over time.
Framework-Specific Skills#
TypeScript/JavaScript:
frontend-patterns- React, Next.js patternsbackend-patterns- Node.js, API patterns
Python:
python-patterns- Pythonic code patternspython-testing- pytest, testing strategiesdjango-patterns- Django-specific patternsdjango-tdd- TDD with Djangodjango-security- Django security
Go:
golang-patterns- Idiomatic Gogolang-testing- Go testing patterns
Java:
java-coding-standards- Java conventionsspringboot-patterns- Spring Boot patternsspringboot-tdd- TDD with Springspringboot-security- Spring securityjpa-patterns- JPA/Hibernate patterns
Database:
postgres-patterns- PostgreSQL best practicesclickhouse-io- ClickHouse analytics
Using Skills#
Skills are typically activated automatically based on context, but you can explicitly request them:
textRules#
Rules are always-follow guidelines that Claude checks automatically. They're organized by scope:
textCommon Rules Include#
Coding Style:
- Keep files 200-400 lines (max 800)
- Prefer immutability
- Validate all inputs
- No console.log in production
Git Workflow:
- Use conventional commits
- Require PR reviews
- Branch naming conventions
Testing:
- 80% minimum coverage
- 100% for critical paths (auth, security, payments)
- Write tests before implementation
Security:
- No hardcoded credentials
- Use environment variables
- Parameterized queries
- CSRF protection
Hooks#
Hooks automate actions based on triggers. They're defined in ~/.claude/hooks/hooks.json.
Available Triggers#
| Trigger | When It Fires |
|---|---|
PreToolUse |
Before a tool executes |
PostToolUse |
After a tool completes |
SessionStart |
When a session begins |
SessionEnd |
When a session ends |
PreCompact |
Before context compression |
Stop |
When Claude stops |
Example Hooks#
Remind to use tmux for long commands:
jsonAuto-format TypeScript on edit:
jsonBlock random markdown creation:
jsonReview reminder before git push:
jsonContexts#
Contexts inject different system prompts for different modes of work.
Available Contexts#
| Context | Purpose |
|---|---|
dev.md |
Active development mode |
research.md |
Investigation and learning |
review.md |
Code review focus |
Switch contexts by referencing them:
textMCP Configs#
Pre-configured integrations for external services. Edit credentials in ~/.claude/mcp-configs/mcp-servers.json.
Available Integrations#
Development:
- GitHub - PRs, issues, repos (requires PAT)
- Supabase - Database operations
- Vercel - Deployments
- Railway - Railway deployments
Utilities:
- Memory - Persistent memory across sessions
- Sequential Thinking - Chain-of-thought reasoning
- Filesystem - Local file operations
- Firecrawl - Web scraping
Documentation:
- Context7 - Live docs lookup
- Cloudflare Docs - CF documentation search
Analytics:
- ClickHouse - Analytics queries
Performance Note#
"Your 200k context window might only be 70k with too many tools enabled."
Recommendation: Keep 20-30 MCPs configured but enable fewer than 10 simultaneously.
Example CLAUDE.md Structure#
The repo includes an example project CLAUDE.md you can adapt:
markdownQuick Reference#
Daily Workflow Commands#
textWhen to Use What#
| Situation | Use |
|---|---|
| Starting a new feature | /plan first, then /tdd |
| Fixing a bug | /tdd to write failing test first |
| PR review | /code-review |
| Build failing | /build-fix |
| Security audit | Security Reviewer agent |
| Architecture decisions | Architect agent |
| Large refactor | /refactor-clean with Refactor Cleaner agent |
Tips from the Author#
- Don't over-engineer your config - Treat it as fine-tuning, not architecture
- Context window management - Keep MCPs under 10 active at once
- Use tmux - For long-running commands and log persistence
- TDD is non-negotiable - "Never skip the RED phase"
- Subagents for focus - Delegate specialized tasks to preserve main context