A practical, opinionated guide to getting the most out of Claude Code. Two proven workflows, real configs, and the mental model that ties it all together.
Each solves a different problem. Use the right one for the job — don't cram everything into .claude.md.
The core principle: context is precious. .claude.md is always loaded (keep it under 300 lines). Skills load on demand. Sub-agents get their own context windows. Hooks run outside context entirely. Design for progressive disclosure, not "dump everything upfront."
Use this to decide which layer is right for each piece of knowledge or behavior:
Project-specific (build commands, tech stack) → .claude.md
Cross-project, stable (metric definitions, API standards) → Skill
Rapidly changing (sprint priorities, temp workarounds) → .claude.md
Specialized mindset (code reviewer, security auditor) → Sub-Agent
Context isolation needed (heavy analysis, exploration) → Sub-Agent
External APIs, live data (GitHub, database, Sentry) → MCP Server
Must always happen (format code, block .env edits, log commands) → Hook
If you're relying on Claude "remembering" to do something, it should be a hook.
From problem definition through verified, shipped code — with context transferring cleanly across sessions.
A structured interview that walks through problem definition, jobs-to-be-done mapping, and codebase analysis before any code is written.
"What problem are you trying to solve?" — forces clarity before solutions. Challenges vague or solution-first thinking.
"What job are users hiring this feature to do?" — maps functional jobs to specific functionality and success criteria.
Agent explores existing patterns, affected files (with line numbers), database impact, security implications. You get a confirmation checkpoint before it proceeds.
TDD-focused recommendations: phase-by-phase breakdown, files to create/modify, test strategy. Everything the next developer needs.
Converts everything from the interview into a comprehensive GitHub issue. This invokes the github-issue-creator skill, which structures the output for another developer (or agent) to implement.
The issue includes: root cause analysis, specific file references with line numbers, TDD workflow (mandatory), user integration flow, proposed data model changes, and security considerations.
Key principle: "Write for the next developer." They won't have your conversation — only this issue. The /document command transfers all your research into something actionable.
Start a new session (clear context). This command reads the GitHub issue and sets up everything automatically:
feature/247-engagement-history)For complex issues, this is where agent teams come in: each implementation phase gets a discrete agent with focused scope. They share context through the issue spec and follow the best practices outlined in it.
Not done until verified through two channels:
Automated tests: TDD means tests were written first. Baseline is compared — new failures block shipping.
Chrome MCP: Claude drives the browser directly — navigates to the feature, interacts with it, screenshots for visual verification. Catches what unit tests miss.
Commits (conventional commit format), pushes, writes changelog entries (both internal CHANGELOG.md and public changelog page), creates a PR. Every step requires your approval.
The "Think Out Loud" pattern — don't tell Claude to fix it. Tell Claude to explain what changes are needed.
The insight: When you ask Claude to "fix this bug," it jumps straight to code. When you ask Claude to "review this code and determine what changes would be needed," it thinks through the problem systematically — building rich context in the process. That context is what makes /document produce a thorough implementation spec.
"Review the code related to [feature/area]" — gets Claude oriented in the relevant part of the codebase.
"What changes would be needed for the system to [desired behavior]?" — deliberately asks Claude to articulate, not implement.
This is the priming step. Claude walks through affected files, dependencies, edge cases, and tradeoffs — building context that wouldn't exist if you just said "fix it."
Converts all that analysis into a TDD-focused GitHub issue. The issue is richer because Claude already thought through the problem.
New session picks up the well-documented issue. TDD ensures the fix is verified. Same pipeline as Workflow 1 from here.
You're not writing prompts. You're designing how Claude builds understanding.
The requirements interview isn't just gathering info — it's building the context that makes /document produce great output. The quality of the input determines the quality of the artifact.
Clear context between phases. The GitHub issue is the knowledge transfer mechanism — it carries what matters and leaves stale context behind. Fresh sessions mean fresh performance.
Sub-agents don't just save tokens — they bring unbiased perspective. A code reviewer that didn't write the code catches things the author won't. A database auditor that loads the security skill finds risks the implementer overlooked.
Don't skip to Month 4 on Day 1. Each layer builds on the previous.
Start with a lean .claude.md for your project. Under 300 lines. Include:
# .claude.md
## Tech Stack
Next.js 14, TypeScript, Tailwind, Supabase
## Commands
- npm run dev — Start dev server
- npm test — Run test suite
- npm run build — Production build
## Conventions
- Components in src/components/
- Server actions in src/actions/
- Tests in __tests__/ directories
Add hooks for things that must always happen. Start with protected files and auto-formatting.
// ~/.claude/settings.json
{
"hooks": {
"PostToolUse": [{
"matcher": "Edit|Write",
"hooks": [{
"type": "command",
"command": "prettier --write \"$FILEPATH\""
}]
}],
"PreToolUse": [{
"matcher": "Edit|Write",
"hooks": [{
"type": "command",
"command": "~/.claude/hooks/block-protected.sh"
}]
}]
}
}
Why hooks over prompting? Prompting says "please format code." Hooks say "code is always formatted." One is a suggestion. The other is a guarantee.
Connect Claude to the services you use repeatedly. Start with GitHub and your database.
# Add GitHub MCP
claude mcp add --transport stdio github \
-- npx -y @anthropic/mcp-server-github
# Add PostgreSQL MCP
claude mcp add --transport stdio postgres \
--env DATABASE_URL=${DATABASE_URL} \
-- npx -y @modelcontextprotocol/server-postgres
Notice patterns you explain repeatedly. Create your first skill with progressive disclosure: a lean SKILL.md (~500 words) with detailed references on demand.
# ~/.claude/skills/company-metrics/SKILL.md (~500 words)
---
name: company-metrics
description: "Company metric definitions and calculation patterns"
---
## Key Metrics
- MRR: SUM(subscription_amount) WHERE status='active'
- Churn: See references/churn-calculation.md
- LTV: See references/ltv-model.md
# ~/.claude/skills/company-metrics/references/churn-calculation.md
# (detailed docs, loaded only when relevant)
Progressive disclosure: Load 500 words upfront, 10,000 words on-demand. Context stays clean.
Create agents for specialized behavior. The key: agents are for behavior, not knowledge. Put knowledge in skills and let agents inherit it.
# .claude/agents/code-reviewer.md
---
name: code-reviewer
description: "Reviews code for quality, security, and convention compliance"
---
You are a code reviewer. Review with fresh perspective.
Focus on: security issues, missing error handling,
convention violations, and test coverage gaps.
Load the api-standards skill for pattern reference.
Once you know your workflow, encode it into commands. Commands are the glue — they orchestrate skills, agents, and tools into repeatable sequences.
# .claude/commands/start-work.md
# Fetches issue, creates branch, runs baseline,
# detects TDD requirements, reviews available tools
# .claude/commands/ship-it.md
# Builds, tests, commits, pushes, writes changelog, creates PR
# .claude/commands/document.md
# Converts conversation into a GitHub issue
# using the github-issue-creator skill
Commands are where the five layers come together. A single /start-work 247 can fetch an issue (MCP), create a branch (bash), load skills (knowledge), spawn agents (behavior), and enforce TDD (hooks).
Starter configs you can adapt. Copy what's useful, skip what's not.
# ~/.claude/skills/your-skill/SKILL.md
---
name: your-skill-name
description: "One line that tells Claude when to load this"
---
# Skill Name
## Purpose
What this skill teaches Claude to do.
## Core Knowledge (~500 words max)
The essential information Claude needs immediately.
Keep this lean — it's loaded into context.
## References (load on demand)
- See references/detailed-schemas.md for table schemas
- See references/query-patterns.md for SQL patterns
- See references/edge-cases.md for known gotchas
## When to Use
Activate when user asks about [triggers].
Don't use for [anti-triggers].
# .claude/agents/your-agent.md
---
name: your-agent-name
description: "What this agent does (behavior, not knowledge)"
---
You are a [role]. Your job is to [specific behavior].
# Load relevant skills for domain knowledge:
Load the [skill-name] skill for reference.
# Focus areas:
- [Specific thing to look for]
- [Specific thing to look for]
- [Specific thing to look for]
# Output format:
Report findings as:
1. Issue description
2. Location (file + line)
3. Severity (critical/warning/info)
4. Suggested fix
# .claude/commands/your-command.md
# /your-command - Short description
What this command does in one sentence.
## Usage
/your-command <argument>
## Workflow Steps
Execute in order. STOP and report if any step fails.
### Step 1: Pre-flight
[Validation checks]
### Step 2: Main action
[The core work — can invoke skills, agents, tools]
### Step 3: Verification
[Confirm the work succeeded]
### Step 4: Report
[Show results to user]
## Error Handling
| Error | Action |
|-------|--------|
| [Error type] | [What to do] |
Over 500 lines? You're wasting 20%+ of context before any work starts. Move cross-project knowledge to skills. Link instead of pasting.
Agents are for behavior, not knowledge. Put domain knowledge in skills and let agents inherit it. Otherwise you reload 10,000 words every time the agent runs.
Same metric definition in .claude.md, a skill, AND an agent prompt? That's 3x context cost and 3x update burden. Single source of truth, always.
"Always format code" in .claude.md is a suggestion. A PostToolUse hook is a guarantee. If it must always happen, make it a hook.