Borrowing it
Nothing to install: this file belongs to jnerytech/specd. 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/jnerytech/specd/main/.claude/skills/docgen/SKILL.mdgit clone --depth 1 https://github.com/jnerytech/specdWrote 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/skills/jnerytech/specd/docgen)<a href="https://agentmods.dev/skills/jnerytech/specd/docgen"><img src="https://agentmods.dev/badge/skills/jnerytech/specd/docgen/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/skills/jnerytech/specd/docgen"><img src="https://agentmods.dev/badge/skills/jnerytech/specd/docgen.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.00102 | $0.02638 |
| Opus 5.5 | $0.00041 | $0.01055 |
| Sonnet 5.5 | $0.00020 | $0.00528 |
| Haiku 4.5 | $0.00010 | $0.00264 |
Grade A, and why
docgen 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 12d 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 — 293 lines — stays where its author put it; the contents beside it link to each section on GitHub.
DocGen — code documentation generator
Generate one or more documentation artifacts for the repository in the current working directory, from real code analysis only.
Arguments
$ARGUMENTS is a space-separated list, all parts optional and order-free:
- repo path — a token that names an existing directory (contains
/, or is., or resolves to a directory). Defaults to the current working directory. This is the repository root: everything is read from it and output goes inside it. - language —
--lang <code>/--lang=<code>(e.g.pt-BR,es,en). Defaults to English. - doc types — everything else. Empty → produce all 8, in the order listed
below. Matched loosely:
c4,c4-modelsandc4_modelsall selectc4-models.md.
If a token matches no doc type and is not an existing directory, list the valid types and stop rather than guessing.
| doc type | output file |
|---|---|
readme |
README.md |
wiki |
wiki.md |
business-rules |
business-rules.md |
business-overview |
business-overview.md |
technical-overview |
technical-overview.md |
c4-models |
c4-models.md |
uml-diagrams |
uml-diagrams.md |
project-overview |
project-overview.md |
Procedure
- Scan. Build a picture of the repo before writing anything:
git -C <repo> ls-files(fall back tofind <repo>if not a git repo) for the file inventory; read the manifest (package.json,pyproject.toml,go.mod,pom.xml, …), the entrypoints, the config, and the modules that carry the domain logic. Read enough real code to write specifics — file names, function names, class names. Skip vendored trees (node_modules,.venv,vendor,dist,build) and anything.gitignored. - Write. For each selected doc type, compose the full markdown per the shared
rules and the per-document spec below, then
Writeit to<repo>/docgen-output/<output file>. Create the directory if missing. One complete document per file — never a stub, never a placeholder. - Report. List the files written with their sizes.
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.
- 12d ago First seen · 293 lines · 102 tokens per session scan A a84b8e8a3f1e
docgen is a skill published in the GitHub repository jnerytech/specd (0 stars, last pushed 2mo ago), licensed MIT. It adds 102 tokens to every session and 2,638 once invoked, about $0.0004 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-10-02.
Other skills, from other repositories
ospec-goal
Create or advance a full OSpec goal using the current document, task graph, worker, review, and evidence workflow.
ospec
Document-driven OSpec workflow for initialization, change/goal routing, validation, archiving, and durable project knowledge.
ospec-change
Create or advance a lightweight OSpec change using the classic fast workflow.
spec-generator
Usa esta skill cuando el usuario pida crear, redactar o revisar una especificación (spec) de una funcionalidad. Guía una entrevista de requisitos y produce un spec.md siguiendo la plantilla del equipo.
openspec-schema-authoring
Create or customize OpenSpec workflow schemas in this repository using openspec schema init and openspec schema fork. Use when the user wants to add, fork, or validate a schema under openspec/schemas/.
openspec-linearized
Use whenever Codex operates on an OpenSpec change lifecycle or artifact, including propose/new change, apply/implement tasks, archive/finalize, sync specs, continue/update artifacts, validate/status checks, or work under openspec/changes/. This is the Linear lifecycle overlay for OpenSpec work: bind Linear issues…