Part 2 of 6

Part 2 — The Playbook: Standards That Apply Every Turn

ai claude cowork rules standards cowork-rules

Created: April 17, 2026 | Modified: April 22, 2026

Standards that apply on every turn

The Instructions (saved in CLAUDE.md, loaded on every prompt) are the always-on context for the workspace. They tell Cowork what the role is, who it serves, and how to think about the work. The Playbook layers on top of that: a small set of standards that constrain how Cowork behaves no matter what the task is.

When Cowork drafts a response, the standards are active. When it produces an outline, the standards are active. When it scores an input against a rubric, the standards are active. They are constraints, not suggestions — and they live in their own files so the Instructions stay short.

Four areas need a standard for any working role: voice, output, process, and approval. The Playbook is what those four files together do.

How the Playbook plugs into the Instructions

Cowork doesn't auto-discover a standards folder. Each standard becomes its own file at a path you choose, and the Instructions get an explicit pointer for each one — a single line that reads roughly:

"For voice, ALWAYS read <voice-file> before producing any draft."

That pointer is the link in the chain. Cowork loads the Instructions on every prompt, sees the pointer, and follows it to the standards file. Add a standard for output: write the output file, add a pointer. Add a standard for approval: write the approval file, add a pointer. The Instructions stay lean; the standards live where they belong.

This is the branching-tree pattern. The Instructions are the trunk. Each standard is a branch the trunk explicitly points to.

the Instructions  (CLAUDE.md, loaded every turn)
├── ALWAYS read <your-voice-file>     for tone and vocabulary
├── ALWAYS read <your-output-file>    for length, structure, required elements
├── ALWAYS read <your-process-file>   for the workflow and quality checklist
└── ALWAYS read <your-approval-file>  for the definition of done

Where those files actually live on disk is your call. The setup interview in the Prompts panel asks where you want each one stored, writes the file at that location, and adds the matching pointer to the Instructions. Wherever you put them, the pointer in the Instructions is what makes them load.

Why externalize the standards at all

Two reasons. The first is size: the Instructions sit at the top of every conversation, and every line costs context budget. Inlining four full standards there bloats the brief and crowds out the role description.

The second is reuse. A separate voice file can be referenced from a Skill, from an Agent, or from a future role — anywhere a pointer can be added. An inline section in the Instructions can only be read by the Instructions.

Voice standard

Every output the workspace produces passes through this filter. Get it wrong and the output sounds generic. Get it right and the output reads like your organization wrote it.

A voice file has the same shape across functions — tone descriptors, vocabulary use/avoid lists, wrong/right examples — and the content tracks whatever the workspace is scoped to. The skeleton:

# <Function> Voice

## Tone
3-5 adjectives that describe how the output should feel.

## Vocabulary
### Words We Use
- preferred phrases, structures, or moves
- named outcomes with numbers when relevant

### Words We Never Use
- banned phrases, hedges, clichés, category-specific filler

## Voice in Action
**Wrong:** a sentence that violates the rules above.
**Right:** the same idea, written inside the rules.

The structure matters more than the specifics. Tone descriptors, an approved vocabulary, a banned vocabulary, and at least one wrong/right pair. The vocabulary lists typically mirror the approved and banned word lists you wrote into the Instructions in Part 1.

Read the wrong/right examples out loud. If the "right" version doesn't sound like something your team would actually produce, revise it. The positive examples do more work than the adjectives — they anchor the pattern Cowork matches against.

Don't list twenty banned words and call it a voice guide. A wall of prohibitions teaches Cowork what to avoid but not what to aim for. Spend more time on the positive examples than on the banned list.

To create the file and wire it in, run the Voice interview in the Prompts panel. It asks where you want the file stored, drafts the standard from your answers, and adds the "ALWAYS read" pointer to the Instructions on your approval.

Output standard

Voice governs how the output sounds. The output standard governs what it looks like structurally — length, format, required elements, channel conventions. Different output types have different requirements, and those boundaries have to be stated explicitly.

The domain determines the standards. Whatever artifact types your workspace produces — ticket replies, proposals, runbooks, articles, reports — each gets a required-fields list, a length-or-shape guideline, and a set of structural conventions. The file names the slots; the interview fills them in with the specifics that match your artifact types.

Each output file declares:

A general formatting section — headings, paragraph length, list conventions, bolding policy.
A length and shape guidelines by type section — one block per output type the role produces, with the explicit range and structure.
A required elements section — what must be present in every output of this type, regardless of length.

Run the Output standard interview in the Prompts panel for the version tailored to the output types your role actually produces.

Standards should match your actual output types, not a theoretical ideal. If your role produces three artifact types, the file covers three — not ten. Unused rules add noise. Cowork performs better against a short, relevant ruleset than against a comprehensive rulebook it has to sift through.

Process standard

In Part 1, you built an accountability framework with review checkpoints and a human in the loop at each one. The process standard encodes that framework so Cowork follows it automatically, without you restating it each session.

The structure of a process file:

# Process

## Workflow Sequence
Every output follows this sequence. Do not skip steps.

1. **Intake**: Classify the task from the inputs given.
   State the classification before drafting.
2. **Diagnose or frame**: State the most likely approach in one
   sentence, citing evidence from the input. If evidence is thin,
   say so.
3. **Draft**: Write the output following voice and output standards.
4. **Self-Review**: Run the Quality Checklist against the draft. Fix
   any failures before presenting.
5. **Present for Review**: Show the draft with the completed checklist.
   Flag any items that are borderline or need input.

## Quality Checklist
Before presenting any draft, verify:
- [ ] Tone matches voice file descriptors
- [ ] No banned vocabulary
- [ ] Required fields for this output type are present
- [ ] Concrete nouns, named entities, plain numbers
- [ ] No blame language, no hedge language
- [ ] Required metadata populated before draft is shown

## When Stuck
If the input is ambiguous, missing information, or conflicts with
existing standards: ask for clarification. Do not guess at root cause
or promise an outcome you cannot commit to.

Workflow sequence, quality checklist, and "when stuck" clause are the three constant sections. The specific steps inside each one track whatever work your workspace actually produces.

Connecting to Part 1

The Quality Checklist is the codified version of the accountability framework from Part 1. There, you saw why review checkpoints matter and how to hold Cowork to a standard. Here, that standard becomes a constraint that runs on every task. Cowork self-reviews against this checklist before showing you any draft.

Run the Process interview in the Prompts panel to tailor the workflow to the output types your role actually produces.

A common mistake is writing a process that describes an ideal workflow you don't actually follow. If your team never writes outlines for short replies, don't require them. Steps Cowork follows but you ignore create friction. Match the process to how you actually want to work.

Approval standard

The final file defines what "done" looks like. This is the checkpoint between draft and finished work — the last thing Cowork reviews against before it hands the draft to the human in the loop. Without it, Cowork has no explicit threshold for when something is ready for your review versus still needing iteration.

The structure of an approval file, role-agnostic:

# Approval

## Definition of Done
Ready for my review when ALL of the following are true:

### Quality Gates
1. **Checklist Complete**: Every item in the Quality Checklist
   (process file) passes. No "close enough."
2. **Voice Match**: The output reads like our organization, not like
   generic output. Test: could a competitor or peer ship this
   unchanged? If yes, it is not specific enough.
3. **Claims Verified**: Every statistic, data point, or factual claim
   is sourced or explicitly marked "to be verified."
4. **Output Clarity**: The one concrete action the reader should take
   next is stated in full, not implied.
5. **Audience Fit**: The output addresses the specific audience segment
   identified upstream, not a generic reader.

### Presentation Requirements
When presenting a draft, include:
- The completed Quality Checklist with pass/fail per item
- The target audience or recipient
- The one concrete action the draft asks for
- Any items flagged as borderline or needing my input

### Rejection Triggers
If any of the following are present, the draft is not ready:
- Any word from the banned vocabulary list
- Missing required field from the output standard
- Opening sentence that describes the sender instead of the reader's situation
- Unsourced claim without a "to be verified" label
- Output length outside the specified range for its type

## Escalation
If requirements conflict (e.g., length limit versus thoroughness),
flag the conflict and present two options with a recommendation.
Do not silently choose one over the other.

This file works hand-in-hand with the process standard. Cowork runs the workflow, self-reviews against the checklist, and checks the approval criteria before presenting work. Three layers of quality control, all running before you see a single draft.

Run the Approval interview in the Prompts panel for the tailored version.

The "Voice Match" test is the most valuable check in this file. Generic output is the most common weakness of a predictive text system. If your organization's name can be swapped for a peer's and the output still works, the voice standard hasn't done its job. This check catches that — and the human in the loop catches what the check misses.

What happens on every turn

Cowork loads the Instructions at the start of every prompt. The Instructions contain a pointer for each standard you've added. Cowork follows each pointer, reads the file, and applies it as an unconditional constraint. No manual trigger. No re-paste. The pointer is the trigger.

Precedence is worth stating plainly. The Instructions are context Cowork reasons with. The standards are constraints it doesn't override. When two standards disagree with each other, Cowork tries to honor both — which is why conflict resolution matters. If the voice file says "never use the word unlock" and the output file says "every email must include an unlocking value statement," one of them will lose and neither of you will know which. Resolve conflicts in the file, not in the conversation.

Putting it together

With four standards in place — voice, output, process, approval — the Instructions point to all four, and Cowork enforces all four on every turn:

the Instructions  (CLAUDE.md)
├── ALWAYS read <your-voice-file>      → How we sound
├── ALWAYS read <your-output-file>     → What our output looks like
├── ALWAYS read <your-process-file>    → How we work
└── ALWAYS read <your-approval-file>   → When work is done

Together with the role brief from Part 1, the four standards turn a general-purpose predictive text system into a scoped configuration for one function. The Instructions provide context. The standards provide constraints. Cowork combines them on every turn.

Test the setup now. Give Cowork a task within your role's scope and watch the standards in action. It should follow the workflow from the process file, write in the declared voice, meet the shape guidelines from the output file, and present the draft with a completed quality checklist. If any of those steps are missing, check the corresponding pointer in the Instructions — and the file it points to.

Off-Ramp 1: What you have built

What you have: A working Cowork configuration with full role context, an accountability framework, and four codified standards. Cowork applies your voice, your audience framing, and your quality bar on every turn.

What is ahead: Parts 3-5 add reusable Skills, sub-agents, and a scheduled pipeline that turn this foundation into structured execution. Worth doing when you are ready — what you have now is already a capable scoped workspace for one function.

This is a real stopping point. Plenty of teams run an effective function with exactly this setup: a well-briefed configuration with clear standards. You hand it tasks, it produces drafts, you review and ship. No Skills, no Agents, no scheduled pipelines.

If you stop here, you have something most teams don't — a scoped configuration that applies your voice, follows your process, and holds itself to your standards on every single task (plus your review and decision time).

What just changed

You wrote four standards files at locations you chose, and you added four "ALWAYS read" pointers to the Instructions — one per standard. Cowork now reads the Instructions on every turn, follows each pointer, and applies all four standards as constraints. The playbook is on the wall.

In Part 3, you add Skills — saved, repeatable prompt configurations the workspace invokes on demand. Skills follow the same branching-tree pattern: each Skill is a file you store where you choose, and the Instructions get a pointer that tells Cowork when to use it. Instead of composing a new prompt every time you need a specific output, you trigger the Skill and get a consistent, standards-compliant artifact.

Part 2 of 6