An agent with no configuration is a stranger who shows up every morning having forgotten the job. Configuration is the file that hands it the job description before it starts. You already wrote your project's rules; this chapter defines a specific agent with a role of its own.
9.5.1Give each agent a role
A role is a small file, not a paragraph you retype into chat each time. In Claude Code it lives in .claude/agents/, and every serious tool has the same idea: a YAML frontmatter block, the settings at the top, plus instructions.
That is a coworker defined in a file your project keeps, not a mood you set and lose each session.
Hint: Each agent runs on a model, and the best model for one job is rarely the best for every job. Route your agents through OpenRouter, one account across most models. That way you can match a model to a role and swap as the leaders change, without locking your whole system to a single vendor.
9.5.2Skills and rules per agent
A role carries two kinds of attachment, and you keep them as separate files so they compose. A skill is a procedure loaded only when the task needs it. A rule is a hard line, always on.
That layout is Claude Code's; every serious tool has an equivalent folder. You never pour all of it into one giant prompt. You attach the right skill to the right role and let the rest stay out of the way until it is needed.
9.5.3Point skills at your docs, don't copy them
Some knowledge is heavy or shared: your API's rules, the architecture you wrote down, the conventions the whole project follows. Do not paste it into a skill. Keep one doc as the single source of truth and have the skill point to it: follow the API contract in docs/api.md.
Copy the knowledge instead and the two versions drift the day one of them changes. A pointer stays true, because there is only one copy left to update.
9.5.4Let the agent write its own skills
You will not sit down and author these. The useful ones get written the moment something is learned, and the agent is the one who learns it.
Give it one standing instruction: when I correct the same thing twice, write it into the skill that covers it, or start a new skill if none does. The second correction is the trigger, because the first might be a one-off and the third is one too many.
That is what makes the system compound. The deploy quirk you explained in March is in the deploy skill by April, and nobody explains it again.
Watch out: bound this or you get a hundred skills nobody loads. A skill earns its place when it is a repeatable procedure or a hard-won fact, not when it is a preference you happened to voice once.
9.5.5Configuration keeps output consistent
Unconfigured agents drift: the same request gives a different shape of answer on Monday and Friday. A rule file pins the shape:
Now the quality bar lives in a file, not in your memory of how you happened to ask last time.
9.5.6Write it once, reuse everywhere
Configuration is an asset, not a chore. The role you define today serves every task that agent ever runs, and the rule you write once fires on every future turn.
An hour spent standing an agent up correctly pays back on every job it does after. You are not configuring a task, you are configuring an employee, and the file is committed alongside the code it governs.
This prompt has your agent write its own role file, in your tool's format:
Do this now: paste the prompt so your agent writes the reviewer role file, then read it and tighten one line yourself.
