Yes — here’s the clean mental model for how Claude Code’s **default structure** fits together for code development. The key idea is: **instructions shape behavior, skills add task playbooks, hooks enforce policy, and permissions govern what tools may run**.[^2_1][^2_2][^2_3] ## Overall flow ```text You / repo context / CLAUDE.md / rules ↓ Claude decides what to do ↓ May load a Skill if relevant ↓ May trigger Hooks around events ↓ Permission system checks the tool use ↓ Tool runs or is blocked / approved ↓ Claude continues ``` That flow is the default loop for development work, with hooks and permissions acting as guardrails around the model’s normal tool use.[^2_4][^2_2][^2_3] ## What each layer does | Layer | Purpose | Typical scope | | :-- | :-- | :-- | | `CLAUDE.md` / `.claude/rules/*.md` | Persistent repo guidance and coding conventions | Session or path-based context | | Skills | Task-specific playbooks and reusable workflows | Loaded when relevant or invoked directly | | Hooks | Deterministic automation and policy enforcement | Before/after tool use, session events, config changes | | Permissions | Approvals for tool actions like read, edit, write, bash | Per tool call / permission mode | Claude Code loads instruction files like `CLAUDE.md` and `.claude/rules/*.md` into context, and there is an `InstructionsLoaded` hook event when that happens. Skills are separate modular capabilities with `SKILL.md` frontmatter and body instructions, and they load only when triggered unless you invoke them directly. Hooks run at lifecycle points such as `PreToolUse`, `PostToolUse`, `SessionStart`, and `InstructionsLoaded`. Permissions then decide whether a given tool call can proceed.[^2_2][^2_3][^2_4] ## Default development structure ```text Repo root ├─ CLAUDE.md ├─ .claude/ │ ├─ rules/ │ │ └─ *.md │ ├─ skills/ │ │ └─ /SKILL.md │ ├─ hooks/ │ │ └─ scripts... │ └─ settings.json └─ source files ``` `CLAUDE.md` and `.claude/rules/*.md` are the always-on or path-scoped instruction layer, while `.claude/skills/` contains reusable workflows and `.claude/hooks/` contains automation or guardrails.[^2_4][^2_2] ## How the layers interact A skill can include its own `allowed-tools`, which lets Claude use those tools without prompting while that skill is active, but it does **not** replace your baseline permission settings. Hooks are stronger than permission modes in the sense that a `PreToolUse` hook can deny a tool call even if permission mode would otherwise allow it. That means skills add capability, hooks enforce policy, and permissions stay the final normal gate unless a hook blocks first.[^2_3][^2_2][^2_4] ## Practical example If you ask Claude to refactor a module, it may: - read `CLAUDE.md` for repo conventions. - load a relevant skill like a code-review or refactor skill if the description matches. - run `Read` and `Grep` freely. - prompt before `Edit` or `Write` depending on permission mode. - trigger `PostToolUse` hooks after edits, for example to lint or validate.[^2_2][^2_4] That means you can make the system behave like “inspect freely, ask before changing” by combining permissive read access with guarded write/edit permissions and optional hooks for extra enforcement.[^2_3][^2_4] ## The important nuance Skills are **suggestive and contextual**, not hard enforcement. Claude may choose not to load one unless the description fits well, unless you invoke it manually. Hooks are **deterministic**: if they match, they run. Permission rules are the per-tool approval layer, and hooks can tighten those rules but not loosen them beyond what settings allow.[^2_4][^2_2][^2_3] ## Best diagram for coding work ```text CLAUDE.md / rules ↓ Skill selection ↓ Tool call proposed ↓ PreToolUse hook ↓ Permission check ↓ Read / Edit / Write / Bash ↓ PostToolUse hook ↓ Next reasoning step ``` For code development, that is the useful default diagram: instructions first, skills second, hooks around execution, and permissions as the gate for changes.[^2_2][^2_3][^2_4] ## How to think about it - Use `CLAUDE.md` for stable project rules and style guidance.[^2_4] - Use skills for repeatable workflows like refactors, reviews, deploys, or docs generation.[^2_2] - Use hooks for enforcement, auditing, linting, or blocking risky actions.[^2_4] - Use permissions for deciding what Claude can do without asking.[^2_3] --- ## Claude's tool layer — the internal \*ix Claude Code's built-in tools form a Unix-like OS inside the model: read-only tools are safe to allowlist freely, mutating tools require permission by default, and Bash is the universal escape hatch that can be either. ``` Claude Code Tools ├── Filesystem │ ├── [R] Read — cat / head / tail │ ├── [R] Grep — grep / rg / ag │ ├── [R] Glob — find + wildcard patterns (*.py, **/*.md) │ ├── [M] Edit — sed -i / patch (exact-string replace in existing file) │ ├── [M] Write — > redirect (create or overwrite) │ └── [M] NotebookEdit — in-cell Jupyter edit ├── Shell │ └── [R/M] Bash — sh/bash (read-only OR mutating — allowlist by pattern) ├── Web │ ├── [R] WebFetch — curl / wget │ └── [R] WebSearch — (no *ix analog) ├── Process │ ├── [R/M] Agent — fork / subprocess (spawns specialized sub-agent) │ └── [R] Monitor — tail -f / watch (streams background process output) ├── Tasks │ ├── [M] TaskCreate — (new entry) │ ├── [R] TaskGet — cat task │ ├── [R] TaskList — ls tasks │ ├── [M] TaskUpdate — in-place edit │ ├── [M] TaskStop — kill │ └── [R] TaskOutput — tail log ├── Flow / Session │ ├── [R/M] Skill — . source (load + run a skill playbook) │ ├── [R] AskUserQuestion — read / prompt │ ├── [-] EnterPlanMode / ExitPlanMode │ └── [-] EnterWorktree / ExitWorktree — git worktree add/remove ├── Schedule │ ├── [M] ScheduleWakeup — at (one-shot future wake) │ ├── [M] CronCreate — crontab -e (add) │ ├── [M] CronDelete — crontab -e (remove) │ ├── [R] CronList — crontab -l │ ├── [M] RemoteTrigger — curl POST (fire remote agent) │ └── [M] PushNotification — notify-send └── MCP └── [?] mcp__* — plugins; mutability varies by server ``` Key: `[R]` read-only · `[M]` mutating · `[R/M]` depends on use · `[-]` mode switch, no I/O · `[?]` server-defined ## Permission implications | Category | Tools | Default permission | Safe to allowlist? | | :-- | :-- | :-- | :-- | | Pure read | Read, Grep, Glob, WebFetch, WebSearch, Monitor, TaskGet, TaskList, TaskOutput, CronList | Prompt or pre-approved | Yes — no mutation possible | | Shell read | `Bash(ls *)`, `Bash(find *)`, `Bash(grep *)`, `Bash(cat *)` | Prompts (Bash is general) | Yes — allowlist by pattern in settings.json | | Mutating filesystem | Edit, Write, NotebookEdit | Always prompts | No | | Shell mutating | `Bash(rm *)`, `Bash(git reset *)`, etc. | Always prompts | No | | Process / agent | Agent, Bash (general), Skill | Prompts | Selectively — depends on what the agent/skill does | | Schedule / notify | CronCreate, CronDelete, ScheduleWakeup, RemoteTrigger, PushNotification | Prompts | No | | MCP | mcp__* | Server-defined | Case by case | ## The Glob tool specifically Glob finds files by wildcard pattern — it is the closest Claude analog to `find -name` or shell globbing. - Pattern examples: `*.py`, `**/*.md`, `src/**/*.ts` - Returns matching file paths only — no content, no mutation - Safe to allowlist unconditionally: `"Bash(glob *)"` is not needed; Glob is a dedicated tool distinct from Bash - Use Glob when you know the shape of what you're looking for; use Grep when you know the content