Policy Drafter Skill
Internal policies fail readers two ways: legalese nobody parses (so folklore governs instead), or vague aspiration ("use good judgment with expenses") that answers no actual question. A followable policy states each rule plainly with its reason (reasons recruit compliance and guide the unlisted cases), separates bright lines (never/always, no judgment) from judgment zones (factors + who decides), and works three real edge cases in the text — because the edge cases are what people actually come to a policy to resolve. Honesty requirement: the enforcement section describes what actually happens, not theater.
What This Skill Produces
- The policy — scope, the rules with reasons, bright lines vs. judgment zones marked
- The worked edge cases — 3–5 real scenarios resolved in the text, showing the principle in motion
- The enforcement section — what happens on violation, honestly, and who decides gray cases
- The one-page summary — the rules card people will actually consult (the full policy is the reference; the card is the interface)
Required Inputs
Ask for these if not provided:
- The behavior being governed and why now — the incident, the ambiguity, the new tool; policies exist for reasons and the reasons belong in the text
- The real cases — the actual questions people have asked ("can I expense the airport lounge?", "can I use AI on customer data?") — these become the worked examples, and a policy that doesn't answer them fails at its job
- The bright-line candidates — what leadership genuinely intends as never/always, vs. what they want discretion on; drafting discovers this boundary and forces the conversation
- The enforcement truth — what will actually happen on violation; if the answer is "probably nothing," the policy needs redesign (fewer rules, real ones), not stronger language
Framework: The Followability Rules
- Every rule carries its reason: "Expenses over $500 need pre-approval — because surprises at that size break the team budget's month" — the reason converts rules from arbitrary to legible, guides cases the rule didn't list, and survives the rule's author leaving. Rules without reasons age into folklore.
- Bright lines and judgment zones get different grammar: bright lines are absolute and short ("customer data never enters unapproved tools — no exceptions") · judgment zones name the factors and the decider ("client gifts: consider value, timing, and optics; over $100 or near a renewal → ask [role]"). Blending the two produces policies that are simultaneously rigid and vague.
- Edge cases are worked in the text: the 3–5 real questions get answered with the reasoning shown ("Lounge on a delayed red-eye: yes — the reason behind the meal rule (reasonable comfort on work travel) covers it") — teaching the principle so the sixth case answers itself.
- The floor is the busy reader: the one-page card carries the rules and bright lines; the full policy holds reasons, edges, and process. A policy only consultable by reading eleven pages will be consulted never; the card is the interface, per the template-designer lightness law.
- Enforcement honesty: the section states the actual consequence ladder and the gray-case decider — and if drafting reveals there's no appetite to enforce a rule, the rule gets cut or softened to guidance now. Unenforced rules teach that the whole policy is decorative; three real rules beat eleven ornamental ones.
Output Format
Policy: [domain] — v[N], owner: [role]
Why This Policy Exists
[Two sentences — the incident/ambiguity it resolves]
The Rules (with reasons)
[Each: the rule · — because [reason] · 🔒 bright line / ⚖️ judgment zone (factors + decider)]
Worked Edge Cases
[The real questions, resolved with reasoning shown]
Enforcement (honestly)
[The consequence ladder as it will actually run · gray cases → [decider] · review cadence]
The One-Page Card
[Rules + bright lines only — the consultable interface]
Quality Checks
Anti-Patterns
1---2name: policy-drafter3description: Draft an internal policy people can actually follow — the rule stated plainly with its reason, the bright lines separated from the judgment zones, the edge cases resolved by principle, and the enforcement reality stated honestly. Use when asked write our expense/remote-work/AI-use/security policy, turn this incident into a policy, our policy doc is unreadable, or people keep asking what's allowed. Produces the policy with rules-plus-reasons, the bright-line/judgment split, the worked edge cases, and the honest enforcement section.4---5
6# Policy Drafter Skill
7
8Internal policies fail readers two ways: legalese nobody parses (so folklore governs instead), or vague aspiration ("use good judgment with expenses") that answers no actual question. A followable policy states each rule plainly *with its reason* (reasons recruit compliance and guide the unlisted cases), separates bright lines (never/always, no judgment) from judgment zones (factors + who decides), and works three real edge cases in the text — because the edge cases are what people actually come to a policy to resolve. Honesty requirement: the enforcement section describes what actually happens, not theater.
9
10## What This Skill Produces
11
12- **The policy** — scope, the rules with reasons, bright lines vs. judgment zones marked
13- **The worked edge cases** — 3–5 real scenarios resolved in the text, showing the principle in motion
14- **The enforcement section** — what happens on violation, honestly, and who decides gray cases
15- **The one-page summary** — the rules card people will actually consult (the full policy is the reference; the card is the interface)
16
17## Required Inputs
18
19Ask for these if not provided:
20- **The behavior being governed and why now** — the incident, the ambiguity, the new tool; policies exist for reasons and the reasons belong in the text
21- **The real cases** — the actual questions people have asked ("can I expense the airport lounge?", "can I use AI on customer data?") — these become the worked examples, and a policy that doesn't answer them fails at its job
22- **The bright-line candidates** — what leadership genuinely intends as never/always, vs. what they want discretion on; drafting discovers this boundary and forces the conversation
23- **The enforcement truth** — what will actually happen on violation; if the answer is "probably nothing," the policy needs redesign (fewer rules, real ones), not stronger language
24
25## Framework: The Followability Rules
26
271. **Every rule carries its reason:** "Expenses over $500 need pre-approval — because surprises at that size break the team budget's month" — the reason converts rules from arbitrary to legible, guides cases the rule didn't list, and survives the rule's author leaving. Rules without reasons age into folklore.
282. **Bright lines and judgment zones get different grammar:** bright lines are absolute and short ("customer data never enters unapproved tools — no exceptions") · judgment zones name the factors and the decider ("client gifts: consider value, timing, and optics; over $100 or near a renewal → ask [role]"). Blending the two produces policies that are simultaneously rigid and vague.
293. **Edge cases are worked in the text:** the 3–5 real questions get answered *with the reasoning shown* ("Lounge on a delayed red-eye: yes — the reason behind the meal rule (reasonable comfort on work travel) covers it") — teaching the principle so the sixth case answers itself.
304. **The floor is the busy reader:** the one-page card carries the rules and bright lines; the full policy holds reasons, edges, and process. A policy only consultable by reading eleven pages will be consulted never; the card is the interface, per the [template-designer](../template-designer/SKILL.md) lightness law.
315. **Enforcement honesty:** the section states the actual consequence ladder and the gray-case decider — and if drafting reveals there's no appetite to enforce a rule, the rule gets cut or softened to guidance *now*. Unenforced rules teach that the whole policy is decorative; three real rules beat eleven ornamental ones.
32
33## Output Format
34
35# Policy: [domain] — v[N], owner: [role]
36
37## Why This Policy Exists
38[Two sentences — the incident/ambiguity it resolves]
39
40## The Rules (with reasons)
41[Each: the rule · — because [reason] · 🔒 bright line / ⚖️ judgment zone (factors + decider)]
42
43## Worked Edge Cases
44[The real questions, resolved with reasoning shown]
45
46## Enforcement (honestly)
47[The consequence ladder as it will actually run · gray cases → [decider] · review cadence]
48
49## The One-Page Card
50[Rules + bright lines only — the consultable interface]
51
52## Quality Checks
53
54- [ ] Every rule states its reason
55- [ ] Bright lines and judgment zones are visually and grammatically distinct
56- [ ] The worked cases are the team's real questions, reasoning shown
57- [ ] Enforcement describes reality — no rule survives that nobody will enforce
58- [ ] The card fits a page and answers the common cases alone
59
60## Anti-Patterns
61
62- [ ] Do not draft in legalese — unparsed policies govern nothing; folklore fills the gap
63- [ ] Do not write "use good judgment" as a rule — name the factors and the decider or it's not policy
64- [ ] Do not skip the edge cases — they're the questions the policy exists to answer
65- [ ] Do not keep unenforceable rules for tone — each one discounts the enforceable ones
66- [ ] Do not publish without an owner and review date — orphan policies drift into fiction within a year