Domain 3 Project — configure Claude Code for a team, then put it in CI
Claude Certified Architect - Foundations (CCAR-F) › Domain 3: Claude Code Configuration & Workflows
Domain 3 Project — configure Claude Code for a team, then put it in CI
One repository, six stages. It starts with a single CLAUDE.md and finishes running unattended in a pipeline, posting review findings on pull requests.
This is the closest any of the five projects gets to being the exam guide's own: Preparation Exercise 2 supplies five of the six stages almost directly.
Domain 3 is 20% of the exam and it is the one that names exact paths and flags — and tests them literally. Every stage here has you create the file rather than read about it, because a path you have typed is a path you can recall under time pressure.
The project at a glance
- 3 · Claude Code Configuration & Workflows (20%)
- 6, one per task statement
- Intermediate
- 195 minutes
- Claude Code, a git repository you can edit freely, and a CI runner
- Exam guide Preparation Exercise 2
What you will be able to do
- Place configuration at the level that reaches the people it is meant to, and diagnose a scope bug with /memory
- Scope a rule to a glob so it loads only when it applies, and say when that beats a directory-level file
- Configure a skill with context: fork, allowed-tools and argument-hint, and say what each one prevents
- Choose plan mode or direct execution from a task's ambiguity rather than its difficulty
- Run Claude Code unattended with structured output, and keep a re-run from repeating itself
Before you start
You need Claude Code and a repository you can make a mess of. A scratch clone of something real is better than an empty directory — several stages need files that already have structure to scope rules against.
git clone <something-you-can-break> ccarf-domain-3 && cd ccarf-domain-3
mkdir -p .claude/rules .claude/commands .claude/skillsThen confirm the CLI is alive and, more importantly, that you can read back what it loaded:
claude --versionInside a session, /memory is the instrument for this whole project. It lists which memory files are actually in effect, and four of the six stages are verified by reading it rather than by inferring from behaviour. Learn it now.
Stage 3.6 needs somewhere to run a job. GitHub Actions is fine; so is running the same command locally with the CI environment variable set, if wiring a real pipeline is more than you want today.
Build it in this order
Rules come straight after CLAUDE.md because they are the same question — what loads, and when — asked once unconditionally and once conditionally. Guide order would put commands and skills between two halves of one idea.
Six stages
3.1 · The hierarchy, and a bug only a teammate sees · 30 min
BUILD — A project-level CLAUDE.md with real standards, a user-level one with a personal preference, and an @import pulling a shared standards file into a package. Then run /memory and read back exactly which files loaded. WHY — Almost every Domain 3 diagnosis is a scope question, and the classic stem is a new team member who is not getting instructions that work perfectly for everyone else. Seeing /memory list what actually loaded is what makes that stem obvious rather than clever. YOU SHOULD SEE — /memory naming all three sources, and a clear sense of which of them a colleague cloning the repo would and would not receive. TRAP — Putting team standards in the user-level file. It works flawlessly for its author, forever, and fails silently for everyone else — which is precisely why the exam likes it. STUCK? — If /memory shows fewer files than you wrote, check where you are running from before you check the files. A project-level file is invisible from outside the project.
Stage 3.1 in full
Three levels, three audiences
Where configuration lives
User level. Yours alone. Never reaches a teammate, because it is not in the repository.
Project level. Committed, so everyone who clones gets it.
Directory level. For a convention that genuinely belongs to one part of the tree.
Topic files, optionally glob-scoped — the subject of stage 3.3.
Build all three
Project level, committed, and true for everyone:
# Project standards
- Tests live beside the code they test, named *.test.ts.
- Every exported function has a one-line doc comment saying what it is FOR.
- Never commit a .env file.User level, yours, and deliberately a preference rather than a rule:
# My preferences
- Explain changes briefly before making them.
- Prefer British spelling in prose I will read.Now the modular part. Rather than one growing file, pull a standards document in where it is relevant:
# Package: api
@../../standards/api-conventions.md
Endpoints in this package additionally follow the versioning rule in that file.Read back what actually loaded
Run /memory in a session. You should see the project file, the user file, and the imported standards. Now ask the question the exam asks: which of these would a colleague get after cloning the repository? Exactly one of the three would not.
A team lead writes coding standards that Claude follows perfectly in their own sessions. A new engineer clones the repository and reports that none of the standards are applied. What is the most likely cause?
One place the guide and the product disagree
Prove stage 3.1 before moving on
- /memory lists all three sources by path, not just a count.
- Move one project-level rule into the user-level file, restart, and confirm /memory shows it arriving from a different place. Then move it back.
- Clone your own repository into a second directory and run /memory there. What is missing is exactly what a teammate would be missing.
When you get stuck
Every stage above ends with a STUCK? line — the first thing worth checking, which is usually the thing actually wrong.
Past that, in the app: the Help button in this page's toolbar sends the tutor the section you are currently reading, together with the project's title, so you can ask "why does this not work" without pasting anything in. It knows which stage you are on.
- Read /memory before theorising. Four of the six stages are verified by what it lists, and a wrong theory about loading costs more time here than anywhere else in the exam.
- Say the path out loud. This domain's distractors are frequently the right idea at the wrong path or with the wrong flag — if you can state the exact file before reading the options, most items resolve in seconds.
- Test with a second clone. Half of Domain 3's bugs are only visible to someone who is not you, and a second checkout is the cheapest way to become that person.
Where the depth lives
This page is for building. The reading is elsewhere, and repeating it here would put the same claims in three places to drift apart:
- The Domain 3 roadmap — what the domain is about, the order to learn it in, and where it catches people
- 6 flashcard decks, 49 cards — one card per published objective
- 50 Domain 3 questions — judgement under exam conditions, inside the six production scenarios
Sources
- CCAR-F Exam Guide v1.0, section 6 — Domain 3's six task statements, which are this project's six stages.
- CCAR-F Exam Guide v1.0, section 8 — Preparation Exercise 2 (Configure Claude Code for a Team Development Workflow), whose five steps supply five of these stages.
- Claude Code documentation — the memory hierarchy, .claude/rules/ frontmatter, skill frontmatter options, and the non-interactive CLI flags. Every command, path and flag this project asks you to type was retrieved from that documentation and checked against what this page says about it; the one disagreement with the exam guide is called out at stage 3.1.