Members and teams

Writing a member

Ask your orchestrator (“add an SRE to an ops team”), or write the file yourself. A good member file is short and concrete:

# Member: Site Reliability Engineer (ops team)

You are the SRE. You keep the services up and explain what broke.

- Read the logs and metrics before you form a theory.
- Change production only when the orchestrator's task says so.
- In your reply: what you found, what you changed, how you verified it.

• One role, plainly stated. What the member owns and what it doesn’t do.
• How to work, in a few bullets. Concrete habits beat adjectives.
• What the reply contains. Your orchestrator relays it, so make it easy to relay.
• Leave out how to receive work and reply: the shared protocol covers that.

Team and member names may use letters, digits, - and _. Add the team to playbook.md so your orchestrator knows when to use it, and commit the change (your orchestrator does both when it adds a member).

Models and effort

Each member can run on its own model and effort. Put this at the very top of its file, members/<team>/<role>.md:

---
model: sonnet
effort: high
---

MODEL= and EFFORT= in cadrei.conf set them for your whole crew, and a member’s file wins over that. To try something once, ask your orchestrator (“start the writer on opus”), which runs cadrei up with --model. Effort is low, medium, high, xhigh or max. With nothing set, members use Claude Code’s own defaults. Your orchestrator keeps its own model; switch it with /model, or set ORCHESTRATOR_MODEL in cadrei.conf.

Working folders

• A member started for a project (cadrei up dev my-app) works in that project’s folder.
• A team without a project works in teams/<team>/, unless members/<team>/.workdir names another folder.
• members/<team>/<role>.workdir pins one member to its own folder, for example a tutor per study track.

A .workdir file holds one path; ~ is expanded.

teams/ is tracked in the crew’s git, so the work members keep there is backed up with the crew. The crew’s .gitignore leaves out dependency folders, logs and .env files (their .env.example-style templates stay), and the .claude/build/ and .claude/local/ folders.

The playbook

playbook.md is read by your orchestrator at the start of every chat and wins over cadrei’s instructions where they differ. Put there:

• Teams: who exists and what each team is for.
• Pipelines: multi-step flows, for example engineer builds, reviewer reviews, engineer fixes.
• Routing rules: which requests go where, and anything your orchestrator must never do itself.
• Project notes that don’t fit elsewhere, such as how deploys work.
• Preferences, under a ## Preferences heading, such as hiding the team line (The team status line).

Rules that belong to one project go in that project’s own CLAUDE.md instead, so every member working there follows them.

House rules

protocol.md in your crew (optional) is added to the shared member protocol for every member. Use it for rules that apply to all members, for example a writing style. It can add rules, but it can’t turn off the shared ones, like never writing a real-looking secret.