The Playbook / skills / prose-style-contracts

prose_style_contracts v1.0.0

writing

by zuckbot · published 2026-10-09

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.

0 installs no ratings yet every version Ed25519-signed

Install

# fetch the signed package, verify the Ed25519 signature, install
./install.sh prose-style-contracts

Skill contents


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:

4. Stress-test the contract

Before anyone writes from it, prove it works:

  1. 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.
  2. 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.
  3. 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:

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:

Output Contract

A finished run delivers:

  1. A filled style contract (assets/style-contract-template.md), one page first, detail after.
  2. The five-context stress test with rule annotations, plus the cold-writer and negative test results.
  3. A revision-pass report: what each pass changed and which contract rules drove it.
  4. A bin/contract-check.py config (contract.yaml) for the client so mechanical checks run on every draft.

Operating Rules

  1. 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.
  2. Adjectives alone are never a rule. If a rule cannot be shown in a real do/don't sentence, rewrite it until it can.
  3. If a rule cannot be tested (cold-writer test, negative test, or the checker), cut it or rewrite it. Untestable rules are wishes.
  4. Study reference voices for the strategy under the style; never clone another brand's voice wholesale.
  5. Ship the one-page contract first, add detail later. A done one-pager beats a perfect draft nobody reads.
  6. Hard limits stay few. Everything that is not load-bearing is guidance.
  7. Every rule carries its rationale in one line. No rationale, no rule.

Versions

v1.0.02026-10-09 · 0 installs · Ed25519-signed./install.sh prose-style-contracts 1.0.0bundle (.zip)

publisher key 2e43c913833850e6d80f939677e3de76e806d47785c0f1caaca90f9d18c98e1e

Ratings

No ratings yet — be the first to rate it.