abuango.
ai developer-tools claude-code workflow mcp

6 Claude Code Features Most Developers Don't Know Exist

· 8 min read
On this page

Most developers use Claude Code the same way: open a terminal, describe a task, watch it write code. Maybe you’ve set up a CLAUDE.md file. Maybe you’ve tried MCP.

That’s roughly 20% of what it can do.

But there’s a layer underneath that most developers never touch. Features buried in docs, behind experimental flags, or just not obvious from the default experience.

Here are six that changed how I work.

1. Hooks: Make Claude Code React to Its Own Actions

Hooks are shell commands that fire automatically when Claude Code does something. Session starts, file edits, task completions. They’re configured in .claude/settings.json and they run without you typing anything.

This is the feature that turns Claude Code from a tool you talk to into a system that enforces your workflow.

What I use hooks for:

Session lifecycle. When I start Claude Code, a SessionStart hook automatically registers the session, loads context, and prints critical reminders:

{
  "hooks": {
    "SessionStart": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "./scripts/session-register.sh claude-code"
      }]
    }]
  }
}

When I close, a SessionEnd hook creates a handoff record so the next session knows what happened.

Plan enforcement. A PreToolUse hook blocks all file edits unless a plan has been approved first. No plan, no code. This catches the most expensive mistake in AI-assisted development: writing code before thinking.

{
  "matcher": "Edit|Write",
  "hooks": [{
    "type": "command",
    "command": "./scripts/plan-gate.sh"
  }]
}

The script checks for a per-context lock file created by approve-plan.sh. If it doesn’t exist, the edit is blocked with a message explaining what to do.

Auto-formatting. A PostToolUse hook runs the right formatter after every edit, based on file extension. PHP gets Pint, TypeScript gets Prettier, Go gets gofmt. No manual formatting step, no forgotten lint runs:

{
  "matcher": "Edit",
  "hooks": [{
    "type": "command",
    "command": "case \"$CLAUDE_FILE_PATH\" in *.php) php vendor/bin/pint $CLAUDE_FILE_PATH ;; *.ts|*.tsx) npx prettier --write $CLAUDE_FILE_PATH ;; *.go) gofmt -w $CLAUDE_FILE_PATH ;; esac"
  }]
}

Why this matters: Hooks let you encode your engineering standards into the tool itself. You stop relying on Claude to remember your rules and start enforcing them mechanically.

2. Custom Skills: Reusable Workflow Templates

Skills are Markdown files in .claude/skills/ that define reusable workflows. They’re like scripts, but for Claude’s behavior rather than shell commands.

Each skill has YAML frontmatter (name, description, allowed tools) and a structured process. When you type /skill-name, Claude loads that file and follows the instructions.

I have 35 skills. Here are a few that get daily use:

/code-review runs a standardized review with checklist categories: plan compliance, code quality, security, testing, performance. Every review follows the same format. Every review checks the same things.

/parallel-review runs three review agents simultaneously. One checks code quality. One checks security. One checks documentation. Results merge into a single severity-ranked report. This implements the parallel workflow pattern from Anthropic’s agent design guide, where independent subtasks run concurrently and results are aggregated.

/plan-generation produces implementation plans with architecture analysis, risk assessment, and task breakdown. The plan becomes the contract. Code only happens after the plan is approved.

The skill structure looks like this:

.claude/skills/
  code-review/
    SKILL.md          # Workflow definition
    references/       # Bundled documentation (loaded on demand)
  security-audit/
    SKILL.md
    references/
      owasp-top10.md  # Loaded only when skill runs

Why this matters: Skills eliminate the “explain it every time” problem. Instead of describing your code review process in every conversation, you define it once and invoke it with a slash command. The process stays consistent across sessions.

3. Agent Teams: Parallel Execution with Delegation

Agent Teams is an experimental feature (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1) that spawns multiple Claude Code agents working on tasks simultaneously. One agent leads, the others execute.

I use this for sprint execution. The /team-sprint skill:

  1. Creates a team via TeamCreate
  2. Spawns teammates (up to 4 engineers) as subagents
  3. Assigns tasks via TaskCreate
  4. The lead monitors progress and approves plans
  5. Each completed task produces a handoff record

The delegation chain maps to real roles: CTO initiates, a TPM leads, engineers execute. The TPM agent operates in delegate mode, reviewing and approving plans before engineers write code.

CTO (you)
  -> TPM Agent (lead, delegate mode)
      -> Engineer Agent 1 (task: API endpoint)
      -> Engineer Agent 2 (task: database migration)
      -> Engineer Agent 3 (task: frontend component)

Lessons learned the hard way:

  • Setting agents to mode: "plan" causes cycling. They re-enter plan mode after every tool use, requiring 10+ approvals per task. Use mode: "default" and add explicit plan instructions to the prompt instead.
  • Handoff records must be created per-task during execution. If you defer them to teardown, you lose context when things fail.
  • TeamDelete fails if any members are still active. Shut down all agents before cleanup.

Why this matters: Some tasks are naturally parallel. A sprint with three independent features doesn’t need to be sequential. Agent Teams let you run them concurrently with coordination.

4. MCP Servers: Custom Tool Integration

MCP (Model Context Protocol) lets you give Claude Code access to external systems through custom tool servers. Most people know about the community MCP servers for GitHub, Slack, or databases. Fewer people build their own.

Building a custom MCP server is simpler than it sounds. You write a Node.js (or Python) server that exposes tools, configure it in .claude/settings.json, and Claude Code can call those tools during conversations:

{
  "mcpServers": {
    "my-tools": {
      "command": "node",
      "args": ["./mcp-server/dist/index.js"],
      "env": {
        "API_URL": "https://your-app.com"
      }
    }
  }
}

Any internal API, database, or service you work with regularly is a candidate. Task management, deployment pipelines, monitoring dashboards, content management systems. Once exposed as MCP tools, Claude can query and act on them without you switching contexts.

The real power comes from combining multiple MCP servers. GitLab for repository management, a deployment platform for releases, your own app’s API for domain-specific operations. Claude Code becomes a single interface to your entire stack.

Why this matters: MCP turns Claude Code into a control plane. Instead of switching between terminals, dashboards, and project boards, you talk to one tool that has access to all of them.

5. Evaluator-Optimizer Loop: Self-Correcting Code Generation

This is a workflow pattern, not a built-in feature. But Claude Code’s custom commands make it easy to implement.

The idea comes from Anthropic’s guide on agent workflow patterns: separate generation from evaluation. One pass writes the code. A second pass evaluates it against criteria. If it fails, it fixes and re-evaluates. Maximum three iterations.

I implemented this as /eval-loop, a custom command in .claude/commands/eval-loop.md:

## Process

1. Capture what changed (git diff)
2. Evaluate against criteria:
   - No functions longer than 30 lines
   - No duplicated logic
   - No TypeScript `any` types
   - All async operations have error handling
   - No SQL injection vectors
   - No hardcoded secrets
3. For each failure: report file:line, issue, fix
4. Apply fixes
5. Re-evaluate (max 3 iterations)
6. Final report: iterations, issues found, issues resolved

The key insight is that generation and evaluation use different thinking. When Claude writes code, it’s optimizing for completing the task. When it evaluates code, it’s optimizing for finding problems. Separating these into distinct passes catches issues that a single pass misses.

After writing a feature, I type /eval-loop and the agent re-reads what it just wrote with fresh eyes.

Why this matters: AI-generated code has predictable failure modes: missing error handling, overly long functions, security oversights. A structured evaluation loop catches these systematically instead of hoping the first pass was clean.

6. Parallel Review: Multi-Agent Code Review

This combines patterns 2 and 3. Instead of one reviewer catching everything, three specialized agents review simultaneously and their findings merge into one report.

I built /parallel-review as a custom skill:

Step 1: Identify changed files (git diff)
Step 2: Spawn 3 agents in parallel:
  - Agent 1: Code quality (functions, duplication, types, error handling)
  - Agent 2: Security (OWASP Top 10, secrets, injection, XSS)
  - Agent 3: Documentation (comments, tests, README, changelog)
Step 3: Synthesize results
  - Deduplicate findings across agents
  - Rank by severity (Critical > High > Warning > Suggestion)
  - Group by file for easy navigation
Step 4: Generate unified report

The output is a single report with a summary table and severity-ranked findings:

| Category       | Critical | High | Warning | Suggestion |
|----------------|----------|------|---------|------------|
| Code Quality   | 0        | 1    | 3       | 2          |
| Security       | 1        | 0    | 1       | 0          |
| Documentation  | 0        | 0    | 2       | 4          |

Each agent gets the same file list but a different focus. They don’t interfere with each other. The synthesis step handles overlapping findings.

Why this matters: A single code review pass tends to anchor on one category. If the reviewer finds a security issue, they focus on security and miss code quality problems. Parallel specialized reviewers eliminate this bias.

The Pattern Behind the Features

These six features share a theme: they move Claude Code from “tool I talk to” toward “system that enforces my workflow.”

  • Hooks enforce rules mechanically
  • Skills encode processes as reusable templates
  • Agent Teams parallelize work with coordination
  • MCP Servers connect to external systems
  • Eval-Loop separates generation from evaluation
  • Parallel Review distributes review across specialists

None of these require building a custom product. They’re all configuration: JSON settings, Markdown files, and shell scripts in a Git repo.

The broader principle from Anthropic’s agent workflow patterns guide applies: start simple, add complexity only when you can measure the improvement. I started with CLAUDE.md. Then hooks. Then skills. Each addition solved a specific problem I could point to.

If you’re using Claude Code and it still feels like a chatbot, start with hooks. Automate one thing that you currently do manually every session. That’s the entry point to everything else.

The workflow system behind these features is open source at github.com/abuango/pos-ai. The agent workflow patterns referenced are from Anthropic’s Common Workflow Patterns for AI Agents.