Claude Code operation

What you’ll be able to do

• Match each Claude Code component to the job it does
• Apply the CLAUDE.md hierarchy so standards reach the whole team
• Choose the right run mode for interactive work versus CI
• Recognise Rule-versus-Command questions

What you need to know

Five components, five distinct jobs

• Rules — persistent behavioural constraints applying every session. "Never suggest code that writes directly to the production database."
• Skills — packaged capabilities the model can invoke.
• Commands — reusable slash-command workflows. A repeated multi-step process, invoked once.
• Agents — delegated subtasks running with their own context.
• Agent Memory — state persisting across sessions.

Rule or Command — the distinction that gets tested

The CLAUDE.md hierarchy

Files layer broad to specific, and a more specific file overrides a broader one — a monorepo's frontend package can carry conventions the backend package shouldn't.

The reliably tested mistake: a tech lead puts team conventions in their personal settings. It works for them and silently doesn't exist for anyone else. Anything the team must follow goes in a project-level CLAUDE.md, committed to the repo, arriving with every clone. /init generates a project-tailored starting point.

Run modes

• Interactive — a human at the keyboard approving as it goes.
• Streaming — output as it's produced.
• Auto mode — approvals relaxed for speed, with the supervision tradeoff that implies.
• Headless — non-interactive, for scripts and CI pipelines where nobody is present to answer a prompt.

A nightly CI job is the canonical headless scenario. Any option implying a human approves steps is wrong there by definition — there's nobody there.

Key concept

Commands are invoked, Rules always hold. Team standards belong in a project-level CLAUDE.md, not personal settings. Headless mode is what runs in CI where no human is present to approve anything.

Practice scenario

Build exercise — Turn a repeated process into a Command

Beginner · 25 min

What you’ll learn

• Telling a Rule from a Command by what triggers it
• Making a team convention reach the whole team

1. Write down a multi-step process you repeat by hand in Claude Code — a review checklist, a release prep, a refactor pattern.

   • Why: Repeated manual steps are precisely what Commands exist to replace.
   • You should see: Three or more steps you’ve typed more than twice.

2. Separately, write down a constraint that should hold whether or not anyone invokes anything — something Claude should never suggest.

   • Why: This is the Rule-versus-Command distinction the exam tests directly: does someone run it, or does it always hold?
   • You should see: Two clearly different things. If you can’t separate them, the constraint is probably a step in disguise.

3. Put the first in a Command and the second in a Rule, both at project level, and commit them.

   • Why: Project-level and committed is what makes them exist for everyone rather than just you.
   • You should see: A teammate clones the repo and gets both without being told.

Exam traps

Putting team conventions in personal settings

It works for one developer and does not exist for anyone else on the team.

Confusing a Rule with a Command

Ask whether someone runs it or it always holds. Commands are invoked; Rules are ambient constraints.

Choosing interactive mode for a CI pipeline

There is no human present to approve steps. That is what headless mode exists for.

Pasting a checklist into every conversation

A repeated multi-step process is a Command. Manual repetition is the problem being described.

Sources

• Claude Code Docs