Rules, Skills, and Plan Mode — Advanced Claude Code Configuration for the CCA

Your CLAUDE.md file is 847 lines long. It covers API conventions, test standards, deployment procedures, database migration rules, and the style guide for three different frontend frameworks. Every time Claude Code starts a session, it loads the entire thing — even when you are fixing a typo in a README.

This is the configuration problem the CCA exam tests. Not whether you can write a CLAUDE.md file. Whether you know when to split it, scope it, and isolate execution contexts so the right instructions load at the right time.

The Configuration Hierarchy

Claude Code loads configuration in layers, and each layer serves a different purpose. Understanding which layer to use is the core skill the CCA tests.

User-level (~/.claude/CLAUDE.md) applies to every project, every session. This is for personal preferences — your preferred editor settings, aliases, global conventions. It is not shared with teammates via version control.

Project-level (CLAUDE.md at repo root or .claude/CLAUDE.md) applies to everyone working on this repository. Stack documentation, test commands, deploy steps, coding conventions — anything the entire team needs.

Rules (.claude/rules/*.md) are the precision instrument. Each rule file has YAML frontmatter with glob patterns that determine when it loads:

---
paths: ["src/api/**/*"]
---
All API routes must validate request body with Zod schemas.
Never return raw database objects — always use response DTOs.
Rate limiting middleware must be applied to all public endpoints.

The rule above only loads when Claude is editing files that match src/api/**/*. When you are editing a React component, this rule does not consume tokens or attention. When you are editing src/api/users/create.ts, it loads automatically.

Rules solve a specific problem that directory-level CLAUDE.md files cannot: conventions that span multiple directories. Test files spread across src/, lib/, and api/ can all be covered by a single rule with paths: ["**/*.test.tsx"]. Without rules, you would need a CLAUDE.md in every directory containing test files.

The @import Pattern

For large projects, CLAUDE.md files become monolithic. The @import syntax solves this:

# CLAUDE.md

@import docs/api-standards.md
@import docs/testing-conventions.md
@import docs/deployment-guide.md

Each import pulls in a separate file, keeping configuration modular and maintainable. The CCA tests whether you know this pattern exists and when to apply it — specifically when a monolithic CLAUDE.md becomes unmaintainable and different packages need different subsets of standards.

Skills vs Commands

This is the distinction the CCA tests most aggressively in Domain 3. Both are invoked with a slash (/name). Both live in the .claude/ directory. The similarity ends there.

Commands live in .claude/commands/ and are simple prompt templates. They inject text into the current conversation. The $ARGUMENTS placeholder lets you pass parameters. Commands share the main session's context — their output stays in the conversation, consuming tokens.

# .claude/commands/review.md
Review the following file for security vulnerabilities: $ARGUMENTS
Focus on: SQL injection, XSS, auth bypass, secrets in code.

Skills live in .claude/skills/*/SKILL.md and support frontmatter that fundamentally changes how they execute:

---
context: fork
allowed-tools: ["Read", "Grep", "Glob"]
argument-hint: "path to the directory to analyze"
---
Analyze the codebase structure of the provided directory.
Map all exports, identify dead code, and return a summary.

The forked context returns a summary to the main session. This is why skills are the correct choice for analysis tasks that produce verbose output — codebase exploration, brainstorming alternatives, or generating comprehensive reports. Without forking, that output fills your context window.

allowed-tools restricts which tools the skill can access during execution. A documentation-generation skill that should only read files can be restricted to ["Read", "Grep", "Glob"] — preventing it from accidentally writing or deleting files.

The parallel applies precisely to plan mode vs direct execution. The exam tests your judgment about when each is appropriate.

Plan Mode vs Direct Execution

Plan mode exists because some tasks should not be executed immediately. When Claude Code enters plan mode, it explores the codebase, considers approaches, and designs a plan before writing any code. This prevents costly rework on complex changes.

Use plan mode when:

• The change spans multiple files. A library migration affecting 45 files should be planned, not executed file-by-file with fingers crossed.
• Multiple valid approaches exist. Choosing between a webhook integration and a polling integration requires weighing tradeoffs before committing.
• Architectural decisions are involved. Restructuring a monolith into microservices is not a direct-execution task.
• You are in an unfamiliar area of the codebase. Explore first, then execute.

Use direct execution when:

• Single-file bug fix with a clear stack trace. You know exactly what is wrong and where.
• Adding a validation check to one function. The scope is contained.
• Obvious typo or configuration fix. No ambiguity, no exploration needed.

The CCA does not test whether you know plan mode exists. It tests whether you choose correctly in a scenario. Scenario 2 (Code Generation) presents situations where one approach is clearly better than the other. A microservice restructuring in direct mode is a wrong answer. A single-line bug fix in plan mode is also wrong — it wastes time.

Session Management

The CCA tests three session management patterns:

--resume continues a previous session. Use it when the prior context is mostly still valid — you stepped away for lunch, not for two weeks of code changes. If the codebase has changed significantly since the session, starting fresh with an injected summary is more reliable than resuming with stale tool results.

/compact reduces context usage during extended exploration sessions. When your context window fills with verbose discovery output, /compact summarizes the conversation and frees tokens. The exam tests when to use this — during long exploration sessions, not at the start of a fresh session.

/memory shows which memory files are currently loaded. This is the diagnostic tool for configuration hierarchy issues. If Claude is not following conventions you expected, /memory reveals whether the relevant configuration file loaded.

Lesson 126 Drill

Configure Claude Code for this scenario: a monorepo with three packages (api/, web/, shared/) where each has different conventions.

1. Create a root CLAUDE.md with shared conventions and @import for each package's standards
2. Create three .claude/rules/ files with path-scoped globs for each package
3. Create a skill with context: fork for codebase analysis that produces verbose output
4. Create a command for a quick boilerplate generator that stays in the main session
5. Identify which of the three packages would benefit most from plan mode during refactoring

The output of this drill is not the files themselves. It is the reasoning about which configuration layer to use for each requirement. The CCA tests the reasoning, not the syntax.

Bottom Line

The configuration hierarchy exists because a monolithic CLAUDE.md does not scale. Rules scope instructions to matching files. Skills isolate execution contexts. Commands inject simple templates. Plan mode prevents costly rework on complex changes. Direct execution ships obvious fixes fast.

The CCA does not test whether you have memorized these features. It tests whether you can look at a team's problem — "our test conventions are not being followed," "our analysis skills pollute the main context," "our migration went sideways because we did not explore first" — and select the correct configuration pattern to solve it. That judgment is 20% of the exam.