← Blog · 2026-10-16

"CLAUDE.md vs Skills vs Hooks: Which Goes Where"

Build any of the three in your browser: CLAUDE.md generator · SKILL.md builder · hooks & settings.json generator

You're a solo consultant. You've opened Claude Code in a client folder and there are three places people keep telling you to put instructions: a CLAUDE.md file, a skill (SKILL.md), and hooks in settings.json. Put the same rule in the wrong place and either Claude ignores it, you burn context every session, or a "never send email" rule is still just a suggestion.

This guide is a decision tree. Facts checked against the Claude Code docs for memory / CLAUDE.md, skills, and hooks.

The one-sentence version

The docs put it bluntly for memory: Claude treats CLAUDE.md as context, not enforced configuration. To block an action no matter what Claude decides, use a PreToolUse hook (or a deny permission rule).

Decision tree (start here)

Ask these in order. Stop at the first "yes."

1. Must this happen even if Claude ignores the instruction?

Yes → hook or permission rule.

Examples for consultants:

• Never read .env or private keys
• Never run rm -rf on a client folder
• Always ask before any MCP tool that sends or posts (email, Slack, CRM)
• Always ask before git push

These live in settings.json as permissions.deny / permissions.ask and/or hooks.PreToolUse. User-level ~/.claude/settings.json covers every client folder on your machine.

2. Is this a multi-step procedure you only need sometimes?

Yes → skill.

Examples:

• Monthly retainer report from this week's notes
• Meeting transcript → owned, dated tasks
• Invoice chase email (draft only)
• Proposal outline from a discovery call

Skills live at ~/.claude/skills/<name>/SKILL.md (all your projects) or .claude/skills/<name>/SKILL.md (this project). The body loads only when the skill is used, so long checklists don't tax every session. The docs say: when a section of CLAUDE.md has grown into a procedure rather than a fact, move it to a skill.

3. Is this always true about how you work?

Yes → CLAUDE.md.

Examples:

• Your services, niches, and "draft only; never send"
• Where client folders live and how they're named
• Rate / billing rules Claude must not invent
• Tone: short, plain English, no jargon

Project: ./CLAUDE.md or ./.claude/CLAUDE.md. Personal across all projects: ~/.claude/CLAUDE.md. Keep it short — the docs recommend targeting under ~200 lines; longer files cost context and reduce adherence. Run /init for a starter, then cut anything Claude can already see in the repo.

If none of the three fit, you might not need a file yet. Just tell Claude in chat once; if you repeat the same correction twice, then write it down (that's the docs' signal to add to CLAUDE.md or auto memory).

Side-by-side with consultant examples

CLAUDE.md — "always true"

# CLAUDE.md

## About this practice
- Solo consultant. Draft-only for client email; never send.
- Never invent prices, hours, or case-study metrics.
- Client folders: `clients/<slug>/`. Read that folder's CLAUDE.md first.

## Billing
- See `rates.md`. If a number isn't there, ask me — don't guess.

Put long reference (full rate card, style guide) in separate files and mention the path. Imports with @path work, but imported files still load at launch — they don't save context the way a skill does.

Skill — "do this job when asked"

---
name: retainer-report
description: Draft a monthly retainer report from this week's notes. Use when the user asks for a retainer report, monthly client update, or renewal summary.
disable-model-invocation: false
---

1. Read the client's CLAUDE.md for goals and tone.
2. Collect notes and finished tasks from the date range given.
3. Group work under the client's goals. No invented metrics.
4. List blockers and what I need from the client.
5. Write next month's top 3 priorities.
6. Output a draft markdown file only — do not email it.

Invoke with /retainer-report or by asking in plain language that matches the description. For anything with side effects (deploy, send), set disable-model-invocation: true so only you can trigger it.

Hook — "block or ask, every time"

Permission rules for simple patterns; hooks when you need a script to inspect the command:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)"],
    "ask": ["Bash(git push *)"]
  }
}

A PreToolUse hook can deny rm -rf or MCP tools whose names contain send / post / reply. Check what loaded with /hooks in a session.

Common mix-ups

Quick checklist for a new client folder

1. Root or practice CLAUDE.md (facts + draft-only).
2. Optional clients/<slug>/CLAUDE.md (that client's goals, contacts, quirks).
3. Skills you reuse across clients (reports, follow-ups, meeting → tasks).
4. User-level hooks/permissions once, so they follow you into every folder.
5. Confirm: /context (memory files), /skills, /hooks.

Free builders (same three levers)

• CLAUDE.md generator — practice facts in a copy-paste file
• SKILL.md builder — name, description, steps, guardrails
• Hooks & settings.json generator — deny secrets, block mass deletes, ask before send/push

Related guides: CLAUDE.md for consultants, skill description that triggers, skill not triggering checklist, hooks for non-developers.

Want a starter pack instead of blank files?

• Free 3-skill sample: client follow-ups, meeting-to-tasks, invoice chase
• Solo Consultant Kit ($29): 8 draft-only skills, 12 CLAUDE.md practice templates, safety hooks

Disclosure: I make Solo Stack Kits. The sample is free; paid kits are optional.

Not affiliated with Anthropic. "Claude" is a trademark of Anthropic. Facts above are from Anthropic's Claude Code documentation; check the live docs if something changes.