Borrowing it
Nothing to install: this file belongs to ibrhr/qdoc. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/ibrhr/qdoc/main/.opencode/commands/add-docs.mdgit clone --depth 1 https://github.com/ibrhr/qdocWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/ibrhr/qdoc/add-docs)<a href="https://agentmods.dev/commands/ibrhr/qdoc/add-docs"><img src="https://agentmods.dev/badge/commands/ibrhr/qdoc/add-docs/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/ibrhr/qdoc/add-docs"><img src="https://agentmods.dev/badge/commands/ibrhr/qdoc/add-docs.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00027 | $0.01297 |
| Opus 5.5 | $0.00011 | $0.00519 |
| Sonnet 5.5 | $0.00005 | $0.00259 |
| Haiku 4.5 | $0.00003 | $0.00130 |
Grade A, and why
add-docs scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 109 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Research the $ARGUMENTS documentation site thoroughly. This is a multi-phase task. Complete each phase before moving to the next.
Phase 1: Discover the documentation site
Search the web to find the official documentation URL for $ARGUMENTS. Once found:
- Note the base URL (e.g.
https://docs.example.com) - Note the index page URL (the page listing all doc pages — usually the root or
/docs) - Note any link prefix that filters to doc-only pages (e.g.
/docs/,/latest/)
Confirm the URL is accessible by fetching it.
Phase 2: Traverse and map the documentation
Fetch the index page and study ALL available documentation pages. Your goal is to understand where every piece of information lives. Specifically:
- Categories of docs (getting-started, guides, API reference, tutorials, advanced, deployment, etc.)
- Sub-paths under each category and what they cover
- Hidden/less-obvious sections (changelogs, migration guides, internal architecture, community pages, contributing guides, security policies, deprecation notices)
- Special pages (glossary, FAQ, troubleshooting, common-errors, best-practices, style-guide)
- Version-specific pages (e.g.
/v2/,/v3/,/next/) - How the docs differentiate between major versions or editions (e.g. App Router vs Pages Router in Next.js, or Standard Library vs Language Reference in Python)
- Non-obvious docs: CLI references, configuration file options, environment variables, editor/IDE setup, testing guides, benchmarking, deployment checklists
Be thorough. Read 5-10 actual pages to understand the content depth and style. Note:
- How deeply nested sections go
- Whether pages are self-contained or reference each other heavily
- Whether examples are runnable or illustrative
- Whether there are interactive playgrounds or sandboxes
Phase 3: Analyze and take notes
Study the documentation structure thoroughly in your working context (no persisted file). Note:
- The full categorized layout of sections and sub-paths
- Hidden/non-obvious sections (changelogs, migration guides, security policies, deprecation notices, contributing guides, glossary, FAQ)
- Quirks & gotchas (URL overlaps, deprecated pages still indexed, redirects, sparse pages, JS-rendered content)
- Content quality: shallow vs deep coverage, example quality, cross-referencing habits
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 109 lines · 27 tokens per session scan A 37de80f18624
add-docs is a command published in the GitHub repository ibrhr/qdoc (2 stars, last pushed 1mo ago), licensed MIT. It adds 27 tokens to every session and 1,297 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.
speckit.bug.fix
Apply the remediation from a bug assessment and record what was changed.
speckit.bug.test
Validate that a previously fixed bug is resolved and record the verification report.