Skip to main content

docs-verify-machine-facts

Verify machine-read values (scutil, route, ifconfig, local config) against the authoritative IaC before publishing. Use when org docs quote DNS names, IPs, endpoints, or versions read off this host.

Informações da origem

Repositório
laurigates/claude-plugins
Última atividade na origem
20 de agosto de 2026 às 03:39
Idioma detectado do SKILL.md
inglês
Estrelas
58
Forks
6

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
name
docs-verify-machine-facts
description
Verify machine-read values (scutil, route, ifconfig, local config) against the authoritative IaC before publishing. Use when org docs quote DNS names, IPs, endpoints, or versions read off this host.
allowed-tools
Read, Grep, Glob, Edit, TodoWrite
created
2026-08-19T00:00:00.000Z
modified
2026-08-19T00:00:00.000Z
reviewed
2026-08-19T00:00:00.000Z
# Verify Machine-Read Facts Against the Org Source-of-Truth Before Publishing When documenting infrastructure from values read off **your own machine** — `ifconfig`, `scutil --dns`, `route get`, `netstat -rn`, `defaults read`, a local config file — those readings can carry **personal or host-specific artifacts** that are not org facts. Publishing them to shared documentation silently passes off your home network (or a stale local override, or another VPN) as the organization's configuration. ## The failure mode A diagnostic session reads the live state of a tool on your laptop, the output looks authoritative, and environment-specific lines get lifted verbatim into an org doc: 1. You run `scutil --dns` / `route get` to investigate a VPN/tunnel. 2. The output interleaves **multiple** resolvers and routes — the org tunnel's *and* your home network's, your other VPN's, a local `/etc/hosts` override. 3. You document the interesting values without separating "this is the org's" from "this is mine." 4. The doc now tells every reader that the org's internal DNS domain is `intra.lakuz.com` with resolvers `100.95.0.251–.254` — which was the **author's home LAN**, not the org's anything. The tell: the value is specific and plausible, so reviewers don't question it — it reads as researched fact. The leak surfaces only when someone who knows the real environment says "that's not ours." > Canonical break (2026-06): an FVH Twingate troubleshooting DevGuide > published `intra.lakuz.com` + `100.95.0.x` as the org's internal DNS. > Both were the author's home network, picked up from a `scutil --dns` > dump where the home resolver sat in `resolver #1` above the Twingate > overlay. The real FVH resource domains (`*.dataportal.fi`, `*.fvh.io`, > `*.cluster.local`) live in `twingate/resources.tf`. Corrected in a > follow-up commit after the user caught it. ## The rule Before a machine-read value lands in **org / shared / outward-facing** documentation, cross-check it against the **authoritative source** — not the local readout: - **Network/DNS/routing facts** → the IaC that defines them (`twingate/resources.tf`, Terraform, the DHCP/DNS config), not `scutil`/`route`/`ifconfig` on one host. - **Endpoints, domains, IP ranges** → the config that provisions them, not what resolved on your machine this session. - **Versions, flags, paths** → the project's manifest/lockfile, not what happens to be installed locally. If you cannot tie a specific value to an authoritative source, either **omit it** or **describe the mechanism instead of the literal**. The mechanism is environment-independent and cannot leak: ``` # Leaky — pins host-specific literals as if they were org facts Internal DNS resolvers: 100.95.0.251–.254 ; search domain intra.lakuz.com # Safe — verifiable mechanism, no machine-specific artifact Twingate resolves configured resource domains (*.dataportal.fi, *.fvh.io, *.cluster.local — see twingate/resources.tf) into the 100.96/12 overlay. Verify by resolving the name: the answer should be a 100.96.x address. ``` ## Separating yours from theirs in a multi-source readout `scutil --dns`, `netstat -rn`, and `route get` show **all** active resolvers/routes interleaved. To attribute a line correctly: - A value reachable only **through the tunnel interface** (`utunN`) is the org's; a value on `en0`/Wi-Fi is local. - Cross-reference the route table: the org tunnel's routes point at the tunnel interface and match the IaC's resource ranges. Home/local resolvers route via your LAN gateway. - When in doubt, the IaC is authoritative over any local readout. ## Stale, not just misattributed A fact true when drafted can be false when published. Re-derive mutable ones (dates, versions, IDs, counts) in the breath that publishes. 2026-08: a draft held through two review rounds needed a rolled-over date and 2 of 11 version IDs fixed at post time. ## Relationship to sibling rules - `git-plugin:git-upstream-fix-check` — same instinct (check the authoritative source before acting) applied to vendored code. - `documentation-plugin:docs-single-source` — link to the source-of-truth rather than transcribing; a value you can't link to the source is a value you probably shouldn't hardcode. - The `agent-patterns-plugin:cold-read-gate` pattern — an outside reader catches what the author, steeped in their own environment, cannot see is host-specific. ## Rationale A wrong machine-read literal in shared docs is worse than no value: it is confidently specific, so it propagates as fact and misleads everyone who can't independently check it. The cost of verification is one lookup against the IaC at authoring time; the cost of skipping it is a published leak (sometimes of personal infrastructure) and a re-do once someone with ground truth notices. Prefer the verifiable mechanism over the convenient literal whenever the literal came from your own host.
Ver no GitHub