Claude Code Configuration & Workflows

1. 3.1CLAUDE.md hierarchy and organizationPlace always-loaded instructions at the user, project or directory level, and keep them modular with @import and .claude/rules/ so each session loads only what applies.
2. 3.2Slash commands and skillsPackage repeatable workflows as project or personal commands and skills, using SKILL.md frontmatter to isolate output, restrict tools and prompt for arguments.
3. 3.3Path-specific rulesAttach conventions to glob patterns in .claude/rules/ so they load only when matching files are edited, wherever those files live.
4. 3.4Plan mode vs direct executionPlan first when a task is large, multi-file or has several valid approaches; execute directly for small, clear changes; use the Explore subagent to keep discovery out of the main context.
5. 3.5Iterative refinementSteer Claude with concrete input/output examples, tests written first, and the interview pattern, reporting interacting issues together and independent ones one at a time.
6. 3.6CI/CD integrationRun Claude Code non-interactively with -p, request structured JSON output for the pipeline, supply context through CLAUDE.md, and review with an independent instance.

• Put team conventions in the project CLAUDE.md (shared through the repo), personal preferences in the user file, and folder-specific notes in that folder.
• Keep CLAUDE.md small with @import and topic files in .claude/rules/.
• Use path-scoped rules with glob patterns for conventions that apply to files spread across many folders, such as all tests.
• Share team commands and skills in the project's .claude folder; keep personal ones in your home folder.
• Use context: fork in a skill to keep noisy work out of the main conversation, and allowed-tools to limit what it can do.
• Plan first for large, multi-file or open-ended changes; just do it for small, clear ones.
• In CI, run Claude Code with -p and ask for JSON output so the pipeline can read the result.
• Have a separate Claude instance review code, not the session that wrote it.

• Team rules saved in a user-level file that no one else receives.
• Copying the same convention into many folder-level CLAUDE.md files instead of one path-scoped rule.
• Starting a multi-file migration without a plan.
• Rewriting a prompt description a fourth time instead of giving input and output examples or tests.
• Workarounds in CI instead of the -p flag.

You get 4 of the 6 scenarios at random, so practice this domain in each of them. All six scenarios.

1. Set up a repo with a project CLAUDE.md, one @import, and a path-scoped rule for test files.
2. Write a skill with context: fork, allowed-tools and an argument hint, then run it.
3. Do one change in plan mode and one directly, and note which needed the plan.
4. Run Claude Code with -p and JSON output from a script and parse the result.