Code Example Verifier
Verify documentation code examples against the current repository and toolchain, then fix snippets, imports, commands, and expected output without changing the documented intent. Use when docs examples may be stale, an SDK or API changed, users report copy-paste failures, or before publishing tutorials, READMEs, migration guides, and release documentation.
npx agentscamp add skills/code-example-verifierInstall to ~/.claude/skills/code-example-verifier/SKILL.md
Turns documentation snippets into tested examples. It inventories fenced code and shell commands, maps each example to the current API and supported versions, extracts or reproduces snippets in a minimal harness, runs them with sanitized inputs, verifies expected output, fixes the documentation rather than hiding errors, and reports examples that cannot be executed automatically.
Make documentation examples copy-pasteable and truthful against the current codebase. Do not silently convert real examples into vague pseudocode to make the audit pass.
Workflow
- Inventory examples. Find fenced code, inline shell commands, configuration blocks, request examples, imports, package names, paths, environment variables, and claimed output. Group duplicated snippets by canonical source.
- Classify execution. Mark each example
runnable,compile-only,requires controlled integration,destructive/manual, orpseudocode. Flag unlabeled pseudocode presented as executable code. - Check prerequisites. Verify supported runtime and package versions, setup steps, imports, public APIs, file paths, environment variables, and permissions against the repository—not memory.
- Build minimal harnesses. Extract examples into temporary or existing documentation-test fixtures without altering their semantics. Use sanitized local data and mock only external boundaries that the example is not teaching.
- Run safely. Execute format, compile/typecheck, and runtime commands as appropriate. Never run destructive, production, billing, or credentialed examples; validate their syntax and document the manual test boundary.
- Verify outputs. Assert exit status, response shape, created artifacts, and documented output. Normalize volatile timestamps, ports, IDs, and paths without weakening meaningful assertions.
- Fix the source. Update imports, commands, setup, code, output, and cleanup in the documentation. Prefer linking or generating from tested canonical examples when duplication causes drift.
- Add repeatable checks. Integrate deterministic examples into the repository's docs test, typecheck, or CI workflow when within scope.
- Report exceptions. List examples not executed, why, the risk, and the exact manual verification needed.
WARNING
Never execute a documentation command merely because it is fenced as bash. Inspect for deletion, deployment, migration, credential use, external side effects, and production targets first.
Output
Return:
- an example inventory with classification and verification status
- documentation edits for every stale or incomplete example
- harness or CI changes for deterministic examples
- exact commands run and observed results
- unverified examples with reason and manual verification procedure
- duplicated snippets that should be generated from one tested source
Frequently asked questions
- Should every documentation snippet run in CI?
- Run every example that can be made deterministic and safe. Mark conceptual pseudocode clearly, and review examples requiring credentials, external services, destructive commands, or large environments with a documented manual verification procedure.
- Is checking that code compiles enough?
- No. Compilation catches syntax and type drift but not wrong output, missing setup, incorrect commands, unsafe defaults, or runtime API changes. Verify the user-visible result and cleanup path as well.
Related
- 7 Best Claude Skills for DocumentationUse Claude skills to verify code examples and create accurate READMEs, API docs, runbooks, onboarding guides, ADRs, and diagrams.
- Readme GeneratorGenerate or refresh a project README grounded in the actual repository. Use when a project has no README, a stale one, or you want install/usage/scripts/structure sections that match the real code.
- OpenAPI Doc WriterProduce and maintain OpenAPI documentation for an HTTP API. Use when documenting endpoints, request/response schemas, or generating API reference docs.
- Runbook WriterWrite an operational runbook a half-asleep on-call engineer can execute at 3am — scoped to ONE alert, leading with how to confirm the problem, the copy-pasteable mitigation that stops user pain, then diagnosis, escalation, and verification. Use when an alert has no documented response, after an incident exposed a missing procedure, or when standing up on-call for a service.
- Onboarding Guide WriterWrite a developer onboarding guide that gets a new contributor from clone to first merged change fast — a verified golden path, a quick architecture map, the real workflow conventions, and the gotchas that live only in senior engineers' heads. Use when a repo has no onboarding doc, when new hires keep asking the same setup questions, or when the README is a marketing page instead of a contributor guide.
- Documentation EngineerUse this agent to write and maintain technical docs that stay true to the code — READMEs, how-to guides, API references, and runbooks. Examples — updating a stale README after a refactor, documenting a new public API from its signatures, writing an on-call runbook for a service.