plain-prose

Applies plain-English writing rules and removes LLM-voice patterns from human-facing text.

1|Updated May 6, 2026
One-click install
npx skills add https://github.com/diy-accounting-uk/submit.diyaccounting.co.uk --skill plain-prose-diy-accounting-uk
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: plain-prose
Source: https://github.com/diy-accounting-uk/submit.diyaccounting.co.uk/tree/main/.claude/skills/plain-prose
Command: npx skills add https://github.com/diy-accounting-uk/submit.diyaccounting.co.uk --skill plain-prose-diy-accounting-uk

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Drafts of docs, site copy, and chat replies often read as machine-generated: long sentences, em-dash sprinkling, hype adjectives, and negation-contrast phrasing. This Skill provides a standing style guide that rewrites such text into plain, human prose and keeps supporting evidence out of reader-facing pages. ## Core Features & Use Cases - Plain English base rules: Enforces short sentences (15-20 words), active voice, everyday words, and a substitution table for jargon (e.g. "utilise" to "use"). - LLM-voice tell removal: Cuts em-dash stacking, "not X, it's Y" constructions, announced-honesty preambles, colon reveals, anthropomorphized tools, and hype words like "seamless" or "robust". - Reader-facing surface structure: Leads README and site pages with the benefit and headline fact, then links out to REPORT_.md, RUNBOOK_.md, and PLAN_*.md files for the proof. - Use Case: Before publishing a new README section or runbook, run the five-step edit workflow to split long sentences, remove machine-voice tells, and check that methodology does not appear before the benefit. ## Quick Start Review this draft paragraph using the plain-prose rules and rewrite it in plain, human prose.

Frequently Asked Questions about plain-prose

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I make AI-generated writing sound more human?▼

Apply plain-English rules first: short sentences of 15-20 words, active voice, and everyday words. Then cut machine-voice tells like em-dash stacking, "not X, it's Y" phrasing, announced-honesty preambles, and hype adjectives such as "seamless" or "robust".

What are the common LLM writing tells to avoid?▼

Common tells include em-dash sprinkling, "not only X but also Y" constructions, colon reveals, anthropomorphizing tools, rule-of-three padding, and filler phrases like "it's worth noting" or "delve". State what the thing is in a plain declarative sentence instead.

How long should sentences be in plain English writing?▼

Aim for an average of 15-20 words per sentence, mixing short and longer ones. Split any sentence running past roughly 25 words, and keep one idea per sentence rather than joining clauses with dashes or semicolons.

Should a README include full proof and methodology details?▼

No. Reader-facing surfaces like README files and site pages should lead with the benefit and one headline fact, then link out to separate report, runbook, or plan documents for the full evidence. The claim lives in the window and the proof lives in the back room.

When should I not use this plain-prose style guide?▼

The guide targets human-facing prose, so it does not apply to code syntax, API schemas, or log formats. It also permits rare deliberate em-dashes and factual "NOT" scope sections, so it is not a blanket ban on every flagged pattern.