writing-skills 0.4.0 → 0.5.0

package/.claude-plugin/marketplace.json

@@ -5,14 +5,14 @@
     "url": "https://github.com/surendranb"
   },
   "metadata": {
-    "description": "14 production writing-style skills and character frameworks for AI agents with dynamic GitHub skill loading.",
-    "version": "0.4.0"
+    "description": "15 production writing-style skills and character frameworks for AI agents with dynamic GitHub skill loading.",
+    "version": "0.5.0"
   },
   "plugins": [
     {
       "name": "writing-skills",
       "source": "./",
-      "description": "14 production writing-style skills and character frameworks for AI agents with dynamic GitHub skill loading.",
+      "description": "15 production writing-style skills and character frameworks for AI agents with dynamic GitHub skill loading.",
       "strict": false
     }
   ]

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "writing-skills",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "description": "14 production writing-style skills and character frameworks for AI agents with dynamic GitHub skill loading.",
   "author": {
     "name": "Surendran B",

package/README.md

@@ -4,7 +4,7 @@
 
 # writing-skills
 
-**14 writing-style skills for AI agents: 7 measurable frameworks, 7 character voices.**
+**15 writing-style skills for AI agents: 8 measurable frameworks, 7 character voices.**
 Plain `SKILL.md` files. Works in any agent that reads skills
 (Claude Code, opencode, Codex, Cursor, Kiro, Gemini).
 
@@ -54,6 +54,7 @@ Every skill ends with a `Verify` checklist the agent must pass before it deliver
 | `asd-ste100` | Simplified Technical English. One instruction per sentence, no idioms. |
 | `google-dev-docs` | Google style. Active voice, present tense, verb-first headings. |
 | `journalism-ap` | AP Stylebook. Attribution, number rules, zero editorializing. |
+| `scott-adams` | Simplicity-is-persuasion. Curiosity-hook openers, ≤15-word sentences, prune "very/really". |
 
 ### Voices — characters, rate-limited against caricature
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "writing-skills",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "description": "Procedural writing-style skills for agents — measurable standards, voice craft, and character voices as SKILL.md instructions.",
   "license": "MIT",
   "repository": {

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
   "name": "writing-skills",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "description": "Procedural writing-style skills for agents \u2014 measurable standards, voice craft, and character voices as SKILL.md instructions.",
   "author": "Surendran",
   "homepage": "https://github.com/surendranb/writing-skills",

package/skills/asd-ste100/SKILL.md

@@ -1,52 +1,55 @@
 ---
 name: asd-ste100
-description: Write controlled, unambiguous technical prose per ASD-STE100 Simplified Technical English — the aerospace standard for maintenance manuals and technical documentation. Use when the user writes technical procedures, instructions, warnings, manuals, or any text where every reader (including non-native English speakers) must understand exactly one meaning.
+description: Use when writing technical procedures, instructions, warnings, maintenance manuals, or any text where every reader including non-native English speakers must understand exactly one meaning.
+compatibility: Requires standard Markdown parser and agent context
 ---
 
-# ASD-STE100 (Simplified Technical English)
+# ASD-STE100 Simplified Technical English
 
-One sentence, one instruction, one meaning. The standard for safety-critical documentation.
+Control vocabulary and syntax to eliminate ambiguity in technical documentation.
 
 ## The core rule
 
-**Every sentence has exactly one interpretation — because every sentence has one instruction, one approved word, and no synonyms.** STE-100 trades elegance for certainty: writers cannot choose between "start", "begin", "activate", "commence" — they use the approved word and only the approved word.
+**One word, one meaning. Imperative voice for instructions. Maximum 20 words per sentence.**
 
-Workflow: `state the objective` → `write instructions as short imperative sentences` → `use only approved vocabulary, one meaning per word` → `separate warnings from actions` → `run the verification checklist`.
+Workflow: `choose approved STE vocabulary` → `write imperative command` → `restrict sentence length to 20 words max` → `verify zero ambiguity`.
 
 ## Mechanics
 
-1. **One instruction per sentence.** "Open the valve. Wait 30 seconds. Close the valve." Never chain ("open the valve, then after waiting, close it").
-2. **Sentences ≤ 20 words** (procedures); ≤ 25 for descriptions.
-3. **Imperative mood for procedures.** "Remove the cover." — direct commands only.
-4. **One meaning per word, always.** Approved technical terms mean one thing; never use a synonym in the same document. Pick "remove" and never "detach/unfasten/take off" for the same object.
-5. **Active voice, present tense.** "The pump moves the fluid" not "the fluid is moved by the pump".
-6. **No verbs derived from nouns** (make a decision → decide; perform an inspection → inspect).
-7. **Articles always required.** "The valve", "an adapter" — never bare "valve" where grammar allows dropping the article.
-8. **Warnings are exact and separate.** "WARNING: HIGH PRESSURE. Do not open the valve while the system is pressurized." Structure: warning keyword, hazard, consequence, instruction.
-9. **Numbers and units written exactly.** "6 mm", "100 °C" — spelled-out numbers only for 1–9 where the approved dictionary says so.
-10. **No idioms, no metaphor, no humor.** "It's the heart of the system" is banned. The reader may not share the culture.
+1. **Approved vocabulary.** Use only words from the ASD-STE100 dictionary or approved technical nouns.
+2. **Imperative commands.** Start steps with an action verb ("Remove the bolt", not "You should remove the bolt").
+3. **Word count limits.** Maximum 20 words for procedural sentences; maximum 25 words for descriptive sentences.
+4. **No noun clusters.** Maximum of 3 nouns in a sequence (e.g. use "valve control switch" instead of "engine fuel system valve control switch").
+5. **Present tense.** Describe current states in present tense; avoid future tense ("The light is on" not "The light will turn on").
+6. **No gerunds in titles.** Use simple nouns or infinitives for headings.
+7. **Explicit conditions.** Place conditional clauses at the beginning of the sentence ("If the pressure is low, replace the filter").
+8. **Approved modifiers.** Avoid vague adjectives like "extreme", "rapid", or "normal" unless quantified.
 
 ## Verify
 
-- Every sentence ≤ 20 words and contains exactly one instruction
-- Every sentence in active voice (no "was/were + past participle")
-- No synonyms for the same object/action anywhere in the document
-- No noun-verb constructions ("perform a test" → "test")
-- No idioms or metaphors (search for "like", "as if", figurative phrases)
-- Warnings follow the keyword-hazard-consequence-instruction shape
+- Sentences do not exceed 20 words for procedures
+- Every instruction starts with an active imperative verb
+- No noun clusters exceeding 3 words
+- All technical terms conform to standard dictionary definitions
+- Zero ambiguous pronouns (replace "it" or "they" with specific nouns)
 
 ## Do not
 
-- Chain instructions with "then/after/while" — split them
-- Use unapproved vocabulary for any safety-critical step
-- Assume a shared cultural or technical background with the reader
+- Use words with multiple meanings (e.g., use "fast" or "secure", avoid "fixed")
+- Write conditional clauses after the main action
+- Use contractions or colloquialisms
+- Use passive voice in maintenance steps
+
+## References
+
+For the enforceable limits (sentence/paragraph/noun-cluster caps), safety-text structure (WARNING/CAUTION/NOTE), and punctuation rules, read `references/REFERENCE.md` when a draft is borderline or needs verification — load on demand, not upfront.
 
 ## Example transformations
 
-**Before:** "Prior to commencing the disassembly process, ensure that the pressure has been completely relieved from the system, as failure to do so may result in the sudden and dangerous release of pressurized fluid which could cause serious injury or even death."
+**Before:** "It is recommended that technicians should carefully inspect the aforementioned component assembly for any potential signs of wear prior to system operation."
 
-**After:** "WARNING: HIGH PRESSURE. The fluid in the system is under pressure. If you open the system while it is pressurized, the fluid can spray out and cause injury. 1. Turn the system OFF. 2. Wait until the pressure gauge shows zero. 3. Open the drain valve."
+**After:** "Inspect the component assembly for wear before you operate the system."
 
-**Before:** "When you've finished, it's good practice to give the unit a quick check for any loose connections and make sure everything is nice and snug."
+**Before:** "When the pressure drops too low, you might want to consider resetting the main system valve."
 
-**After:** "Check all connections. Tighten any loose connection. Make sure each connection is secure."
+**After:** "If the pressure is low, reset the main valve."

package/skills/asd-ste100/references/REFERENCE.md

@@ -0,0 +1,36 @@
+# ASD-STE100 Reference — The Rules Behind the Skill
+
+Read this when you need the precise limits and rule structure of the standard, or when a draft is borderline. Sources: asd-ste100.org (official), the ASD-STE100 term-checker rules, and the standard's published rule summaries. The standard is 53 writing rules in 9 sections plus a controlled dictionary; the dictionary itself is copyright ASD and is not reproduced here — apply its principle (plainest word, one meaning) rather than checking against the official word list.
+
+## Verified limits (the numbers you can enforce)
+- Instructions (procedures): maximum 20 words per sentence.
+- Descriptive text: maximum 25 words per sentence.
+- Maximum 6 sentences per paragraph; one topic per paragraph.
+- Maximum 3 words in a noun cluster: "the hydraulic pump shaft" — not "the engine fuel pump drive shaft assembly".
+- One instruction per sentence. If two actions happen at the same time, they may share one sentence ("Open the valve and listen for air flow").
+
+## Word rules
+- Use approved words only with the part of speech and meaning given in the dictionary: "test" is a noun (do the test), not a verb (to test).
+- No synonyms: use "start", not "begin", "commence", or "initiate".
+- No contractions (don't, isn't) and no omitted words to shorten a sentence.
+- No idioms, slang, or jargon.
+- No phrasal verbs (use "remove" not "take off").
+- Technical nouns and technical verbs are allowed as project terms (your organization's approved additions to the dictionary).
+
+## Sentence structure
+- Write instructions in the imperative: "Close the valve." Not "The valve should be closed."
+- Start an instruction with a clear command or condition: "When the pressure drops, close the valve."
+- If an instruction starts with a descriptive statement, separate it from the command with a comma.
+- Active voice. Passive is allowed only in descriptive text when the agent is unknown.
+- No complex verb constructions (no auxiliary-verb stacks: "has been being checked").
+
+## Safety text (WARNING, CAUTION, NOTE)
+- WARNING: risk of injury or death. CAUTION: risk of damage to equipment. NOTE: information only, never an instruction.
+- Start a safety instruction with the command or condition, then give the consequence: "Close the valve. This prevents fuel spillage."
+- Notes give information only — they never contain instructions.
+
+## Punctuation
+- All standard English punctuation except the semicolon.
+- Hyphens connect closely related words; hyphenated words count as one word for the sentence limit.
+- Parentheses are allowed; text in parentheses counts as one word.
+- In a vertical list, a colon has the same effect on the word count as a full stop.

package/skills/google-dev-docs/SKILL.md

@@ -1,52 +1,55 @@
 ---
 name: google-dev-docs
-description: Write developer documentation to the Google developer documentation style guide — active voice, second person, present tense, task-oriented headings. Use when the user writes API docs, READMEs, tutorials, reference guides, error messages, or any technical content for developers.
+description: Use when writing API documentation, READMEs, tutorials, reference guides, error messages, or any technical content for developers using the Google developer documentation style guide.
+compatibility: Requires standard Markdown parser and agent context
 ---
 
-# Google Developer Docs
+# Google Developer Documentation Style
 
-Write for the developer with a question and a deadline. Clarity over cleverness, always.
+Write precise, task-oriented technical documentation with second-person address and active voice.
 
 ## The core rule
 
-**Answer the reader's question in the fewest steps, in active voice, addressed to "you", in present tense.** Developer docs are read at the moment of need: an error on screen, a deadline, a broken build. Every paragraph must justify itself against that reader.
+**Task-oriented headings, present tense, second person ("you"), active voice.**
 
-Workflow: `name the task in the heading (verb-first)` → `state what the reader will accomplish` → `give the steps in order, one action each` → `show a real example` → `note the failure modes`.
+Workflow: `state user goal in title` → `prerequisites first` → `numbered steps with concrete code examples` → `verification step`.
 
 ## Mechanics
 
-1. **Active voice always.** "The API returns a list" not "a list is returned by the API".
-2. **Address the reader as "you".** "Install the SDK" not "one installs the SDK" and never "we".
-3. **Present tense.** "The server listens on port 8080" not "will listen".
-4. **Task-oriented, verb-first headings.** "Authenticate a user" not "Authentication"; "Configure the proxy" not "Proxy configuration".
-5. **One action per step, numbered.** Steps are imperative, complete, and checkable.
-6. **Examples are real and copyable.** Include actual code/output the reader can run; never pseudo-examples for the happy path only — show the common error too.
-7. **Explain the "why" once, briefly.** One sentence of rationale per non-obvious decision; then move on.
-8. **Consistent terminology.** Pick one term per concept ("request", never "call/invoke/query" interchangeably). Include a definitions list where terms collide.
-9. **Plain language layer.** Even technical prose obeys plain-language rules: short sentences, no marketing, no "effortlessly/simply/seamlessly".
-10. **Error messages are docs too.** Say what failed, why, and how to fix: "Error: port 8080 is in use. Stop the process using it, or set PORT to a free port."
+1. **Second person.** Address the developer directly as "you"; avoid "we", "us", or third-person generalities.
+2. **Present tense.** Describe current system behavior in present tense ("Returns a 200 OK status", not "Will return").
+3. **Task-oriented headings.** Start headings with gerunds or action verbs ("Configuring authentication", not "Authentication overview").
+4. **Active voice.** "The server processes the request" rather than "The request is processed by the server".
+5. **Code blocks with context.** Every code snippet must include necessary imports, setup, and expected output.
+6. **Pronoun clarity.** Ensure "this", "that", and "it" clearly point to a preceding noun.
+7. **Consistent terminology.** Use identical terms across guides, API references, and UI labels.
+8. **Concise error messages.** Explain what went wrong and how to fix it immediately.
 
 ## Verify
 
-- Every heading starts with a verb (or a noun that is the reader's search term)
-- No passive voice (search "was/were/are + past participle")
-- No "we" referring to your org; no marketing adjectives (simple, easy, powerful, robust)
-- Every step is imperative, numbered, and results in something checkable
-- Present tense throughout (search "will ", "would ")
-- At least one runnable example per tutorial section
+- Headings use gerunds or action verbs describing tasks
+- Sentences consistently use second person ("you")
+- Code snippets are complete, syntactically valid, and tested
+- Active voice used throughout instructions
+- Present tense used for API descriptions
 
 ## Do not
 
-- Write "getting started" without stating prerequisites up front
-- Hide errors — document what breaks and why
-- Use the reader's learning time for product marketing
+- Use future tense for deterministic software behavior ("The method will return...")
+- Leave code snippets without imports or setup context
+- Use vague filler phrases ("Simply run...", "Just configure...")
+- Mix second person and first person within the same tutorial
+
+## References
+
+For exact mechanical rules (numbers, percentages, ordinals, ranges, abbreviations, units), read `references/REFERENCE.md` when a draft contains any of these — load on demand, not upfront.
 
 ## Example transformations
 
-**Before:** "In order to make use of the API, it is necessary that an API key be obtained. This can be done by navigating to the dashboard, where the key will be displayed once a project has been created. The key should then be included in the Authorization header of every request that will be made."
+**Before:** "In order to initialize our SDK, users are required to first invoke the setup method, after which time you will be able to make API requests successfully."
 
-**After:** "1. Create a project in the dashboard. 2. Copy your API key. 3. Send it with every request: Authorization: Bearer YOUR_KEY. All requests must include this header; without it, the API returns 401."
+**After:** "To initialize the SDK, call `setup()`. Once initialized, you can make API requests."
 
-**Before:** "The system is designed to facilitate seamless integration of third-party services through a robust and flexible webhook architecture."
+**Before:** "Simply add the configuration dictionary to your project and you're good to go!"
 
-**After:** "Webhooks notify you when an event happens (for example, a payment succeeds). Add your webhook URL to the dashboard, and we'll POST the event payload to it within 2 seconds."
+**After:** "Add the configuration dictionary to your project configuration file."

package/skills/google-dev-docs/references/REFERENCE.md

@@ -0,0 +1,28 @@
+# Google Developer Documentation Style — Mechanical Rules
+
+Read this when you need exact rules for numbers, abbreviations, or units. Source: Google developer documentation style guide (developers.google.com/style).
+
+## Numbers
+- Spell out zero through nine; use numerals for 10 and above: "five minutes", "24 hours".
+- Always use numerals (even below 10) for: version numbers, technical quantities (memory, disk space, queries, usage limits), page/chapter/section/step numbers, prices, negative numbers, decimals, fractions, percentages, dimensions, measurements, and numbers in ranges.
+- Mixed sentence: numerals for all when any number exceeds 9: "The menu has 15 options but 6 are deselected."
+- Spell out a number that starts a sentence — or rearrange the sentence. A four-digit year may start a sentence.
+- Ordinals: always spell out: first, twelfth, forty-third. Never 1st, 5th.
+- Fractions: express as decimals (0.75); if words are required, hyphenate (two-fifths).
+- Percentages: numeral + % with no space: 40%. Exception: sentence-start "Forty percent of the files".
+- Ranges: hyphen with no spaces (2012-2016). Never an en dash.
+- Commas: standard American grouping, including four-digit numbers: 2,000 (never 2000).
+- Decimals: leading zero required (0.3 inches, never .3); treat decimals as plural (1.0 inches).
+
+## Abbreviations
+- Spell out on first reference, italicizing both the full term and the abbreviation: "Establish _Border Gateway Protocol_ (_BGP_) sessions."
+- Capitalize the spelled-out form only if it is a proper noun: "data manipulation language (DML)", not "Data Manipulation Language".
+- Use the abbreviation alone after first reference. If used once, include it only when the abbreviation is as common as the full term.
+- No periods in acronyms or initialisms (API, not A.P.I.).
+- Periods in shortened words (Dr., approx.) except date/time abbreviations.
+- Never i.e. or e.g. — use "that is" and "for example".
+- No internet slang: tl;dr, ymmv, RTFM.
+- Don't use abbreviations as verbs: "Use SSH to connect", not "Then ssh into your remote shell".
+- No need to spell out: AI, API, DVD, HTML, PC, RAM, REST, URL, USB, PDF/XML file formats, MB/MiB/GB/GiB units.
+- "a" vs "an" follows pronunciation of the abbreviation.
+- Don't use "10x" — write "10 times".

package/skills/gov-uk-style/SKILL.md

@@ -1,51 +1,55 @@
 ---
 name: gov-uk-style
-description: Write to the GOV.UK style guide — the gold standard of public-sector plain language — with short sentences, keyword-first headings, and ruthless simplicity. Use when the user writes public-facing content, government or civic communication, help pages, policy summaries, or wants maximum-scope readability.
+description: Use when writing public-facing content, government or civic communication, help pages, policy summaries, or content requiring maximum-scope readability according to GOV.UK standards.
+compatibility: Requires standard Markdown parser and agent context
 ---
 
 # GOV.UK Style
 
-The reader is skimming, searching, or stressed. Write so they can't miss it.
+Make complex information instantly clear, scannable, and accessible to every citizen.
 
 ## The core rule
 
-**Put the reader's keyword in the first words, the answer in the first sentence, and the content in the smallest possible space.** GOV.UK's rule of thumb: if the reader understands your first two sentences, you have done your job; everything after is detail for those who need it.
+**Start with the user's need. Sentences under 25 words, paragraphs under 5 lines, active voice, zero jargon.**
 
-Workflow: `state what the page or message is about in the title (with the real keyword)` → `answer the core question in the first paragraph` → `chunk everything else under keyword-first headings` → `cut until it hurts, then cut once more`.
+Workflow: `state user goal immediately` → `bullet points for eligibility or steps` → `plain active verbs` → `delete preamble`.
 
 ## Mechanics
 
-1. **Sentences ≤ 25 words; paragraphs ≤ 5 sentences.** Long sentences become two.
-2. **Keyword-first headings.** "Renew your passport" not "Passport renewal process". The words the user would type are the words in the heading.
-3. **First paragraph answers the core question.** No scene-setting, no "in today's fast-paced world".
-4. **The user's goal, not your department's structure.** Organize by reader task, never by org chart or legal document order.
-5. **Specific over general.** "You must apply within 30 days" not "applications must be submitted within a specified timeframe".
-6. **Address the reader as "you".** "You can appeal if you disagree with the decision."
-7. **Common words; explain unavoidable ones on first use.** No Latinates, no "utilise/pursuant/henceforth".
-8. **Use lists.** Bullets and numbered steps beat paragraphs for anything a reader must scan or do.
-9. **No legal or marketing register.** Not "we are delighted to announce"; not "the provisions of Section 4(2) shall apply" without translation.
-10. **Cut words, not meaning.** "In order to" → "to". "A number of" → "some". "At this point in time" → "now".
+1. **User need first.** Every page starts with what the user can do or find.
+2. **Short sentences.** Maximum 25 words; vary length for rhythm.
+3. **Active voice.** "You must apply online" not "Applications must be submitted".
+4. **No jargon.** Replace bureaucratic terms with plain English (e.g. "pay" instead of "remuneration").
+5. **Bulleted lists for steps.** Use bullet points for conditions, steps, or requirements instead of dense paragraphs.
+6. **Bold sparingly.** Use bold only for critical warnings or key criteria.
+7. **No Latin or Latinisms.** Use "for example" instead of "e.g." and "that is" instead of "i.e.".
+8. **Anchor links.** Clear, descriptive link text that explains where the link goes.
 
 ## Verify
 
-- Longest sentence ≤ 25 words; longest paragraph ≤ 5 sentences
-- First paragraph answers the page's core question
-- Headings contain the user's likely search keywords
-- Zero words from the ban list (utilise, facilitate, commence, henceforth, aforementioned, in order to, in excess of, at this point in time)
-- Read a heading alone: does it tell the reader what to do?
+- First sentence directly addresses the user's primary intent
+- Sentences average under 20 words
+- Bullet points used for lists of 3 or more items
+- Zero Latin abbreviations (e.g., i.e., et al.)
+- Active voice used throughout
 
 ## Do not
 
-- Write for the institution instead of the reader
-- Nest information under vague headings ("Introduction", "General information", "Additional considerations")
-- Let policy complexity leak into sentence complexity
+- Use introductory throat-clearing ("It is important to note that...")
+- Assume prior knowledge of government processes
+- Write paragraphs longer than 5 lines
+- Use passive voice for user instructions
+
+## References
+
+For exact mechanical rules (numbers, dates, times, money, measurements, links, abbreviations, punctuation), read `references/REFERENCE.md` when a draft includes any of these — load on demand, not upfront.
 
 ## Example transformations
 
-**Before:** "Introduction: The Authority wishes to bring to the attention of all residents the forthcoming changes to waste collection arrangements, which will take effect from the 1st of April. It is important that residents familiarize themselves with the new schedule in order to avoid any disruption to their weekly collections."
+**Before:** "In the event that an individual wishes to make an application for financial assistance, it is required that they submit documentation demonstrating eligibility prior to the commencement of the review process."
 
-**After:** "Waste collection days are changing. From 1 April, put your bins out on a different day. Check your new collection day with your postcode. If your collection day has changed, you'll get a letter this month."
+**After:** "You must send your eligibility documents before we review your financial aid application."
 
-**Before:** "Should applicants fail to provide the requisite documentation within the stipulated period, their application shall be deemed incomplete and shall not be considered further."
+**Before:** "Users should note that e.g. tax returns must be filed by January 31st i.e. the end of the month."
 
-**After:** "You must send us your documents within 30 days. If you do not, we will close your application."
+**After:** "You must file your tax return by 31 January."

package/skills/gov-uk-style/references/REFERENCE.md

@@ -0,0 +1,64 @@
+# GOV.UK Style Reference — Mechanical Rules
+
+Read this when you need exact formatting rules for numbers, dates, times, money, links, or abbreviations. Source: GOV.UK A to Z style guide (gov.uk/guidance/style-guide).
+
+## Numbers
+- Use "one" in prose unless it is a step, list point, or a numeral makes more sense.
+- Use numerals for everything else, including 2 to 9: "You will see 5 signs."
+- Spell out a number that starts a sentence (except in titles/subheadings).
+- Comma for clarity over 999: 9,000.
+- Fractions in words are hyphenated: two-thirds. Decimals are numerals: 0.5 (never .5), 0.75.
+- Percentages: use the % sign: 50%.
+- Negative numbers use the minus sign: –6.
+- Ordinals: spell out first to ninth, then 10th, 11th onward.
+- Ranges: use "to", never hyphens: "500 to 900", "49 to 53 Cherry Street".
+- File sizes: KB under 1MB, MB over 1MB, up to 2 decimal places.
+
+## Dates
+- Day Month Year, no comma between month and year: 4 June 2017.
+- Truncate months (Jan, Feb) only in tables or publication titles.
+- Ranges use "to": tax year 2011 to 2012.
+- Deadlines: "on or before 6 September 2025".
+
+## Times
+- 5:30pm (never 1730hrs, never 17:30).
+- midnight (not 00:00), midday (not 12 noon, noon, or 12pm).
+- Ranges use "to": 10am to 11am.
+- Use "11:59pm" when a single end-of-day time must be unambiguous.
+
+## Money
+- £ symbol with no space: £75.
+- No decimals unless pence included: £75.50 but not £75.00.
+- Write pence in full: "calls will cost 4 pence per minute".
+- Use million/billion in full: £138 million. Never abbreviate to m or b.
+- Amounts under £1 million/billion: use the smaller unit (£200,000), unless in a sequence with larger amounts.
+
+## Measurements
+- Numeral + unit with no space: 3,500kg.
+- grams (never grammes). Celsius: 37°C.
+- Multi-word units: spell out first use with abbreviation, then abbreviate: kilometres per hour (km/h).
+
+## Links
+- Front-load link text with the relevant term; make it active and specific.
+- Link to online services first, offer offline alternatives afterwards.
+- Never "click here" or bare URLs as link text.
+
+## Abbreviations and acronyms
+- Explain in full on first use, then use initials: Personal Independence Payment (PIP) becomes PIP.
+- No full stops in abbreviations: BBC, not B.B.C.
+- No need to explain well-known ones: BBC, EU, GP, HM, MOT, MP, NHS, PAYE, TV, UK, URL, USA, VAT, VPN, and file types (JPG, PDF, PNG).
+
+## Punctuation and formatting
+- Quotes: single quote marks for quotations, individual words ('Submit' button), and publication titles.
+- Bullets: no semicolons inside, no full stop after the last bullet.
+- Numbered steps end with a full stop (each is a complete sentence).
+- Hyphens: only where confusion would result without one. Use "to" for ranges, never hyphens.
+- Maths: one space each side of + – × ÷ and =; no space in ratios (5:12).
+- References section: no italics, single quotes around titles, "and others" not "et al", no full stops after initials.
+- Page titles: 65 characters or less, no dashes, slashes, question marks, or trailing full stops.
+
+## Words to avoid
+- "in order to" (just "to")
+- "hub", "portal", "one-stop shop" (use "website" or "service")
+- "ring fencing" (use "separate")
+- "devolved administrations" (use "devolved governments")

package/skills/scott-adams/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: scott-adams
+description: Use when the user wants to simplify prose, prune extra words, craft high-curiosity opening hooks, write punchy short sentences, and structure ideas for maximum human brain comprehension based on Scott Adams' famous business writing method.
+compatibility: Requires standard Markdown parser and agent context
+---
+
+# Scott Adams' Business Writing Method
+
+Simplicity is persuasion. Prune unnecessary words, hook readers instantly, and write short sentences matched to how human brains process ideas.
+
+## The core rule
+
+**Simplicity equals persuasion. Cut extra words, write a high-curiosity opening hook, keep sentences short, and put the actor before the action.**
+
+Workflow: `craft a high-curiosity hook` → `prune all filler and adverbs` → `write short sentences (one thought per sentence)` → `order subject before action`.
+
+## Mechanics
+
+1. **Prune extra words.** Delete filler words (e.g., "very", "really", "quite"). If removing a word doesn't change the meaning, delete it.
+2. **Humor equals precise word choice.** Use specific, punchy verbs and nouns instead of generic verbs modified by adverbs (e.g., "swill" instead of "drink a lot").
+3. **The curiosity hook.** The first sentence creates an information gap: the reader knows something valuable is coming but cannot see it, so they must read on to close the gap. Adams' own opener did this: "I went from being a bad writer to a good writer after taking a one-day course in 'business writing.'" (Which course? What did it teach?) Build the gap by promising a payoff, stating a surprising claim, or ending the sentence just before the answer. Adams rewrote that first sentence "a dozen times" until it made the reader curious. Test: if the reader can stop after sentence one, it is not a hook.
+4. **One thought per sentence.** Keep sentences short. Never bundle multiple complex ideas into a single sentence. Readers comprehend simpler chunks faster.
+5. **Actor before action.** Sequence sentences so the subject (actor) appears before the verb (action). Human brains process "the boy hit the ball" faster than "the ball was hit by the boy."
+6. **No complex nesting.** Avoid subordinate clauses that delay the core subject-verb relationship.
+
+## Verify
+
+- First sentence opens an information gap — reader cannot stop after it
+- Zero unnecessary filler words or intensifiers ("very", "really")
+- Sentences average under 15 words and contain only one thought
+- Subject precedes the verb in active, direct voice
+- No complex or passive sentence constructions
+
+## Do not
+
+- Use passive voice ("was hit by") when active voice ("hit") works
+- Pack multiple thoughts or dependent clauses into a single long sentence
+- Rely on adverbs to add flavor when a stronger single noun or verb exists
+- Settle for the first draft of an opening sentence
+
+## Example transformations
+
+**Before:** "It is very important to note that the team was quite successful in implementing the new features after they were thoroughly tested."
+
+**After:** "The team shipped the new features."
+
+**Before:** "The data was analyzed by the analysts very carefully, and it appeared that sales were declining significantly."
+
+**After:** "Sales dropped 20%."
+
+---
+
+Source: Scott Adams, "The Day You Became A Better Writer" (2007), archived at https://web.archive.org/web/20240302003157/https://dilbertblog.typepad.com/the_dilbert_blog/2007/06/the_day_you_bec.html — the original Typepad post was taken offline when Typepad shut down on 30 September 2025.