OpenAgents

Code

.agents/skills/google-developer-style/SKILL.md

main at 58e6347eeb72 · 2 KB

name: google-developer-style description: Apply the Google Developer Documentation Style Guide to user-facing docs, READMEs, AGENTS.md, and commit messages. Use when writing or reviewing prose in this repo.

Google Developer Documentation Style

Use this skill when you write or review user-facing documentation, READMEs, AGENTS.md, and commit messages for OpenAgents.

How to use this skill

Apply these rules to the text you produce or edit. When a rule would make something less clear, break the rule and stay consistent.

Voice and tone

  • Be conversational and friendly, but not frivolous or overly casual.
  • Write as a knowledgeable friend who understands what the developer wants to do.
  • Avoid jargon, buzzwords, clichés, metaphors, ableist language, and pop-culture references.
  • Avoid exclamation marks and over-polite phrases such as "please" or "please note."
  • Avoid filler words like "simply," "just," "it's easy," or "quickly" in procedures.
  • Avoid phrasing like "let's do something" or "we" for the reader; speak to the reader with "you."

Language and grammar

  • Use active voice. Make clear who performs the action.
  • Use second person ("you") for the reader.
  • Use present tense.
  • Use standard American spelling and punctuation.
  • Put conditions before instructions, not after.
  • Use serial commas.
  • Do not use ampersands (&) as conjunctions in body text or headings.

Formatting

  • Use sentence case for all headings, titles, and navigation.
  • Use code font for code, filenames, class names, method names, HTTP status codes, placeholders, and user input.
  • Use bold for UI elements and run-in headings.
  • Use italics sparingly, mainly when introducing or defining terms.
  • Underline only for link text.
  • Do not override global font styles.

Lists

  • Use numbered lists for sequences and procedures.
  • Use bulleted lists for related but unordered items.
  • Use description lists for related pairs of data.
  • Keep list items parallel in structure.

Code and links

  • Put code in text in code font.
  • Use descriptive link text. Avoid "click here" or "this page."
  • Use unambiguous date and time formatting.
  • Provide alt text for images.

Banned patterns

  • "Dude!" / "This is awesome!"
  • "It's that simple" / "It's easy" / "simply"
  • "Please" in instructions
  • "At this time" / "please note"
  • "Let's" as an imperative to the reader
  • All-caps or title-case headings

Source