Department brief

Use when a team hands a stream of work (product, development, operations, docs, support) to Claude Code sessions and each session needs to know where its job starts and stops. A brief is what you would tell a new hire on day one, and nothing more. Pair it with backlog-item (the work itself) and approvals (the human yes).

Ground rules

• Ten lines or fewer. A long brief is not read; detail belongs in the code, the docs and the tasks.
• Kept in the repo next to the work: a CLAUDE.md in that folder, or docs/roles/<department>.md that sessions are pointed to. Not only in a chat or a page that one person can open.
• One lead per department owns the brief, named by role ("the docs lead"). A session proposes changes to it; the lead approves them.
• No secrets, tokens, customer data or private contact details in a brief.

The five parts

1. Responsibility: what the department delivers and for whom, in one or two lines.
2. Must not touch: other departments' areas, production settings, money, anything public. Name them concretely ("the payment code in src/billing/"), not "be careful".
3. Where it works: repos, folders, branch prefix, and the commands that check its work.
4. Who approves: which role reviews its output, and which of its actions always need a human yes (see approvals).
5. How it reports: where the result goes (the pull request, the task, the status file) and what a report holds: what works, what is not done, what could not be checked.

Example

# Docs department
Responsible for: the public docs site (guides and API reference) for developers who integrate the orders service.
Must not touch: application code outside `docs/`, the site's deploy settings, the pricing page.
Works in: `docs/` on `docs/<short-name>` branches; check with `npm run docs:build` and the link checker.
Approves: the docs lead reviews every pull request; publishing the site is a human yes.
Reports: in the pull request: pages changed, what was checked in the preview, open questions.
Asks first: anything that changes what the product promises (limits, prices, guarantees).

Using a brief in a session

• Read the brief before the first change. If the task needs something the brief rules out, stop and ask; do not widen the brief yourself to fit the task.
• One session, one task, one department. When the work moves to another department, say so and switch brief rather than drifting across everything in one long session.
• No brief yet: draft one from what you can see (folders, owners files, existing tasks), mark it as a draft, and ask the lead to approve it before relying on it.

Reviewing a brief

Check that each part is present and concrete. Defects worth reporting:

A brief that is complete and current is a valid result: say so, do not pad.

How to report

When writing: the brief as a file in the diff, and the questions you could not answer from the repo, each with your recommended answer. When reviewing: one finding per defect with the line, what is wrong and the replacement line.