Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/acaprino/daodan/docs-creategit clone --depth 1 https://github.com/acaprino/daodanWhat 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 | $0.00113 | $0.02317 |
| Opus 5 | $0.00056 | $0.01158 |
| Sonnet 5 | $0.00023 | $0.00463 |
| Haiku 4.5 | $0.00011 | $0.00232 |
Grade A, and why
docs-create 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 2d 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 — 209 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Create Documentation
CRITICAL RULES
- Analyze code before writing. Read the actual source code first. Never write documentation based on assumptions.
- Bottom-up approach. Start from code structure, then build documentation that reflects reality.
- Confirm scope with user. Present what will be documented before generating.
- Never enter plan mode. Execute immediately.
Step 1: Analyze Target
Determine what to document from $ARGUMENTS:
- If a file/directory path: scan the code structure
- If a class/module name: find it in the codebase
- If no target: scan the entire project
# Discover project structure
find [target] -type f \( -name "*.py" -o -name "*.ts" -o -name "*.js" -o -name "*.rs" -o -name "*.go" -o -name "*.java" \) | head -50
Identify:
- Language & framework (from package.json, Cargo.toml, pyproject.toml, etc.)
- Key modules (entry points, API routes, core business logic)
- Existing docs (README, docstrings, JSDoc, rustdoc, etc.)
- Public API surface (exports, endpoints, CLI commands)
Step 2: Confirm Documentation Plan
Present the plan and ask for approval. The documentation dimensions are grouped into 5 fasce. The user can pick one dimension, several (combined into a single artifact with sections), an entire fascia, or --full for everything.
Documentation plan for: [target]
Language: [detected]
Framework: [detected]
Files to document:
- [file1] -- [type: API endpoint / class / module / ORM model / config / etc.]
- [file2] -- [type]
- ...
Documentation dimensions (pick one or more; can also pick a whole fascia):
SURFACE (what the system exposes)
- [ ] interfaces -- HTTP/REST, gRPC, GraphQL, WebSocket, CLI, library exports, events emitted (Kafka topics, RabbitMQ exchanges, webhooks emitted)
- [ ] config -- env vars, config files, feature flags, secrets references, runtime profiles
- [ ] integrations -- webhooks consumed, third-party APIs called, message queues, scheduled jobs/cron
INTERNALS (what the system is)
- [ ] architecture -- layers, bounded contexts, component boundaries, design decisions (ADR-style)
- [ ] data-model -- entities, DB schema, DTO/Pydantic/Zod/dataclass, ER diagram, constraints, indexes, migrations
- [ ] data-flows -- request lifecycle, data pipelines, event flows, sequence diagrams, sagas
- [ ] state-machines -- FSMs, lifecycle of domain objects, allowed transitions
- [ ] dependencies -- internal module-to-module call graph + external libraries (with versions) + external services / SaaS
- [ ] concurrency -- workers, queues, schedulers, async tasks, locking, idempotency
- [ ] glossary -- ubiquitous language, domain terminology, business rules
OPERATIONS (how the system runs)
- [ ] auth -- authn/authz flows, RBAC/ABAC, secrets management, PII handling, threat surface
- [ ] errors -- error catalog, retry policy, circuit breaker, fallback, idempotency boundaries
- [ ] observability -- logs emitted, metrics exposed, traces, alerts, referenced dashboards
- [ ] deployment -- Docker/K8s/Terraform, CI/CD, environments, DNS/networking, operational runbooks
PROCESS (how the system evolves)
- [ ] build-release -- versioning, changelog, release cadence, hot-fix process
- [ ] testing -- test pyramid, fixtures, mocks, coverage gaps
- [ ] migrations -- upgrade paths, breaking changes, deprecation cycle
CROSS-CUTTING
- [ ] performance -- SLA/SLO, latency, throughput, known bottlenecks
- [ ] compliance -- GDPR/PCI/HIPAA/SOC2 controls visible in code
TARGETED
- [ ] component -- deep dive on a single module/class (zoom)
FULL
- [ ] full -- all of the above, indexed with table of contents
Output: [format] at [output path]
1. Proceed with this plan
2. Adjust scope -- I'll tell you what to change
3. Cancel
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.
- 2d ago First seen · 209 lines · 113 tokens per session scan A 479804656579
docs-create is a command published in the GitHub repository acaprino/daodan (8 stars, last pushed 7d ago), licensed MIT. It adds 113 tokens to every session and 2,317 once invoked, about $0.0006 per session on Opus 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
git
Git operations with intelligent commit messages and workflow optimization.
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.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
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.