plain-prose

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

Updated Aug 4, 2026
One-click install
npx skills add https://github.com/polycode-public/the-mechanical-code-talker --skill plain-prose-polycode-public
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: plain-prose
Source: https://github.com/polycode-public/the-mechanical-code-talker/tree/main/.claude/skills/plain-prose
Command: npx skills add https://github.com/polycode-public/the-mechanical-code-talker --skill plain-prose-polycode-public

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Drafts of docs, READMEs, site copy, and chat replies often carry the stock LLM writing voice — em-dash sprinkling, negation-contrast phrasing, hype adjectives, and announced-honesty preambles — which reads as machine-made and undercuts reader trust. This Skill provides a standing style guide that catches those tells and enforces plain, direct prose. ## Core Features & Use Cases - Plain English base rules: Enforces short sentences (15–20 words), active voice, everyday words, and a substitution table for bureaucratic phrasing, based on the Plain English Campaign's guidelines. - LLM-voice tell detection: Lists specific machine-voice fingerprints to cut, including em-dash overuse, "not X, it's Y" constructions, colon reveals, anthropomorphized tools, and rule-of-three padding. - Reader-surface structure rules: Separates claims from proof — homepage and README lead with the benefit and link out to benchmark write-ups for full evidence. - Use Case: After drafting a new section of a README or a benchmark write-up, run the editing workflow to split long sentences, strip filler, and verify the benefit appears before the methodology. ## Quick Start Review this README draft against the plain-prose rules and rewrite any sentences that carry LLM-voice tells.

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 documentation sound more human?▼

Apply plain-English rules: keep sentences at 15–20 words, use active voice and everyday words, and cut filler openers. Then remove LLM-voice tells like em-dash sprinkling, "not X, it's Y" phrasing, and hype adjectives such as "powerful" or "seamless".

What are the common tells of LLM-generated writing?▼

Common tells include em-dashes bolting clauses together, negation-contrast constructions ("not X but Y"), announced-honesty preambles like "to be clear", dramatic colon reveals, anthropomorphized tools, and rule-of-three padding. This Skill lists each tell with its fix.

How should a README balance claims and supporting evidence?▼

Lead with what the product does and the benefit to the reader, then state the headline result in one sentence with its key number and condition. Link out to full benchmark write-ups for tables, methodology, and caveats instead of reproducing them on the landing page.

When should I not use this writing style guide?▼

The guide targets human-facing prose, so it does not apply to code, API schemas, log output, or machine-readable formats. It also permits deliberate exceptions, such as an intentionally framed narrative device that the project has already established.

Does this style guide apply to chat responses and code comments?▼

Yes. The scope covers everything written for a human reader: docs, homepage copy, benchmark reports, code comments, and the assistant's own chat replies. The same sentence-length, active-voice, and tell-cutting rules apply across all of them.