Most of what an organization writes, it has written before. A sales team answers another request for proposal. A nonprofit fills in the same paperwork for every program and every event it runs. A legal practice prepares case documents that follow the same shape from one matter to the next. An IT operations team writes a change request before each release and a runbook for each maintenance window. The details change every time. The document does not.
That makes standard documents the obvious place to put AI to work, and most teams start the same way. Someone opens a chat, types a request, and gets back a draft that looks finished. It is quick and cheap, and the team can produce as many as it likes.
Then someone reads them. The drafts fail in the same ways: facts nobody supplied, sections that wander off on a tangent, whole pages circling one topic the model fixated on. A request typed fresh each time carries nothing forward from the last one, so every draft starts from zero and every reviewer starts rewriting. Nobody knows which of those drafts is any good until a person has read it, and a workflow like that only looks cheap until someone counts the review time and token / usage costs.
What those workflows lack is a standard: a written statement of what a good version of this document contains, checked before a person spends any time on the draft.
A rubric
says what good looks like.
That standard is a rubric, a marking scheme for one type of document. Each line is a question a reviewer can answer yes or no, so "it looks finished" becomes a check the draft either passes or fails.
Take the IT operations team. Its change request goes to one person who can approve it, and the rubric asks what that person would ask. Does the first sentence say what the business gets, before any system is named? Does it carry exactly one change? Does it say what happens if the answer is no? Its runbook gets a different test: at two in the morning, does the person holding step fourteen know what to do, what must already be true, how to tell the step worked and who to call if it did not? Does every step name an owner, something the person can see is already in place, and a check that proves the step is done?
A sales team's rubric asks whether every question in the buyer's request has been answered, and whether any promise goes beyond what the business has agreed to. Different questions, the same yes-or-no test.
Because every draft of a type is now judged on the same questions, a team can finally compare quality with cost. Without a rubric, the cheapest workflow looks best, because nothing records what it got wrong, and documents made that way are poor whatever model writes them. With one, a smaller model can be tested fairly against a larger one.
A rubric can tell you whether a draft is good. It cannot supply what the draft needs to know, and the facts that matter are spread across old documents and the heads of the people who asked for it.
So the rubric needs a partner: a generator. By that I mean a skill, a folder of written instructions the model follows every time it writes one type of document. Each generator holds five things: a checklist of every section the document must have and where each one's content comes from, a template laid out from that checklist, an interview, the rubric, and a short page for people explaining what the document is for and who reads it. The interview is the part that runs first.
The generator
interviews the person first.
The generator starts by asking. I call this reverse prompting: instead of a person writing a prompt for the model, the model interviews the person.
It does not ask everything. It first answers every question it can from what the organization already holds: last quarter's change requests, the ticket, the policy, the previous proposal. Only what is left reaches a person, and those are the questions no page can answer. What does the plan do if the change is refused? Who can approve it? For a nonprofit, which program is this, and what did the funder ask to see?
Each question arrives with a recommendation and what taking it would change: we suggest this, because of that; if you would rather do something else, say so and the document changes. The runbook's interview asks how long each service can be unavailable during the window, and offers a suggested answer drawn from the last one. A person can answer a question like that in seconds. A blank chat box asks them to know in advance everything a good document needs, which is the knowledge the generator was supposed to carry.
The interview is where the person does their real work. They are dialling in the content: supplying the judgement, the context and the decisions that only they have.
The answers
write the draft.
Those answers are what the draft is built from. Each section is filled from an answer or from a source the generator can name. Where neither exists, the section says what is missing and who owes it. The model never fills a gap with something plausible, because a plausible gap-filler is exactly the invented fact a reviewer would otherwise have to find.
A decision still open is written as a position, so the person can agree with one word. The change request does not say the release is booked for Thursday; it says the team would proceed with the first option unless told otherwise by Wednesday, and what that option leaves the business carrying.
Because those rules live in the generator, not in whoever typed the request, the tenth change request is written as carefully as the first. Every one has the same sections, asks the same kind of questions and faces the same test, whoever on the team needed one that week.
The draft is checked
before anyone reads it.
Before a person sees the draft, the model reviews its own work against the rubric, revises what fails and checks again. It grades the draft the way a strict colleague would, and it can do that more than once, from different angles: a blind read, an attempt to break the argument, a line-by-line pass against the rubric. The goal is for that loop to take the draft as far as it can without a person, so that what reaches the reviewer already meets the rubric.
Content outranks structure in that review. A draft that has every section and fails one content question is not ready.
The draft then arrives in one reply, in a fixed order: what was written, the questions still open, each with its recommendation, the model's own review findings, worst first, and finally the link to the document. That order came from a correction. Early on, the model handed me a strong review of what a project was missing, mentioned it had two questions for me, and stopped without asking them. The document was good; the questions were never asked. Now the reply asks them.
The person reviews the words as plain text, before any formatted file exists. Checking the wording first is cheaper than rebuilding a polished document around a correction, and once the words are validated, producing the branded version is a routine step that software handles without AI. A person sends the finished document. The model never does.
The reviewer's job has changed by this point. They receive a draft that already meets the rubric, and they dial it in rather than rewrite it.
Every correction
improves the generator.
Whatever the reviewer still changes is the most useful thing the process produces, because each change shows something the generator did not know.
So the correction goes back into the generator. The rule: when the same problem appears a second time, it becomes a line in the instructions or a question in the rubric, so it cannot appear a third time. The model writes the new rule itself, and it is better than a person at that level of detail. The person's part is to answer its questions well and confirm the rule, including whether it always applies. Some rules are optional, and some only matter in certain situations, such as a release that touches customer data or a proposal for a public-sector buyer. Those are written with the situation that calls for them, and the generator raises them only when it arises.
One of those rules came from a project plan that arrived with several sections that were a heading and a table and nothing else. It passed every check for having the right sections. Now every table needs a line saying what the reader is looking at and what to do with it, checked section by section, so a thin section cannot hide behind a thick one.
Rules like these start in one document type's rubric. When a second type needs one, it moves into a shared rubric that every type is held to. A type can add questions and make a shared one stricter, but never waive one. Each new document type starts from everything the earlier ones learned.
That is how the output improves. The next change request is checked for everything a reviewer caught on the last one, and so is the next proposal, the next program report and the next case summary, wherever the rule is shared.
Start every document
from the generator.
Over time the reviewer asks for fewer changes, because the ones they used to ask for are already rules. Their time moves from rewriting drafts to the judgement only they can give.
That only works if people use the generators. A team member who writes a change request from scratch, or copies last month's and edits it, produces a document the rubric never checked and a correction the generator never learns from. So I recommend making the standard generator everyone's baseline: the first draft of every standard document comes from it, and people spend their effort dialling that draft in.
Used that way, each generator becomes the team's own procedure, written down and improving with use, with a reviewer's judgement built into the workflow at every step.
Which document does your team rewrite most often, and what would its rubric ask?
Build your first generator
from these two files.
This is a generator for one document type, a change request, and the shared rubric every type is held to; adapt the first to the document your team writes most. Save the skill as .claude/skills/doc-change-request/SKILL.md (or wherever your agent reads skills) and the rubric beside your document skills as rubric-shared.md, then ask your agent for a change request.
---
name: doc-change-request
description: Drafts a change request, the document that puts one proposed change in front of the person who can approve it, as a decision rather than a notification. Use when work is wanted that the agreed scope does not cover, or when someone asks for a change request. Drafts Markdown for a person to validate; it approves nothing and sends nothing.
---
# Change request
## What the reader gets
One person who can say yes reads this once, usually in under five minutes. They need to know what they are being asked to agree to, what it gets the business, what it touches, and what happens if they say no. The document ends in one decision they can answer in one reply.
## The sections (the checklist)
| Section | Where its content comes from | If nothing supplies it |
|---|---|---|
| What the business gets | The request or ticket | Interview question 1 |
| What it touches | The systems or services list | Name it as owed, with its owner |
| What is already agreed about it | Earlier decisions, cited, never restated | Interview question 2 |
| What happens if the answer is no | The plan's default | Interview question 3 |
| Who approves it | The team's approval list | Interview question 4 |
| When the answer is needed | The release calendar | Interview question 5 |
| The decision | Two or three real options, one recommended | Never left blank |
## Template
Lay the draft out in the checklist's order, one heading per section, with a line under each heading saying what the section is for. Keep the standard blocks every document carries (document control, confidentiality, related documents) in one shared file and name them here; never paste their wording into this skill.
## Interview (reverse prompting)
1. Answer every question you can from what already exists: earlier change requests, the ticket, the calendar, the decision log. Record where each answer came from.
2. Ask the person only what is left. Each question says what we suggest, why, and what changes if they choose otherwise: "We suggest X, because Y. If you would rather Z, tell us and we will change it."
3. Never ask about a file, a template or a field name. Ask about the change.
Questions, used only when nothing already answers them:
1. In a sentence, what does the business get from this change?
2. Does this reopen something already decided? If so, what has changed since?
3. If the answer is no, what does the plan do, and what does that leave the business carrying?
4. Who can approve it, and who needs to be told?
5. By when must the answer arrive for the release to hold?
## Drafting
- Fill each section from an answer or a named source. Where neither exists, write what is missing and who owes it. Never invent a fact, a figure or a way of doing something.
- The outcome comes before the mechanism. The first sentence says what the business gets.
- One change per request. Two changes cannot be approved with one answer.
- State a default as a position, never as a fact: "we would proceed with option A unless you tell us otherwise by <date>."
## Before anyone reads it
1. Review the draft against `rubric-shared.md` and the type criteria below. Revise every failure and review again.
2. Deliver it in one reply, in this order: what was written, the open questions (each with its recommendation), the review findings worst first, then the link to the Markdown.
3. Stop. A person validates the Markdown before any formatted version is produced. Nothing is sent by an agent.
## Type criteria (added to the shared rubric)
| ID | Criterion |
|---|---|
| CR-01 | The request carries exactly one change. |
| CR-02 | The decline position says what the plan does and what the business carries. |
| CR-03 | Every option can be answered in one reply, and one is recommended. |
| CR-04 | No price or effort figure appears that a named owner has not declared. |
## Growing this skill
When a reviewer asks for the same change a second time, add it here the same day: as a drafting rule if it is about how to write, as a criterion if it can be checked. Say whether it always applies, is optional, or applies only in a named situation (for example, "when the change touches customer data"), and apply it only then. Record the document and the date beside it. When a second document type needs the same criterion, move it to `rubric-shared.md`.# Shared rubric: what every standard document is held to
Every document type has its own criteria on top of these. A type may add criteria and may make one of these stricter. It may never waive one.
Content outranks structure. A draft that fails one content criterion is not ready, however complete its sections are.
| ID | Criterion | Rank |
|---|---|---|
| S-01 | The first sentence says what the reader gets. The case comes before the mechanics. | content |
| S-02 | The decisions the reader must make are listed, each with what happens if it is not made and by when. | content |
| S-03 | Every action, gap and open question names who owns it: a role, and a person wherever one is known. | content |
| S-04 | Every commitment carries a date, or the dependency that fixes one. "In due course" is not a date. | content |
| S-05 | Nothing is invented. Every fact comes from an answer or a named source; anything without one is listed as owed, with its owner. | content |
| S-06 | A negative finding is a measurement. "No conflicts found" names what was compared, on what, and how many were checked, or it is not written. | content |
| S-07 | Every number can be traced to where it was read, and a number repeated in two places is the same number. | content |
| S-08 | The document does not contradict itself, or an earlier decision. A conflict is raised as a question, never edited into agreement. | content |
| S-09 | Every question the interview left open was asked, with its recommendation, in the reply that delivered the draft. | content |
| S-10 | A reader outside the team can follow it: no internal file paths, tool names, internal roles or rates, and no jargon the document does not explain. | content |
| S-11 | Headings are plain labels for what the section holds, never questions or teasers. | structural |
| S-12 | No section is a bare heading and a table. Every table has a line saying what the reader is looking at and what to do with it. Check section by section. | structural |
| S-13 | No placeholder stands in a required section: no TBD, no "pending", no empty row. List here the placeholders your own tools write when they have nothing to fill in, and check for those too. | structural |
| S-14 | Every section the type's checklist names is present, or says what is missing and who owes it. | structural |
## Growing this rubric
When a person catches something this rubric missed, and a second document type needs the same fix, add a row here the same day. Record the document it was found in and the date, so the reason for the rule is never lost. Never renumber a row.