Claude is powerful out of the box — but the real leverage comes from configuring it properly. Most developers treat Claude as a chat interface and leave significant capability on the table. This guide walks through the four pillars of Claude Agent configuration: Skills, MCP Servers, Rules, and Prompts.

By the end, your Claude agent will have persistent tools, consistent behavior, domain-specific knowledge, and reusable workflows.

The Four Configuration Layers Think of a Claude Agent as a stack:

┌─────────────────────────────┐ │ Prompts │ ← What you ask ├─────────────────────────────┤ │ Skills │ ← How it behaves (workflows) ├─────────────────────────────┤ │ Rules │ ← Guardrails and style ├─────────────────────────────┤ │ MCP Servers │ ← Tools and external access └─────────────────────────────┘ Each layer builds on the one below. Let's configure them from the bottom up.

Layer 1: MCP Servers — Give Claude Tools MCP (Model Context Protocol) is Anthropic's standard for connecting Claude to external systems. An MCP server exposes tools that Claude can call: read files, query databases, search the web, interact with APIs.

Setting Up Your First MCP Server For Claude Code, MCP servers are configured in your project's .mcp.json file or globally at ~/.claude/mcp.json:

{ "mcpServers": { "github": { "command": "npx", "args": ["@modelcontextprotocol/server-github"], "env": { "GITHUB_TOKEN": "your_token_here" } }, "filesystem": { "command": "npx", "args": [ "@modelcontextprotocol/server-filesystem", "/Users/you/projects" ] }, "postgres": { "command": "npx", "args": [ "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb" ] } } } Essential MCP Servers to Start With Server What it does When to add it @modelcontextprotocol/server-github Full GitHub API: PRs, issues, code search Any dev project @modelcontextprotocol/server-filesystem Read/write local files safely Local automation @modelcontextprotocol/server-postgres Query PostgreSQL databases Backend work @modelcontextprotocol/server-fetch HTTP requests + web content API integrations @modelcontextprotocol/server-memory Persistent knowledge graph Long-running agents @modelcontextprotocol/server-brave-search Web search Research tasks A Note on Security Only add MCP servers you trust. Each server runs a process on your machine with the permissions you grant it. For filesystem servers, always scope to specific directories — never / or ~.

{ "mcpServers": { "filesystem": { "command": "npx", "args": [ "@modelcontextprotocol/server-filesystem", "/Users/you/projects/myapp" // ✅ Scoped path // "/Users/you" // ❌ Too broad ] } } } Layer 2: Rules — Define Consistent Behavior Rules (also called system instructions or CLAUDE.md) tell Claude how to operate in your environment. They answer: what style of code should it write? What should it never do? What conventions does your team follow?

The CLAUDE.md File For Claude Code, create a CLAUDE.md at your project root. Claude reads this automatically at the start of every session.

CLAUDE.md

Project: MyApp API

Stack

Language: Go 1.23+
Framework: Echo v4
Database: PostgreSQL with sqlc (NO raw sql.DB queries)
Tests: testify/assert, table-driven style

Coding Rules

Never use interface{} — use concrete types or generics
All errors must be wrapped with fmt.Errorf("context: %w", err)
HTTP handlers are thin — delegate all logic to service layer
No third-party packages without discussing first

Commit Style

Conventional commits: feat/fix/docs/refactor/test/chore
Present tense, imperative mood: "add feature" not "added feature"
Max 72 chars in subject line

Never Do

Never delete database migration files
Never expose internal errors to API responses
Never commit secrets or .env files Global vs. Project Rules You can have rules at two levels:

Project level (./CLAUDE.md) — applies to this codebase only Global level (~/.claude/CLAUDE.md) — applies to all your Claude sessions A good global CLAUDE.md might include your preferred communication style, coding philosophy, and personal shortcuts. Project-level rules handle project-specific conventions.

What Makes a Good Rule? Be specific and actionable:

// ❌ Too vague Be careful with databases.

// ✅ Specific Always use transactions for operations that modify more than one table. Rollback on any error. Log the error with context before returning. Explain the "why" for non-obvious rules:

// Use sqlc for all database queries (not raw DB calls) // Reason: Type safety + all queries are auditable in one place Layer 3: Skills — Encode Repeatable Workflows A Skill is a reusable behavioral module — a structured prompt that encodes a workflow. Unlike one-off instructions, skills are consistent, shareable, and composable.

What's in a Skill? A skill is typically a markdown file that defines:

Trigger — when this skill activates Steps — the workflow to follow Output format — what to produce Here's a real example — a code review skill:

Code Reviewer Skill

Trigger

Activated when reviewing a PR or when asked to review code.

Workflow

Read the diff and understand what changed and why
Check for security issues first (OWASP Top 10, injection, auth)
Check logic correctness — edge cases, error handling
Check code quality — duplication, readability, naming
Check tests — coverage of new code, test quality
Summarize findings by severity: Critical / Warning / Suggestion

Output Format

Security (Critical)

[issue]: [specific location] — [why it's a problem] — [how to fix]

Logic Issues (Warning)

[issue]: [location] — [explanation]

Suggestions

[improvement]: [location] — [rationale]

Rules

Lead with the most important finding
Always link to the specific line or function
Never give generic advice — be specific to this code Installing Skills in Claude Code Place skill files in your .claude/skills/ directory:

.claude/ ├── skills/ │ ├── code-reviewer.md │ ├── git-workflow.md │ ├── tdd-master.md │ └── incident-responder.md └── CLAUDE.md Then reference them in your CLAUDE.md:

Available Skills

Code review: use the code-reviewer skill
Git commits: use the git-workflow skill
Writing tests: use the tdd-master skill Pre-built Skills Worth Using Rather than writing skills from scratch, you can find community-built skills for common workflows:

Git Workflow — Conventional commits, branch naming, PR templates TDD Master — Red-green-refactor cycle, test-first discipline Code Reviewer — Security, quality, and test coverage checks Performance Profiler — N+1 detection, bottleneck analysis Incident Responder — Triage, escalation, and post-mortem reports Database Migrator — Safe migration planning with rollback strategies You can find a curated collection of these at skillbrew.dev — a community hub for Claude Agent configurations.

Layer 4: Prompts — Reusable Templates Prompts are the instructions you give Claude for specific recurring tasks. The difference from skills is that prompts are task-specific, while skills are workflow-specific.

Building a Prompt Library Create a directory for your reusable prompts:

.claude/ └── prompts/ ├── write-tests.md ├── document-function.md ├── refactor-to-service.md └── generate-migration.md Example prompt template for writing tests:

Write Tests Prompt

Write comprehensive tests for the following code.

Requirements:

Use table-driven tests (Go) / parameterized tests (Python/JS)
Cover: happy path, edge cases, error cases
Mock external dependencies — never hit real APIs or databases
Test behavior, not implementation
Each test should have a clear name describing what it verifies

Output: Complete test file ready to run. No placeholders. Prompt vs. Rule vs. Skill — When to Use Which Use... When... Example Rule Always apply this constraint "Never use any type in TypeScript" Skill This is a repeatable multi-step workflow Code review, incident response Prompt This is a specific task I run periodically "Write tests for this function" Putting It All Together: A Complete Setup Here's a complete Claude Agent configuration for a backend developer:

.mcp.json

{ "mcpServers": { "github": { "command": "npx", "args": ["@modelcontextprotocol/server-github"], "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" } }, "postgres": { "command": "npx", "args": ["@modelcontextprotocol/server-postgres", "${DATABASE_URL}"] }, "filesystem": { "command": "npx", "args": ["@modelcontextprotocol/server-filesystem", "./src"] }, "fetch": { "command": "npx", "args": ["@modelcontextprotocol/server-fetch"] } } } CLAUDE.md (project root)

My Backend API

Stack

Go 1.23, Echo v4, PostgreSQL, sqlc, Docker

Rules

Handlers delegate to services — no business logic in handlers
Use sqlc for all queries — no raw database/sql
Conventional commits always
Table-driven tests, no external calls in unit tests

Skills

Code review → use code-reviewer skill
Git → use git-workflow skill
Tests → use tdd-master skill

MCP Tools Available

github: read/write PRs and issues
postgres: query the database (read-only in production)
filesystem: work with files in ./src
fetch: call external APIs With this setup, Claude knows your stack, has access to your tools, follows your conventions, and has ready-made workflows for common tasks — without you re-explaining any of it.

Troubleshooting Common Issues MCP server not connecting

Test the server directly

npx @modelcontextprotocol/server-github

Should start without errors

Claude ignoring CLAUDE.md rules

Check the file is at the project root, not a subdirectory Confirm Claude Code has read the file (it shows at session start) Make rules more explicit — vague rules get ignored Skills not activating

Ensure the skill file is in .claude/skills/ Reference the skill explicitly in CLAUDE.md Use clear trigger language in the skill definition Next Steps Start with one MCP server — GitHub or Filesystem depending on your work Write a CLAUDE.md for your most-used project today Create one skill for your most repeated workflow (code review is a good start) Explore skillbrew.dev for community-built configurations The marginal effort to configure Claude properly is low. The compounding benefit over hundreds of sessions is significant.

Want ready-made Skills, MCP Servers, Rules, and Prompts? Browse the community collection at skillbrew.dev.