What you will be able to do
- Decide what belongs in a project CLAUDE.md and what to leave out
- Package a repeatable workflow as a skill, choose where it loads, and predict which copy wins when names collide
- Pick a permission mode and use allowlists or sandboxing to cut interruptions safely
- Choose among routines, desktop scheduled tasks, GitHub Actions and /loop for automated runs
1.CLAUDE.md: the context every session starts with
Well-written prompts help one developer in one session. To improve a team's workflow, the useful context has to be there automatically. CLAUDE.md is where that context goes. The how-it-works page describes it as a markdown file of project-specific instructions and conventions that Claude should know in every session. The /init command generates a starter file for you. If the repository already has an AGENTS.md for other coding agents, Claude can read that instead of or alongside CLAUDE.md.
# Code style
- Use ES modules (import/export) syntax, not CommonJS (require)
- Destructure imports when possible (eg. import { foo } from 'bar')What decides whether the file is useful is what you leave out. Include what Claude can't work out for itself. Leave out anything it can find by reading the code, and anything that goes stale quickly.
| Include | Exclude |
|---|---|
| Bash commands Claude can't guess | Anything Claude can figure out by reading code |
| Code style rules that differ from defaults | Standard language conventions Claude already knows |
| Testing instructions and preferred test runners | Detailed API documentation (link to docs instead) |
| Repository etiquette (branch naming, PR conventions) | Information that changes frequently |
| Developer environment quirks (required env vars) | File-by-file descriptions of the codebase |
| Common gotchas or non-obvious behaviors | Self-evident practices like "write clean code" |
2.Skills and subagents: a shared prompt library
CLAUDE.md is loaded every time. A skill is a workflow that runs when it's needed. The guide's fix-issue skill turns a multi-step procedure into one command: fetch the issue with gh, search the codebase, implement the change, write and run tests, lint and type-check, then commit, push and open a PR. The $ARGUMENTS placeholder takes whatever follows the command. Skills are the newer format for what used to be command files in .claude/commands/. Those still work, but the docs recommend skills for new work because skills can include supporting files.
---
name: fix-issue
description: Fix a GitHub issue
disable-model-invocation: true
---
Analyze and fix the GitHub issue: $ARGUMENTS.Where you save a skill decides who gets it. A skill in the project's .claude/skills/ applies to that repository, and committing it gives the whole team the same library. An enterprise skill in the managed settings directory loads for every user on machines where the organization deploys it. A personal skill in ~/.claude/skills/ follows you across your own projects. When two locations define the same name, enterprise wins over personal and personal wins over project. A skill that shares a name with a bundled command replaces that command but not its aliases.
Subagents solve a related problem. The common-workflows page recommends handing research to a subagent so your main context stays clean, as in "use a subagent to investigate how our auth system handles token refresh". The guide's security-reviewer example shows that a subagent can be restricted to specific tools (Read, Grep, Glob, Bash) and given its own model and instructions.
A team wants Claude Code to query their internal PostgreSQL database directly during a session, without the team writing custom tool-execution code themselves. Which approach fits the Model Context Protocol integration model?
Correct answer: A — Configure an MCP server for the database and let Claude discover its tools through the protocol
- A. Correct. MCP servers expose external systems like databases as a set of discoverable tools that Claude can call directly, which is the documented mechanism for connecting Claude to systems such as a PostgreSQL database without hand-writing tool execution code.
- B. Incorrect. Hooks run deterministic shell commands at lifecycle events for validation or logging; they are not designed to serve as the mechanism through which Claude discovers and calls a database's query capabilities.
- C. Incorrect. Granting unrestricted Bash access lets Claude shell out to a CLI client, but this bypasses the structured, discoverable tool interface MCP provides and removes the scoped, auditable tool boundary the team wants.
- D. Incorrect. Putting schema details in a subagent's system prompt gives Claude static knowledge about the database, not a way to actually execute queries against it; it still lacks the live tool connection MCP provides.
3.Permission modes, allowlists and sandboxing
Every approval prompt interrupts the developer. Removing all of them removes a safeguard. Claude Code's permission modes let you choose where to sit between those two, and the how-it-works page lists four.
| Mode | Behaviour |
|---|---|
| Manual | Claude asks before file edits and shell commands |
| Accept edits | Edits files and runs common filesystem commands like mkdir and mv without asking; still asks for other commands |
| Plan | Explores and proposes a plan without editing your source files |
| Auto | A classifier reviews most actions in the background and blocks risky ones instead of asking you |
Two further tools reduce prompts without switching to a looser mode. A permission allowlist pre-approves specific commands you know are safe, such as the linter or git commit. Sandboxing works at the operating-system level, restricting filesystem and network access so Claude can act more freely inside those limits. Skills don't get around any of this: Claude Code honors skill frontmatter in every kind of session, and an allowed-tools grant still goes through the normal permission flow.
Add npm run lint to the permission allowlist. Accept edits mode wouldn't help, because it only skips prompts for file edits and common filesystem commands such as mkdir and mv. Auto mode would stop the prompts for many more commands than the one the developer asked about.
4.Taking workflows beyond the interactive session
Some workflows shouldn't need someone at the keyboard. Claude Code can be piped into scripts for CI and batch jobs. You can resume a conversation later with claude --continue, and run parallel sessions in separate worktrees (for example claude --worktree feature-auth) so concurrent edits don't collide.
git log --oneline -20 | claude -p "summarize these recent commits"| Option | Where it runs | Best for |
|---|---|---|
| Routines | Cloud, Anthropic-managed by default | Tasks that must run with your computer off; can also trigger on API calls or GitHub events |
| Desktop scheduled tasks | Your machine, via the desktop app | Tasks that need local files, tools or uncommitted changes |
| GitHub Actions | Your CI pipeline | Repo events such as opened PRs, or cron alongside your workflow config |
| /loop | The current CLI session | Quick polling while a session is open |
Sources4
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.When a project skill and a personal skill share a name, the project skill runs because it is closer to the code.Why is that wrong?
Precedence is enterprise, then personal, then project. If deploy exists in both ~/.claude/skills/ and the project's .claude/skills/, /deploy runs the personal one.
2.A thorough CLAUDE.md should include the full API reference and a file-by-file description of the codebase.Why is that wrong?
The guide excludes both. Link to API docs instead, and leave out anything Claude can work out by reading the code. Keep CLAUDE.md for what Claude can't guess.
3./loop is the way to run a nightly Claude Code job.Why is that wrong?
/loop only runs inside an open CLI session. For work that has to run with your computer off, use Routines, which run in the cloud.
Practise it for real
Create a personal skill that summarises your uncommitted changes and flags risks, then call it both by name and by describing what you want.
1.Run mkdir -p ~/.claude/skills/summarize-changes
Why: A personal skill lives in ~/.claude/skills/<skill-name>/ and loads in all your projects on this machine.
You should see: The directory exists and is empty.
2.Write ~/.claude/skills/summarize-changes/SKILL.md with a description frontmatter line, a '## Current changes' section containing !
git diff HEAD, and an '## Instructions' section asking for two or three summary bullets and a list of risks.Why: The description tells Claude when to use the skill, and the git diff line gives the skill the current diff to work from.
You should see: A SKILL.md file with frontmatter delimited by --- lines.
3.In a repository with uncommitted edits, start claude and ask: What did I change?
Why: This checks that Claude picks up the skill from its description, without being told the name.
You should see: A short bullet summary of your diff followed by any risks, such as missing error handling or hardcoded values.
4.Now type /summarize-changes
Why: This checks that the skill also works as a slash command.
You should see: The same kind of summary; with a clean working tree, a message that there are no uncommitted changes.
Stuck? Get a nudge
If the skill doesn't appear, check that the folder isn't named synced or anthropic-skills. Claude Code skips skills with those reserved names.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“A markdown file where you store project-specific instructions, conventions, and context that Claude should know every session.”
↩︎ CLAUDE.md: the context every session starts with“/init generates a starter CLAUDE.md for your project”
↩︎ CLAUDE.md: the context every session starts with“a classifier reviews most actions in the background and blocks the risky ones instead of asking you”
↩︎ Permission modes, allowlists and sandboxing“Claude edits files and runs common filesystem commands like mkdir and mv without asking, still asks for other commands”
↩︎ Permission modes, allowlists and sandboxing - 2.https://code.claude.com/docs/en/best-practicesOfficial docs
“Common gotchas or non-obvious behaviors”
↩︎ CLAUDE.md: the context every session starts with“Permission allowlists: permit specific tools you know are safe, like npm run lint or git commit”
↩︎ Permission modes, allowlists and sandboxing“enable OS-level isolation that restricts filesystem and network access, allowing Claude to work more freely within defined boundaries”
↩︎ Permission modes, allowlists and sandboxing“Detailed API documentation (link to docs instead)”
↩︎ Exam trap 2 - 3.https://code.claude.com/docs/en/skillsOfficial docs
“Commit it so your team gets it too”
↩︎ Skills and subagents: a shared prompt library“All users on machines where your organization deploys it”
↩︎ Skills and subagents: a shared prompt library“Prefer a skill for new work, since skills also support supporting files.”
↩︎ Skills and subagents: a shared prompt library“the bundled alias /review never runs your skill”
↩︎ Skills and subagents: a shared prompt library“Claude Code honors the frontmatter in every kind of session, so an allowed-tools grant goes through the normal permission flow.”
↩︎ Permission modes, allowlists and sandboxing“Enterprise over personal, and personal over project.”
↩︎ Exam trap 1 - 4.https://code.claude.com/docs/en/common-workflowsOfficial docs
“Delegate research to subagents to keep your main context clean”
↩︎ Skills and subagents: a shared prompt library“Pipe Claude into scripts for CI and batch processing”
↩︎ Taking workflows beyond the interactive session“Run parallel sessions with worktrees so concurrent edits”
↩︎ Taking workflows beyond the interactive session“Quick polling while a session is open.”
↩︎ Taking workflows beyond the interactive session“Tasks that should run even when your computer is off.”
↩︎ Exam trap 3