Plainly

Plainly

Outcome

Produce prose the reader can use on the first pass. Name the actor. Put the answer or the task first. Preserve facts, code, UI labels, product names, and the author's useful voice.

Authority

1. The user's explicit request and the destination's requirements.
2. Facts, quotations, code, filenames, API names, UI labels, and required structure in the source.
3. Project style, then this skill.
4. Live Google Developer Documentation Style Guide pages only for a specialized question this skill does not cover.

Depart from a guideline when the result is clearer for the actual reader. Stay consistent after that choice.

Dialect for this copy of the skill: Plainly (Google + anti-slop). Apply Google-derived rules AND the anti-slop appendix. Prefer the shortest accurate word.

Write or revise

1. Identify the reader, the goal, and whether you are drafting, revising, or auditing.
2. Mark what must not drift: facts, hedges (can, might, should, will as obligation), quotations, technical tokens, links.
3. Lead with the result or the purpose. One idea per paragraph. Critical information first.
4. Use you, active voice, and present tense. Use imperatives for steps.
5. Put the condition before the instruction it controls.
6. Prefer short familiar words. One term per concept. Define jargon on first use.
7. Vary sentence rhythm. Short is good; identical staccato is not. Contractions are fine.
8. Remove throat-clearing, pre-announcements, brochure words, idioms, and fake certainty.
9. Structure for scanning: sentence-case headings, numbered lists for sequences, bullets for parallel items, descriptive links, UI labels in bold.
10. Stop when the page is clear. Do not keep polishing lines that already work.

Do not

• Add facts, praise, urgency, or product claims.
• Change modality (might to will) to satisfy tense preference.
• Replace code, commands, filenames, API names, UI labels, or quotations with "clearer" synonyms.
• Rewrite when the user asked for an audit. Report findings in priority order with bounded examples.
• Flatten every sentence into the same length. Do not make prose childish.
• Force this style onto dialogue, fiction, legal language, or a deliberately personal voice.

Anti-slop appendix

Delete these on sight unless they are a quotation or a required term:

• Openers: I'd be happy to, Certainly!, Great question, As an AI, Let's dive in, Let's delve, Without further ado
• Wrappers: It's important to note, It's worth noting, It should be noted, Needless to say, Rest assured
• Brochure: robust, seamless, cutting-edge, groundbreaking, game-changer, unlock the potential, empower, foster, harness, leverage, utilize, tapestry, landscape of, pivotal, multifaceted, holistic, synergy, paradigm, supercharge, revolutionize, in today's rapidly evolving
• False ease: simply, just click, it's easy, please note
• Padding: in order to → to; due to the fact that → because; in this guide we will → start the task

For the full tell list, read references/appendix.md.

Google-derived core

• Be conversational without being frivolous.
• Don't pre-announce. Don't write "this document will cover".
• Second person. Active voice. Present tense for current behavior.
• Put conditions before instructions.
• No please in instructions. No simply / just / easy.
• Sentence case headings. Numbered lists for sequences. Serial comma.
• Write for a global audience: no idioms, sports metaphors, or slang.
• UI elements in bold. Descriptive link text. Alt text on images.

House banned words

• (none)

Validate before you return

• The opening answers the reader's question.
• Every instruction names or clearly implies the actor.
• Conditions precede actions.
• Pronouns have referents.
• Claims match the source. Technical tokens are unchanged.
• A global reader can understand it.
• It still sounds like the author when voice matters.

Attribution

Operationalizes the Google developer documentation style guide (CC BY 4.0). Independent; not endorsed by Google. Anti-slop rules are original to Plainly.