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.

7 files changed, 792 insertions, 0 deletions

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 ` `
+  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