Part 2 — The Playbook: Always-On Rules for Every Turn
The trunk is in place: an Instructions file at the root, with a few branches pointing at files you named. The Instructions tell Cowork what this workspace is for. They don't yet tell it how to behave once it gets to work — purpose and behaviour are different jobs.
Part 2 closes that gap. You add a small set of always-on rules: the things you want true on every turn, no matter the task. They live in their own files alongside the existing Instructions and the files it points at, with new pointers in the Instructions sending Cowork to read them on every run.
When you finish, your folder still holds the existing Instructions file, unchanged at the top, with a few new ALWAYS read lines appended underneath. Each of those new lines points at a file you named, placed, and approved. The rules they hold apply on every turn this workspace runs.
- A workspace that behaves the same way every time, without you restating how it should sound or what counts as ready.
- New rules slotted into the layout you already have — no new top-level shape, no churn on what's already there.
- An Instructions file that grows by exactly the lines you wrote, in the same branching shape you started with.
What "always-on" actually means
A reference file is one Cowork reaches for when a topic comes up. An always-on rule is the opposite. Cowork reads it on every turn, applies it as a constraint, and does not get to ignore it just because the task does not seem related.
Two reasons it works that way.
- Drift. Turn-to-turn behaviour drifts if it is not pinned. You can repeat "match our voice" in a chat fifty times and still get a fifty-first reply that sounds generic. Pinning the rule to a file Cowork loads on every turn fixes that.
- Reuse. A separate file can be referenced from anywhere a pointer can sit: from the Instructions, from a focused helper you build later, from a multi-step pipeline. An inline section can only be read by the file it sits in.
The kinds of things that belong in an always-on rule are usually the things you find yourself saying twice in a row. A way you want the work to sound. A check that has to run before something is considered done. A line you do not want the workspace to cross without asking you. The walkthrough surfaces those from the way you describe the work — you do not need a list going in.
The lines this part adds to the Instructions follow the same ALWAYS read [your-file] for [the kind of behaviour it covers] template the existing pointers use. Same shape, new pointers underneath the ones already there.
How to run it
Open the prompts panel on this article and paste the Part 2 prompt. The model re-reads the Instructions file at the root, reads the rest of your folder, and asks you in one sentence what this workspace should always do, or never do, on every turn. You walk through the rest. The model proposes shapes; you decide what each new piece is called and where it lives.
What happens when you paste the prompt
Same shape as the setup walkthrough, scoped to the new layer.
- Read what's there. The prompt starts by reading what's already on disk: the Instructions, the slots you've named, the files you wrote. Then it asks you, in one sentence, what this workspace should always do or never do on every turn. Short, plain answers work. If your answer is thin, the prompt offers a few short multiple-choice follow-ups to thicken it.
- Propose the rule list. From your answer, the prompt proposes a list of always-on rules in plain language. Each one is a sentence describing a kind of behaviour the workspace should hold to. You walk through the list with the prompt: drop one, rename one, add what's missing, or say it looks right. The list does not move forward until you do.
- Confirm placement. For each rule on the confirmed list, the prompt asks which of the existing slots it fits into. New rules slot into existing slots first. The prompt only asks about adding a new slot if you said the existing layout doesn't have a home for the rule. You stay in charge of where things go.
- Walk file by file. After placement, it goes one rule at a time. Name the file, read the draft contents, accept or edit or ask for a different angle, write it on your go.
- Append the pointers. When all the new files are on disk, the prompt shows you the exact new lines it wants to append to the Instructions. Each is the same
ALWAYS read [your-file] for [the kind of behaviour it covers]shape already in use. You approve the lines. They land underneath the existing ones. Nothing existing gets moved or rewritten. - Read it back. Last, you see the updated layout and the updated Instructions read back from disk. If anything's off, you can rename, move, edit a draft, or restart from a different one-sentence answer.
When you're done
The Instructions still read end-to-end in under a minute. The first lines are still the ones already there. Underneath them are the new ALWAYS read pointers, each one going to a file you named. Cowork loads the Instructions on every turn, follows each pointer, and applies what it finds as a constraint on the work.
Picking up the running example, CLAUDE.md at the root of your folder reads roughly like this after this run:
This workspace handles inbound product feedback for the support team.
Voice is plain, calm, and concrete. Replies stay short.
ALWAYS read voice.md for how this workspace should sound.
ALWAYS read audience.md for who's on the other side of the work.
ALWAYS read ready-check.md for what counts as done before sending.
ALWAYS read tone-guardrails.md for words and phrases this workspace will not use.
ALWAYS read escalation-rule.md for what this workspace will not do without checking with you.
The first block is what was already there, untouched. The second block is the new pointers, appended underneath. Your filenames will be different. The shape is the same.
The shape of the workspace has not changed. It has gotten denser. The next part keeps that pattern going.
Next: Part 3 — Skills extends the same workspace with reusable plays for the work you do over and over.