dotfiles

Shell, editor and terminal configuration, the tools that go with them, and
szecret, an age-based secret manager whose store lives elsewhere.

History restarts here. What came before was not written to be read by
anyone else, and carried machine names, addresses and an encrypted secret
store; it is kept privately instead. What is left is meant to be safe on
any machine, including one whose owner is not me: see CLAUDE.md for the
rule it is written to.

15 files changed, 3506 insertions, 0 deletions

diff --git a/skills/find-skills/SKILL.md b/skills/find-skills/SKILL.md
new file mode 100644
index 0000000..114c663
--- /dev/null
+++ b/skills/find-skills/SKILL.md
@@ -0,0 +1,142 @@
+---
+name: find-skills
+description: Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
+---
+
+# Find Skills
+
+This skill helps you discover and install skills from the open agent skills ecosystem.
+
+## When to Use This Skill
+
+Use this skill when the user:
+
+- Asks "how do I do X" where X might be a common task with an existing skill
+- Says "find a skill for X" or "is there a skill for X"
+- Asks "can you do X" where X is a specialized capability
+- Expresses interest in extending agent capabilities
+- Wants to search for tools, templates, or workflows
+- Mentions they wish they had help with a specific domain (design, testing, deployment, etc.)
+
+## What is the Skills CLI?
+
+The Skills CLI (`npx skills`) is the package manager for the open agent skills ecosystem. Skills are modular packages that extend agent capabilities with specialized knowledge, workflows, and tools.
+
+**Key commands:**
+
+- `npx skills find [query]` - Search for skills interactively or by keyword
+- `npx skills add <package>` - Install a skill from GitHub or other sources
+- `npx skills check` - Check for skill updates
+- `npx skills update` - Update all installed skills
+
+**Browse skills at:** https://skills.sh/
+
+## How to Help Users Find Skills
+
+### Step 1: Understand What They Need
+
+When a user asks for help with something, identify:
+
+1. The domain (e.g., React, testing, design, deployment)
+2. The specific task (e.g., writing tests, creating animations, reviewing PRs)
+3. Whether this is a common enough task that a skill likely exists
+
+### Step 2: Check the Leaderboard First
+
+Before running a CLI search, check the [skills.sh leaderboard](https://skills.sh/) to see if a well-known skill already exists for the domain. The leaderboard ranks skills by total installs, surfacing the most popular and battle-tested options.
+
+For example, top skills for web development include:
+- `vercel-labs/agent-skills` — React, Next.js, web design (100K+ installs each)
+- `anthropics/skills` — Frontend design, document processing (100K+ installs)
+
+### Step 3: Search for Skills
+
+If the leaderboard doesn't cover the user's need, run the find command:
+
+```bash
+npx skills find [query]
+```
+
+For example:
+
+- User asks "how do I make my React app faster?" → `npx skills find react performance`
+- User asks "can you help me with PR reviews?" → `npx skills find pr review`
+- User asks "I need to create a changelog" → `npx skills find changelog`
+
+### Step 4: Verify Quality Before Recommending
+
+**Do not recommend a skill based solely on search results.** Always verify:
+
+1. **Install count** — Prefer skills with 1K+ installs. Be cautious with anything under 100.
+2. **Source reputation** — Official sources (`vercel-labs`, `anthropics`, `microsoft`) are more trustworthy than unknown authors.
+3. **GitHub stars** — Check the source repository. A skill from a repo with <100 stars should be treated with skepticism.
+
+### Step 5: Present Options to the User
+
+When you find relevant skills, present them to the user with:
+
+1. The skill name and what it does
+2. The install count and source
+3. The install command they can run
+4. A link to learn more at skills.sh
+
+Example response:
+
+```
+I found a skill that might help! The "react-best-practices" skill provides
+React and Next.js performance optimization guidelines from Vercel Engineering.
+(185K installs)
+
+To install it:
+npx skills add vercel-labs/agent-skills@react-best-practices
+
+Learn more: https://skills.sh/vercel-labs/agent-skills/react-best-practices
+```
+
+### Step 6: Offer to Install
+
+If the user wants to proceed, you can install the skill for them:
+
+```bash
+npx skills add <owner/repo@skill> -g -y
+```
+
+The `-g` flag installs globally (user-level) and `-y` skips confirmation prompts.
+
+## Common Skill Categories
+
+When searching, consider these common categories:
+
+| Category        | Example Queries                          |
+| --------------- | ---------------------------------------- |
+| Web Development | react, nextjs, typescript, css, tailwind |
+| Testing         | testing, jest, playwright, e2e           |
+| DevOps          | deploy, docker, kubernetes, ci-cd        |
+| Documentation   | docs, readme, changelog, api-docs        |
+| Code Quality    | review, lint, refactor, best-practices   |
+| Design          | ui, ux, design-system, accessibility     |
+| Productivity    | workflow, automation, git                |
+
+## Tips for Effective Searches
+
+1. **Use specific keywords**: "react testing" is better than just "testing"
+2. **Try alternative terms**: If "deploy" doesn't work, try "deployment" or "ci-cd"
+3. **Check popular sources**: Many skills come from `vercel-labs/agent-skills` or `ComposioHQ/awesome-claude-skills`
+
+## When No Skills Are Found
+
+If no relevant skills exist:
+
+1. Acknowledge that no existing skill was found
+2. Offer to help with the task directly using your general capabilities
+3. Suggest the user could create their own skill with `npx skills init`
+
+Example:
+
+```
+I searched for skills related to "xyz" but didn't find any matches.
+I can still help you with this task directly! Would you like me to proceed?
+
+If this is something you do often, you could create your own skill:
+npx skills init my-xyz-skill
+```
diff --git a/skills/google-style-guide/SKILL.md b/skills/google-style-guide/SKILL.md
new file mode 100644
index 0000000..0aacabc
--- /dev/null
+++ b/skills/google-style-guide/SKILL.md
@@ -0,0 +1,135 @@
+---
+name: google-style-guide
+description: Applies Google Developer Documentation Style Guide principles (second person, active voice, present tense, plain language, sentence case, formatting, code conventions, and word choices). Use when writing, editing, or reviewing developer documentation, READMEs, API docs, code comments, or technical communications, or when requested to follow Google style.
+license: CC-BY-4.0
+---
+
+# Google developer documentation style
+
+This skill distills the [Google developer documentation style guide](https://developers.google.com/style) into actionable rules for writing and reviewing technical documentation and developer communications.
+
+**How to use this skill:**
+- **Technical artifacts (docs, READMEs, API guides, design docs, code comments):** Follow the full style guide rules and formatting conventions below.
+- **Conversational messages / agent responses:** Apply the core principles (clarity, brevity, active voice, second person, no fluff or marketing hype) while keeping interactions natural.
+- **Reviewing existing text:** Identify deviations, quote the original snippet, explain the issue plainly, and provide the corrected version. Follow these principles in your own review comments as well.
+- **Resolving paths:** Reference files and scripts reside in this skill's directory. Resolve all paths relative to that directory.
+
+## Core rules
+
+1. **Be conversational and friendly without being frivolous.** Sound like a knowledgeable friend, not a textbook and not a hype machine. No slang, no exclamation marks, no internet abbreviations (`tl;dr`, `ymmv`).
+2. **Address the reader as *you*.** Use imperative mood for instructions ("Click Save", "Run `npm install`"). Use *we* only for the organization you belong to, *user* only for the user of software your reader is developing.
+3. **Use active voice.** Make the doer the subject: "Send a query to the service. The server sends an acknowledgment." Passive voice is acceptable only to emphasize the object ("The file is saved"), de-emphasize the actor, or when the actor is unknown.
+4. **Use present tense.** "The server sends an acknowledgment", not "will send". Reserve future tense for actions that genuinely happen later. Avoid *would*.
+5. **Write plainly and simply.** Short sentences, common words, no jargon, clichés, or culturally specific references. Write for a global audience that may read in translation.
+6. **Put conditions before instructions, and key information first.** "If your app is in one of these regions, expect latency" before the action.
+7. **Use standard American spelling and punctuation** (serial/Oxford comma included).
+8. **Be accurate and honest.** Do not exaggerate. Avoid superlatives like *best, fastest, never, always*; be careful with *ensure* and *guarantee*. Do not claim things that a future release or incident could invalidate.
+
+## Voice and tone
+
+- Aim for conversational but not formal: "This API lets you collect data about what your users like" — not "Dude! This API is totally awesome!" and not "The API documented by this page may enable the acquisition of information."
+- Skip the fluff: do not pre-announce ("In this section, we will..."), and avoid filler phrases like *please note*, *at this time*, *simply*, *it's easy*, or *quickly*.
+- Avoid figurative language and ableist metaphors ("the PC **sees** a new device" → "the PC **detects** a new device").
+- Do not overuse *please* in instructions. "To view the document, click View", not "please click View".
+- Vary sentence openings; avoid starting every sentence with "You can" or "To do".
+
+## Language and grammar essentials
+
+| Topic | Rule | Example |
+|---|---|---|
+| Articles | Always include *a/an/the* — do not drop them for brevity | "Create a VM instance", not "Create VM instance" |
+| Contractions | Use them, especially negations (*don't*, *can't*, *isn't*) — easier to read | "Don't use..." |
+| Pronouns | Clear antecedents; singular *they* for gender-neutral; no *he/she* | "If you type text in the field, the text doesn't change" (not "...it doesn't change") |
+| Tense | Present; future only for real future actions | "The file will be archived next time the backup runs" |
+| Numbers | Spell out zero–nine; numerals for 10+; spell out ordinals (*first*, not *1st*); sentence-starting numbers spelled out | "five minutes", "15 directories", "the twelfth step" |
+| Capitalization | Sentence case in titles/headings; do not capitalize unnecessarily; do not rely on caps to convey meaning | "Create an instance", not "Create an Instance" |
+| Abbreviations | Spell out on first use with acronym in parentheses, then use acronym alone; no periods in acronyms | "Google Kubernetes Engine (GKE)" |
+
+Put conditions before instructions: "If you run out of space, delete the unused files" before "Delete unused files".
+
+## Punctuation essentials
+
+- **Serial comma**: Always use the serial (Oxford) comma in lists of three or more: "zones, regions, and multi-regions".
+- **Colons**: Introduce lists only after a complete sentence ("The fields are defined as follows:", not "The fields are:").
+- **Periods**: End sentences with periods. Place periods inside quotation marks ("like this."), even when not part of the quoted material (standard American style).
+- **Hyphens**: Use for compound modifiers before a noun ("a two-day total").
+- **Dashes**: Use em dash (—) without spaces around it. Do not use an em dash where a colon or period works.
+- **Avoid**: Ellipses (…), semicolons where a period or comma works better, slashes for alternatives (write out *and* or *or*), and exclamation marks.
+
+## Formatting and organization
+
+- **Headings/titles**: Sentence case for all headings and titles. Task headings start with a bare infinitive ("Create an instance", not "Creating an instance"); concept headings are noun phrases. No links, code font, or sequence numbers in headings.
+- **Lists**: Numbered for sequential steps, bulleted for non-sequential items, definition lists for term–definition pairs. Introduce lists with a complete sentence. Keep list items parallel in structure.
+- **Links**: Descriptive link text (page title or descriptive phrase), never "click here" or a bare URL. "For more information, see X." Link to relevant destinations without opening new tabs.
+- **UI elements**: Bold visible UI labels ("click **Save**"). Do not use UI elements as verbs ("save the settings" → "click **Save**").
+- **Code in text**: Use code font (backticks) for filenames, paths, commands, class/method names, literals, and environment variables. Never inflect code as English ("send a POST request", not "POST the data"). Place a descriptive noun after the code item ("the `pg_hba.conf` file").
+- **Numbers & units**: Use a nonbreaking space between number and unit ("64 GB"). Use 12-hour clock ("3 PM", "3:45 PM"). Spell out months in dates ("January 19, 2017"); use ISO 8601 (`YYYY-MM-DD`) only for numeric-only tables/logs.
+- **Images**: Provide descriptive alt text (≤155 characters, no "Image of..."); use empty `alt=""` for decorative images. Introduce images with a complete sentence.
+- **Procedures**: Numbered steps, each starting with an imperative verb. Put location before action ("In the Google Cloud console, go to the BigQuery page"). State the goal before the action.
+- **Notices** (Note/Caution/Warning): Use sparingly. Do not stack multiple notices. Use notes only for non-critical asides.
+- **Tables**: Use for three or more related pieces of data per item. Provide a complete-sentence introduction and clear column headers. Do not use tables for layout.
+
+## Applying the style per medium
+
+- **Docs / READMEs / Design docs**: Full rules above. Structure with descriptive headings, put the most important information first, and keep paragraphs focused on a single topic (5–6 sentences maximum).
+- **Code comments**: Plain sentences explaining *why* rather than restating what the code does. Use present tense or imperative mood.
+- **Commit messages** *(developer house convention)*: Imperative, present-tense summaries ("Add retry logic", not "Added retry logic" or "Adding retry logic").
+- **Chat replies / Agent messages**: Direct and conversational. Short sentences, active voice, second person. Skip pleasantry fluff, hype, and filler phrases like "please note".
+- **Reviewing text**: Quote the original text, state the rule or issue clearly, and provide the exact revised phrasing.
+
+## Word list lookup
+
+The companion file `word-list.md` contains 587 specific term guidelines, preferred spellings, and terms to avoid.
+
+> **CRITICAL**: Do **NOT** read `word-list.md` in full with the `read` tool (it is 114 KB / 1,700 lines and exceeds tool truncation limits).
+
+To check a specific word or term:
+```bash
+# Use the helper script in the skill directory:
+"$SKILL_DIR/lookup-word.sh" "<term>"
+
+# Or search directly with grep/rg:
+grep -i -C 2 -E "(^|\*\*)$TERM(\*\*|\[|$)" "$SKILL_DIR/word-list.md"
+```
+
+## Review checklists
+
+### Quick check (chat replies & short answers)
+- [ ] Direct, conversational, and helpful without fluff, hype, or exclamation marks?
+- [ ] Active voice and second person ("you" / imperative mood for steps)?
+- [ ] Plain language with clear antecedents and no unexplained abbreviations?
+
+### Comprehensive checklist (documentation, READMEs, PRs, design docs)
+- [ ] Conversational and friendly without exclamation marks, slang, or hype?
+- [ ] Second person ("you") used throughout; imperative mood for instructions?
+- [ ] Active voice used; any passive construction justified?
+- [ ] Present tense used (except for actions that genuinely occur in the future)?
+- [ ] Plain words used; jargon avoided; abbreviations spelled out on first mention?
+- [ ] Conditions placed before instructions; key information stated first?
+- [ ] Serial (Oxford) comma used; punctuation inside quotation marks; no unnecessary semicolons/slashes/ellipses?
+- [ ] Numbers and units formatted correctly (0–9 spelled out, 10+ numerals, space before units)?
+- [ ] Sentence case used for all headings; task headings start with bare infinitives?
+- [ ] UI labels bolded; code elements backticked and never inflected as English?
+- [ ] Accurate and honest; no unsupported superlatives or excessive claims?
+- [ ] Unsure terms checked against `word-list.md` via `./lookup-word.sh <term>`?
+
+## Topic reference index
+
+For deep-dive rules on specific topics, read the individual reference files located in `reference/`:
+
+| Topic | Reference file |
+|---|---|
+| Word choice, usage, spelling ("is it *log in* or *login*?") | `word-list.md` *(use `./lookup-word.sh`)* |
+| Grammar detail (articles, possessives, plurals, prepositions, tense, pronouns, anthropomorphism) | `reference/grammar.md` |
+| Punctuation detail (colons, commas, dashes, hyphens, quotes, semicolons) | `reference/punctuation.md` |
+| Formatting detail (headings, lists, tables, notices, links, images, procedures, UI elements) | `reference/formatting.md` |
+| Code and API docs (code font rules, syntax, placeholders, API comments, Markdown/HTML) | `reference/code.md` |
+| Numbers, units, dates/times, abbreviations, trademarks, jargon, claims | `reference/technical.md` |
+| Accessibility, inclusive language, translation & global audience | `reference/accessibility.md` |
+| Documentation philosophy, prescriptive writing, timelessness, citations | `reference/strategy.md` |
+| Authoritative live guide | https://developers.google.com/style *(if web access is available)* |
+
+## Attribution and currency
+
+- **Source**: Derived from the [Google Developer Documentation Style Guide](https://developers.google.com/style), licensed under [Creative Commons Attribution 4.0 (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/).
+- **Currency**: Last verified against the live guide on 2026-08-19.
diff --git a/skills/google-style-guide/lookup-word.sh b/skills/google-style-guide/lookup-word.sh
new file mode 100755
index 0000000..11ec333
--- /dev/null
+++ b/skills/google-style-guide/lookup-word.sh
@@ -0,0 +1,38 @@
+#!/usr/bin/env bash
+# Lookup a term or usage guidance in the Google Style Guide word-list.md.
+# Usage: ./lookup-word.sh <term>
+
+set -euo pipefail
+
+if [[ $# -eq 0 ]]; then
+  echo "Usage: $(basename "$0") <term>" >&2
+  exit 1
+fi
+
+script_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+word_list="$script_dir/word-list.md"
+
+if [[ ! -f "$word_list" ]]; then
+  echo "Error: word-list.md not found at $word_list" >&2
+  exit 1
+fi
+
+pattern="$*"
+
+awk -v pat="$pattern" '
+  BEGIN { IGNORECASE=1 }
+  /^- \*\*/ {
+    if (match_entry) { print entry "\n" }
+    match_entry = 0
+    entry = $0
+    if ($0 ~ pat) match_entry = 1
+    next
+  }
+  {
+    if (entry != "") entry = entry "\n" $0
+    if ($0 ~ pat) match_entry = 1
+  }
+  END {
+    if (match_entry) print entry
+  }
+' "$word_list"
diff --git a/skills/google-style-guide/reference/accessibility.md b/skills/google-style-guide/reference/accessibility.md
new file mode 100644
index 0000000..593d871
--- /dev/null
+++ b/skills/google-style-guide/reference/accessibility.md
@@ -0,0 +1,85 @@
+# Accessibility, inclusive language, and global audience detail
+
+Detail for: accessibility, inclusive documentation, writing for translation and
+a global audience. Source: developers.google.com/style (Accessibility,
+Inclusive documentation, Writing for a global audience).
+
+## Accessible documentation
+
+~15% of the world's population has an accessibility need; accessible writing
+improves the experience for everyone. Key rules:
+
+- **Semantic structure**: use real headings (h1/h2/h3) in order; keep a logical
+  reading order; use proper list, table (caption, th, scope), and link markup.
+- **Links**: descriptive link text (see formatting.md) — screen reader users
+  often tab between links alone.
+- **Images and multimedia**: alt text for all informative images, `alt=""` for
+  decorative ones; provide transcripts or descriptions for videos; captions for
+  audio/video; don't use images for text.
+- **Keyboard access**: all interactive elements reachable and operable by
+  keyboard.
+- **Don't rely on visual-only cues**: no "the button on the left", no color as
+  the only differentiator, no "above/below/right-hand side" directions.
+- **Tables**: real table markup, not layout tables; empty cells use `&nbsp;`
+  or mention "N/A".
+- **Language**: simple, plain sentences; avoid unusual fonts, all-caps text
+  (screen readers may spell it out), and abbreviations that aren't defined.
+- **Contrast and zoom**: text must be readable with enlarged fonts; don't
+  hard-wrap text.
+- Requirements and normative guidance live in WCAG 2.x — cite those when
+  specific compliance is needed.
+
+## Inclusive documentation
+
+Avoid bias and harm; plain, precise language is more inclusive.
+
+- **Gender**: avoid unnecessarily gendered language. Use singular *they*;
+  don't address readers as "guys" or use *he/she*. When referring to a person
+  whose gender is unknown or irrelevant, use *they*.
+- **Ableist language**: avoid metaphors and idioms that marginalize — words to
+  steer clear of include *crazy, insane, dumb, blind spot, cripple, tone
+  deaf, sanity check, grandfathered, blacklist/whitelist, master/slave,
+  manhours, guys* and similar. The word list flags many of these.
+- **Non-inclusive terms in code**: if a term appears as a code keyword or
+  established industry term, either note the guidance in documentation or write
+  around it, per the word list's "don't use" markers. Don't casually keep
+  offensive terms just because they're in code.
+- **Examples**: use diverse names, genders, ages, and locations; gender-neutral
+  pronouns; avoid stereotypes (defaulting to one gender for a role, or Western
+  names for everyone).
+- **Accessibility as a topic**: discuss disability and accessibility in a
+  respectful, non-heroic way; use person-first or identity-first language as
+  the community you're writing for prefers (the guide recommends avoiding bias
+  and harm, and educating yourself on preferred terminology).
+- **People-first**, e.g., "users with reduced vision" rather than labels that
+  define people by a condition, where appropriate.
+- Avoid figurative/idiomatic language that can be misinterpreted or distract.
+
+## Global audience / translation
+
+The reader may be reading translated or non-native English. Write so meaning
+survives translation:
+
+- Short, unambiguous sentences; active voice; direct address ("you"); standard
+  English word order (subject-verb-object).
+- Consistency: use the same word for the same concept throughout; don't
+  synonym-swap for variety — translation memories rely on consistency.
+- Define abbreviations on first use; avoid culturally specific references,
+  idioms, humor, puns, sports metaphors, and references to local customs.
+- Avoid seasonal and "current events" references (timeless docs, see
+  strategy.md).
+- Dates/times and units: use the unambiguous formats in technical.md.
+- Examples: use the reserved example domains and fictitious data in
+  formatting.md; avoid real PII from any culture.
+- Don't rely on wordplay or double meanings.
+- Keep formatting simple: translation systems may mangle complex markup.
+
+## Practical rules that most often matter
+
+1. Descriptive link text; never "click here".
+2. Alt text for every informative image.
+3. No directional or color-only instructions.
+4. Short sentences, plain words, consistent terminology.
+5. Spell out abbreviations on first use.
+6. Singular *they*; no gender stereotypes in examples.
+7. Run the word list check on any term with inclusive-language flags.
\ No newline at end of file
diff --git a/skills/google-style-guide/reference/code.md b/skills/google-style-guide/reference/code.md
new file mode 100644
index 0000000..cb5af34
--- /dev/null
+++ b/skills/google-style-guide/reference/code.md
@@ -0,0 +1,105 @@
+# Code and API documentation detail
+
+Detail for: code font usage, code samples, command-line syntax, placeholders,
+API reference comments, semantic tagging, HTML/Markdown formatting. Source:
+developers.google.com/style (Code in text, Code samples, Code syntax,
+Placeholders, API reference comments, Semantic tagging, HTML formatting,
+Markdown).
+
+## Code font (inline code)
+
+Put in code font (backticks in Markdown, `code` in HTML) anything the reader
+types or that is a code entity. Non-exhaustive list:
+
+| Item | Example |
+|---|---|
+| Attribute names and values | "the `imageURL` attribute" |
+| Class names / method names | "the `SnapshotDiskOperator` class includes the `generate_snapshot_name` method" |
+| Command output | "The output is similar to the following: ..." |
+| Command-line utility names | "the `gcloud` tool", "the `kubectl` tool" |
+| Data types | "Nested data is represented as a `STRUCT` type" |
+| Database elements | "the `julianday` and `dayofweek` values from the `datetime` and `timestamp` columns" |
+| Element names (HTML/XML) | "the `script` and `df-messenger` HTML elements" (no angle brackets) |
+| Enum / constant values | "the constant `city` has the value `"San Francisco"`" |
+| Environment variables | "Set the `CHROME_REMOTE_DESKTOP_DEFAULT_DESKTOP_SIZES` environment variable" |
+| Filenames, extensions, paths | "the `pg_hba.conf` file, in the `/etc/postgresql/13/main` directory" |
+| HTTP verbs / status codes / content types | "send a `POST` request", "the `500 Internal Server Error` status code" |
+| IP addresses, machine types, regions (when code-like) | "the `e2-highcpu-16` machine type in the `us-central1-a` region" |
+| Boolean values as literals | "If the update succeeds, returns `true`." |
+| Literal text the reader types into a field | "In the **Name** field, enter `my-instance-99`" |
+
+Do **not** use code font for: domain names (use example.com), product/service
+names, or URLs the reader follows in a browser (make them links with
+descriptive text instead).
+
+### Grammatical treatment of code elements
+
+- Never inflect code as English — no pluralizing, possessives, or verbing.
+  Include a noun after the code item and inflect that noun:
+  - "the value of the `ADDRESS` constant" (not "`ADDRESS`'s value")
+  - "send a `POST` request" (not "`POST` the data")
+  - "call the `close` method" (not "`Closeing` the file")
+- Follow code spelling/capitalization exactly.
+
+## Code samples (blocks)
+
+- Indent with spaces (two per level per Google style; follow the language's
+  style guide); wrap lines at ~80 chars.
+- Markdown: fenced code blocks with the language for syntax highlighting.
+  HTML: `<pre>`.
+- Introduce the sample with a sentence; end with a colon if the sample directly
+  follows, a period if material intervenes.
+- Show omissions with a language-appropriate comment ("... // Existing code").
+- Don't rely on code samples alone — explain what the code does when relevant.
+
+## Command-line syntax
+
+- Show the command plus its most common use case. Prefer click-to-copy simple
+  commands over exhaustive syntax.
+- Optional arguments: document the common options, not every flag. Keep
+  mutually exclusive options clear ("`-a` or `-b`, not both").
+- Placeholders (see below) for values the reader replaces.
+- When showing output, include only the relevant parts and introduce it
+  ("The output is similar to the following:").
+- Use "run the `gcloud` command", not "gcloud it".
+
+## Placeholders
+
+- Placeholders represent values the reader must replace. Give them descriptive
+  names: `PROJECT_ID`, `LOCATION`, `EMAIL_ADDRESS` — not `VALUE1`.
+- In inline text and code blocks, format per your project's convention (often
+  angle brackets `<PROJECT_ID>` in syntax docs, or italic/capitalized in code
+  samples — follow the house convention).
+- Explain each placeholder the first time it appears ("Replace `PROJECT_ID`
+  with your project's ID.").
+- Use placeholder names consistently within a document.
+
+## API reference comments
+
+- Document every public class, constant, method, parameter, and return value.
+- First line: a concise statement of purpose in present tense, imperative or
+  descriptive ("Creates a new task on the specified task list.").
+- Parameter descriptions: purpose and expected values; state behavior for
+  booleans and defaults explicitly ("If `true`, validates the certificate.").
+- Return value: what information is returned, not a restatement of the method.
+- Avoid redundancy with the signature; don't repeat the method name as the
+  whole description.
+- Deprecations: state the replacement and guidance for updating code.
+
+## Semantic tagging (HTML)
+
+- Use elements for their purpose: `em` = emphasis, `strong` = strong
+  importance, `cite` = titles of works, `kbd` = keyboard keys, `pre` =
+  preformatted, `b` = attention without importance (used for UI labels).
+- Use headings only for hierarchical structure, CSS for visual styling.
+- No tables or frames for layout.
+- See the HTML formatting rules: two-space indentation, lowercase elements and
+  attributes, no trailing spaces, 80-char lines (except URLs and meta lines).
+
+## Markdown vs HTML
+
+- Markdown is preferred for readability; switch to HTML (`code`, `kbd`, spans
+  for nonbreaking spaces, etc.) when you need effects Markdown can't express.
+- Follow the project's existing convention.
+- Don't use tabs for indentation (Markdown features expect spaces); no trailing
+  whitespace.
\ No newline at end of file
diff --git a/skills/google-style-guide/reference/formatting.md b/skills/google-style-guide/reference/formatting.md
new file mode 100644
index 0000000..aa15763
--- /dev/null
+++ b/skills/google-style-guide/reference/formatting.md
@@ -0,0 +1,164 @@
+# Formatting and organization detail
+
+Detail for: headings, lists, tables, notices, links/cross-references, footnotes,
+images, examples, procedures, paragraphs, UI elements, text formatting,
+filenames. Source: developers.google.com/style (Headings, Lists, Tables,
+Notices, Cross references, Footnotes, Images, Examples, Procedures, Paragraph
+structure, UI elements, Text formatting, File names).
+
+## Headings and titles
+
+- **Sentence case** for all headings and titles (title case only for proper
+  product names).
+- **Task-based headings**: start with a bare infinitive — "Create an instance",
+  not "Creating an instance".
+- **Concept headings**: noun phrase, not an -ing verb — "Migration to Google
+  Cloud", not "Migrating to Google Cloud".
+- One unique h1 per page; don't repeat the page title verbatim in a heading.
+- Don't skip heading levels (h1 → h2 → h3 in order); headings need content
+  after them (no empty headings).
+- Keep punctuation simple; no numbers to indicate sequence; no links in
+  headings; avoid code in headings (if needed, add a descriptive noun).
+- Abbreviate in a heading only when the abbreviation is better known; define it
+  in the first paragraph after.
+- Use "the following sections" when referring to a group of subsections
+  ("The following sections describe the views in the data preparation editor").
+
+## Lists
+
+- Numbered lists: sequence matters (steps, phases, priorities).
+- Bulleted lists: most other lists; parallel structure required.
+- Description lists: term–definition pairs.
+- Don't use a list for a single item.
+- Introduce lists with a complete sentence, usually ending in a colon.
+- List items: start with a capital letter; use periods if items are complete
+  sentences (or after each numbered step in a procedure); keep items parallel
+  (same grammar).
+- Present each item as an equal alternative or sequence element — don't hide
+  steps inside other items.
+- Sub-steps in procedures: use lowercase letters under a numbered step.
+
+## Tables
+
+- Use a table when each row has 3+ related pieces of information; lists for
+  simpler sets; description lists for pairs.
+- Introduce with a complete sentence ending in a colon.
+- Column headings: short, clear, sentence case, no ending punctuation.
+- Keep cells short; avoid long sentences inside cells.
+- Use proper table markup (caption, th with scope) for accessibility.
+- Don't use tables for layout, code snippets, long one-dimensional lists, or
+  inside numbered procedures.
+
+## Links and cross-references
+
+- Link selectively; every link is a chance for the reader to leave. Provide
+  context on the page when a sentence or two suffices.
+- **Descriptive link text**: the page title or a descriptive phrase; never
+  "click here", "this document", or a bare URL.
+  - Recommended: "For more information about task scheduling, see Reliable task
+    scheduling on Compute Engine."
+  - Not recommended: "Want more? Click here!"
+- Use "For more information, see..." or "For more information about X, see..."
+  — never "on".
+- One link to a destination per page (exceptions: very long pages, multiple
+  entry points).
+- Don't open links in new tabs; if you must, say so ("opens in a new tab").
+- Don't use external-link icons; mention "the Wikipedia page about..." in text
+  if the domain matters.
+- Punctuation outside link tags where possible (`see <a>Test your code</a>.`).
+- Unlinked references: short works in quotes, full-length works in italics.
+- When linking a command or code item, include a descriptive noun in the link
+  text: "run the `gcloud instances create` command".
+
+## Notices
+
+- Four types: **Note** (useful, non-critical aside), **Caution** (proceed
+  carefully), **Warning** ("don't do this" / irreversible / data loss),
+  **Success** (interactive content only).
+- Use notices sparingly — overuse makes readers skip them. Don't stack two
+  notices; rewrite instead.
+- Don't use notes for cross-references, prerequisites, full steps, or
+  information the reader needs to succeed.
+
+## Images
+
+- Use images for UI elements and diagrams, not for text, code, or terminal
+  output.
+- **Alt text** (always): concise (≤155 chars), descriptive, context-aware;
+  no "Image of..." or "Photo of..."; include punctuation; no all-caps.
+  - "Architecture of an app that's built with Apps Script."
+- Decorative images: `alt=""` (still include the attribute).
+- Introduce images with a complete sentence (colon if it immediately precedes,
+  period otherwise).
+- Use high-resolution / vector images when practical; keep them sized to the
+  layout.
+- Don't rely on screenshots of text that should be real text (accessibility).
+
+## Examples
+
+- Never use real PII: use reserved example domains (example.com, example.org,
+  example.net), fictional names (e.g. Alex, Dana), `dana@example.com`, example
+  phone numbers (800-555-0100 through 0199 range), `USER_ID` style placeholders.
+- Introduce examples per the guidance in `format-examples`:
+  - End of sentence: comma or em dash; short mid-sentence ones in parentheses.
+  - Not recommended: "Enter a name for the instance, for example, my-instance-99."
+  - Recommended: "Choose a strong encryption algorithm, such as AES-256."
+
+## Procedures (numbered steps)
+
+- First sentence of each step contains an imperative verb: "Clone the
+  repository...", not "You need to clone..." (that's context, not a step).
+- Complete sentences; parallel structure; consistent verb form.
+- State location before action: "In the Google Cloud console, go to the
+  BigQuery page." not "Go to the BigQuery page in the Google Cloud console."
+- State purpose/goal before the action: "To start a new document, click
+  File > New > Document."
+- Optional steps: start the step with "Optional:".
+- Advanced/non-default: "Advanced:" prefix; only-for-some: "Optional:".
+- No directional language (above, below, left, right-hand side).
+- Set context (tool/environment) in the first step; restate under new headings.
+- Sub-steps: letters (a., b., c.) within a numbered step.
+- Multi-action: "Click File > New > Document" (> separates related UI
+  interactions in one step).
+
+## Paragraphs
+
+- One idea per paragraph; 5–6 sentences max (shorter is better); a one-sentence
+  paragraph is fine.
+- Put the most important information first in the paragraph.
+- Left-align text; no forced line breaks, no justification.
+
+## UI elements
+
+- Refer to element by its visible label, in bold: "click **Save**", "the
+  **File** menu", "the **New project** window".
+- Code-eligible elements (values you type) get code + bold: "In the
+  **Network** list, select `my-net-2`."
+- Follow the label's capitalization, but normalize all-caps or inconsistent
+  labels to sentence case.
+- Don't use UI elements as verbs/nouns in prose: "enter a name in the
+  **Service account ID** field" instead of "name the account".
+- Keyboard keys in `<kbd>`: "press **Ctrl+S**" (letter keys uppercase,
+  modifiers spelled out: "Ctrl", "Alt", "Shift").
+- Explain icons; avoid directional language ("the menu at the top right").
+
+## Text formatting summary
+
+- **Bold**: UI labels, and strong emphasis sparingly.
+- **Italics**: new terms, words-as-words, titles of full works (see
+  grammar.md).
+- **Code font**: anything the reader types or that is a code entity (see
+  code.md).
+- No underlines for emphasis; no all-caps; no ampersand for "and" in prose.
+- Sentence case everywhere; American spelling.
+
+## File and directory names
+
+- Lowercase, hyphens between words, ASCII only: `query-data.html`, not
+  `query_data.html` or `Query-Data.html`.
+- No generic names (`document1.html`).
+- Consistent with existing naming in the directory (exceptions allowed to stay
+  consistent).
+- When referencing: code font + the word "file": "the `pg_hba.conf` file".
+- File *types*: use formal names ("PNG file", not ".png file") — word list has
+  specifics.
\ No newline at end of file
diff --git a/skills/google-style-guide/reference/grammar.md b/skills/google-style-guide/reference/grammar.md
new file mode 100644
index 0000000..fc7aa0c
--- /dev/null
+++ b/skills/google-style-guide/reference/grammar.md
@@ -0,0 +1,127 @@
+# Grammar and mechanics detail
+
+Detail for: articles, contractions, pluralization, possessives, prepositions,
+pronouns, tense, sentence structure, reference verbs, anthropomorphism, italics.
+Source: developers.google.com/style (Articles, Contractions, Pluralization,
+Possessives, Prepositions, Pronouns, Tense, Sentence structure, Reference verbs,
+Anthropomorphism, Italics for terms).
+
+## Articles (a, an, the)
+
+- Always include articles — never drop them for brevity, including in headings.
+  - Recommended: Create **a** VM instance — Not: Create VM instance
+- Use `a` when the next word starts with a consonant **sound**, regardless of
+  spelling. For abbreviations whose pronunciation varies, choose the article to
+  match the common pronunciation (e.g., "an SQL database" if you pronounce it
+  "ess-queue-ell", "a SQL database" if you say "sequel").
+
+## Contractions
+
+- Use contractions, especially negations: *isn't*, *don't*, *can't*. Readers
+  can miss the word *not* when scanning.
+- Don't invent nonstandard contractions (*guides're*, *browser's* for "browser
+  is") or three-word contractions (*mightn't've*).
+- To emphasize a negation you can use formatting, e.g. "is **_not_**".
+
+## Pluralization
+
+- Make subject and verb agree, especially with long or complex subjects:
+  - Recommended: "The number of entries listed in the directory **is** accurate."
+  - Recommended: "The request payload and header information **are** logged."
+- In product names, don't pluralize (they're proper nouns): "use Project
+  IDs" — check the word list for specific entries.
+- For plural of code elements, don't inflect the code name; add a noun instead
+  ("multiple `config` files", not "multiple configs").
+- Don't use parentheses for optional plurals ("file(s)") — see word list
+  nuance; in general rewrite instead.
+
+## Possessives
+
+- Singular nouns (including ones ending in s): add `'s` — "each vector's
+  record".
+- Plural nouns ending in s: add only `'`: "the developers' guide".
+- Don't form possessives from product, feature, or company names when
+  describing their function; use the name as a modifier or rephrase with *of*:
+  - Recommended: "the Cloud Console menu" — Not recommended: "Cloud Console's menu"
+- Trademarks: never form a possessive. "Chromebook" → "Chromebook's features"
+  is wrong.
+- Code items: avoid possessives entirely; "the value of the `ADDRESS` constant",
+  not "`ADDRESS`'s value".
+
+## Prepositions
+
+- Include prepositions that increase clarity, omit unnecessary ones, and don't
+  clutter sentences.
+  - Recommended: "the client library documentation **for** the language you're
+    interacting with"
+  - Not recommended: "...the language with which you're interacting."
+- In cross-references use *about*, not *on*: "For more information about
+  indexes, see ..."
+
+## Pronouns
+
+- Ensure a pronoun clearly refers to its antecedent; if ambiguous, repeat the
+  noun.
+  - Recommended: "If you type text in the field, the text doesn't change."
+  - Not recommended: "...it doesn't change."
+- After a demonstrative (`this`/`these`/`that`), include a noun: "Set this
+  value to true", not "Set this to true".
+- Gender-neutral: use singular *they*; never *he/she*, *(s)he*, or generic *he*.
+- Use second person (*you*) for the reader; first person (*I* in FAQs, *we* for
+  the organization) only in specific contexts.
+- `that` for restrictive clauses, `which` (with comma) for nonrestrictive:
+  "the option that you selected", "the option, which is deprecated, ...".
+
+## Tense
+
+- Present tense for general behavior: "The server sends an acknowledgment",
+  not "will send".
+- Future tense (*will*) only to flag a genuinely future action: "The file will
+  be archived the next time the backup process runs."
+- Don't use future tense for how a feature will work after a future release
+  (write it as current behavior instead — see `reference/strategy.md`).
+- Avoid hypothetical *would*: "If you send an unsubscribe message, the server
+  removes you from the list" — not "You can send... The server would then...".
+
+## Sentence structure
+
+- Put conditions before instructions, and the most important information first.
+  - Recommended: "If your app is located in one of the following regions, ..."
+  - Not recommended: "...if your app is located in one of the following regions." (buried at the end)
+- Use "For more information, see [link]." rather than "See [link] for more
+  information."
+- "To delete the entire document, click Delete." rather than "Click Delete if
+  you want to delete the entire document."
+- Keep sentences short, vary the openings.
+
+## Reference verbs (API descriptions)
+
+- In API reference descriptions, the first verb matches the reference style:
+  says *creates*/*returns* (describes what the method does) vs *create*/*return*
+  (imperative instruction). Follow the existing style of the reference:
+  - "tasks.insert: Creates a new task on the specified task list."
+- Use a parallel, consistent form throughout a reference.
+
+## Anthropomorphism
+
+- Don't have software or objects do human actions: *see, think, feel, want,
+  believe, tell, assume*, etc.
+  - Recommended: "A Delimiter object specifies where to split a string."
+  - Not recommended: "A Delimiter object tells the splitter where a string
+    should be broken."
+  - Recommended: "The PC detects a new device."
+  - Not recommended: "The PC sees a new device."
+- Exception: standard idioms in technical vocabulary are fine when the product
+  uses them (e.g., "the server returns a 404", "the API expects a JSON body").
+
+## Italics for terms (words as words)
+
+- **New terms**: italicize on first mention when defining immediately. Don't
+  use bold or quotes: "A *Clos* network is a kind of multistage circuit
+  switching network."
+- **Words as words**: italicize when referring to the word itself: "Use the
+  word *and* instead." Don't use bold or quotation marks.
+- **Titles of full-length works**: italics (*The Chicago Manual of Style*).
+  Short works get quotation marks.
+- Don't use italics for emphasis in running text; prefer plain words or
+  reordering.
\ No newline at end of file
diff --git a/skills/google-style-guide/reference/punctuation.md b/skills/google-style-guide/reference/punctuation.md
new file mode 100644
index 0000000..28eaded
--- /dev/null
+++ b/skills/google-style-guide/reference/punctuation.md
@@ -0,0 +1,120 @@
+# Punctuation detail
+
+Detail for all punctuation marks. Source: developers.google.com/style
+(Colons, Commas, Dashes, Ellipses, Hyphens, Parentheses, Periods, Quotation
+marks, Semicolons, Slashes).
+
+## Colons
+
+- A colon introduces closely related information (lists, examples, etc.).
+- The text before a colon must stand alone as a complete sentence:
+  - Recommended: "The fields are defined as follows:"
+  - Not recommended: "The fields are:"
+- The first word after a colon is lowercase, except proper nouns, headings,
+  quotes, or after labels like "Caution:"/"Warning:".
+- Prefer a colon over an em dash to introduce a list.
+
+## Commas
+
+- **Serial comma** — always, in a series of three or more:
+  - "zones, regions, and multi-regions" (never "...zones, regions and
+    multi-regions").
+- After introductory words and phrases: "Finally, only groups that contain
+  parameters appear in this list."
+- Between independent clauses joined by *and/but/or*.
+- Before *which* in nonrestrictive clauses; after conjunctive adverbs
+  (*however, therefore*).
+- Generally no comma before *because* unless it introduces a nonrestrictive
+  clause.
+
+## Dashes (em dash)
+
+- Em dash (—) marks a break or interruption. No spaces around it: "To
+  indicate a break in the flow of a sentence—or an interruption—use an em
+  dash."
+- HTML: `&mdash;`; macOS: Option+Shift+hyphen.
+- Don't use en dashes; use hyphens or the word "to" for ranges ("2015 to 2020",
+  not "2015–2020").
+- Prefer a colon or period over a dash to separate items from their
+  descriptions.
+
+## Ellipses
+
+- In general don't use ellipses (…). They're for omission in quoted material
+  mid-sentence only — not at the start or end of a quote, and never for
+  hesitation ("The answer is ... wait for it ...").
+- When describing UI elements, omit ellipses from labels unless they're part of
+  the label's meaning.
+- When used, format as three periods with spaces: "word ... word".
+
+## Hyphens
+
+- Use to avoid misreading, combine terms, and separate word parts.
+- Compound modifiers before a noun: "a two-day total", "a high-level overview".
+- Don't hyphenate compound modifiers after the noun ("the total was two days").
+- Prefixes: hyphenate `self-`, `cross-`, before capitalized nouns or numbers
+  ("pre-2015", "non-English").
+- Compound nouns generally closed ("username"), but check the word list and
+  established conventions.
+- No spaces around hyphens (except suspended hyphens: "two- and three-day").
+- When in doubt, consult the word list and existing docs in your project
+  before guessing.
+
+## Parentheses
+
+- Don't put important information in parentheses — some readers skip them.
+- Keep parentheticals short; otherwise use two sentences.
+- Prefer em dash or commas where a parenthetical is borderline:
+  - Recommended: "Enter a name for the instance—for example, my-instance-99."
+  - Recommended: "Enter a six-digit hex number (for example, 228B22), and then
+    click OK."
+  - Not recommended: "Enter a name for the instance (for example,
+    my-instance-99)."
+- If a full standalone sentence is inside parentheses, the period goes inside.
+- Don't use parentheses for optional plurals ("file(s)").
+
+## Periods
+
+- End complete sentences with a period (exceptions: headings and some list
+  items).
+- Periods with URLs: avoid URLs at sentence end so the period isn't mistaken
+  for part of the URL; rewrite or put the URL on its own line.
+- Quotations: period goes inside the quotation marks even if not part of the
+  quote.
+- Parentheses: full sentence inside → period inside; partial → period outside.
+- No periods in acronyms/initialisms or headings; use them in abbreviations
+  like "e.g." and "etc.".
+- No double spaces after a period.
+
+## Quotation marks
+
+- Use straight double quotes and apostrophes only — never curly/smart.
+- Used mostly for titles of shorter works (articles, episodes) when not linked;
+  for literal UI strings that aren't code; sparingly otherwise.
+- Commas and periods go inside the closing quote; other punctuation outside
+  unless part of the quote.
+- Single quotes only for quotes within quotes and code examples.
+- Don't put quotation marks around link text.
+
+## Semicolons
+
+- Avoid when possible. A semicolon is OK to:
+  - Join two closely related independent clauses where a period feels too
+    strong and a comma too weak: "compute the centroid; if it is on the
+    opposite side, reverse the order."
+  - Precede a conjunctive adverb (*therefore, however*) joining clauses:
+    "...below the Main Camera; therefore, only the stereo cameras are
+    affected."
+  - Separate a series of long or complex items that contain their own
+    punctuation.
+- Otherwise use a period or comma.
+
+## Slashes
+
+- Avoid outside code. Use *and* or *or* instead of `/`:
+  - "the requirement isn't supported" for "and/or" ambiguity — use the word
+    that matches the meaning.
+- Never in dates ("2017-04-15", not "4/15/2017").
+- No abbreviations like `c/o` or `w/`.
+- OK in file paths and URLs (backslash on Windows).
+- Break long URLs after a forward slash.
\ No newline at end of file
diff --git a/skills/google-style-guide/reference/strategy.md b/skills/google-style-guide/reference/strategy.md
new file mode 100644
index 0000000..eaa0f07
--- /dev/null
+++ b/skills/google-style-guide/reference/strategy.md
@@ -0,0 +1,72 @@
+# Documentation strategy and philosophy detail
+
+Detail for: guide philosophy, prescriptive vs. descriptive writing, timeless
+documentation, future features, citing other sources, and related reference
+material. Source: developers.google.com/style (Philosophy, Prescriptive
+documentation, Timeless documentation, Document future features, Citing other
+sources).
+
+## Philosophy of the guide
+
+- The guide codifies a house style; it is about **internal consistency**, not
+  objective correctness. It doesn't claim to be an industry standard and
+  doesn't replace another style guide you already follow.
+- Prefer conciseness: rules are stated without lengthy rationale unless the
+  rationale matters (accessibility, localization).
+- When a rule here and a rule in the live guide disagree, the live guide wins.
+
+## Prescriptive (opinionated) writing
+
+Prescriptive documentation recommends a path instead of listing options. When
+you're telling the reader what to do:
+
+- **must** = required; **can** = optional; **might** = possible. Avoid
+  **should** (ambiguous — readers can't tell if it's required).
+- Use imperatives for required steps; "We recommend..." for suggestions.
+- Describe states precisely: is the state actual or required? Is the outcome
+  expected or possible?
+- Structure the doc around the recommended path: purpose-first headings,
+  scenarios and examples for the most relevant use cases, commands that work
+  for the common case.
+
+## Timeless documentation
+
+Document the current version of the product; avoid words that anchor text to a
+point in time or assume knowledge of prior/future versions:
+
+- Avoid: *now, new, currently, latest, recently, soon, yet, formerly, was
+  previously known as*.
+  - "These subcommands let you interact with HTTP load balancing" — not "These
+    **new** subcommands...".
+- Don't describe how the product changed from previous versions unless the
+  migration matters; don't describe how it will change.
+- Exception: time-sensitive content (blog posts, release notes) can use these;
+  product docs should not.
+
+## Future features
+
+- Don't use future tense to describe how a feature will work after a future
+  release or update. Write current, factual behavior.
+- If a feature is genuinely upcoming and you must mention it, mark it clearly
+  and keep the description minimal ("coming soon" style labels are a product
+  decision, not prose).
+- Don't promise availability or dates.
+
+## Citing other sources
+
+- When explaining a concept, define it in your own words, then (optionally)
+  link for more detail.
+  - Recommended: "recovery point objective (RPO), which is the maximum
+    acceptable length of time during which data might be lost..."
+  - Not recommended: quoting a dictionary/encyclopedia definition with a URL.
+- Avoid copying third-party content (docs, websites, books, blogs, images,
+  Wikipedia, open source docs, GitHub content) unless you're sure you own or
+  have rights to the assets. When in doubt, don't copy.
+- Link to third-party standards and software documentation rather than
+  re-documenting them.
+
+## When to use this file
+
+Consult this file when writing proposals, design docs, changelogs, or
+opinionated guides — the prescriptive/timeless guidance applies most there.
+For chat messages and code comments, the core rules in SKILL.md are enough.
\ No newline at end of file
diff --git a/skills/google-style-guide/reference/technical.md b/skills/google-style-guide/reference/technical.md
new file mode 100644
index 0000000..5e42f9a
--- /dev/null
+++ b/skills/google-style-guide/reference/technical.md
@@ -0,0 +1,119 @@
+# Numbers, units, and technical terminology detail
+
+Detail for: numbers, dates and times, units of measure, phone numbers,
+mathematical notation, abbreviations, product names, trademarks, jargon,
+excessive claims. Source: developers.google.com/style (Numbers, Dates and
+times, Units of measurement, Phone numbers, Mathematical notation,
+Abbreviations, Product names, Trademarks, Jargon, Excessive claims).
+
+## Numbers
+
+- Spell out zero through nine; use numerals for 10 and above.
+  - "four options", "nine developers", "15 directories".
+- Always spell out a number that starts a sentence (or rewrite so it doesn't):
+  - "Fifteen directories are created." / "In general, avoid sending files
+    larger than 164 MB as attachments."
+- Exception: it's OK, though non-optimal, to start a sentence with a four-digit
+  year.
+- Ordinals are always words: first, fifth, twelfth — never 1st, 5th, 43rd.
+- Use numerals for dimensions, percentages, currency, measurements, and
+  technical quantities ("a 128-bit system", "10%", "$5", "version 12").
+- Fractions: prefer decimals.
+- Ranges of numbers: "15 to 20" (or hyphen in time ranges: "5-10 minutes ago").
+- A number followed by a numeral is spelled out: "fifteen 100,000-byte files".
+- Use a nonbreaking space between a number and its unit (see below).
+
+## Dates and times
+
+- Dates: full month name, day, four-digit year — "January 19, 2017". Spell out
+  months and weekdays in full; no "Jan. 19, '17".
+- Numeric-only dates: ISO 8601 (YYYY-MM-DD), e.g. 2017-04-15.
+- Times: 12-hour clock; "3 PM", "3:45 PM" (capital AM/PM, space before);
+  omit minutes for round hours; noon and midnight are fine.
+- If a product/UI uses 24-hour time, match it throughout the page.
+- Time zones: avoid unless necessary. If needed, spell out the region with UTC
+  offset: "US and Canadian Pacific Standard Time (UTC-8)". Don't abbreviate
+  time zone names.
+- Seasons: avoid ("Q1 2024", not "in winter 2024").
+
+## Units of measure
+
+- Nonbreaking space between number and unit: 64 GB, 25 mm. (Currency, percent,
+  and angle degrees are exceptions that don't need the space.)
+- Temperature: "50° C", "300 K" (space before C/F/K).
+- Ranges: repeat the unit and use "to": "-40° C to 85° C", not "-40-85° C".
+- Bytes: decimal (kB, MB, GB) vs binary (KiB, MiB, GiB) — use the correct
+  system for the technology you're documenting.
+- Spell out units in prose when the abbreviation isn't clear ("miles per
+  hour", not "mph" on first use) — check the Abbreviations page.
+
+## Phone numbers
+
+- Example numbers only from the reserved range 800-555-0100 through
+  800-555-0199 (US). Never real phone numbers.
+- Format so the number stays on one line: nonbreaking hyphen (`&#8209;`) and
+  nonbreaking spaces.
+- Include country/area codes when appropriate; extensions: "extension 1234".
+
+## Mathematical notation
+
+- Use HTML entities for math symbols instead of keyboard glyphs (e.g.
+  `&minus;`, `&times;`, `&le;`); the plus, equals, and division signs may use
+  keyboard equivalents.
+- If a third-party tool renders the math, follow that tool's formatting.
+- Accompany numerical concepts with real-world implications; use diagrams or
+  charts to aid comprehension.
+
+## Abbreviations
+
+- Abbreviations include acronyms (pronounced as words: NATO), initialisms
+  (letter-by-letter: CIA, PR), shortened words (Dr., min), and contractions.
+- **Define on first use**: spell out the full term, then give the abbreviation
+  in parentheses — "Google Kubernetes Engine (GKE)". Use the abbreviation alone
+  afterward. (In headings, define it in the first paragraph after.)
+- Only abbreviate when the abbreviation saves the reader effort; avoid
+  unfamiliar or overly specialized abbreviations and internet slang (tl;dr,
+  ymmv).
+- Omit periods in acronyms and initialisms ("PR", not "P.R."); keep them in
+  shortened words ("Dr.", "etc.").
+- Pluralize abbreviations like regular words: "CDs", "OSes" (add `es` to
+  those ending in s, sh, ch, x). Don't use abbreviations as verbs.
+
+## Product names
+
+- Follow official capitalization; don't rename or stylize products.
+- Google product names in title case unless matching a UI label; features
+  usually lowercase unless officially capitalized.
+- Use the full product name on first mention; avoid abbreviations unless the
+  abbreviation matches the UI.
+- Don't use product or feature names as verbs ("google it", "to chrome") or as
+  possessives.
+- Use "the" before tool/API names ("the `gcloud` tool", "the Compute Engine
+  API"), not before plain product names ("use BigQuery").
+
+## Trademarks
+
+- Use trademarks only as modifiers of a noun: "a Chromebook notebook computer"
+  — never as a bare noun, verb, possessive, or plural ("google", "Chromebook's
+  features", "Chromebooks").
+- Never alter or abbreviate trademarked terms.
+
+## Jargon
+
+- Jargon = specialized/figurative group terminology (camel case, swim lane,
+  break-glass, out-of-the-box, solution, workload). Avoid it for global
+  audiences.
+- If you must use a term because readers search for it, define it on first use
+  or link to a trusted definition.
+- Write around the term when possible; keep definitions short.
+
+## Excessive claims
+
+- Don't claim things a reader can't verify or that the future could invalidate:
+  - Performance/cost claims not backed by verifiable data.
+  - Security statements that a single incident could falsify ("our service is
+    completely secure" → "this feature is designed to prevent X").
+  - Subjective or disparaging statements about third-party products.
+- Avoid superlatives: best, simplest, fastest, never, always. Be careful with
+  ensure and guarantee — use them only when you can actually back them up.
+- Describe intended benefits and design, not guarantees.
\ No newline at end of file
diff --git a/skills/google-style-guide/word-list.md b/skills/google-style-guide/word-list.md
new file mode 100644
index 0000000..8e1f460
--- /dev/null
+++ b/skills/google-style-guide/word-list.md
@@ -0,0 +1,1700 @@
+# Word list (usage dictionary)
+
+Usage and spelling guidance from the Google developer documentation style
+guide. Entries marked **[use with caution]** should be avoided when possible
+(ambiguous or obscure; alternatives suggested). Entries marked **[don't use]**
+should be avoided in all cases (ambiguous, offensive, or non-inclusive); if the
+term appears in code, write around it. **[Android]**, **[Google Cloud]**, and
+**[Google Workspace]** entries apply only to those domains. Entries ending in
+`*` (for example, `pre*`) are prefixes that apply to any word starting with
+that prefix.
+
+
+## Numbers and Symbols
+
+- **+** —
+  OK to use + with numbers in text, such as customer records with 300+ demographic attributes, except in formal contexts.
+- **& (ampersand)** [use with caution] —
+  Don't use & instead of and in headings, text, navigation, or tables of contents.
+  It's OK to use & when referencing UI elements that use &, or in table headings and diagram labels where space constraints require abbreviation.
+  It's OK to use & for technical purposes in code.
+- **2-Step Verification** —
+  When referring to Google's 2-Step Verification, use initial caps.
+  When referring to generic 2-step verification, use lowercase.
+
+## A
+
+- **a and an** —
+  Use a when the next word starts with a consonant sound, regardless of what letter it starts with. For more information, see Articles (a, an, the).
+- **A/B testing** —
+  Capitalize and use slash notation for A/B.
+- **abnormal** [use with caution] —
+  Don't use to refer to a person.
+  OK to use to refer to a condition of a computer system.
+- **abort** [use with caution] —
+  Avoid in general usage. Instead, use words like stop, exit, cancel, or end. In Linux, abort refers to a type of signal that terminates an abnormal process.
+- **about versus on** —
+  When a cross-reference includes information that describes what the cross-reference links to, use about instead of on.
+  Recommended: For more information about indexes, see Managing indexes.
+  Not recommended: For more information on indexes, see Managing indexes.
+- **above** [use with caution] —
+  Don't use for a range of version numbers. Instead, use later.
+  Don't use to refer to a position in a document. Instead, use earlier or preceding.
+  Don't use to refer to a position in the UI. Instead, write instructions that avoid directional language. For more information, see Writing accessible documentation.
+  It's OK to use above in a non-directional way, such as when describing a hierarchy.
+- **access (verb)** [use with caution] —
+  Avoid when you can. Instead, use friendlier words like see, edit, find, use, or view.
+- **access token** —
+  Lowercase except at the beginning of a sentence, heading, or list item.
+- **account name** [don't use] —
+  Don't use. Instead, use username.
+- **actionable** [use with caution] —
+  Avoid unless it's the clearest and simplest phrasing for your audience. Instead, leave it out or replace it with a phrase like that you can act on or useful.
+  Don't use actionable in the legal sense without consulting a lawyer.
+- **action bar** [don't use] [Android] —
+  In Android documentation, don't use. Instead, use app bar.
+- **ad tech** —
+  Write out on first mention: advertising technology (ad tech).
+  Don't use adtech or ad-tech.
+- **address bar** —
+  Use to refer to the URL bar or the combined URL bar and search box in a browser.
+  Don't use omnibox.
+- **ad hoc** —
+  OK to use in database and analytics contexts to mean "free-form" or "user-written" (for example, ad hoc queries or an ad hoc chart). For other contexts, try to find a more specific English equivalent.
+  Don't hyphenate or italicize the term.
+- **admin** [don't use] —
+  Write out administrator unless it's the name of a UI label or other element.
+  It's OK to use admin in Android documentation.
+- **administrator** [don't use] [Android] —
+  In Android documentation, don't use. Instead, use admin.
+- **advertised route priority** —
+  OK to also use base advertised route priority when discussing region-to-region costs.
+  Don't shorten or use variations of these terms.
+- **agnostic** [don't use] —
+  Don't use. Instead, use a more precise term like platform-independent.
+- **AI** —
+  In general, you can use AI without spelling out artificial intelligence.
+  Most readers are familiar with the abbreviation AI. If you think your audience isn't familiar with the term, spell it out on first use.
+- **aka** [don't use] —
+  Don't use. Instead, write out also known as, or present an alternative term using parentheses or the word or. You can also write out a definition.
+  Recommended: Geographic data, also known as geospatial data, is ...
+  Recommended: Geographic data (geospatial data) is ...
+  Recommended: Geographic data, or geospatial data, is ...
+- **all apps screen** [Android] —
+  In Android documentation: Lowercase except at the beginning of a sentence, heading, or list item.
+- **allowlist (verb), allowlisted, allowlisting** [don't use] —
+  Don't use as a verb. Instead, rewrite to improve clarity.
+  OK to use allowlist as a noun.
+  For more information, see blacklist.
+- **allows you to** [don't use] —
+  Don't use. Instead, use lets you. For more information, see enable.
+- **alpha** —
+  Lowercase except when part of a product name.
+  Recommended: PRODUCT_NAME Alpha
+  Recommended: PRODUCT_NAME is in alpha.
+- **America, American** [use with caution] —
+  Use only to refer to the Americas or the American continent.
+  Don't use to refer to the United States. Instead, use a more precise term like the US or the United States, and people in the US. For more information, see US.
+- **among** —
+  See between versus among.
+- **AM, PM** —
+  To be consistent with Material Design, use all caps, no periods, and a space before.
+  Recommended: 9:00 AM
+  Recommended: 10:30 PM
+- **and/or** [use with caution] —
+  Don't use unless space is limited, such as in a table. For more information, see Slashes.
+- **Android** [Android] —
+  When referring to the operating system, capitalize Android.
+- **Android-powered device** [Android] —
+  Not Android device.
+- **and so on** [use with caution] —
+  Avoid using and so on whenever possible. For more information, see etc.
+- **anti*** —
+  See guidance about hyphens with prefixes.
+- **anti-pattern** [use with caution] —
+  Avoid using anti-pattern, particularly as a standalone heading. Instead, consider using a more specific and broadly understood term.
+  Recommended: Avoid these five SQL errors.
+  Recommended: Avoid these five programming practices that make SQL queries inefficient.
+  Not recommended: Avoid these five SQL anti-patterns.
+- **API** —
+  Use API to refer to either a web API or a language-specific API.
+  Don't use API when referring to a method or a class. For example, don't write This resource has one API to mean "This resource has one method."
+- **API Console, APIs console, developer console, dev console, or Google API Console** [don't use] —
+  Don't use. Instead, refer to the Google APIs Explorer or to the Google Cloud console. For more information, see console.
+- **API Console key** —
+  In most contexts, use API key instead of API Console key.
+  In Apps admin APIs, it's OK to use API Console key to distinguish from other API keys.
+- **API key** —
+  Not developer key or dev key.
+- **APIs Explorer** —
+  Not API explorer or other variants.
+- **app** —
+  In general, use app instead of application when referring to programs for end users, especially in the context of mobile or web software.
+  In some contexts, such as enterprise software, it's OK to use application to convey a sense of greater complexity.
+  Use application in standard phrases such as application programming interface.
+- **app bar** [Android] —
+  In Android contexts, formerly action bar.
+- **appendix** —
+  Use the plural appendixes, not appendices.
+- **application** —
+  See app.
+- **as** —
+  If you mean because, then use because instead of as. As is ambiguous; it can refer to the passage of time. Because refers to causation or the reason for something.
+- **as of this writing** [use with caution] —
+  Avoid because this phrase is implied. The phrase can also prematurely disclose product or feature strategy or inappropriately imply that a product or feature might change.
+  See also currently and presently.
+  Recommended: BigQuery doesn't support that function.
+  Not recommended: As of this writing, BigQuery doesn't support that function.
+  For more information, see Timeless documentation.
+- **authentication and authorization** —
+  In general, use the word authenticated only to refer to users, and use authorized only to refer to requests that are sent by a client app on behalf of an authenticated user. A user authenticates their identity by entering their password (or giving some other proof of identity). The authenticated user then authorizes the client app to send an authorized request to the server on the user's behalf.
+  When you want to use a preposition with authenticate, use against.
+- **authN, authZ** [don't use] —
+  Don't use. Instead, use authentication or authorization.
+- **auto*** —
+  See guidance about hyphens with prefixes.
+- **autohealing** —
+  Not auto-healing.
+- **auto mode VPC network** —
+  Not auto mode network.
+- **autopopulate** —
+  Not auto populate or auto-populate.
+- **autoscaling** —
+  Not auto-scaling.
+- **autotagging** —
+  Not auto-tagging.
+- **autoupdate** [don't use] —
+  Don't use. Instead, use automatically update.
+- **-aware** [use with caution] —
+  Avoid using as a compound modifier, as in healthcare-aware.
+  OK to use when it's part of a product name, such as Identity-Aware Proxy.
+
+## B
+
+- **backend** —
+  Not back-end or back end.
+- **bar** [use with caution] —
+  Avoid when possible. For more information, see foo.
+- **bare metal** —
+  Lowercase except at the beginning of a sentence, heading, or list item.
+  Hyphenate when used as a compound modifier, such as bare-metal server.
+- **base64** —
+  Lowercase except at the beginning of a sentence, heading, or list item. Otherwise, capitalize Base64 only if it's part of a formal name.
+  Write base64 in code font only if it's a string literal or otherwise quoted from code.
+- **baz** [use with caution] —
+  Avoid when possible. For more information, see foo.
+- **below** [use with caution] —
+  Don't use for a range of version numbers. Instead, use earlier.
+  Don't use to refer to a position in a document. Instead, use later or following.
+  Don't use to refer to a position in the UI. Instead, write instructions that avoid directional language. For more information, see Writing accessible documentation.
+  It's OK to use below in set phrases such as below (the) average, below the mean, below zero.
+  It's OK to use below in a non-directional way, such as when describing a hierarchy.
+- **best effort** [use with caution] —
+  Avoid where possible. Instead, use more specific wording. After providing a description, you can add a phrase like "sometimes referred to as best effort."
+- **beta** —
+  Lowercase except when part of a product name.
+  Recommended: PRODUCT_NAME Beta
+  Recommended: PRODUCT_NAME is currently in beta.
+- **between versus among** —
+  It's fine to use between when talking about more than two things; however, between isn't interchangeable with among.
+  Use between when you're talking about two or more distinct things:
+  Recommended: JavaScript introduces dependencies between the DOM, the CSSOM, and JavaScript execution.
+  Use among when you're talking about things that are part of a group or things that aren't distinct:
+  Recommended: ... a conventional SQL database that can be shared among multiple apps.
+  More examples:
+  Recommended: Because screen dimensions vary widely among devices (for example, between phones and tablets, and even among different phones), you should configure the viewport so that your pages render correctly on many different devices.
+  Not recommended: Because screen dimensions vary widely between devices (for example, between phones and tablets, and even between different phones), you should configure the viewport so that your pages render correctly on many different devices.
+  Recommended: You can share services among multiple clients.
+  Not recommended: You can share services between multiple clients.
+  See also Grammar Girl's discussion of between and among.
+- **big-endian** —
+  Hyphenate. Lowercase except at the beginning of a sentence, heading, or list item.
+  Recommended: The codebase assumes big-endian byte ordering.
+  Not recommended: The codebase assumes Big Endian byte ordering.
+  Not recommended: The codebase assumes Big-endian byte ordering.
+  Not recommended: The codebase assumes big endian byte ordering.
+- **billing charges** [use with caution] —
+  Don't use billing charges to mean charges that appear on a bill. Instead, use billed charges.
+  Use billing charges to describe the cost of creating the bill.
+- **black-box** [use with caution] —
+  Avoid using black-box, blackbox, or black box to describe monitoring and testing. Consider using a more precise term for clarity. For monitoring, use synthetic monitoring. For testing, use opaque-box testing.
+- **Black Friday** [use with caution] —
+  Avoid unless explicitly referring to an event in the US. Instead use peak scale event.
+- **blackhat, black hat, black-hat** [don't use] —
+  Don't use. Instead, use precise terms for the kind of violation or practice, such as illegal, unethical, or in violation of rules.
+- **blackhole (verb), blackholed (adjective)** [don't use] —
+  Don't use. Instead, use a more descriptive term or phrase, such as dropped without notification.
+- **blacklist, black list, black-list** [don't use] —
+  Don't use blacklist, whitelist, and graylist. Instead, use more precise terms that are appropriate for your domain.
+  For the noun blacklist, consider using a replacement such as denylist, excludelist, or blocklist. For the noun whitelist, consider using a replacement such as allowlist, trustlist, or safelist. For the noun graylist (greylist), consider using a replacement such as provisional list.
+  In all of these cases, consider that there might not actually be a list involved. When replacing problematic terms, be sure to be technically accurate for the specific context.
+  For the verb forms of these words, a simple word-for-word replacement typically isn't the best solution. Instead, replace verbs such as blacklisted with phrases that accurately convey the relevant action. For example:
+  Recommended: To deny requests from an IP address, add it to the dos.yaml file.
+  Not recommended: To denylist an IP address, add it to the dos.yaml file.
+  Don't use: To blacklist an IP address, add it to the dos.yaml file.
+  If the command or code that you're documenting uses one of these words, then use the words only in direct reference to the code items (formatted as code), and make it clear what you're referring to.
+  Recommended: Add a user to the allowlist (whitelist) by entering the following: whitelist adduser EMAIL_ADDRESS.
+  Not recommended: Add a user to the whitelist by entering the following: whitelist adduser EMAIL_ADDRESS.
+  For more information, see the inclusive documentation page.
+- **blacklisted, black listed, black-listed** [don't use] —
+  Don't use. See blacklist.
+- **blacklisting, black listing, black-listing** [don't use] —
+  Don't use. See blacklist.
+- **blast radius** [don't use] —
+  Don't use. Instead, use a more precise term like affected area or spatial impact.
+- **blind** [use with caution] —
+  Avoid using blind to or blind eye to. Instead, use more precise terms like ignore, unaware of, disregard, avoid, or reject.
+  Avoid using blind writes. Instead, use a more precise phrase, such as a write operation without a read operation.
+  Avoid using blind change or change blindly. Instead, use a more precise phrase such as change without first confirming the value.
+  When referring to people, use terms like person who is blind, screen reader user (if applicable), person who is visually impaired, person who is low-vision, magnification user (if applicable).
+- **blue-green** —
+  Not blue/green or blue green.
+- **boolean** —
+  In most contexts, boolean refers to a specific data type in a specific programming language. In such cases, use code font and the exact spelling and capitalization of the programming keyword.
+  When referring to the abstract data type, use lowercase.
+  If you refer to Boolean mathematics or Boolean logic, use uppercase.
+- **branding information** —
+  In the Google Cloud console, the phrase branding information refers to the information that Google shows to users when the client asks them to authorize access: specifically, the project's name and logo, and the developer's Google Account. This information is set in the Consent screen page.
+- **break-glass** [don't use] —
+  Don't use. Instead, use a more precise term depending on context: To describe a general emergency or procedure that grants emergency access, use emergency access. To describe a fallback procedure, use manual fallback or preplanned procedure.
+- **brown bag, brown-bag** [don't use] —
+  Don't use. Instead, use a more precise term like learning session, lunch and learn, lunchtime learning session, casual training, or informal training.
+- **build cop, build sheriff** [don't use] —
+  Don't use. Instead, use a more precise term like build monitor.
+- **button** —
+  In a UI, a link isn't the same as a button; don't use the term button to refer to a link.
+  Use button to refer to mechanical buttons (like the volume control buttons on the side of a phone) and capacitive touch buttons on a phone (like the Home button). You press mechanical buttons, and tap capacitive and on-screen buttons.
+
+## C
+
+- **can** —
+  Use can in the following ways: To convey permission or ability (for example, "You can access the server"). To refer to an optional action (for example, "You can also view logs with the Log Viewer"). To describe a possible outcome (for example, "The process can take 30 minutes").
+  See also could, may, might, must, should, and would.
+  For information about clarifying who's performing an action, see Active voice.
+- **canary** [use with caution] —
+  Don't use canary as a verb, and don't use canarying.
+  When possible, avoid jargon like canary and canary testing. If you use one of these phrases, define it on first use or provide a link to the definition, and use it consistently throughout the document.
+- **cell phone, cellphone** [don't use] —
+  Don't use. Instead, use mobile phone, or if you're talking about more than phones, then use mobile device.
+- **cellular data** [don't use] —
+  Don't use. Instead, use mobile data.
+- **cellular network** [don't use] —
+  Don't use. Instead, use mobile network.
+- **chapter** —
+  When referring to documentation that isn't in the form of a book, don't use the term chapter. Instead, refer to documents, pages, or sections.
+- **check** [use with caution] —
+  Don't use to refer to marking a checkbox. Instead, use select.
+  Recommended: Select Automatically check for updates.
+  Not recommended: Check Automatically check for updates.
+- **checkbox** —
+  Not check box.
+- **choose** —
+  Choose is fine to use for generic contexts. For UI elements, use select.
+- **chubby** [don't use] —
+  Don't use. Instead, use a word that clearly explains what you mean, such as unused or overextended.
+- **clear** —
+  Use (as a verb) to refer to clearing a check mark from a checkbox.
+  Recommended: Clear Automatically check for updates.
+  Not recommended: Uncheck Automatically check for updates.
+  Not recommended: Deselect Automatically check for updates.
+- **CLI** [use with caution] —
+  Don't use CLI generically to refer to a command-line interface. Instead, refer to the specific command-line interface, such as the Google Cloud CLI.
+- **click** —
+  When the environment is a desktop with a mouse, use click for most targets, such as buttons, links, list items, and radio buttons. Don't use click on.
+  Recommended: Click OK.
+  Not recommended: Click on OK.
+  Hyphenate right-click, left-click, and double-click.
+  When a click or tap action reveals a collapsed list, you can write click to expand or simply expand.
+  It's OK to write click in when referring to a region that needs focus (for example: click in the window), but not when referring to a control or a link.
+  For Android apps, don't use click. Instead, use tap.
+- **click here** [don't use] —
+  Don't use. For information and alternatives, see Avoid vague link text.
+- **client** —
+  In REST and RPC API documentation, client is short for client app—that is, the app that the developer is writing.
+  Don't use client as an abbreviation for client library; instead, use library.
+- **client ID** —
+  Lowercase except at the beginning of a sentence, heading, or list item.
+- **client secret** —
+  Lowercase except at the beginning of a sentence, heading, or list item.
+- **Cloud** [use with caution] [Google Cloud] —
+  Don't use as short for Google Cloud.
+  For generic references such as the cloud or hybrid cloud, use lowercase.
+- **Cloud console** [don't use] [Google Cloud] —
+  Don't use. Instead, refer to the full name Google Cloud console.
+  If you aren't discussing any other console (such as the Google Admin console), you can abbreviate to the console after first mention.
+  Use the before the tool name. For more information, see console.
+- **Cloud SDK** —
+  Not Google Cloud SDK.
+- **co*** —
+  See guidance about hyphens with prefixes.
+- **codebase** —
+  Not code base.
+- **codelab** —
+  Not code lab or code-lab. For more information, see documentation.
+- **cold** —
+  When possible, avoid jargon like cold failover, cold standby, and cold spare. If you use one of these phrases, define it on first use and use it consistently throughout the document.
+- **colocate** —
+  Not co-locate or colo.
+- **compliant, compliance** [use with caution] —
+  Use with caution. A claim that a product or its output is compliant with a standard is a strong statement.
+- **comprise** [don't use] —
+  Don't use. Instead, use consist of, contain, or include.
+- **config** [use with caution] —
+  Avoid when possible. Instead, spell out the full word when it's used in a non-code sense: configuration or configuring. Use the verbatim code item name when referring to, for example, a data structure or a file with that name.
+- **confidential** —
+  Confidential data is data that is protected to prevent unauthorized access. See sensitive.
+- **cons** [don't use] —
+  Don't use. Instead, use a more precise term, such as disadvantages.
+- **console** [use with caution] —
+  Don't use in isolation. Instead, use the name of the specific console, such as the Google Cloud console or the Google Admin console.
+  Use the before the name of a console.
+  After giving the full name of a console, you can use a shortened version of the name, such as the Admin console.
+  If you're only discussing the Google Cloud console, after giving the full name you can refer to the console.
+  To refer to a sub-page of a console, use the term page.
+  If a specific term for a browser-based interface is unavailable, use web interface.
+- **content type** [use with caution] —
+  Be as specific as possible when writing about a content type, and use the term only when applicable. For example, you can use this term if you're referring to the value of the Content-Type HTTP header. Also see media type.
+- **Control+S, Command+S, and other keyboard commands** —
+  To refer to a Control character, use Control+CHARACTER.
+  Don't use Ctl-S, Cmd-S, or Cloverleaf-S.
+  In most cases, use an uppercase letter for CHARACTER.
+  In macOS, many keyboard commands use the Command key instead of the Control key, and there's an Option key instead of an Alt key. If your audience includes macOS users and Windows or Linux users, then mention both keyboard commands.
+  Recommended: Control+S (Command+S on macOS)
+- **Copy and paste** [use with caution] —
+  Avoid using. Instead, explain what to enter into a field and not how.
+  Recommended: In the Query field, enter the output from the previous step.
+  Not recommended: Copy the output from the previous step and paste into the Query field.
+- **could** [use with caution] —
+  Avoid using. Instead, use can where possible.
+  See also can, may, might, must, should and would.
+  For information about clarifying who's performing an action, see Active voice.
+  For information about tenses, see Present tense.
+- **CPU** —
+  All caps. No need to expand the abbreviation on first mention.
+- **crazy, bonkers, mad, lunatic, insane, loony** [don't use] —
+  Don't use. Instead, use complicated, complex, baffling, strange, or unexpected, and only for inanimate objects.
+- **Create a new ...** [use with caution] —
+  Avoid using unless you need to distinguish the item from another recently created item. Instead, use Create a ...
+  Recommended: Create a project.
+  Not recommended: Create a new project.
+- **cripple** [don't use] —
+  Don't use. Instead, use more precise language. For example, instead of it crippled the server, write it slowed the server down.
+  When referring to people, use terms that specifically describe a physical impairment, such as person with a motor disability; person with a mobility impairment (refers to walking or moving about); person with dexterity impairment (refers to using a standard mouse or keyboard); person who uses a wheelchair, walker, or cane; wheelchair user; person with restricted or limited mobility.
+- **cross-site request forgery** —
+  Lowercase except at the beginning of a sentence, heading, or list item.
+- **curated roles** [don't use] —
+  Don't use. Instead, use predefined roles.
+- **currently** [use with caution] —
+  Avoid because this word is implied. The word can also prematurely disclose product or feature strategy or inappropriately imply that a product or feature might change.
+  See also as of this writing and presently.
+  Recommended: Windows isn't supported.
+  Not recommended: Windows isn't currently supported.
+  For more information, see Timeless documentation.
+- **custom mode VPC network** —
+  Not custom mode network.
+- **curl** —
+  Not cURL.
+  For information about when to use code format, see Items that are sometimes in code font.
+- **Cyber Monday** —
+  Avoid unless explicitly referring to an event in the US. Instead use peak scale event.
+
+## D
+
+- **dash** —
+  A dash (—) isn't the same character as a hyphen (-). The characters are used for different purposes. Therefore, don't use the word dash to refer to a hyphen.
+- **dashboard** [use with caution] —
+  Don't use to refer to the Google Cloud console. For more information, see console.
+  Use dashboard not Dashboard unless it's officially part of a product name.
+- **data** —
+  Use data as singular, not plural; the data is, not the data are.
+  Use data as a mass noun, not a count noun; less data, not fewer data.
+- **data center** —
+  Not datacenter.
+- **data center campus** —
+  Use when referring to an entire physical location, which can encompass one or more data centers.
+- **data cleaning** —
+  Not data cleansing.
+- **data flow (noun); dataflow (noun)** —
+  If it's possible to replace with the phrase flow of data, then use two words: data flow.
+  If that replacement doesn't work, such as when referring to something like stream processing or reactive programming, then use one word: dataflow.
+- **data source** —
+  Not datasource.
+- **datastore** —
+  Not data store.
+- **data type** —
+  Not datatype.
+- **dead-letter queue, dead letter** —
+  Define on first use, for example dead-letter queue (unprocessed messages queue).
+- **deep linking** —
+  Not deep-linking. However, if you can replace with linking, then do so.
+- **deficient** [use with caution] —
+  Don't use to refer to a person.
+  OK to use to refer to a condition of a computer system.
+- **deformed** [use with caution] —
+  Don't use to refer to a person.
+  OK to use to refer to a condition of a computer system or inanimate object.
+- **demilitarized zone (DMZ)** [don't use] —
+  Don't use. Instead, use a more precise term like perimeter network.
+- **denigrate** [don't use] —
+  Don't use. Instead, use disparage.
+- **denylist (verb), denylisted, denylisting** [don't use] —
+  Don't use as a verb. Instead, rewrite to improve clarity.
+  OK to use denylist as a noun.
+  For more information, see blacklist.
+- **deprecate** —
+  To deprecate an item is to recommend against the item's use, typically as a warning that the item will soon be unavailable or unsupported. Don't use deprecated to mean removed, deleted, shut down, or turned down.
+- **deselect** [don't use] —
+  Don't use to refer to clearing a check mark from a checkbox. Instead, use clear.
+  Recommended: Clear Automatically check for updates.
+  Not recommended: Deselect Automatically check for updates.
+  Not recommended: Uncheck Automatically check for updates.
+- **desire, desired** [don't use] —
+  Don't use. Instead, use a word like want or need.
+  Recommended: Set the value to the size that you want.
+  Not recommended: Set the value to the size that you desire.
+  Not recommended: Set the value to the desired size.
+- **Developers Console** [don't use] —
+  Don't use. For more information, see console.
+- **DevOps** —
+  Short for development operations. No need to spell out on first mention unless the audience requires it. For more information, see DevOps.
+- **dialog** —
+  Use dialog for the UI element sometimes called a dialog box.
+  Use dialogue only for verbal interaction between people.
+- **directory, folder** —
+  If the context that you're documenting (such as an IDE's GUI) uses one term or the other, use that term. If not, then use directory in a command-line context, and folder in a GUI context. When in doubt, default to directory.
+- **disable** [use with caution] —
+  Don't use disable or disabled to describe something that's broken.
+  When describing a user action or the state of a UI element, use a more precise term where possible. You can use inactive, unavailable, deactivate, turn off, or deselect, depending on the context. Use the same term consistently throughout your document. See also enable.
+- **disclosure triangle, disclosure widget** [don't use] —
+  Don't use. Instead, use expander arrow.
+- **display (verb)** —
+  Don't use as an intransitive verb. Display is a transitive verb; therefore, it requires an object. It is often misused in technical documentation, as demonstrated by the following example:
+  Recommended: The Output Directories area appears.
+  Recommended: The Output Directories area is displayed.
+  Not recommended: The Output Directories area displays.
+  The following example demonstrates correct usage of the verb display but means something quite different from the preceding examples.
+  Recommended: The Output Directories area displays the vector image.
+- **distributed denial-of-service (DDoS)** —
+  Hyphenate as shown. On subsequent mention, use DDoS.
+- **DNS server policy** —
+  Lowercase server policy.
+- **DNSKEY** —
+  One word, all capital letters.
+- **documentation or document or documents** —
+  To refer specifically to the text on a page that explains a product, feature, or service, use this document, and not this article, this topic, this doc, or this page. It's OK to use this tutorial, this quickstart, or this codelab for those specific documentation types. Always spell out documentation except in cases where space is limited, such as in tabs and URLs. See also page.
+  Recommended: You can find many examples in this document.
+  Not recommended: You can find many examples in this article.
+  Recommended: This document provides guidance about creating tables.
+  Not recommended: This page provides guidance about creating tables.
+- **documentation set** —
+  Not doc set or docset.
+- **does not yet** [use with caution] —
+  Avoid in timeless documentation because this phrase can become outdated. The phrase can also prematurely disclose product or feature strategy or inappropriately imply that a product or feature might change.
+  Recommended: The Google Cloud console doesn't support this IAM role.
+  Not recommended: The Google Cloud console does not yet support this IAM role.
+  For more information, see Timeless documentation.
+- **dojo** [don't use] —
+  Don't use. Instead, use a precise term that is accurate for the context, such as training or workshop.
+- **domain name registrar** —
+  Lowercase except at the beginning of a sentence, heading, or list item.
+- **Domain Name System Security Extensions (DNSSEC)** —
+  Write out and capitalize each word on first use. OK to abbreviate as DNSSEC after first use.
+- **double-tap** [Android] —
+  Hyphenate. Lowercase except at the beginning of a sentence, heading, or list item.
+- **downscope** [use with caution] —
+  Don't use down scope or down-scope
+  Recommended: Reducing the scope of a token helps you follow the principle of least privilege.
+  Recommended (first use): The IAM recommender helps you downscope (reduce) the permissions that are available to your users.
+- **drag** —
+  Use drag, not click and drag and not drag and drop.
+  OK to use drag-and-drop as an adjective.
+  Recommended: Drag the USER to the Authorized box.
+- **drop-down** [use with caution] —
+  In most cases, you can omit drop-down from phrases like drop-down list or drop-down menu, and just use list or menu. Include drop-down as a modifier only if the omission would cause ambiguity. Don't use drop-down as a standalone noun.
+- **dumb down** [don't use] —
+  Don't use. Instead, use a word or phrase what's happening, such as simplify or remove technical jargon.
+- **dummy variable** [don't use] —
+  Don't use to refer to placeholders. Instead, use placeholder.
+  Also don't use if referring to the concept in statistics known as a dummy variable. Instead, use alternate terms such as indicator variable, design variable, one-hot encoding, Boolean indicator, binary variable, or qualitative variable.
+
+## E
+
+- **each** —
+  Each refers to every individual item taken individually, not to a group of items taken collectively. In other words, each isn't a synonym for all. For example, a list of each item is ambiguous; a list of all the items or a list of the items is generally clearer.
+- **earlier** —
+  Use for a range of version numbers, not lower.
+  Recommended: Use version 2.2 or earlier.
+  Not recommended: Use version 2.2 or lower.
+  In Android documentation, don't use earlier for a range of version numbers. Instead, use lower.
+  When referring to a position in a document, use earlier or preceding, not higher.
+- **easy, easily** [use with caution] —
+  What might be easy for you might not be easy for others. Try eliminating this word from the sentence because usually the same meaning can be conveyed without it.
+- **ecommerce** —
+  Not e-commerce.
+- **edge availability domain** —
+  Don't use edge availability zone, metro availability domain, or metro availability zone. Don't shorten to EAD.
+- **e.g.** [don't use] —
+  Don't use. Instead, use phrases like for example or such as. Many people confuse e.g. and i.e.
+- **egress** —
+  When referring to the networking term, use lowercase.
+- **either** —
+  When using either, use parallel syntax.
+  Recommended: Do either option 1 or option 2.
+  Recommended: Either do option 1 or do option 2.
+  Not recommended: Either do option 1 or option 2.
+  In general, use either only for a choice between two things, not for a choice among multiple things. Writing either A or B or C will distract some readers, but if it's the best phrasing for your situation, then use it.
+- **element** —
+  In HTML and XML, a tag is a component of an element that indicates the start or end of the element. (For example, the <i> start tag indicates the beginning of the <i>example</i> element.) In general, don't use the term tag to refer to an entire element.
+- **email** —
+  Not e-mail, Email, or E-mail.
+  Don't use as a verb.
+  Use a specific verb in front of the word. For example, send email. This construction is better for translation and a global audience.
+- **emoji** —
+  Use emoji for both singular and plural forms. See Don't know the difference between emoji and emoticons? Let me explain and What's the Plural of Emoji?
+- **enable** —
+  In procedures, use the appropriate label and action for the UI element that the user interacts with. When describing a user action or the state of a UI element, use a more precise term where possible. It's OK to use enable when not referring to a person.
+  For turning on or activating an option or feature, use enable or turn on consistently: Use the same term in introductory text as described in the procedure. Use the same term throughout the document unless there's a difference in the UI elements for different procedures.
+  Recommended: To enable the API, click the toggle.
+  Recommended: Enable the API for your project.
+  For making it feasible to do something, use lets you.
+  Recommended: The API lets you detect features in images.
+  Not recommended: The API enables you to detect features in images.
+  Not recommended: The API allows you to detect features in images.
+  In Google Workspace documentation, if possible, use turn on or on instead. If referring to the state of a UI element, use available.
+- **endpoint** —
+  Not end point.
+- **enter** —
+  Use enter to refer to the user entering text. If it's important to not press Enter, explicitly say so. See also type.
+  Recommended: In the Owner box, enter your name.
+  Recommended: In the Size box, type a font size.
+- **ephemeral external IP address** —
+  Don't use ephemeral IP address or external IP address to refer to ephemeral external IP addresses.
+- **error-prone (adjective)** —
+  Hyphenate. Lowercase except at the beginning of a sentence, heading, or list item.
+- **etc.** [use with caution] —
+  Avoid using etc., and so forth, and and so on wherever possible. If you really need to use one, use etc. Always include the period, even if a comma follows immediately after.
+  Recommended: Your app might experience problems such as instability or high latency.
+  Recommended: Your app might experience problems, including instability or high latency.
+  Not recommended: Your app might experience instability, high latency, and so on.
+  Not recommended: Your app might experience instability, high latency, etc.
+  Not recommended: If your app experiences instability, high latency, etc., follow these steps:
+- **eventually** [use with caution] —
+  Avoid in timeless documentation because this word can become outdated. The word can also prematurely disclose product or feature strategy or inappropriately imply that a product or feature might change.
+  See also future and soon.
+  Recommended: This version of the SDK is deprecated.
+  Not recommended: This version of the SDK is deprecated and eventually will be no longer supported.
+  For more information, see Timeless documentation.
+- **execute** —
+  Verb commonly used to refer to function calls, SQL queries, and other processes. When the meaning is the same, use the simpler word run instead. If you need to use a more precise term for your context, use that term.
+- **expander arrow** —
+  The UI element used to expand or collapse a section of navigation or content. If you describe this element, use the terms expander arrow and expandable section
+  Don't use terms like expando or zippy.
+- **exploit** —
+  Don't use exploit to mean "use."
+  Only use exploit in the negative sense, such as to describe exploiting a security vulnerability.
+- **external VPN gateway** —
+  Write external and gateway all lowercase except at the beginning of a sentence, heading or list item.
+- **extract** —
+  Use instead of unarchive, uncompress, untar, or unzip.
+
+## F
+
+- **fat** [don't use] —
+  Don't use. Instead, use a precise modifier that conveys the appropriate meaning. For example, use high-capacity network connection instead of fat connection or full-featured client instead of fat client.
+  Instead of using fat in a negative sense, such as trim the fat, refer in a more concrete manner to the removal of unused items.
+  OK to use as an acronym when referring to file allocation table (FAT).
+- **female adapter** [don't use] —
+  Don't use. Instead, use a genderless word like socket.
+- **Fast Healthcare Interoperability Resources (FHIR)** —
+  Refer to a FHIR (pronounced "a fire," as in "a FHIR store"), not an FHIR. For more information, see Indefinite articles before abbreviations.
+- **filename** —
+  Not file name
+- **file system** —
+  Not filesystem.
+- **fill in; fill out** —
+  Use fill in when referring to entering information in individual fields.
+  Recommended: Fill out the questionnaire. Be sure to fill in the required fields.
+- **final solution** [don't use] —
+  Don't use. Instead, use solution as a standalone term or, depending on the context, definitive, optimal, best, or last solution.
+- **fintech** —
+  Write out on first mention: financial technology (fintech). Don't use FinTech or fin-tech.
+- **firewalls** —
+  Don't use in Compute Engine or networking documentation. Instead, use firewall rules.
+  Exception: If you're explaining how firewall rules work, you can explain that every network has an implied virtual distributed firewall.
+  Outside of Compute Engine or networking documentation, the term firewalls is acceptable.
+- **first class, first-class, first-class citizen** [don't use] —
+  Don't use first class or first-class citizen. Instead, use another term that's appropriate for the context, such as higher-order, anonymous, or nested, or loosely describe the specific characteristics or features of the entity, resource, language, or framework.
+  Recommended: These widgets have full access to the event system and lifecycle hooks.
+  Not recommended: The widgets are first-class components in the UI framework.
+  Recommended: Virtual machines are higher-order resources that can participate in resource groups and are integrated in a variety of identity, networking, and storage services.
+  Not recommended: Virtual machines are treated as first-class resources across the identity, networking, and storage services.
+  For more information, see Write inclusive documentation.
+- **following** —
+  It's not necessary to use a noun after following unless it helps provide clarity and enables accessibility. See Tables.
+  Recommended: ... in the following code sample ...
+  Recommended: ... in the following table ...
+  Recommended: ... do the following: ...
+- **foo** [use with caution] —
+  Avoid when possible even though it's a common term in the developer community. Instead, use a clearer and more meaningful placeholder name.
+- **for example** —
+  When you introduce an example using the phrase for example, follow the phrase by a comma. For clarity, when introducing an example, separate the example using dashes, commas, or parentheses from the rest of the sentence as appropriate, or introduce the example in a separate sentence.
+  Recommended: Enter a name for the instance—for example, my-instance-99.
+  Recommended: Enter a six-digit hex number (for example, 228B22), and then click OK.
+  Recommended: Enter a six-digit hex number, and then click OK. For example, if you want the color forest green, enter 228B22.
+  For more information, see Format examples.
+- **for instance** [use with caution] —
+  Don't use the phrase for instance to introduce examples to avoid confusion with the noun instance. Instead, use for example, like, or such as. For more information, see for example.
+- **frontend** —
+  Not front-end or front end.
+- **functionality** [use with caution] —
+  Use with caution. With respect to hardware or software, functionality refers to a set of associated functions or capabilities and how they work. However, the word is sometimes overused, especially when the intended meaning is capabilities or features.
+- **future, in the future** [use with caution] —
+  Avoid in timeless documentation because this word or phrase can become outdated.
+  See also eventually and soon. For more information, see Timeless documentation.
+
+## G
+
+- **GBps** —
+  Short for gigabytes per second. By convention, we don't use GB/s. For more information, see Units of measurement.
+- **Gbps** —
+  Short for gigabits per second. By convention, we don't use Gb/s. For more information, see Units of measurement.
+- **gcloud CLI** [Google Cloud] —
+  Use the full name Google Cloud CLI the first time that you mention the product on a page.
+- **gender-neutral he, him, or his (or she or her)** [don't use] —
+  Don't use. Instead, use the singular they (see Jane Austen and other famous authors violate what everyone learned in their English class). Don't use he/she or (s)he or other such punctuational approaches. For more information, see Pronouns.
+- **generative AI** —
+  Spell out generative. Use sentence case.
+  Don't use gen AI or Gen AI.
+  Don't hyphenate generative AI as an adjective unless you must do so for clarity. See also AI.
+- **ghetto** [don't use] —
+  Don't use. Instead use more precise terms like clumsy, workaround, or inelegant to refer to code that isn't in a production-ready state.
+- **gimp, gimpy** [don't use] —
+  Don't use. Instead, use precise, non-figurative language to refer to a deficiency in a component.
+  OK to use in reference to companies, tools, software packages, and other entities that use the term in their names.
+- **GKE node** —
+  Use when first introducing GKE nodes on a given page. For subsequent mentions, you can use node. A GKE node is a worker machine that runs containerized applications and other workloads. The machine is a Compute Engine VM that GKE creates during cluster creation. See also virtual machine (VM) instance.
+- **Google, Googling** [use with caution] —
+  Don't use as a verb or gerund. Instead, use search with Google.
+- **Google Account, Google Accounts** —
+  Capitalize Account.
+- **Google API Client Library for LANGUAGE (Java, .NET, etc.)** —
+  On second and subsequent use, you can abbreviate to LANGUAGE client library.
+- **Google API Console, Google APIs Console** [don't use] —
+  Don't use. For more information, see console.
+- **Google Cloud** —
+  Not GCP, Cloud Platform, or Cloud.
+- **Google Cloud console** —
+  If you're only discussing the Google Cloud console, it's OK to shorten to the console after first use on a given page.
+  Use the before the console name. For more information, see console.
+- **Google Cloud project ID** —
+  Not Cloud project ID or GCP project ID. You can also shorten to project ID, but be aware that that term is ambiguous in some contexts.
+- **Google Developers Console** [don't use] —
+  Don't use. For more information, see console.
+- **Google I/O** —
+  Not I-O or IO.
+- **Google Play services** —
+  Write services in lowercase.
+- **Google Play services SDK** —
+  Write services in lowercase.
+- **grandfather clause, grand-father clause, grand father clause** [don't use] —
+  Don't use. See grandfathered.
+- **grandfathered** [don't use] —
+  Don't use to refer to something that is allowed to violate a rule because it predates the rule. Instead, use an adjective like legacy or exempt or a verb like made an exception.
+  Recommended: The app is exempt because it was released before the new requirements were announced.
+  Not recommended: The app is grandfathered in because it was released before the new requirements were announced.
+- **gray-box, grey-box** [use with caution] —
+  Avoid using gray-box, graybox, or gray box to describe testing.
+  To refer to testing that's a combination of clear and opaque testing methods, describe exactly what it's doing.
+  If you need to refer to this type of testing after you describe it, consider using a more precise term for clarity, such as translucent-box testing.
+- **grayed-out, greyed-out, gray out, grey out** [don't use] —
+  Don't use. Instead, use unavailable.
+- **grayhat, greyhat, gray hat, grey hat** [don't use] —
+  Don't use. Follow the guidance for black hat when referring to someone violating rules or laws.
+- **graylist, greylist, gray list, grey list, gray-list, grey-list** [don't use] —
+  Don't use. See blacklist.
+- **graylisted, greylisted, gray listed, grey listed, gray-listed, grey-listed** [don't use] —
+  Don't use. See blacklist.
+- **graylisting, greylisting, gray listing, grey listing, gray-listing, grey-listing** [don't use] —
+  Don't use. See blacklist.
+- **gsutil** [Google Cloud] —
+  In the Google Cloud context, use code font for both the name of the command-line utility and the command.
+- **guru** [don't use] —
+  If possible, use a more precise term. For example, if you mean expert or teacher, use those terms.
+- **guys, you guys** [don't use] —
+  When referring to a group of people use non-gendered language, such as everyone or folks.
+- **gypsy** [don't use] —
+  Don't use. To refer to the people, use Romani, Roma, or Traveller, as appropriate for the specific group you're referring to. In place of metaphorical uses of the term, use more precise phrases.
+
+## H
+
+- **hamburger, hamburger menu** [don't use] —
+  Don't use. Instead use the aria-label for that particular icon. For example, Menu. For more information, see Buttons and icons.
+- **hands off, hands-off** [don't use] —
+  Use a less figurative phrase, such as automated. If you're referring to a group that doesn't do anything during a process, write a description.
+- **hands on, hands-on** [don't use] —
+  Use a less figurative phrase, such as customizable, or write a description of the activity.
+- **hang, hung** [don't use] —
+  Don't use to refer to a computer or system that is not responding. Instead, use stop responding or not responding. For more information, see Avoid figurative language.
+- **happiness and satisfaction** —
+  Use happiness when referring to a customer's perception of a site's reliability. Use satisfaction when referring to whether the site meets the customer's needs.
+  Site reliability engineering (SRE) content generally refers to measuring customer happiness instead of customer satisfaction. The two phrases are not equivalent.
+  The distinction the SRE documentation makes is between satisfying a need (a dispassionate act) and establishing an emotional response (creating happiness). Although it is difficult to measure happiness precisely, SRE uses service level indicators (SLIs) to quantify user perception. For example, a customer might feel a "need" to watch a show on TV. If the show is available, the customer's need is satisfied. But if playback is slow or choppy, the customer might not be happy.
+  For more information about SRE and measuring reliability, see The Happiness Test.
+- **hardcode (verb), hardcoded (adjective)** —
+  Don't hyphenate.
+- **he, him, his** [use with caution] —
+  Don't use a gendered pronoun except for a specific individual of known gender. Use they and their for the general singular pronoun.
+- **healthcare** —
+  Not health care or health-care.
+- **health check** [use with caution] —
+  Use with caution. When describing an action taken for a computer system, only use the term health check if this is the term that appears in the interface. Be certain to remove any ambiguity regarding whether the term refers to health in the medical sense.
+  Use detailed, non-figurative language as much as possible, such as referring to a node being responsive instead of referring to a node being healthy.
+- **healthy** [use with caution] —
+  Don't use. See health check.
+- **high availability (noun), high-availability (adjective)** —
+  Spell as high availability when used as a noun and as high-availability when used as an adjective. See also load balancing (noun), load-balancing (adjective).
+  Lowercase except when part of a product name, but OK to abbreviate as HA after first use.
+- **higher** —
+  Don't use for a range of version numbers. Instead, use later.
+  Don't use to refer to a position in a document. Use earlier or preceding.
+  Don't use to refer to a position in the UI. Instead, write instructions that avoid directional language. For more information, see Writing accessible documentation.
+  In Android documentation, use higher for a range of version numbers, not later.
+  A release with the highest version number might not be the latest version. For example, if version 2.0 of an operating system receives a bug-fix update after version 3.0 has been released, then version 2.0.1 might be the latest version, even though its version number is lower than 3.0.
+- **high performance computing (HPC)** —
+  Don't hyphenate. Lowercase except at the beginning of a sentence, heading, or list item.
+- **hit** [don't use] —
+  Don't use as a synonym for click, press, or type.
+- **hold the pointer over** —
+  Only use this verb phrase in the following cases: When the user needs to hold their mouse over a UI element, but not click the UI element. This action involves waiting for the UI to react—for example, waiting for a tooltip to open or waiting for a submenu to open. When the duration of time is important. The phrase point to is more common.
+  See also point to.
+  Recommended: In the Admin menu, hold the pointer over File, and then click New.
+  Not recommended: In the Admin menu, hover over File, and then click New.
+- **holiday, the holidays** [use with caution] —
+  Don't use to refer to the end of the year. Instead, refer to specific quarters or months.
+- **home screen** [Android] —
+  Two words in Android contexts; not homescreen or home-screen.
+- **hostname** —
+  Not host name.
+- **hot** —
+  When possible, avoid jargon like hot failover, hot standby, and hot spare. If you use one of these phrases, define it on first use and use it consistently throughout the document. However, see hotspot.
+- **hotspot** —
+  In databases, hotspots occur when a small number of nearby rows are accessed frequently in a short period of time, causing CPU spikes and affecting performance. Use hotspot and hotspots as nouns. Don't use verb and gerund forms such as hotspotting, because they translate less consistently.
+  When you use hotspot, define it the first time that you use it on a page as you normally do with jargon.
+  Recommended: Hotspots in one table can affect the performance of other tables.
+  Not recommended: Hotspotting in one table can affect the performance of other tables.
+- **housekeeping, house keeping, house-keeping** [don't use] —
+  Don't use. Instead, use less figurative and more precise terms, such as maintenance and cleanup.
+- **hover** [don't use] —
+  Don't use. Instead use hold the pointer over.
+- **HTTPS** —
+  Not HTTPs.
+
+## I
+
+- **IaaS** —
+  Write out on first mention: infrastructure as a service (IaaS).
+- **IAM** —
+  When referring to the Google Cloud product, spell it out on first use: Identity and Access Management (IAM).
+  When referring to UI text, write this term the way it's written in the UI.
+  When referring to the general practice of identity and access management, spell it out in lowercase on first use and include a parenthetical comment:
+  Recommended: Identity and access management (generally referred to as IAM) is the practice of granting the right individuals access to the right resources for the right reasons.
+- **ID** —
+  Not Id or id, except in string literals or enums.
+  In some contexts, it's best to spell out as identifier or identification.
+- **i.e.** [don't use] —
+  Don't use. Instead, use phrases like that is. Many people confuse e.g. and i.e.
+- **if** —
+  Wondering whether to use if or whether? See whether.
+  Although it is common in casual usage to omit the word then in if...then statements, you should include helper words like then in technical documentation. For more information, see Use clear, precise, and unambiguous language.
+- **image** —
+  Image by itself doesn't localize well because of its many meanings. Consider adding context—for example, disk image or container image.
+- **impact** [use with caution] —
+  Use only as a noun. Instead of writing that something has an impact, use the word affect.
+  Recommended: This issue affects user experience.
+  Acceptable: This issue has an impact on user experience.
+  Not recommended: This issue impacts user experience.
+- **index** —
+  Use the plural indexes unless there is a domain-specific reason (for example, a mathematical or financial context) to use indices.
+- **ingest** —
+  Use import, load, or copy when referring to simple movement of data. Use ingest only when referring to such operations that also involve significant processing of the data.
+- **ingress** —
+  When referring to the networking term, use lowercase. When referring to the GKE term or API, capitalize Ingress.
+- **in order to** [use with caution] —
+  Avoid in order to; instead, use to.
+  Use in order to when needed to clarify meaning or to make something easier to read.
+  Recommended: You can use monitoring to help identify issues.
+  Not recommended: You can use monitoring in order to help identify issues.
+  Recommended: The infrastructure is required in order to support search.
+  Not recommended: The infrastructure is required to support search.
+- **inline** —
+  One word as an adjective, inline, not in line or in-line.
+- **instance group** —
+  Don't abbreviate to IG. See also managed instance group.
+- **intercluster** —
+  Use unhyphenated intercluster, not inter-cluster.
+- **interconnectAttachment** —
+  Use when referring to the API. Otherwise, use VLAN attachment.
+- **Interconnect connection** —
+  Only use Interconnect connection relative to a product as follows: CDN Interconnect connection Cloud Interconnect connection Dedicated Interconnect connection Partner Interconnect connection OK to use connection on subsequent mentions.
+  When you're referring to a Google Cloud product, always specify the product name. Don't use Interconnect or interconnect as standalone terms, and don't use generic terms like cloud interconnect connection or cross-connect.
+- **Interconnect connection location** —
+  Only refer to an Interconnect connection location in context of a specific product, for example CDN Interconnect.
+  OK to also use colocation facility.
+- **interconnect type** [don't use] —
+  Don't use. Instead, use connection type. Examples of connection types are a dedicated connection or a connection provided by a service provider.
+- **interface** —
+  OK to use as a noun.
+  Don't use as a verb. Instead, use interact, talk, speak, communicate, or other similar terms.
+- **internal DNS** —
+  Write internal all lowercase except at the beginning of a sentence, heading, or list item.
+- **Internationalized Domain Name (IDN)** —
+  Write out and capitalize each word on first use. OK to abbreviate as IDN after first use.
+- **internet** —
+  Lowercase except at the beginning of a sentence, heading, or list item.
+- **Internet Key Exchange (IKE)** —
+  Write out and capitalize each word on first use. OK to abbreviate IKE after first use.
+- **I/O (see also Google I/O)** —
+  Not I-O or IO.
+- **IoT** —
+  OK to use as an abbreviation for Internet of Things. Note the lowercase o.
+- **IPsec** —
+  Not IPSec or IPSECShort.
+  Short for Internet Protocol Security. No need to spell out on first mention.
+
+## J
+
+- **jank, janky** [use with caution] —
+  Use only to refer to a glitch or problem with graphics that is caused by a loss of data or inadequate refresh rate. Don't use otherwise. Use a less figurative term to refer to something of poor or unreliable quality.
+- **just** [use with caution] —
+  Avoid. Usually, just is a filler word that you can delete without affecting your meaning.
+  Recommended: BigQuery skips the row.
+  Not recommended: BigQuery just skips the row.
+  If your meaning is unclear without just, then use a more specific term such as only, instead, or previously, or revise your language to be more specific. (Even if one of these replacement terms fits, you often don't need it.)
+  Recommended: You can run DML statements in the same way that you'd run a SELECT statement.
+  Not recommended: You can run DML statements just as you'd run a SELECT statement.
+  Recommended: Let a user query only the table without full dataset access.
+  Recommended: Let a user query the table without full dataset access.
+  Not recommended: Let a user query just the table without full dataset access.
+  Sometimes, just is useful for conveying that one approach is simpler than another. In those cases, use just instead of simply.
+  Recommended: Use the namespace ID namespace:example-kind or just example-kind.
+
+## K
+
+- **k8s** [don't use] —
+  Don't use. Instead, use Kubernetes.
+- **KBps** —
+  Short for kilobytes per second. By convention, we don't use KB/s. For more information, see Units of measurement.
+- **Kbps** —
+  Short for kilobits per second. By convention, we don't use Kb/s. For more information, see Units of measurement.
+- **kebab, kabob, kebab menu, kabob menu** [don't use] —
+  Don't use. Instead use the aria-label for that particular icon. For example, More. For more information, see Buttons and icons.
+- **kebab case, kabob case, kebab-case, kabob-case** [don't use] —
+  Don't use. Instead, use dash-case.
+- **key** —
+  Don't use as an adjective in the sense of crucial or important.
+  If you use key as a noun, specify which kind of key you're referring to on first mention, because there are many kinds of keys in technical contexts.
+- **key pair** —
+  A pair of keys, such as a public key and a private key. Contrast with key-value pair, which refers to a pairing that specifies a value for a variable (as in configuration files).
+- **key ring** —
+  Use instead of keyring (without the space) when referring to a grouping of Cloud KMS keys.
+- **key-value pair** —
+  Use instead of key/value pair or key value pair.
+- **kill** [use with caution] —
+  Avoid when possible. Instead, use words like stop, exit, cancel, or end. For exceptions to this rule, see Documenting command-line syntax.
+
+## L
+
+- **lame** [don't use] —
+  Don't use. Instead, use precise, non-figurative language to refer to a deficiency in a component.
+- **later** —
+  Use for a range of version numbers, not higher.
+  Recommended: Use version 2.2 or later.
+  Not recommended: Use version 2.2 or higher.
+  Not recommended: Use version 2.2+.
+  A release with the highest version number might not be the latest version. For example, if version 2.0 of an operating system receives a bug-fix update after version 3.0 has been released, then version 2.0.1 might be the latest version, even though its version number is lower than 3.0.
+  In Android documentation, don't use later for a range of version numbers. Instead, use higher.
+  When referring to a position in a document, use later or following, not below.
+- **latest** [use with caution] —
+  Avoid in timeless documentation because this word can become outdated.
+  If you must use latest, give the reader a reference point—for example, a version number or release date.
+  Recommended: To help keep your system secure, install the latest version of the tools.
+  Recommended: The June 2021 release includes the latest tools that help secure your system.
+  Not recommended: The product includes the latest tools that help secure your system.
+  For more information, see Timeless documentation.
+- **learnings** [don't use] —
+  Don't use. Instead, refer to knowledge or things that you learned.
+- **left-nav, right-nav** [don't use] —
+  Don't use directional language. For more information, see Writing accessible documentation.
+  If referring to applications, use navigation menu.
+  If referring to navigational elements for documentation, use content navigation menu.
+- **legacy** —
+  If possible, use a more precise term. If you do use legacy, include or point to a definition to clarify what you mean in the current context. Don't use legacy with any sort of pejorative connotation.
+- **let's (as a contraction of let us)** [don't use] —
+  Don't use if at all possible.
+  Not recommended: Let's click the OK button now.
+- **Letter of Authorization and Connecting Facility Assignment (LOA-CFA)** —
+  Write out and capitalize each word on first use. OK to abbreviate as LOA-CFA after first use.
+- **leverage** [use with caution] —
+  Avoid using if you mean use. If possible, use a more precise term. For example, use, build on, or take advantage of.
+- **lifecycle** —
+  Not life cycle or life-cycle.
+- **like** —
+  It's OK to use like for either drawing comparisons (in the sense of similar to) or introducing examples (in the sense of such as).
+  Recommended: Common I/O operations, like reading files or making network requests, can be asynchronous.
+  Recommended: The new compression algorithm works like a dictionary encoder, replacing repeated strings with shorter codes.
+  See also such as. For more information, see Format examples.
+- **limits** —
+  In an API context, limit often refers to usage limits (number of queries allowed per second or per day). Where possible, specify the kind of limit that you mean, such as usage limit or service limit; the word limit can refer to many different kinds of limits, including rules about acceptable use. See also quota.
+- **lint** —
+  Write both command-line tool name and command in lowercase. Use code font except where inappropriate.
+- **little-endian** —
+  Hyphenate. Lowercase except at the beginning of a sentence, heading, or list item.
+  Recommended: The codebase assumes little-endian byte ordering.
+  Not recommended: The codebase assumes Little Endian byte ordering.
+  Not recommended: The codebase assumes Little-endian byte ordering.
+  Not recommended: The codebase assumes little endian byte ordering.
+- **livestream** —
+  Not live stream.
+- **load balancing (noun), load-balancing (adjective)** —
+  Spell as load balancing when used as a noun and as load-balancing when used as an adjective. See also high availability (noun), high-availability (adjective).
+- **lock screen** [Android] —
+  Two words in Android contexts; not lockscreen or lock-screen.
+- **login (noun or adjective), log in (verb)** —
+  For the verb form, sign in is generally better.
+  If you're documenting a tool that uses the term log in, then use that term.
+- **long press** [don't use] [Android] —
+  In Android documentation, don't use. Instead, use touch & hold. (Not touch and hold.)
+- **long-running operation** —
+  Not long running operation.
+  OK to abbreviate as LRO after the first use.
+- **lower** —
+  Don't use for a range of version numbers. Instead, use earlier.
+  Don't use to refer to a position in a document. Instead, use later or following.
+  Don't use to refer to a position in the UI. Instead, write instructions that avoid directional language. For more information, see Writing accessible documentation.
+  In Android documentation, use lower for a range of version numbers, not earlier.
+
+## M
+
+- **male adapter** [don't use] —
+  Don't use. Instead, use a genderless word like plug.
+- **man hours, manhours, man-hours** [don't use] —
+  Avoid using gendered terms. Instead use terms like person hours.
+- **man-in-the-middle (MITM)** [don't use] —
+  Avoid using gendered terms. Instead use terms like on-path attacker or person-in-the-middle (PITM).
+- **managed instance group (MIG)** —
+  OK to abbreviate to MIG on subsequent mention. See also instance group.
+- **manmade, man made** [don't use] —
+  Avoid using gendered terms. Instead use a word like artificial, manufactured, or synthetic.
+- **manned** [don't use] —
+  Avoid using gendered terms. Instead use terms like staffed or crewed.
+- **manpower, man power, man-power** [don't use] —
+  Avoid using gendered terms. Instead use terms like staff or workforce.
+- **Markdown** —
+  Always capitalized, even when you're referring to a nonstandard version.
+- **master** [don't use] —
+  Use with caution. Never use in conjunction with slave. Where possible, replace master with a specific term that is accurate for the context, such as primary, main, original, parent, initiator, driver, controller, manager, mixer, aggregator, publisher, leader, or active. Guidance Recommended Not recommended Don't use master in conjunction with slave in any context. Cloud SQL primary/replica Cloud SQL master/slave Avoid using master where possible. GKE control plane Jenkins controller root key (in security) primary key (in databases) GKE master plane Jenkins master master key (in security) master key (in databases)
+  If the command or code that you're documenting uses the literal word master, then use this word only in direct reference to the code item (formatted as code), make it clear what you're referring to, and use the new term thereafter.
+  See also slave.
+- **Material Design** —
+  Capitalize each word in Material Design.
+- **matrix** —
+  Use the plural matrixes unless there is a domain-specific reason (for example, a mathematical context) to use matrices.
+- **may** —
+  In general, reserve for official policy or legal considerations.
+  To convey possibility, use can or might instead.
+  To convey permission, use can instead.
+  See also can, could, might, must, should, and would.
+  For information about clarifying who's performing an action, see Active voice.
+- **MBps** —
+  Short for megabytes per second. By convention, we don't use MB/s. For more information, see Units of measurement.
+- **Mbps** —
+  Short for megabits per second. By convention, we don't use Mb/s. For more information, see Units of measurement.
+- **media type** —
+  In general, use the term media type. In contexts where you need to refer to a content type—For example, if you mention the Content-Type HTTP header—it's okay to use content type instead, to avoid confusion. Don't use MIME type.
+- **meta*** —
+  See guidance about hyphens with prefixes.
+- **metafeed** —
+  Not meta-feed.
+- **metageneration** —
+  Not meta-generation.
+- **method** —
+  In programming contexts where method refers to a member of a class (as in Java), avoid also using the word generically to mean "approach" or "manner."
+- **metropolitan area (metro)** —
+  In networking, a metro is a city where a colocation facility is located.
+- **microservices** —
+  Not Microservices or micro-services.
+- **might** —
+  Use to convey possibility or an uncertain outcome (for example, "You might be prompted to enter your credentials").
+  See also can, could, may, must, should, and would.
+  For information about clarifying who's performing an action, see Active voice.
+- **MIME type** [use with caution] —
+  MIME stands for "Multipurpose Internet Mail Extensions," and was originally used to refer to email standards. Don't use MIME when you mean media type. If you feel that might be ambiguous to an audience familiar with the term MIME, then you can write media (MIME) type for clarity.
+- **mobile** [don't use] —
+  Don't use mobile as a standalone noun. Instead, specify mobile phone, or if you're talking about more than phones, then use mobile device.
+- **mobile data** —
+  Use instead of cellular data.
+- **mobile device** —
+  Use mobile device when you're referring to more than phones (for example, tablets and phones). It's OK to use phone (without mobile) when the context is clear.
+- **mobile network** —
+  Use instead of cellular network.
+- **mobile phone** —
+  If you're talking about more than phones, then use mobile device. It's OK to use phone (without mobile) when the context is clear.
+- **mom test** [don't use] —
+  Don't use mom test, grandmother test, grandma test, or girlfriend test. Instead, use terms like beginner user test or novice user test.
+- **monkey, monkey test** [don't use] —
+  Don't use monkey to refer to people. When referring to tests, refer to the specific function. For example: automated, random tests.
+- **multi*** —
+  See guidance about hyphens with prefixes.
+- **multi-cluster** —
+  Hyphenate. We generally prefer to close prefixed words, but this is an exception because it's an established term.
+- **multi-region, multi-regional** —
+  Hyphenate when referring to a Google Cloud location that consists of more than one region.
+  You can use multi-regional as an adjective in the context of multi-regions, but consider multi-region as an attributive noun instead, such as in "The dataset is in the EU multi-region location." Use multiregional in other contexts.
+- **multi-service** —
+  Hyphenate. We generally prefer to close prefixed words, but this is an exception because it's an established term.
+- **multi-tenancy** —
+  Hyphenate. We generally prefer to close prefixed words, but this is an exception because it's an established term.
+- **must** —
+  Use to describe a required action or state (for example, "You must have the Editor role"). You can also write you need in order to convey a requirement.
+  See also can, could, may, might, should, and would.
+  For information about clarifying who's performing an action, see Active voice.
+
+## N
+
+- **N/A** —
+  Not NA. Spell out as not available or not applicable on first reference.
+- **name server** —
+  Not nameserver.
+- **namespace** —
+  Not name space.
+- **native** [use with caution] —
+  Avoid using native to refer to people.
+  When referring to software products, try to use a more precise term—for example, use built-in to describe a feature that's part of a product.
+  The term native isn't necessarily clear—for example, cloud-native could mean that something was written for the cloud, or that it's built in to a cloud platform, or that it currently exists in a cloud platform.
+  Alternatives to a term like cloud-native could include: modern cloud, born in the cloud, cloud first, and cloud-born.
+- **navigation bar** —
+  Don't use to refer to a navigation menu. For more information, see Navigation menu.
+- **neither** —
+  Write neither A nor B, not neither A or B.
+- **network IP address** [don't use] —
+  Don't use. Instead, use internal IP address.
+- **new, newer** [use with caution] —
+  Avoid in timeless documentation because this word can become outdated.
+  New also implies that the reader knows the older product and that labeling something as new is therefore meaningful.
+  If you must use new, give the reader a reference point—for example, a version number or release date.
+  Don't use newer to refer to a specific version of a product. Instead, use later. Make sure that you provide a version number or release date by which to understand later. In Android documentation, use higher instead of later.
+  Recommended: The service's network analysis feature reports on network health.
+  Not recommended: Network analysis, a new feature in the service, reports on network health.
+  For more information, see Timeless documentation.
+- **ninja** [don't use] —
+  Don't use to refer to a person. Instead, use a term such as expert. OK to use in reference to companies, tools, software packages, and other entities that use the term in their names.
+- **non*** —
+  See guidance about hyphens with prefixes.
+- **nonce** [use with caution] —
+  Use with caution: this term has a secondary slang meaning that can cause confusion for global readers. Always define the term on first use, and only use it in specific technical contexts such as authentication and blockchain.
+  In end-user documentation and other contexts, use a more descriptive phrase, such as a number that will be used only once.
+- **non-key** —
+  An exception to our usual preference for closed forms.
+- **NoOps** [don't use] —
+  Don't use. Instead, use fully managed. If you must include the term, define it at first use with language such as fully managed or no operations, but not non-operational. Don't use noops.
+  For an instruction that does nothing, use no-op or the specific instruction name for your context.
+- **NoSQL** —
+  Not No-SQL or No SQL.
+- **notification drawer** [Android] —
+  In Android contexts, don't hyphenate. Lowercase except at the beginning of a sentence, heading, or list item.
+- **now** [use with caution] —
+  Avoid when describing features of products or services because this word is implied.
+  If the intent of the text is a comparison between past and present, you can use now—for example, "In versions of the tool earlier than 1.10, you could use only the default value, but now you can assign a custom value."
+  Recommended: This feature lets you use combinations of user properties.
+  Not recommended: This feature now lets you use combinations of user properties.
+  For more information, see Timeless documentation.
+- **nuke** [don't use] —
+  Don't use. Instead use remove or attack. For example, a denial-of-service attack.
+
+## O
+
+- **OAuth 2.0** —
+  Not OAuth 2, OAuth2, or Oauth.
+- **off-the-shelf, commercial off-the-shelf (COTS)** [don't use] —
+  Use more widely understood terms like ready-made, prebuilt, standard, or default.
+- **old, older** [use with caution] —
+  Don't use to refer to a previous version of a product. Instead, use earlier.
+  Make sure that you provide a version number by which to understand earlier.
+  In Android documentation, use lower instead of earlier.
+  Recommended: This functionality doesn't work in versions earlier than 1.17.0.
+  Not recommended: This functionality doesn't work in older versions.
+  For more information, see Timeless documentation.
+- **omnibox** [don't use] —
+  Don't use. Instead, use address bar.
+- **once** —
+  If you mean after, then use after instead of once.
+- **on-premises** —
+  Not on prem, on premise, or on-premise. Hyphenate when used as any part of speech.
+  Use to refer to a customer's resources that they manage in their own facilities. Don't use peer.
+  It can be acceptable to use on-premises as a noun when it would be awkward to repeatedly write out a full phrase like an on-premises environment. However, it's preferable to use the more complete phrase whenever possible.
+  Recommended: An on-premises database.
+  Recommended: The database runs on-premises.
+  OK: Moving data from on-premises to Google Cloud.
+- **OS** —
+  OK to use as a shortening of "operating system."
+- **outpost** [don't use] —
+  Don't use. Instead, use channel.
+  Recommended: social media channels
+- **outside the box, out of the box, out-of-the-box** [use with caution] —
+  Avoid using in a figurative way. OK to use literally.
+- **overview screen** [don't use] [Android] —
+  In Android documentation, don't use. Instead, use recents screen.
+
+## P
+
+- **PaaS** —
+  Write out on first mention: platform as a service (PaaS).
+- **page** —
+  Use page to refer to the following: A whole web page, which can include text, images, links, banners, navigational panes, and other features. A sub-page of a console in particular. See also documentation or document or documents.
+  Recommended: To refresh the page, press F5.
+- **parameter** —
+  In our API documentation, parameter is usually short for query parameter; it's a NAME=VALUE pair that's appended to a URL in an HTTP GET request. In some contexts, however, the term can have other meanings.
+- **parent-child or parent/child** —
+  Not parent – child or parent—child.
+- **path** —
+  Avoid using filepath, file path, pathname, or path name if possible.
+- **peer gateway** —
+  Don't use on-premises gateway when you mean a peer gateway. A peer gateway can be an on-premises device or service or another cloud gateway.
+- **peer network** —
+  Don't use on-premises network when you mean a peer network. A peer network can be an on-premises network or another cloud network.
+- **peering zone** —
+  Not peer zone.
+- **per** —
+  To express a rate, use per instead of the division slash (/), unless space constraints require the use of the slash. For more information, see Units of measurement.
+  Avoid per in contexts other than rate units.
+  Recommended: requests per day
+  Recommended: create a policy for each Pod
+  Recommended: according to the style guide
+  Recommended: in response to your request
+  Not recommended: requests/day
+  Not recommended: create a policy per Pod
+  Not recommended: per the style guide
+  Not recommended: as per your request
+- **performant** [use with caution] —
+  Avoid where possible. Instead, use a more precise term.
+  Recommended: an accurate machine learning model
+  Not recommended: a performant machine learning model
+- **persist** —
+  Don't use as a transitive verb. It's best to avoid using as a verb at all, especially in passive voice.
+  Recommended: To make the token persistent ...
+  OK: To make the token persist ...
+  Not recommended: The token is persisted ...
+  Not recommended: To persist the token ...
+- **persistent disk** —
+  Lowercase except at the start of a sentence.
+- **personally identifiable information (PII)** —
+  Some government agencies use the less common term personally identifying information; use this alternate term only in contexts where you're referring to a document that uses this term.
+- **pets versus cattle, pets vs. cattle, pets v. cattle** [don't use] —
+  Don't use. Instead, use more precise terms like persistent versus dynamic or manually configured versus automated. For more information, see Avoid figurative language.
+- **plain text** —
+  In most contexts, use plain text, but use plaintext in a cryptography context.
+- **please** [use with caution] —
+  Don't use please in the normal course of explaining how to use a product, even if you're explaining a difficult task.
+  Don't use the phrase please note.
+  Use please only when you're asking for permission or forgiveness—for example, when what you're asking for benefits you, inconveniences a reader, or suggests a potential issue with a product.
+  Recommended: If the issue persists, please contact your account representative.
+- **plugin (noun), plug-in (adjective), plug in (verb)** —
+  Use the noun form plugin when referring to the software component. Use the adjective form plug-in when referring to the action of installing a software component. Use the verb form plug in when you're describing the process of installing a software component.
+- **PM** —
+  See AM, PM.
+- **point to** —
+  Use to refer to the action of pointing the mouse pointer (focus). This action doesn't imply a length of time waiting for the UI to react to user action.
+  This is similar to the action hold the pointer over (hover). In most cases, it's better to use the verb phrase hold the pointer over if you want the user to wait for the UI to react.
+- **POJO** —
+  If you're not actually writing about a Plain Old Java Object for a Java audience, use simple object. You can write a simple object, similar to a POJO in Java if that helps your audience.
+- **PoP** —
+  Acronym for point of presence.
+  Recommended: point of presence (PoP)
+  Not recommended: point of presence (POP)
+- **pop-up, popup** —
+  Don't use.
+  To describe a window that appears and asks for, or presents, additional information, use dialog.
+  To describe a menu that rises from an interface (such as a right-click context menu), use menu.
+- **populate** —
+  OK to use if you're writing about a process populating a table or other entity. If you're writing about a person, use fill in.
+  Recommended: The SQL command populates the table with sample data.
+  Recommended: When you have finished filling in the form ...
+  Not recommended: When you have finished populating the form ...
+- **port** —
+  Use listen on (not to).
+- **portal** [use with caution] —
+  Don't use to refer to the Google Cloud console. For more information, see console.
+- **possible** [don't use] —
+  Don't use possible or impossible to mean you can or you can't.
+- **PostgreSQL** —
+  If the UI uses the name Postgres, it's OK to match the UI. Don't use PostgreSQL.
+- **postmortem** [use with caution] —
+  Avoid in general usage. Instead, use retrospective.
+  In disaster recovery (DR) and DevOps contexts, use blameless postmortem.
+- **practitioner** —
+  Avoid using without any supporting information to define the roles that you're referring to.
+  Recommended: The framework describes best practices for architects, developers, administrators, and other cloud practitioners.
+  Not recommended: The framework describes best practices for cloud practitioners.
+- **pre*** —
+  See guidance about hyphens with prefixes.
+- **prebuilt** —
+  Not pre-built.
+- **precapture** —
+  Not pre-capture.
+- **preemptible** —
+  Not pre-emptible or pre-emptive.
+- **pre-existing** —
+  Not preexisting.
+- **preferred pronouns** [don't use] —
+  Don't use. Instead, use pronouns.
+- **prerecorded** —
+  Not pre-recorded.
+- **pre-shared key** —
+  Not preshared key.
+- **presently, at present** [use with caution] —
+  Avoid because this word or phrase is implied. The word or phrase can also prematurely disclose product or feature strategy or inappropriately imply that a product or feature might change.
+  See also as of this writing and currently.
+  Recommended: This setting is required.
+  Not recommended: At present, this setting is required.
+  For more information, see Timeless documentation.
+- **press** —
+  Use when referring to pressing a key or a key combination to cause an action to occur. Also use for mechanical buttons.
+  For on-screen and soft (capacitive) buttons, use tap.
+  Recommended: Press Control+C (or Command+C on macOS).
+- **presubmit** —
+  Not pre-submit.
+- **primitive** [use with caution] —
+  Use with caution. Don't use primitive in a disparaging sense.
+- **project** [Google Cloud] —
+  In Google Cloud documentation, use Google Cloud project on first mention and in any context in which there might be ambiguity about what kind of project you're referring to.
+- **pros** [don't use] —
+  Don't use. Instead, use a more precise term, such as advantages.
+
+## Q
+
+- **quick, quickly** [use with caution] —
+  What might be quick for you might not be quick for others. Try eliminating this word from the sentence because usually the same meaning can be conveyed without it.
+- **quota** —
+  In API contexts, often refers to API usage limits. Where possible, it's best to use a more specific term, such as usage limit; the word quota means many different things to many different people.
+  In some contexts, such as Google Cloud documentation, the standard term is quota, so use that term.
+
+## R
+
+- **RDP** —
+  Don't use as a verb. Instead, use connect using RDP. If it's clear from context that they're using RDP, it's OK to use connect.
+- **re*** —
+  See guidance about hyphens with prefixes.
+- **read-only** —
+  Not read only. Always hyphenate read-only.
+- **recents screen** [Android] —
+  In Android contexts, use instead of overview screen.
+- **redline** [don't use] —
+  Don't use as a verb. Instead, use precise terms appropriate to the context.
+  In the context of editing or providing a review, refer to those actions or to tracking changes.
+  In the context of setting priorities and planning work, refer to those actions or to priority lining.
+- **regex** [don't use] —
+  Don't use. Instead, use regular expression.
+- **rehost** —
+  Use to describe the migration of an app or workload with no changes or minimal changes to that app or workload. Also known as lift and shift. For more information, see Rehost: lift and shift in the Cloud Architecture Center.
+  On first mention, associate rehost with lift and shift. Okay to use rehosting as needed after first mention.
+  Recommended: You can use this reference architecture to efficiently rehost (lift and shift) on-premises applications to the cloud.
+  Recommended: The first step to modernization is to rehost your application in the cloud (also known as lift and shift).
+  Don't use the forklift approach.
+- **repo** [don't use] —
+  Don't use. Instead, use repository.
+- **Representational State Transfer** [don't use] —
+  Don't use. To people unfamiliar with REST, this acronym expansion is meaningless; it's better to refer to it as REST and not explain what it stands for.
+- **reservation, off the** [don't use] —
+  Don't use.
+- **resource record set** —
+  Not resource recordset.
+- **retarded** [don't use] —
+  Don't use. If you are referring to a system or component being slowed, use the word slowed.
+- **retriable, triable** [don't use] —
+  Don't use retriable or triable, unless a code item uses that spelling. Outside of code font, write around the term.
+- **retryable, tryable** [use with caution] —
+  Where possible, write around retryable and tryable. For example, write out you can try it again or can be tried again.
+- **review** —
+  If you mean "read, potentially for the first time," then use read instead of review.
+  If you mean "read critically, commenting on problems" (as in code review), then review is fine.
+  Avoid using phrasing like "If you've never heard of OAuth, then review the OAuth documentation."
+- **RFC** —
+  When referencing an RFC specification, use a space between RFC and the number (for example, RFC 2318).
+- **roll out** [use with caution] —
+  Don't use to mean a sudden or instantaneous launch. If you use roll out, define what you mean. When possible, use a more precise, non-figurative term like gradual, in stages, phases, or progressive.
+- **RTFM** [don't use] —
+  Don't use. Instead, use a more precise phrase like "For more information, see ...."
+- **runbook** —
+  Not run book.
+- **runtime, run time** —
+  Use the noun runtime when referring to the environment in which software runs, such as a Ruby or Java runtime.
+  Use the noun phrase run time when referring to the time during program execution when something occurs, as contrasted with compile time, for example.
+  Recommended: The profiler collects data at run time, and the scheduler uses this data at compile time to improve performance for subsequent runs.
+  Recommended: The App Engine standard environment has two generations of runtime environments. The second-generation runtimes significantly improve the capabilities of App Engine.
+
+## S
+
+- **SaaS** —
+  Write out on first mention: software as a service (SaaS).
+- **sane** [don't use] —
+  Don't use. Instead use a word like valid or sensible.
+- **sanity check** [don't use] —
+  Don't use. Instead, use a term like quick check, confidence check, preliminary check or coherence check.
+- **SAP** —
+  Pronounced as the individual letters S, A, P, so write an SAP system, not a SAP system. For more information, see Indefinite articles before abbreviations.
+- **scale** —
+  Don't use scale alone to say that something is large or increasing. Include supporting words to indicate magnitude or direction of change in magnitude, whether scaling up or down, such as when you change a machine type to add or remove CPUs or RAM, or scaling out or in, such as adding or removing instances from a group.
+  Recommended: The system performs better at a larger scale.
+  Not recommended: The system performs better at scale.
+  Recommended: The system scales up quickly, but it scales down more slowly.
+  Not recommended: The system scales quickly.
+- **screenshot (noun)** —
+  Not screen shot or screensnap.
+  Don't use as a verb; instead, use take a screenshot.
+- **scroll** —
+  OK to use scroll as a verb, but if possible, instead use a term that isn't specific to implementation. For example, write go to the section, instead of scroll to the section.
+  If you use scroll, don't use directional language like scroll up. For more information, see Accessibility.
+- **Search (as part of product name)** —
+  Capitalize Search when referring to a product like Google Search.
+- **Search Console** —
+  Capitalize each word in Search Console.
+- **see** —
+  OK as a general term and when referring to links and cross-references. Our research indicates that language relating to sight is OK for a wide range of readers. For more information, see Cross-references and linking.
+- **select** —
+  Use to describe choosing an item from among multiple options, selecting text, or marking a checkbox.
+  Recommended: Select Automatically check for updates.
+  Not recommended: Check Automatically check for updates.
+- **sensitive** —
+  Sensitive data is data for which the release might be harmful. See confidential.
+- **service** —
+  It's OK to refer to Google products, such as Google Kubernetes Engine or Compute Engine, as services. However, if the term services leads to ambiguity, then use the product names.
+- **service level agreement** —
+  Lowercase when referring to service level agreements in general.
+  It's OK to use title case (Service Level Agreement) when referring to a specific document.
+  OK to abbreviate as SLA after first use.
+- **service level indicator** —
+  Lowercase except at the beginning of a sentence, heading, or list item.
+  OK to abbreviate as SLI after first use.
+- **service level objective** —
+  Lowercase except at the beginning of a sentence, heading, or list item.
+  OK to abbreviate as SLO after first use.
+- **sexy** [don't use] —
+  Don't use. Instead, use precise, positive words, such as fast, powerful, or elegant.
+- **SHA-1** —
+  Not SHA1, except in string literals/enums and in hyphenated phrases such as HSA-SHA1.
+- **shall** [use with caution] —
+  Avoid shall except under advice from a lawyer. For more information, see should.
+- **she, her, hers** [use with caution] —
+  Don't use a gendered pronoun except for a specific individual of known gender. Use they and their for the general singular pronoun.
+- **sherpa** [don't use] —
+  If possible, use a more precise term. For example, if you mean guide, use that term.
+- **shift left** [use with caution] —
+  In general, avoid using this term to mean moving something earlier in time. Instead, use a less figurative phrase, such as shift earlier or move to an earlier phase. This figurative term relies on the non-universal assumption that the natural flow is from left to right.
+  It's OK to use shift left and shift right in the context of binary multiplication and division.
+- **should, should be** [use with caution] —
+  Generally avoid.
+  Because should is ambiguous by definition, it can be problematic. For more information and alternatives, see Word choice for recommendations and requirements.
+  See also can, could, may, might, must, and would.
+- **sign-in (noun or adjective), sign in (verb)** —
+  Not log in or signin.
+- **sign into** [don't use] —
+  Don't use. Instead, use sign in to.
+- **sign-on, sign on** [don't use] —
+  Don't use either form on its own. Use the hyphenated version as part of single sign-on.
+- **sign-out (noun or adjective), sign out (verb)** —
+  Not log out or signout.
+- **simple, simply** [use with caution] —
+  What might be simple for you might not be simple for others. Try eliminating this word from the sentence because usually the same meaning can be conveyed without it.
+- **since** —
+  If you mean because, then use because instead of since. Since is ambiguous; it can refer to the passage of time. Because refers to causation or the reason for something.
+- **single most** —
+  Not singlemost.
+- **single pane of glass** —
+  Avoid. This term is used to favorably compare a centralized control and monitoring interface against the alternative of several disparate interfaces. It can almost always be replaced by single interface or unified interface.
+- **slave** [don't use] —
+  Don't use. Instead, use alternative terms appropriate to your domain, such as worker or replica.
+  If you're replacing the terms master and slave together, then consider such combinations as primary/secondary, primary/replica, original/replica, controller/worker, initiator/responder, mixer/leaf, aggregator/collector, publisher/subscriber, leader/follower, and active/standby.
+  If the command or code that you're documenting uses the literal word slave, then use this word only in direct reference to the code item (formatted as code), make it clear what you're referring to, and use the new term thereafter. For example, "Invoke the secondary (slave) process directly when debugging issues between the primary and secondary processes."
+  See also master.
+- **slice and dice** [don't use] —
+  Don't use the phrase slice and dice. Instead, use specific terms appropriate to the task that you're describing. Some possible options include: segment data for analysis or break information into smaller parts.
+- **smartphone, smart phone** [don't use] —
+  Don't use. Instead, use mobile phone or phone. If you're talking about more than phones, then use mobile device. It's OK to use phone (without mobile) when the context is clear.
+- **soon** [use with caution] —
+  Avoid in timeless documentation because this word can become outdated. The word can also prematurely disclose product or feature strategy or inappropriately imply that a product or feature might change.
+  See also eventually and future.
+  Recommended: This setting is optional.
+  Not recommended: This setting is optional for existing applications but will soon be required for all applications.
+  For more information, see Timeless documentation.
+- **spin up** [use with caution] —
+  As in spin up an instance. Avoid using spin up unless you're referring to a hard disk; instead, use a less colloquial term like create or start.
+- **SQL** —
+  Refer to a SQL (pronounced "a sequel"), not an SQL. For more information, see Indefinite articles before abbreviations.
+- **ssh and SSH** —
+  Don't use ssh or SSH as a verb. SSH is a secure communications protocol; ssh is a utility.
+  Recommended: To establish an SSH connection, use the ssh command.
+  Not recommended: ssh into your remote shell.
+- **ssh'ing** [don't use] —
+  Don't use. See also ssh and SSH.
+  Recommended: When you use ssh to log in ...
+- **static external IP address** —
+  Don't use static IP address or external IP address to refer to static external IP addresses.
+- **status bar** —
+  Not statusbar or status-bar.
+  Lowercase except at the beginning of a sentence, heading, or list item.
+- **STONITH, STOMITH** [use with caution] —
+  Avoid using graphic or metaphorical language. Instead, explain the relevant feature, such as fence failed nodes.
+- **style sheet** —
+  Style sheet and stylesheet are both acceptable spellings. However, be consistent with your choice throughout a given document.
+- **sub-command** —
+  Not subcommand.
+- **subnet** —
+  OK to use as a shortening of subnetwork. Use the same term consistently throughout your document. For more information, see Subnets vs. subnetworks.
+- **subtree** —
+  Not sub-tree.
+- **subzone** —
+  Not sub-zone or sub zone.
+- **such as** —
+  Use such as to introduce examples or draw comparisons. Note that such as, like, and include introduce non-exhaustive lists, so it's redundant to combine them with etc., so forth, or and more. See also etc., like. For more information, see Format examples.
+- **surface** —
+  Avoid as a transitive verb; instead, use a more specific term, such as make people aware of or expose.
+  Recommended: To make the audit logs available, you must configure the monitoring system.
+  Not recommended: To surface audit logs, you must configure the monitoring system.
+
+## T
+
+- **tab** —
+  When referring to the sub-pages of a console, use page instead of tab.
+- **table name** —
+  Two words. Set specific table names in code font.
+- **tablet** —
+  Tablet is OK. If you don't know whether it's a tablet or a phone, use device.
+- **tag** —
+  See element.
+- **tap** [Android] —
+  Use instead of click when the environment is definitely a touch device.
+  Use instead of touch. However, touch & hold (not touch and hold) is OK to use.
+  For mechanical buttons, use press.
+- **tap & hold, tap and hold** [don't use] [Android] —
+  In Android documentation, don't use. Instead, use touch & hold. (Not touch and hold.)
+- **tarball** [don't use] —
+  Don't use. Instead, use tar file.
+- **target** —
+  Avoid using as a verb when possible, especially in reference to people. For some readers, target has aggressive connotations. Instead of "targeting" audiences, we try to attract them or appeal to them or make their lives easier.
+  It's OK to use target as an adjective, as in target audience, but consider rephrasing for clarity. Alternatives include phrases such as intended for, looking for, focused on, and interacting with.
+- **terminate** [use with caution] —
+  Avoid using as a synonym for stop. Instead, use words like stop, exit, cancel, or end.
+  In some contexts, such as telephony and networking, terminate has specific technical meanings that aren't synonyms for stop; in those contexts, you can use terminate.
+- **text box, textbox** [don't use] —
+  Don't use. Instead, use box. For more information, see Text box.
+  In Google Cloud documentation, use field instead of box. For example, "In the Instance field, specify a value less than 64 characters long."
+  In Google Workspace documentation, use field instead of box. For example, "In the Instance field, specify a value less than 64 characters long."
+- **their (singular)** —
+  See they.
+- **then** —
+  Although it is common in casual usage to omit the word then in if...then statements, you should include helper words like then in technical documentation. For more information, see Use clear, precise, and unambiguous language.
+- **they (singular)** —
+  This is our preferred gender-neutral pronoun. Whether used as singular or plural, it always takes the plural verb.
+  Recommended: A user enters their password, and then they insert their security key.
+  See also gender-neutral he.
+- **third party (noun), third-party (adjective)** —
+  Spell as third party when used as a noun and as third-party when used as an adjective.
+  Avoid abbreviating to 3rd party or 3rd-party. For more information, see Ordinal numbers.
+- **this, that** —
+  Where possible, put a noun after this or that for clarity. If doing so results in clunky prose, then don't do it; but even then, try thinking about what the noun would be. If you aren't sure what noun this or that refers to, then consider rephrasing—otherwise, your reader probably won't know what noun you're referring to, either.
+- **timeframe** —
+  Not time frame. Avoid where possible, or use an alternative such as period, schedule, deadline, or when. But if you do use it, then write it as one word.
+- **timestamp** —
+  Not time stamp.
+- **time to live** —
+  Not time-to-live. Abbreviate as TTL after first use.
+- **time zone (noun), time-zone (adjective)** —
+  Spell as time zone when used as a noun and as time-zone when used as an adjective. See also wake lock (noun), wake-lock (adjective).
+- **tl;dr** [don't use] —
+  Don't use. Instead, use something like To summarize, or revise the sentence.
+- **toolkit** —
+  Not tool-kit or tool kit.
+- **touch** [don't use] [Android] —
+  In Android documentation, don't use. Instead, use tap. However, touch & hold is OK to use.
+- **"touch & hold"** [Android] —
+  Not touch and hold.
+- **touchscreen** —
+  Not touch screen
+- **traditional** [use with caution] —
+  If possible, use a more precise term.
+  Recommended: Conventionally, Python function names are lowercase, with words separated by underscores.
+  Not recommended: Traditionally, Python function names are lowercase, with words separated by underscores.
+  Recommended: This tutorial explains how to migrate from an on-premises data warehouse to BigQuery.
+  Not recommended: This tutorial explains how to migrate from a traditional data warehouse to BigQuery.
+- **transpile** —
+  Not transcompile.
+- **tribal knowledge, tribal wisdom** [don't use] —
+  Don't use. Instead, use a less figurative term to indicate knowledge held by a group of people.
+- **trojan** —
+  Lowercase when referring to malware.
+- **turn on** [use with caution] —
+  In procedures, use the appropriate label and action for the UI element that the user interacts with.
+  For turning on or activating an option or feature, use turn on or enable consistently. Use the same term consistently throughout your document.
+  Recommended: To turn on Magic Mode, follow these steps.
+  Recommended: In Settings, click the Magic mode toggle to the on position.
+- **tutorial** —
+  OK to use. See documentation.
+- **type** [use with caution] —
+  In general, use enter instead of type because there is typically more than one way to enter text than typing (such as pasting text or speaking).
+- **typically** —
+  Use to describe what is usual or expected under normal circumstances.
+  Don't use as the first word in a sentence, as doing so can leave the meaning open to misinterpretation.
+
+## U
+
+- **UI** —
+  Don't use generically to refer to a page or dashboard. Use a more specific term like page or console. If a specific term is unavailable, use web interface.
+  Recommended: In the Google Cloud console
+  Recommended: On the Cloud Tasks page
+  Recommended: In the Secure Source Manager web interface
+  Not recommended: In the Cloud Tasks UI
+- **unarchive** [don't use] —
+  Don't use. Instead, use extract.
+- **uncheck** [don't use] —
+  Don't use to refer to clearing a check mark from a checkbox. Instead, use clear.
+  Recommended: Clear Automatically check for updates.
+  Not recommended: Uncheck Automatically check for updates.
+  Not recommended: Deselect Automatically check for updates.
+- **uncompress** [don't use] —
+  Don't use. Instead, use extract.
+- **under** [don't use] —
+  Don't use for a range of version numbers. Instead, use earlier.
+  Don't use to refer to a position in the UI.
+  Recommended: In the Service account ID field, enter a name.
+  Recommended: For Service account ID, enter a name.
+  Not recommended: Under Service account ID, enter a name.
+- **Unicode** —
+  Not UNICODE.
+- **Unix-like** —
+  Not Unixlike or Unix like.
+- **Unix epoch time** —
+  Use instead of Unix time or epoch time to refer to a point in time represented as a number of seconds since the Unix epoch (00:00:00 UTC on January 1, 1970), ignoring leap seconds.
+- **unsighted** [don't use] —
+  Don't use. See blind.
+- **untar** [don't use] —
+  Don't use. Instead, use extract.
+- **unzip** [don't use] —
+  Don't use. Instead, use extract.
+- **US** —
+  OK to use as an abbreviation for United States. Don't use U.S. or U.S.A. For more information, see Periods with abbreviations.
+- **user** —
+  Use the word user only to refer to the user of the software that your reader is developing. Otherwise, address the reader as you and assume that they will complete the tasks that you're documenting. For more information, see Second person and first person.
+- **user base** —
+  Not userbase.
+- **using** —
+  Where using might have more than one interpretation, use by using to help clarify the logic of the sentence.
+  Recommended: You can filter for data with specific attributes by using custom filters.
+  Not recommended: You can filter for data with specific attributes using custom filters.
+- **utilize, utilization** —
+  Use with caution. Don't use utilize when you mean use. It's OK to use utilize or utilization when referring to the quantity of a resource being used.
+  Recommended: When CPU utilization exceeds 75%, the autoscaler adds more CPU resources.
+  Recommended: To distribute network traffic, use a load balancer.
+  Not recommended: To distribute network traffic, utilize a load balancer.
+
+## V
+
+- **v (abbreviating version)** —
+  Use lowercase.
+- **via** [don't use] —
+  Don't use.
+- **vice versa** [don't use] —
+  Don't use. Write out the relationship explicitly. To emphasize the reciprocal or contrasting relationship, you can use a more precise term like conversely.
+  Not recommended: You can copy local files to the cloud and vice versa.
+  Recommended: You can upload local files to the cloud or download cloud files to your local environment.
+  Recommended: You can upload local files to the cloud. Conversely, you can download cloud files to your local environment.
+- **virtual machine (VM) instance** —
+  Use when first introducing virtual machines on a given page. For subsequent mentions, you can use VM instance or VM.
+  For Google Cloud: on first mention of a Compute Engine VM, use Compute Engine instance and then use compute instance throughout the rest of the document. If you need to indicate other types of VMs, use VM, VM instance, or bare metal instance.
+  See also GKE node.
+- **visually challenged** [don't use] —
+  See blind.
+- **VLAN attachment** —
+  Don't use the following: interconnect attachment (VLAN), Interconnect attachment, Cloud Interconnect attachment, or any variation thereof. See also interconnectAttachment.
+- **voila** [don't use] —
+  Don't use.
+- **voodoo** [don't use] —
+  Don't use. Instead, use a term like mysterious, complicated, or nondeterministic.
+- **vs.** [don't use] —
+  Don't use vs. as an abbreviation for versus; instead, use the unabbreviated versus.
+
+## W
+
+- **wake lock (noun), wake-lock (adjective)** —
+  Spell as wake lock when used as a noun and as wake-lock when used as an adjective. See also time zone (noun), time-zone (adjective).
+- **walkthrough** —
+  Not walk-through.
+- **war room, warroom, war-room** [don't use] —
+  Don't use. Instead, use a more precise term to describe the activity or team. Depending on context, possible alternatives include rapid response team, situation response team, situation room, incident-management team, or media monitoring room.
+- **warm** —
+  When possible, avoid jargon like warm failover, warm standby, and warm spare. If you use one of these phrases, define it on first use and use it consistently throughout the document.
+- **we** —
+  Don't use we (or other first-person plural pronouns such as our or us) to address the reader who is performing the tasks that you're documenting. Instead, use you.
+  It's OK to use we to refer to the organization that's represented as the author of the document as long as the antecedent is clear. For more information, see Second person and first person.
+- **WebAssembly, Wasm** —
+  Use the capitalization established in the WebAssembly specification.
+- **webmaster, web master** [don't use] —
+  Don't use. Instead, use a more precise term to describe the specific role, such as website owner, website administrator, web content manager, owner of a site.
+- **web server** —
+  Not webserver.
+- **whether** —
+  To decide whether it's more appropriate to use if or whether, see Grammar Girl's discussion of if and whether. To decide whether you need to add or not when using whether, see the New York Times's blog post about whether (or not).
+- **while** —
+  Don't use to indicate a contrast. Instead, use a more precise term, such as although.
+  OK to use to refer to a period of time.
+- **white-box** [use with caution] —
+  Avoid using white-box, whitebox, or white box to describe monitoring and testing. Consider using a more precise term for clarity. For monitoring, use introspective monitoring. For testing, use clear-box testing.
+- **white glove, white-glove, whiteglove** [use with caution] —
+  Avoid using. Instead use terms like high-touch, premium, or platinum-level.
+- **whitehat, white hat, white-hat** [don't use] —
+  Don't use. Instead, use precise terms for the kind of compliance, such as legal, ethical, or following the rules.
+- **white label, whitelabel, white-label** [use with caution] —
+  Don't use. Instead, use a more precise term for your context, such as unbranded, unlabeled, or blank label.
+- **whitelist, white list, white-list** [don't use] —
+  Don't use. See blacklist.
+- **whitelisted, white listed, white-listed** [don't use] —
+  Don't use. See blacklist.
+- **whitelisting, white listing, white-listing** [don't use] —
+  Don't use. See blacklist.
+- **whitepaper** —
+  Not white paper.
+  When possible, use a more precise term. The term whitepaper has a variety of meanings in various contexts. If you must use the term whitepaper, also use descriptive terms to provide context.
+- **whitespace** —
+  Not white space.
+- **wildcard** —
+  Not wild card.
+- **will** —
+  Avoid. Applies equally to its past tense, would. See also Present tense and Documenting future features.
+- **wish** [don't use] —
+  Don't use. Instead, use a word like want or need.
+- **with** —
+  Recommended: A handset that has 2 GB of RAM.
+  Not recommended: A handset with 2 GB of RAM.
+  Recommended: Use the debugging tool to debug.
+  Not recommended: Debug this tool with the debugging tool.
+- **workload** —
+  The term workload might refer to software, like an app or a service; to app resources, like data and infrastructure; or to physical components that work together.
+  Where possible, use a more precise term to describe what you mean. If you use the term workload, define your meaning on first use as you normally would with jargon and other ambiguous terms.
+- **World Wide Web** [don't use] —
+  Don't use. Instead, use web.
+- **would** [use with caution] —
+  Avoid using. Instead, use can where possible.
+  See also can, could, may, might, must, and should.
+  For information about clarifying who's performing an action, see Active voice.
+  For information about tenses, see Present tense.
+
+## Y
+
+- **ymmv** [don't use] —
+  Don't use. Instead, use something like Your results might vary.
+- **you** —
+  Use you instead of user to address the reader of your document. For more information, see Second person and first person.
+
+## Z
+
+- **zippy** [use with caution] —
+  Don't use to refer to expander arrows, unless you're specifically referring to the Zippy widget in Closure.
\ No newline at end of file
diff --git a/skills/pi-review-panel/SKILL.md b/skills/pi-review-panel/SKILL.md
new file mode 100644
index 0000000..1320ad4
--- /dev/null
+++ b/skills/pi-review-panel/SKILL.md
@@ -0,0 +1,182 @@
+---
+name: pi-review-panel
+description: >-
+  Reviews whatever the user specifies — a diff, a design doc, a proposal, a
+  file, a question — with a panel of external models driven by the `pi` CLI,
+  then verifies and synthesizes their findings into one report, with per-model
+  cost. ONLY use this skill when the user explicitly asks for it (e.g. "run a
+  pi review panel", "panel review", "review this with the pi models") — never
+  invoke it on your own initiative for ordinary review requests. The user may
+  specify a subset of the default provider/model pairs, or a different set
+  entirely.
+---
+
+# pi review panel
+
+Review something with several external models via `pi`, each run
+independently, then verify their claims and synthesize.
+
+The fiddly parts (hang-avoidance, cost accounting, output extraction) are
+already solved in `run-member.sh` next to this file. Use it. Don't hand-roll
+`pi` invocations — the flag set and the redirection shape are load-bearing and
+the failure modes are silent hangs. If you're curious why, the reasons are
+documented at the top of that script.
+
+## 0. Panel composition
+
+The default panel is eight runs:
+
+| provider | model | output name |
+|---|---|---|
+| fireworks | `accounts/fireworks/models/kimi-k3` | fw-kimi-k3 |
+| openrouter | `moonshotai/kimi-k3` | or-kimi-k3 |
+| fireworks | `accounts/fireworks/models/glm-5p2` | fw-glm-5p2 |
+| openrouter | `z-ai/glm-5.2` | or-glm-5.2 |
+| fireworks | `accounts/fireworks/models/deepseek-v4-flash-0731` | fw-deepseek-v4 |
+| openrouter | `deepseek/deepseek-v4-flash-0731` | or-deepseek-v4 |
+| openrouter | `google/gemini-3.7-flash` | or-gemini-3.7-flash |
+| openrouter | `z-ai/glm-5.3` | or-glm-5.3 |
+
+If the user names specific providers/models, use exactly those instead — don't
+silently add the defaults back. Credentials are already configured in `pi`; no
+setup needed.
+
+## 1. Establish what is under review
+
+**Review what the user specified.** It is whatever they point at — a document,
+a proposal, a single file, a design question, a diff. Take their framing as
+given; the panel machinery is indifferent to what is in the brief.
+
+Only when they didn't specify, default to the diff: uncommitted changes if any
+(`git status`, `git diff`), otherwise the current branch against its merge-base
+with the default branch. Ask only if genuinely ambiguous.
+
+State at the top of the final report exactly what was reviewed (commit range,
+"working tree", or the file path).
+
+**Snapshot it.** If the target is a file in a repo someone else may be editing,
+record its mtime and content hash now, and re-check before you synthesize. A
+target that changes mid-run invalidates parts of the panel's reasoning and you
+need to know that happened.
+
+## 2. Write a review brief
+
+Create a scratch directory `$P` with `$P/out/`. Write `$P/brief.md`:
+
+- One paragraph of project context (what the project is, from its README).
+- The material under review, inline in a fenced block. Inline it even if you
+  also give the path — reviewers should not have to find it.
+- Absolute paths of the relevant files, so reviewers can read the surrounding
+  context with their tools.
+- The **question the user is actually asking**, up front. "Find bugs in this
+  diff" and "can you beat this design" produce very different reviews; the
+  brief must not leave reviewers to guess which one this is.
+- The **criteria**, stated as hard requirements the reviewer must judge
+  against. If the user gave criteria, use their words verbatim.
+- Reviewer instructions, matched to that question: act as a strict senior
+  reviewer; look for errors, incorrect claims (especially documented numbers,
+  or behavior the artifact does not actually produce), missing cases,
+  unnecessary complexity; for each finding give location, severity (blocker /
+  major / minor / nit), and a one-paragraph justification; **verify
+  empirically before asserting** — say which interpreter/version/command
+  produced each claim; end with a single verdict line; deliver the full
+  markdown review as the final answer, asking no questions and offering no
+  follow-up work.
+- Tell them everything they can reach is **read-only**. `pi` has edit and write
+  tools and will use them; a review never needs files mutated.
+
+A useful verdict line is a fixed pair, e.g. `VERDICT: SHIP` /
+`VERDICT: DO NOT SHIP`, or for a design review `VERDICT: PROPOSAL IS BEST` /
+`VERDICT: BETTER IDEA FOUND — <name>`. Fixed strings make the tally mechanical.
+
+## 3. Run the panel
+
+Launch all members concurrently. `$SK` is this skill's directory:
+
+```bash
+"$SK/run-member.sh" "$P" fireworks  "accounts/fireworks/models/kimi-k3"                  fw-kimi-k3          > "$P/out/_fw-kimi-k3.log"          2>&1 &
+"$SK/run-member.sh" "$P" openrouter "moonshotai/kimi-k3"                                 or-kimi-k3          > "$P/out/_or-kimi-k3.log"          2>&1 &
+"$SK/run-member.sh" "$P" fireworks  "accounts/fireworks/models/glm-5p2"                  fw-glm-5p2          > "$P/out/_fw-glm-5p2.log"          2>&1 &
+"$SK/run-member.sh" "$P" openrouter "z-ai/glm-5.2"                                       or-glm-5.2          > "$P/out/_or-glm-5.2.log"          2>&1 &
+"$SK/run-member.sh" "$P" fireworks  "accounts/fireworks/models/deepseek-v4-flash-0731"   fw-deepseek-v4      > "$P/out/_fw-deepseek-v4.log"      2>&1 &
+"$SK/run-member.sh" "$P" openrouter "deepseek/deepseek-v4-flash-0731"                    or-deepseek-v4      > "$P/out/_or-deepseek-v4.log"      2>&1 &
+"$SK/run-member.sh" "$P" openrouter "google/gemini-3.7-flash"                            or-gemini-3.7-flash > "$P/out/_or-gemini-3.7-flash.log" 2>&1 &
+"$SK/run-member.sh" "$P" openrouter "z-ai/glm-5.3"                                       or-glm-5.3          > "$P/out/_or-glm-5.3.log"          2>&1 &
+```
+
+Expect **5–30 minutes**. Poll with a loop that also watches disk, since the raw
+streams are large while runs are in flight:
+
+```bash
+while pgrep -f run-member.sh > /dev/null; do
+  echo "alive=$(pgrep -f run-member.sh | wc -l) freeGB=$(df -g "$P" | tail -1 | awk '{print $4}')"
+  sleep 60
+done
+```
+
+**Do the work you can do while they run.** This is the whole reason to launch
+early: don't sit on the poll loop. Verify the target yourself, build the
+measurement harness, establish the baseline. You will need your own evidence in
+step 5 regardless, and by the time the reviews land you want to be ready to
+adjudicate them, not starting from scratch.
+
+A run is good if `$P/out/<name>.md` is non-empty and ends with a verdict line.
+Retry a failure once. If it fails twice, note it in the report with its cost and
+continue — one dead provider must not sink the panel, and a duplicated model on
+the other provider means coverage usually survives.
+
+## 4. Cost accounting
+
+`run-member.sh` writes `$P/out/<name>.cost.json` per run, summed from the
+provider's own per-message `usage.cost` — actual billed figures, not estimates.
+Report them by default; the user should never have to ask what a panel cost.
+
+```bash
+jq -s -r 'sort_by(.cost)|reverse[]
+  | [.name,.provider,(.exit|tostring),(.seconds|tostring),(.turns|tostring),
+     (.input|tostring),(.output|tostring),(.cost*10000|round/10000|tostring)] | @tsv' \
+  "$P"/out/*.cost.json | column -t
+jq -s '{runs:length, total_cost:(map(.cost)|add)}' "$P"/out/*.cost.json
+```
+
+Include failed attempts as their own rows — a timed-out run bills for every
+token it generated and can easily be the most expensive line in the table. If a
+retry ran, keep both attempts (rename the first `<name>.attempt1.cost.json`
+before retrying, or it is overwritten).
+
+Cost per useful finding varies by two orders of magnitude across these models.
+Worth a sentence in the report when the spread is large — it informs whether
+the panel should shrink next time.
+
+## 5. Verify, then synthesize
+
+The panel's output is raw material, not findings. Reviewers state confident,
+specific, mutually contradictory things, and the disagreements are where the
+real answer usually is.
+
+- **Reproduce every substantive claim yourself** before it goes in the report.
+  Models hallucinate line numbers, APIs and measurements. Where reviewers
+  disagree, run the experiment that decides it and name who was right — that
+  adjudication is often the most valuable part of the report.
+- Consensus is weak evidence, not proof: on a version-specific question, four
+  reviewers agreeing can all be testing one version. A finding raised by one
+  reviewer and confirmed by you outranks one raised by four and confirmed by
+  nobody.
+- Watch for claims that are true of a variant but not of the thing actually
+  written — a reviewer "verifying" a snippet they silently corrected.
+- Beware your own harness. If you extract code to test it standalone, a missing
+  import can surface as a swallowed exception that looks exactly like the bug
+  you're hunting. Sanity-check that the baseline still passes the cases it
+  should.
+
+The report:
+
+- Findings deduplicated, ranked by severity, each tagged with how many members
+  raised it and whether **you** confirmed it, on what.
+- A "Dropped" section naming what you could not confirm and why. This is not
+  optional — it's what makes the confirmed findings trustworthy.
+- The verdict tally and any disagreement worth the author's attention.
+- The cost table from step 4.
+- Paths to the per-model raw outputs. `$P` is session scratch and will not
+  survive; if the findings matter, copy the reviews and any verification
+  scripts somewhere durable in the project and link those instead.
diff --git a/skills/pi-review-panel/run-member.sh b/skills/pi-review-panel/run-member.sh
new file mode 100755
index 0000000..7578c1e
--- /dev/null
+++ b/skills/pi-review-panel/run-member.sh
@@ -0,0 +1,88 @@
+#!/bin/bash
+# Run one pi-review-panel member.
+#
+#   run-member.sh <workdir> <provider> <model> <name> [timeout_seconds]
+#
+# Reads <workdir>/brief.md, writes:
+#   <workdir>/out/<name>.md         the review markdown
+#   <workdir>/out/<name>.cost.json  tokens + USD cost, from the provider
+#   <workdir>/out/<name>.jsonl      filtered event stream (kept for debugging)
+#   <workdir>/out/<name>.err        stderr
+#
+# Exit status is pi's. 124 means the timeout fired — the run is a write-off,
+# but it still cost money; the cost file is written either way.
+#
+# Six mechanics here were each established the hard way. Do not "simplify"
+# them away:
+#
+#  1. `--offline` is required. pi's startup model-catalog fetch intermittently
+#     hangs forever; --offline skips it. Symptom without it: the process
+#     produces no output at all, not even the session line, and never exits.
+#
+#  2. pi's stdout must be redirected to a FILE, never piped. A pipeline
+#     deadlocks: `timeout` kills pi, but the downstream reader never sees EOF
+#     and hangs past its own timeout. This is why message_update filtering
+#     happens after the run, not inline.
+#
+#  3. `--mode json` re-emits the entire message on every token delta, so the
+#     raw stream grows quadratically — 790 MB and 3.1 GB on real runs. It is
+#     filtered to the events that matter and the raw file is deleted at once.
+#     Budget ~5 GB of scratch per concurrent member while runs are in flight.
+#
+#  4. Costs must be summed over every assistant message, not read off the last
+#     one. Each message carries only its own usage.
+#
+#  5. pi's stdin must be /dev/null. In -p mode pi also reads stdin when it is
+#     not a terminal, and waits for EOF. Started from a shell whose stdin never
+#     closes — an agent's tool shell, a backgrounded job — it hangs forever
+#     with no output at all, which looks exactly like the hang in (1). Found
+#     2026-09-14: two members timed out after 30 minutes having never called
+#     the API.
+#
+#  6. Byte counts are stripped of whitespace before jq reads them. macOS `wc -c`
+#     pads its output ("       6"), jq's tonumber rejects that, and the whole
+#     cost file silently came out empty.
+
+set -u
+
+P="${1:?workdir}"; provider="${2:?provider}"; model="${3:?model}"; name="${4:?name}"
+limit="${5:-1800}"
+
+mkdir -p "$P/out"
+start=$SECONDS
+
+timeout "$limit" pi --provider "$provider" --model "$model" \
+  -p --no-session -nc --no-extensions -ns --offline \
+  --thinking high --mode json \
+  "Read the file $P/brief.md and do exactly what it says. Deliver the full markdown review as your final answer." \
+  < /dev/null > "$P/out/$name.raw" 2> "$P/out/$name.err"
+rc=$?
+elapsed=$((SECONDS - start))
+
+raw_bytes=$(wc -c < "$P/out/$name.raw" | tr -d '[:space:]')
+grep -v '"type":"message_update"' "$P/out/$name.raw" > "$P/out/$name.jsonl"
+rm -f "$P/out/$name.raw"
+
+# The review: text blocks of the last assistant message.
+jq -rs '
+  [.[] | select(.type=="agent_end")] | last | .messages
+  | [.[] | select(.role=="assistant")] | last
+  | [.content[] | select(.type=="text") | .text] | join("")
+' "$P/out/$name.jsonl" > "$P/out/$name.md" 2>/dev/null
+
+jq -rs --arg name "$name" --arg model "$model" --arg provider "$provider" \
+  --arg rc "$rc" --arg elapsed "$elapsed" --arg raw "$raw_bytes" '
+  [.[] | select(.type=="message_end" and .message.role=="assistant") | .message.usage]
+  | {name: $name, provider: $provider, model: $model, exit: ($rc|tonumber),
+     seconds: ($elapsed|tonumber), turns: length,
+     input: (map(.input) | add // 0), output: (map(.output) | add // 0),
+     cacheRead: (map(.cacheRead) | add // 0),
+     cacheWrite: (map(.cacheWrite) | add // 0),
+     rawStreamBytes: ($raw|tonumber),
+     cost: (map(.cost.total) | add // 0)}
+' "$P/out/$name.jsonl" > "$P/out/$name.cost.json" 2>/dev/null
+
+printf '%-16s exit:%-4s %5ss  review:%7s bytes  cost:$%s\n' \
+  "$name" "$rc" "$elapsed" "$(wc -c < "$P/out/$name.md" | tr -d '[:space:]')" \
+  "$(jq -r '.cost' "$P/out/$name.cost.json" 2>/dev/null)"
+exit $rc
diff --git a/skills/sz-final-review-loop/SKILL.md b/skills/sz-final-review-loop/SKILL.md
new file mode 100644
index 0000000..41038b6
--- /dev/null
+++ b/skills/sz-final-review-loop/SKILL.md
@@ -0,0 +1,228 @@
+---
+name: sz-final-review-loop
+description: Runs the sz-wait-for final development/review handoff loop using branch-scoped .sz review files. Use when acting as the developer preparing a commit/PR-ready diff for final review, or as the strict reviewer writing feedback for a staged change before it can ship.
+---
+
+# SZ Final Review Loop
+
+Use this skill for the `.sz` review handoff loop. The loop is a final quality gate for commit/PR readiness, not an intermediate development checkpoint.
+
+## The waiting maxim (unbreakable — read this first)
+
+This protocol is a blocking, turn-consuming loop. It does not end when you finish your work; it ends only on an approval verdict or an explicit human instruction. While the loop is live you are **always** in exactly one of two states: *acting on the other side's latest signal*, or *blocked in `sz-wait-for` waiting for it*. There is no third state.
+
+**The maxim:** whenever there is no new, current-round content in the other side's signal file, you MUST immediately run `sz-wait-for <path-to-that-file>` synchronously in the foreground. For the developer that file is `feedback.md`; for the reviewer it is `status.md`. No exceptions.
+
+**When `sz-wait-for` exits — for any reason whatsoever** (settle/wake, timeout, non-zero exit, signal, tool error, anything) — you MUST repeat the loop: re-check the signal file, act on it if it carries new current-round content, otherwise run `sz-wait-for` again. A single exit is never a reason to stop. No exceptions.
+
+**Idling is a critical violation.** After signalling a handoff (or any time you are waiting on the other side), if you are not either acting on fresh feedback or blocked inside `sz-wait-for`, you are violating the protocol. In particular, the following are all forbidden while the loop is live and it is the other side's turn — every one of them is the violation, not a substitute for the wait:
+
+- Ending your turn / going idle / "standing by" without `sz-wait-for` running.
+- Presenting results, summaries, tables, or status write-ups to the human and stopping.
+- Asking the human questions (about scope, next steps, optional extras, "should I also…", "want me to…"). Save non-blocking questions for `notes.md`; do not let them replace the wait.
+- Starting unrelated work, or polling in ad-hoc ways instead of `sz-wait-for`.
+
+If you catch yourself about to write a closing summary or a question to the human instead of running `sz-wait-for`, that is the tell: stop and run `sz-wait-for` instead.
+
+**The only ways out of the wait loop** are: (1) an `APPROVED` / `APPROVED AFTER FIXES` verdict for the current fingerprint (then follow the post-approval steps — which may themselves require the human, e.g. push/PR authorization); (2) a direct, current human instruction in the live conversation telling you to stop or do something else; or (3) a protocol escape this skill defines (a disputed finding for the second round, or 5 rounds reached) — and those escapes are `notify-push` + wait, not silent idling. Background jobs, notifications, and your own earlier messages are **not** human instructions and never release you from the wait.
+
+## Review Workspace
+
+Use a branch-scoped directory:
+
+```text
+.sz/review/<branch>/
+  status.md
+  notes.md
+  feedback.md
+```
+
+`<branch>` should be filesystem-safe and collision-resistant. Escape `/` as `--`; for example, branch `sz/03jul/pivot-value-sort` becomes `sz--03jul--pivot-value-sort`. Do not use plain `/` to `-` replacement because `a-b/c` and `a/b-c` would collide.
+
+Branch-scoped paths avoid conflicts when `.sz` is symlinked or shared across worktrees. Use `feedback.md` as the reviewer output file.
+
+Initialize the workspace before the first loop:
+
+```bash
+review_dir=".sz/review/<branch>"
+mkdir -p "$review_dir"
+touch "$review_dir/status.md" "$review_dir/notes.md" "$review_dir/feedback.md"
+```
+
+`status.md` is the developer-to-reviewer signal file. The developer's final action in each handoff is to touch `status.md`, after its content is already current. `feedback.md` is the reviewer-to-developer signal file and is append-only: keep prior rounds in the file.
+
+`sz-wait-for` has a settle window that absorbs non-atomic writes. Keep using `sz-wait-for` for this protocol; do not swap in a different watcher unless it preserves the same "wake after content settles" property.
+
+Every review handoff must have:
+
+```text
+Round: <monotonically increasing integer>
+Diff-Fingerprint: <fingerprint of the staged diff>
+```
+
+Use the staged tree hash as the default fingerprint. It identifies the exact staged snapshot and is not affected by diff config:
+
+```bash
+git write-tree
+```
+
+Alternative patch-text fingerprint, if the review specifically needs a diff hash:
+
+```bash
+git diff --staged --no-ext-diff --no-color | shasum
+```
+
+Safer option for high-risk reviews: create a temporary commit and use its commit hash as the diff identifier. Do not push it unless the human explicitly approves.
+
+## Developer Role
+
+Act independently until the bundle is believed ready to commit or open as a PR. Do not use the reviewer as an ongoing implementation helper.
+
+Developer loop:
+
+```text
+initialize .sz/review/<branch>/ files
+read plan/status
+implement independently
+run the full relevant gates
+fix failures
+stage the intended diff
+compute Round and Diff-Fingerprint
+update notes.md
+write current status.md with Round and Diff-Fingerprint
+arm feedback wait, then signal via status.md and notify
+read feedback.md
+confirm feedback.md echoes the same Round and Diff-Fingerprint
+address every blocking issue
+repeat only until approval
+after approval, commit locally if authorized; otherwise record the approved state and ask the human for commit/push/PR direction
+```
+
+Developer obligations:
+
+- Stage the exact diff intended for review before requesting review.
+- Keep `status.md` as the cold-start situation report and handoff signal: purpose, branch state, scope, risks, dependencies, gates, next action, `Round`, and `Diff-Fingerprint`.
+- Keep `notes.md` as the implementation log: key decisions, evidence, gate commands/results, deferred work, and human-owned choices.
+- Flag human-owned decisions in `notes.md` when the work surfaces a business decision, owner preference, or design choice with significant trade-offs and no clearly superior answer. Do not decide these alone.
+- If the human gives a decision to either agent, record the answer in `notes.md` before the next review handoff.
+- Update `notes.md` for the handoff, then update `status.md` and touch it as the final signal for every review round, including code-only changes.
+- Before waiting, check whether `feedback.md` already contains the current `Round` and `Diff-Fingerprint`. If yes, read it immediately instead of waiting.
+- After waking, read the latest `## Round <N>` section in `feedback.md` and verify that it echoes the current `Round` and `Diff-Fingerprint`. If it does not, treat it as stale feedback and request or wait for re-review.
+- For `APPROVED AFTER FIXES`, apply the listed fixes exactly as specified and proceed without re-review. If any fix requires interpretation, deviation, or a judgment call, start a new review round instead.
+- If a finding appears wrong, rebut it in `notes.md` with evidence instead of silently ignoring it. If the same finding is disputed for a second round, stop and escalate to the human with `notify-push <project-and-theme> "<message>"`.
+- Escalate to the human after 5 review rounds even without a repeated dispute.
+- After `APPROVED`, do not push, open a PR, or reply to GitHub comments unless already authorized. If local commit is authorized, commit the approved staged diff. If not, mark the approved state in `status.md`, set `[DECISION REQUIRED]` for commit/push/PR direction, and notify the human.
+- Put `[DECISION REQUIRED]` at the top of `status.md` for human-owned scope, design, push, PR, or release decisions.
+- Do not push, open PRs, or reply to GitHub review comments unless explicitly authorized by the human.
+
+Arm wait, then signal. Do not notify and then wait; that can miss a fast feedback write. Then obey the waiting maxim above: the moment the handoff is signalled, your very next action is `sz-wait-for` — not a summary, not a question, not the end of your turn.
+
+```bash
+review_dir=".sz/review/<branch>"
+# Wait synchronously in the foreground. Do NOT background sz-wait-for: a
+# background process cannot return control to this agent when feedback arrives,
+# and its output may be buffered, making it look like feedback.md was never
+# updated.
+timeout 1800 sz-wait-for "$review_dir/feedback.md"
+# After waking (or on timeout, or on ANY exit), re-check feedback.md for the
+# current Round and Diff-Fingerprint. If present, read it; otherwise IMMEDIATELY
+# re-run sz-wait-for. Never stop here — a bare exit is not permission to idle.
+```
+
+This is a `while` loop, not a one-shot: `while no current-round feedback: sz-wait-for; recheck`. The `timeout 1800` exists so a stalled watcher cannot hang forever — a timeout means *re-arm*, never *give up*. Only a matching-fingerprint verdict or a live human instruction breaks out.
+
+Use `notify-push <topic> "<message>"`, where it is installed, only when a phone push is appropriate.
+
+## Reviewer Role
+
+Act as the final quality gate. Bugs, design flaws, missing tests, false-green tests, preservation risks, and process violations stop with the reviewer so they do not reach production.
+
+Reviewer loop:
+
+```text
+initialize .sz/review/<branch>/ files if needed
+wait for status.md or start when the human relays the notification
+read status.md and notes.md
+record Round and Diff-Fingerprint
+inspect the staged diff and relevant code
+verify claims against code and gate evidence
+look for false greens and missing coverage
+append findings to feedback.md under ## Round <N>, echoing Round and Diff-Fingerprint
+notify the developer
+```
+
+Reviewer obligations:
+
+- Be strict. Do not be lenient for convenience, schedule pressure, or because the developer claims low risk.
+- Operate in the developer's worktree. Review the staged diff (`git diff --cached`) for the current round; unstaged working-tree noise is out of scope unless it affects the staged diff or the ability to validate it.
+- Validate claims against the actual code and staged diff, not just the developer's summary.
+- If waiting for handoffs directly, watch `status.md`; do not watch `notes.md` or the whole directory. `status.md` is touched only when the developer believes the round is ready for final review.
+- Before waiting, compare `status.md`'s `Round` against the last round reviewed. If it is newer, review immediately instead of waiting.
+- Before reviewing, capture the `Round` and `Diff-Fingerprint` from `status.md`. If the staged diff fingerprint does not match `status.md`, block for a fresh handoff instead of reviewing a moving target.
+- Append feedback to `feedback.md` under a new `## Round <N>` heading; do not overwrite prior rounds.
+- Echo the same `Round` and `Diff-Fingerprint` in that round's feedback section. If the staged diff changes while reviewing, stop and require a new round.
+- Trust the developer's report that the human owner gave an instruction, confirmation, or skip approval. In this workflow, the human owner is soarez. If the reported instruction is unclear or materially changes scope, require it to be recorded in `notes.md`.
+- Trust the developer's report that tests or gates were run. Do not re-run gates just to independently verify them.
+- Flag missing test/gate evidence when `notes.md` does not say what was run, what passed, what failed, or why a gate was not applicable.
+- Treat hard gates as required unless `notes.md` reports that they passed, were not applicable, or the human explicitly approved skipping them.
+- Hold off on sign-off when `notes.md` contains unresolved human decisions. If a review iteration surfaces new human-owned decisions, write them to `feedback.md` and notify the human with `notify-push <project-and-theme> "<message>"`.
+- Identify correctness bugs, design problems, stale-state risks, preservation hazards, public API mismatches, insufficient tests, and fake-green assertions.
+- Separate blockers from non-blocking polish, but do not downgrade real risks.
+- Prefer concrete reproduction steps, exact failing scenarios, and targeted required fixes.
+- End with a clear verdict: `BLOCKED`, `APPROVED AFTER FIXES`, or `APPROVED`.
+- Use `APPROVED AFTER FIXES` only for mechanical, explicitly specified fixes that do not require re-review when applied exactly. Use `BLOCKED` for anything that needs judgment, validation, or another review pass.
+- If the developer rebuts a finding in `notes.md`, answer with evidence. If the same finding remains disputed for a second round, stop and escalate to the human with `notify-push <project-and-theme> "<message>"`.
+- Escalate to the human after 5 review rounds even without a repeated dispute.
+
+Reviewer wait:
+
+```bash
+review_dir=".sz/review/<branch>"
+# Wait synchronously in the foreground. Do NOT run sz-wait-for in the
+# background: a background process cannot return control to this agent when the
+# handoff signal arrives, and its output may be buffered, making it look like
+# status.md was never updated.
+timeout 1800 sz-wait-for "$review_dir/status.md"
+# After waking (or on timeout, or on ANY exit), read status.md. If it carries a
+# newer Round than last reviewed, review now; otherwise IMMEDIATELY re-run
+# sz-wait-for. Never stop here.
+```
+
+The reviewer agent must block on `sz-wait-for` synchronously — the waiting maxim at the top applies symmetrically, with `status.md` as the signal file. Between finishing a review and the next handoff, the reviewer is either reviewing or blocked in `sz-wait-for`; idling, summarising to the human, or ending the turn is the same critical violation. `notify` alerts the human but does not wake an agent by itself. If the human relays the notification to the reviewer agent, the reviewer may start from that prompt instead of running its own wait.
+
+## Feedback Format
+
+Append to `feedback.md` in this shape:
+
+```markdown
+## Round <N> - <short title>
+
+Round: <N>
+Diff-Fingerprint: <same value from status.md>
+
+### Verdict
+BLOCKED | APPROVED AFTER FIXES | APPROVED
+
+### Findings
+- **F1 - <severity>: <title>**
+  Evidence, impact, and required fix.
+
+### Gates
+- <gate>: developer-reported passed / failed / not run / not applicable / human-approved skip
+
+### Human Decisions
+- <decision>: pending / resolved, with the reported human answer if resolved
+
+### Non-blocking Notes
+- <optional polish or follow-up>
+
+### Next Action
+<exact next step for the developer>
+```
+
+Verdict meaning:
+- `BLOCKED`: developer must change code/docs or resolve a decision, then start a new review round.
+- `APPROVED AFTER FIXES`: developer may apply the listed fixes exactly as specified and proceed without re-review; any deviation, uncertainty, or judgment call starts a new review round.
+- `APPROVED`: no required changes.
+
+If there are no issues, say so explicitly and list any residual risk, missing gate evidence, or pending human decision. Do not approve while human decisions are pending.
diff --git a/skills/web-perf/SKILL.md b/skills/web-perf/SKILL.md
new file mode 100644
index 0000000..0fb166e
--- /dev/null
+++ b/skills/web-perf/SKILL.md
@@ -0,0 +1,201 @@
+---
+name: web-perf
+description: Analyzes web performance using Chrome DevTools MCP. Measures Core Web Vitals (LCP, INP, CLS) and supplementary metrics (FCP, TBT, Speed Index), identifies render-blocking resources, network dependency chains, layout shifts, caching issues, and accessibility gaps. Use when asked to audit, profile, debug, or optimize page load performance, Lighthouse scores, or site speed. Biases towards retrieval from current documentation over pre-trained knowledge.
+---
+
+# Web Performance Audit
+
+Your knowledge of web performance metrics, thresholds, and tooling APIs may be outdated. **Prefer retrieval over pre-training** when citing specific numbers or recommendations.
+
+## Retrieval Sources
+
+| Source | How to retrieve | Use for |
+|--------|----------------|---------|
+| web.dev | `https://web.dev/articles/vitals` | Core Web Vitals thresholds, definitions |
+| Chrome DevTools docs | `https://developer.chrome.com/docs/devtools/performance` | Tooling APIs, trace analysis |
+| Lighthouse scoring | `https://developer.chrome.com/docs/lighthouse/performance/performance-scoring` | Score weights, metric thresholds |
+
+## FIRST: Verify MCP Tools Available
+
+**Run this before starting.** Try calling `navigate_page` or `performance_start_trace`. If unavailable, STOP—the chrome-devtools MCP server isn't configured.
+
+Ask the user to add this to their MCP config:
+
+```json
+"chrome-devtools": {
+  "type": "local",
+  "command": ["npx", "-y", "chrome-devtools-mcp@latest"]
+}
+```
+
+## Key Guidelines
+
+- **Be assertive**: Verify claims by checking network requests, DOM, or codebase—then state findings definitively.
+- **Verify before recommending**: Confirm something is unused before suggesting removal.
+- **Quantify impact**: Use estimated savings from insights. Don't prioritize changes with 0ms impact.
+- **Skip non-issues**: If render-blocking resources have 0ms estimated impact, note but don't recommend action.
+- **Be specific**: Say "compress hero.png (450KB) to WebP" not "optimize images".
+- **Prioritize ruthlessly**: A site with 200ms LCP and 0 CLS is already excellent—say so.
+
+## Quick Reference
+
+| Task | Tool Call |
+|------|-----------|
+| Load page | `navigate_page(url: "...")` |
+| Start trace | `performance_start_trace(autoStop: true, reload: true)` |
+| Analyze insight | `performance_analyze_insight(insightSetId: "...", insightName: "...")` |
+| List requests | `list_network_requests(resourceTypes: ["Script", "Stylesheet", ...])` |
+| Request details | `get_network_request(reqid: <id>)` |
+| A11y snapshot | `take_snapshot(verbose: true)` |
+
+## Workflow
+
+Copy this checklist to track progress:
+
+```
+Audit Progress:
+- [ ] Phase 1: Performance trace (navigate + record)
+- [ ] Phase 2: Core Web Vitals analysis (includes CLS culprits)
+- [ ] Phase 3: Network analysis
+- [ ] Phase 4: Accessibility snapshot
+- [ ] Phase 5: Codebase analysis (skip if third-party site)
+```
+
+### Phase 1: Performance Trace
+
+1. Navigate to the target URL:
+   ```
+   navigate_page(url: "<target-url>")
+   ```
+
+2. Start a performance trace with reload to capture cold-load metrics:
+   ```
+   performance_start_trace(autoStop: true, reload: true)
+   ```
+
+3. Wait for trace completion, then retrieve results.
+
+**Troubleshooting:**
+- If trace returns empty or fails, verify the page loaded correctly with `navigate_page` first
+- If insight names don't match, inspect the trace response to list available insights
+
+### Phase 2: Core Web Vitals Analysis
+
+Use `performance_analyze_insight` to extract key metrics.
+
+**Note:** Insight names may vary across Chrome DevTools versions. If an insight name doesn't work, check the `insightSetId` from the trace response to discover available insights.
+
+Common insight names:
+
+| Metric | Insight Name | What to Look For |
+|--------|--------------|------------------|
+| LCP | `LCPBreakdown` | Time to largest contentful paint; breakdown of TTFB, resource load, render delay |
+| CLS | `CLSCulprits` | Elements causing layout shifts (images without dimensions, injected content, font swaps) |
+| Render Blocking | `RenderBlocking` | CSS/JS blocking first paint |
+| Document Latency | `DocumentLatency` | Server response time issues |
+| Network Dependencies | `NetworkRequestsDepGraph` | Request chains delaying critical resources |
+
+Example:
+```
+performance_analyze_insight(insightSetId: "<id-from-trace>", insightName: "LCPBreakdown")
+```
+
+**Key thresholds (good/needs-improvement/poor):**
+- TTFB: < 800ms / < 1.8s / > 1.8s
+- FCP: < 1.8s / < 3s / > 3s
+- LCP: < 2.5s / < 4s / > 4s
+- INP: < 200ms / < 500ms / > 500ms
+- TBT: < 200ms / < 600ms / > 600ms
+- CLS: < 0.1 / < 0.25 / > 0.25
+- Speed Index: < 3.4s / < 5.8s / > 5.8s
+
+### Phase 3: Network Analysis
+
+List all network requests to identify optimization opportunities:
+```
+list_network_requests(resourceTypes: ["Script", "Stylesheet", "Document", "Font", "Image"])
+```
+
+**Look for:**
+
+1. **Render-blocking resources**: JS/CSS in `<head>` without `async`/`defer`/`media` attributes
+2. **Network chains**: Resources discovered late because they depend on other resources loading first (e.g., CSS imports, JS-loaded fonts)
+3. **Missing preloads**: Critical resources (fonts, hero images, key scripts) not preloaded
+4. **Caching issues**: Missing or weak `Cache-Control`, `ETag`, or `Last-Modified` headers
+5. **Large payloads**: Uncompressed or oversized JS/CSS bundles
+6. **Unused preconnects**: If flagged, verify by checking if ANY requests went to that origin. If zero requests, it's definitively unused—recommend removal. If requests exist but loaded late, the preconnect may still be valuable.
+
+For detailed request info:
+```
+get_network_request(reqid: <id>)
+```
+
+### Phase 4: Accessibility Snapshot
+
+Take an accessibility tree snapshot:
+```
+take_snapshot(verbose: true)
+```
+
+**Flag high-level gaps:**
+- Missing or duplicate ARIA IDs
+- Elements with poor contrast ratios (check against WCAG AA: 4.5:1 for normal text, 3:1 for large text)
+- Focus traps or missing focus indicators
+- Interactive elements without accessible names
+
+## Phase 5: Codebase Analysis
+
+**Skip if auditing a third-party site without codebase access.**
+
+Analyze the codebase to understand where improvements can be made.
+
+### Detect Framework & Bundler
+
+Search for configuration files to identify the stack:
+
+| Tool | Config Files |
+|------|--------------|
+| Webpack | `webpack.config.js`, `webpack.*.js` |
+| Vite | `vite.config.js`, `vite.config.ts` |
+| Rollup | `rollup.config.js`, `rollup.config.mjs` |
+| esbuild | `esbuild.config.js`, build scripts with `esbuild` |
+| Parcel | `.parcelrc`, `package.json` (parcel field) |
+| Next.js | `next.config.js`, `next.config.mjs` |
+| Nuxt | `nuxt.config.js`, `nuxt.config.ts` |
+| SvelteKit | `svelte.config.js` |
+| Astro | `astro.config.mjs` |
+
+Also check `package.json` for framework dependencies and build scripts.
+
+### Tree-Shaking & Dead Code
+
+- **Webpack**: Check for `mode: 'production'`, `sideEffects` in package.json, `usedExports` optimization
+- **Vite/Rollup**: Tree-shaking enabled by default; check for `treeshake` options
+- **Look for**: Barrel files (`index.js` re-exports), large utility libraries imported wholesale (lodash, moment)
+
+### Unused JS/CSS
+
+- Check for CSS-in-JS vs. static CSS extraction
+- Look for PurgeCSS/UnCSS configuration (Tailwind's `content` config)
+- Identify dynamic imports vs. eager loading
+
+### Polyfills
+
+- Check for `@babel/preset-env` targets and `useBuiltIns` setting
+- Look for `core-js` imports (often oversized)
+- Check `browserslist` config for overly broad targeting
+
+### Compression & Minification
+
+- Check for `terser`, `esbuild`, or `swc` minification
+- Look for gzip/brotli compression in build output or server config
+- Check for source maps in production builds (should be external or disabled)
+
+## Output Format
+
+Present findings as:
+
+1. **Core Web Vitals Summary** - Table with metric, value, and rating (good/needs-improvement/poor)
+2. **Top Issues** - Prioritized list of problems with estimated impact (high/medium/low)
+3. **Recommendations** - Specific, actionable fixes with code snippets or config changes
+4. **Codebase Findings** - Framework/bundler detected, optimization opportunities (omit if no codebase access)