Verify documentation examples

Examples & Instructions Verification

Every command, code block, configuration snippet and procedural step in documentation must work as written for the version and environment it targets—or be explicitly marked as unverified when it cannot be run safely.

1. Verify commands and step order safely

• Check the exact working directory each command expects (root vs. package folder) and state it in the text or command block.
• Walk the steps in the exact order written to confirm there are no hidden prerequisites (missing install step, unstarted service, unset environment variable, uncreated directory or migration).
• Run safe, read-only or local test commands (such as --help, build, typecheck, dry-run or unit tests) to confirm flags, script names and output match the prose.
• Safety boundary: never run destructive, state-mutating or production-affecting commands (DROP, rm -rf, live webhooks, paid external calls, production deploys) just to test documentation. Verify those against the source code and tests instead, and note how they were checked.

2. Check internal consistency of code and API examples

• Imports, types and signatures: ensure every import path, function name, option key and return shape in a snippet matches the current codebase.
• Request and response payloads: verify that every field in an example JSON request is accepted by the validator/schema and every field in the example response is actually produced by the serializer.
• Identifiers and variables: keep placeholder values (project_123, item_456, $API_TOKEN) consistent from the first step of a guide to the last so a reader following along does not hit a mismatched name.
• Version alignment: confirm syntax and flags match the package and runtime versions pinned in the repository (package.json, composer.json, engine constraints).

3. Sanitize secrets, credentials and benchmark claims

• Replace any real token, API key, password, private URL, session cookie or personal data with clearly fake placeholders (<YOUR_API_TOKEN>, sk-test-placeholder, user@example.com).
• Never present synthetic or placeholder numbers as measured benchmark or production results.

4. State what was tested and what was not

• Never claim you executed an example if you only inspected the code.
• In your handoff or summary, list:
  1. Which commands and examples were executed and verified in the local environment.
  2. Which examples were verified statically against schemas, routes and tests.
  3. Any steps or external integrations that could not be verified locally and why.

Before you finish

• Step order checked for hidden dependencies, working directory and prerequisites.
• Safe commands and checks run; destructive commands verified from code without unsafe execution.
• Code snippets, imports, CLI flags and JSON payloads match the current source and schemas.
• Placeholders are consistent throughout; zero real secrets or personal data appear.
• Executed vs. statically checked vs. unverified items are explicitly reported.