Two researchers at UC Berkeley's Haas School of Business, Aruna Ranganathan and Xingqi Maggie Ye, followed 40 workers at a roughly 200-person US technology company from April to December 2025, across engineering, product, design, research and operations. They wrote it up in Harvard Business Review under the title AI Doesn't Reduce Work, It Intensifies It. Nobody's workload went down. Three things went up instead:
The researchers' phrase for it is silent workload creep, and their warning was that it hides inside what looks like a productivity win. The Register's write-up has the study details outside the paywall if you want them.
Here is the part I care about: none of that is an argument against using AI. It is a description of what happens when you point AI at tasks instead of at processes. Speed up one task and you have not removed the work, you have raised the bar and kept the coordination, the checking and the deciding on your own plate.
A directive is a plain-English markdown file describing one whole process from start to finish. No code, no special syntax, and you write it once. It has seven sections, and the last two are the ones people leave out and then wonder why work keeps coming back.
# [Name of the process]
## What this is for
One paragraph in plain English. What outcome this produces, who it is for, and when it should run. Write it so a competent stranger would understand what "finished" looks like before reading anything else.
## Inputs
Everything needed before starting, and exactly where each one lives. Name the folder, the file, the link, the inbox label. If an input is missing, stop and ask me rather than guessing or inventing a placeholder.
## Steps
1. The first thing to do, written as an instruction, not a description.
2. The next thing. One action per step.
3. Keep going until the process is genuinely finished, including the boring last mile: naming the file, putting it in the right folder, updating whatever tracks it.
## Rules and constraints
The non-negotiables. House style, tone, formats, banned words, things that must never happen, decisions that are mine and not yours. Anything I have corrected more than twice belongs here permanently.
## Definition of done
The checklist you run against your own output before telling me it is finished. Write it as things to verify, not things to do. If any check fails, fix it and re-run the checklist rather than reporting it to me.
- [ ] Check one, stated so it is objectively pass or fail
- [ ] Check two
- [ ] Check three
## What to do when you are stuck
The specific situations where you should stop and ask me instead of deciding: missing input, ambiguous requirement, anything that costs money, anything that gets sent to another person. For everything else, make a sensible call and note it.
## Output
Exactly what lands on my plate at the end, in what format, and where. One sentence. If I have to go looking for the result, this section is not finished.This is a genuinely small process, deliberately, because small ones are where you should start. Notice how much of it is the last three sections.
# Weekly client update
## What this is for
Produces the Friday client update email for each active client, ready for me to read and send. It should be sendable as written, not a draft I have to rewrite.
## Inputs
- The client folder in Drive, which holds the last four updates for tone and continuity.
- My notes file for the week, at notes/this-week.md.
- The shared task board, for what actually shipped and what slipped.
If the notes file is empty or the board has not moved, stop and ask me. Do not write an update from nothing.
## Steps
1. Read the last two updates for that client so the voice and the running threads carry over.
2. Pull what shipped this week, what moved, and what is blocked.
3. Write the update in this order: one-line summary, shipped, in progress, what I need from you, what is next.
4. Name anything that slipped honestly, with the new date, in one sentence and without an apology paragraph.
5. Save it as updates/YYYY-MM-DD-clientname.md and tell me the file path.
## Rules and constraints
- Under 250 words. Clients skim.
- No em dashes, no "we're excited to", no filler openers.
- Never promise a date I have not given you.
- Never mention another client by name.
- If a number is not in my notes or on the board, do not include it.
## Definition of done
- [ ] Every claim traces to the notes file or the task board, with nothing invented
- [ ] Under 250 words and in the five-section order above
- [ ] Every slipped item has a stated new date
- [ ] The "what I need from you" section has either a specific ask or the line "nothing this week"
- [ ] Saved with the correct filename and the path given to me
## What to do when you are stuck
Stop and ask if: the notes are missing, two sources disagree about status, or something looks like bad news the client has not heard yet. Everything else, decide and note the call at the bottom.
## Output
One markdown file per active client in updates/, plus a message listing the file paths and any decisions you made.This is the section that decides whether the work bounces back. Without it, Claude finishes when it runs out of instructions, which is not the same as finishing when the job is right. With it, Claude checks its own output and fixes what fails before you ever see it, which is exactly the review work you were trying to get off your plate.
The rule for writing one: every line has to be objectively pass or fail. "Make sure it is good" cannot be checked. "Every number appears in the source file" can.
SKILL.md inside a folder named after the process, zip the folder, then in the Claude app open Customize, then Skills, then Add, then Upload a skill. Add a description line at the top saying when it should be used, and Claude reaches for it on its own when your request matches. This works on any plan, Free included, and the steps are in Anthropic's creating custom skills article.directives/ folder in the project, one markdown file per process, and reference it from your CLAUDE.md so Claude knows the folder exists. Then "run the weekly client update directive" is the whole instruction. This is the version I use, because the directive sits next to the files it operates on. The memory docs explain how CLAUDE.md is loaded, and slash commands let you give a directive its own shortcut.You do not have to write the directive from a blank page. Have Claude interview you, because it will ask about the parts you have stopped noticing.
I want to hand you an entire process instead of asking you for one task at a time. Help me write a directive file for it, using this structure: what this is for, inputs, steps, rules and constraints, definition of done, what to do when stuck, and output.
The process is: [describe it roughly, the way you would explain it to a friend, including what triggers it and what you end up with].
Interview me before you write anything. Ask me, one small group at a time: where each input actually lives, the steps I do on autopilot that I have not mentioned, the corrections I find myself repeating, what makes a bad version bad, and which decisions must stay mine. Push back if an answer is vague, because vague answers become vague output.
Then write the directive in plain English. For the definition of done, every line must be objectively pass or fail, so rewrite any check that relies on judgement into something verifiable. Finish by telling me which parts you are least confident about and what you would need from me to tighten them.Then run it once on real work, and every time something comes back wrong, add one line to the rules or the definition of done rather than re-explaining in chat. Three or four passes and the process stops needing you.
AI Doesn't Reduce Work, It Intensifies It, Harvard Business Review, 9 February 2026
The Register's summary of the same study, outside the paywall
What are Projects, Claude Help Center
Creating custom skills, Claude Help Center
CLAUDE.md and memory, Claude Code docs
Slash commands, Claude Code docs
Effective context engineering for AI agents, Anthropic