Define, test, and enforce a prose style contract: turn vague voice adjectives into checkable rules, stress-test the voice with a before/after suite, and run revision passes that bring every draft into line. Use when someone wants a consistent writing voice, needs to audit copy against a style guide, or is building writing rules for human or AI writers to follow.
name: "prose_style_contracts" description: "Define, test, and enforce a prose style contract: turn vague voice adjectives into checkable rules, stress-test the voice with a before/after suite, and run revision passes that bring every draft into line. Use when someone wants a consistent writing voice, needs to audit copy against a style guide, or is building writing rules for human or AI writers to follow." metadata: { "includeInPrompt": true }
Prose Style Contracts
Purpose
Most style guides die as PDFs nobody opens. They say "friendly, confident, bold" and stop, which every writer interprets differently. A style contract fixes that: it turns voice into rules specific enough to check. This skill builds the contract, proves it works with a stress test, and then uses it as the backbone of revision passes and ongoing enforcement.
Workflow
1. Audit first
Collect 15 to 20 samples of the existing copy across channels (site, emails, support replies, social). Mark each as on-voice or off-voice in one line. Patterns in the off-voice pile are the rules the contract has to contain. Skip this step and you are writing wishes, not rules.
2. Define the voice, then define what it is not
Name 3 or 4 voice attributes. For each one, write the anti-attribute next to it: Confident, not arrogant. Direct, not blunt. Warm, not gushing. The anti-attribute is what stops drift; writers reach for it when they are unsure.
3. Write the contract
Fill assets/style-contract-template.md. Every rule needs three things: the rule itself, one real-sentence do/don't pair showing it in action, and a one-line rationale. Abstract adjectives alone are banned from the contract. Rationale matters: rules without a reason are the first ones ignored.
The contract has five sections:
- Voice attributes. The 3-4 traits plus anti-traits, each with a do/don't sentence pair.
- Tone spectrum. Voice is constant; tone shifts by context. For each context you actually write in (marketing, support, legal, error messages, social), state the reader's state of mind and how the voice flexes for it.
- Mechanical rules. The checkable ones: max sentence length, contractions yes or no, serial comma yes or no, active voice default, address the reader as "you", target reading level, exclamation and emoji limits, banned words, house terms (use X, never Y).
- Hard limits. The few things that never change. Keep this list short. Everything else is guidance.
- Changelog. Date, what changed, why. A contract nobody updates is a contract that quietly dies.
4. Stress-test the contract
Before anyone writes from it, prove it works:
- Five-context demo. Write the same core message in five contexts: a social post, an email subject plus preview text, a support reply, a headline plus subhead, an about-page excerpt. Annotate each with which rule drove each choice. If you cannot point at the rule, the rule is too vague. Rewrite it.
- Cold-writer test. Hand the contract to someone who did not write it and ask them to produce one paragraph. If they come back with questions the contract should have answered, the contract is incomplete.
- Negative test. Write a paragraph that is deliberately off-voice, then check the contract flags exactly which rules it breaks. A contract that cannot name the violation cannot enforce anything.
A worked stress-test example lives in references/voice-stress-test.md.
5. Revise against the contract
Run four passes, one level at a time, never all at once. Each pass checks the draft only against the contract, not against general taste:
- Pass 1, document level. Headings clear and descriptive, sections flow in a logical order, each paragraph opens with a topic sentence. Cut sections the request never asked for.
- Pass 2, paragraph level. Tone matches the context's place on the tone spectrum. Cut anything the reader does not need to act or decide. Paragraphs built for skimming.
- Pass 3, sentence level. Sentences over ~25 words get split or cut. Active verbs replace passive and vague ones (make, do, have, get). Subject and verb stay close, verb early.
- Pass 4, word level. Concrete, specific words win over abstract ones. Cut filler (very, really, in order to, it should be noted). Banned words from the contract get swapped. One word replaces any wordy phrase.
Full pass checklists are in references/revision-passes.md. bin/contract-check.py automates the mechanical rules (banned words, preferred terms, sentence length, passive-voice flags, filler words) so the human passes can stay focused on voice.
6. Enforce it
A contract without enforcement is decoration:
- Name one owner who makes the final call when reviewers disagree. The owner arbitrates language, not just reviews it.
- Put the contract in the brief, not just the review step. Writers and AI drafts work from the same contract and examples; reviewers check against the same criteria. AI drafts get the contract too, since they only know the context they are given.
- Quarterly tone audit. Pull recent shipped content, score it against the contract, fix drift before it spreads. A 20-minute check beats a rescue operation.
- Share the file where people can reach it without asking. Link it in onboarding. A contract nobody can find is a rumor.
Output Contract
A finished run delivers:
- A filled style contract (
assets/style-contract-template.md), one page first, detail after.
- The five-context stress test with rule annotations, plus the cold-writer and negative test results.
- A revision-pass report: what each pass changed and which contract rules drove it.
- A
bin/contract-check.py config (contract.yaml) for the client so mechanical checks run on every draft.
Operating Rules
- Every factual claim in a skill must be verified via web search or a primary source. Never invent numbers, dates, quotes, or events. Unverifiable gets cut or framed as opinion. No confident unverified claims, ever.
- Adjectives alone are never a rule. If a rule cannot be shown in a real do/don't sentence, rewrite it until it can.
- If a rule cannot be tested (cold-writer test, negative test, or the checker), cut it or rewrite it. Untestable rules are wishes.
- Study reference voices for the strategy under the style; never clone another brand's voice wholesale.
- Ship the one-page contract first, add detail later. A done one-pager beats a perfect draft nobody reads.
- Hard limits stay few. Everything that is not load-bearing is guidance.
- Every rule carries its rationale in one line. No rationale, no rule.
No ratings yet — be the first to rate it.