docs-init
Skill8 starsChanged 48 days agoMITView on GitHub
Bootstraps a documentation structure (architecture, onboarding, data-model,
- Installs packages
3 other projects use a version of this.
Adopted by
Most recently taken up by
- obviousbread/docs-skillstheir own version, first seen Nov 1, 2026
- lelborn/skillstheir own version, first seen Nov 1, 2026
- AosJunior/claude-skillstheir own version, first seen Oct 19, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- AosJunior/claude-skills★ 1same name
- lelborn/skills★ 0same name
- obviousbread/docs-skills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository53 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- agent-browserSkill
- anything-to-skillSkill
- ci-generateSkill
- ci-localSkill
- clotho-researchSkill
- codex-imagegenSkill
- create-ruleSkill
- create-skillSkill
- db-migrateSkill
- docker-initSkill
- docs-adrSkill
- docs-checkSkill
- docs-diagramSkill
- docs-rfcSkill
- docs-updateSkill
- env-setupSkill
- find-skillsSkill
- fix-bugSkill
- git-commitSkill
- git-create-prSkill
- gitflowSkill
- git-releaseSkill
- git-syncSkill
- i18n-checkSkill
- implement-featureSkill
- improve-skillSkill
- inject-docsSkill
- jira-cliSkill
- motion-studioSkill
- optimize-ai-setupSkill
- orchestrateSkill
- oss-launchSkill
- prd-to-issuesSkill
- product-design-specSkill
- product-design-tokensSkill
- product-prdSkill
- project-illustratorSkill
- project-plannerSkill
- refactorSkill
- renderSkill
- review-codeSkill
- review-depsSkill
- review-designSkill
- review-perfSkill
- review-planSkill
- review-securitySkill
- shipSkill
- stopslopSkill
- test-suiteSkill
- vrt-checkSkill
- wtfSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 6 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 27
Every claim in generated docs must trace to something read or grepped in this run:
- Distinctive: line 29
Verify a file/directory exists before referencing it.
- Distinctive: line 33
If a claim can't be verified, drop it rather than guess.
- Very specific: line 41
If a Task/subagent tool is available, delegate this to an Explore agent with that scope.
- Distinctive: line 43
Verify every finding before using it: read the package manifest, read the model file, confirm a directory has real files inside it, not …
- Distinctive: line 56
Don't generate a doc type with no supporting evidence: an empty data-model.md for a stateless CLI is worse than no file at all.
- Very specific: line 69
After writing the file, grep it for \{\{[A-Z_0-9]+\}\} again.
- Very specific: line 88
Create docs/ (and docs/adr/, docs/rfc/ if needed).
- Very specific: line 94
Run this on the files you wrote.
- Distinctive: line 124
Run these directly (or hand them to the Explore agent from step 1):
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Initialize Project Documentation
Bootstrap a docs/ structure for a project with little or no existing documentation. Only generate what the codebase actually evidences.
Anti-hallucination guidelines
Every claim in generated docs must trace to something read or grepped in this run:
- Verify a file/directory exists before referencing it.
- Get counts from
ls/find/grep, never estimate. - Quote real function/class/table names, not assumed ones.
- An empty directory is not a feature, don't document it.
- If a claim can't be verified, drop it rather than guess.
Workflow
1. Explore the codebase
Find: source directories with actual code, package manager files (package.json, pyproject.toml, go.mod, Cargo.toml, ...), database/ORM files, infrastructure configs (Docker, k8s, Terraform), and any existing docs/. See Detection Commands below for the exact patterns.
If a Task/subagent tool is available, delegate this to an Explore agent with that scope. Otherwise run the same grep/find commands inline and Read each hit: the result must be the same either way.
Verify every finding before using it: read the package manifest, read the model file, confirm a directory has real files inside it, not just an empty folder.
2. Detect project characteristics
From the exploration, determine: language/framework stack, project type (web app, CLI, library, service), whether a database/ORM is present, and whether infrastructure/deployment configs exist. These characteristics drive which doc types Phase 3 decides to generate.
3. Decide which docs to generate
- Always:
docs/architecture.md,docs/onboarding.md,docs/adr/0001-record-architecture-decisions.md(Nygard-format meta-ADR, generate inline, no template file) - If a database/ORM was found:
docs/data-model.md - If deployment configs were found (Dockerfile, k8s manifest, CI workflow, IaC):
docs/deployment.md,docs/security.md - If the project looks collaborative (multiple contributors in
git log, an open-source license, no existing CONTRIBUTING):docs/contributing.md,docs/rfc/directory
Don't generate a doc type with no supporting evidence: an empty data-model.md for a stateless CLI is worse than no file at all.
4. Check for existing docs
Scan docs/. For any target file that already exists, do not overwrite it: list it under "skipped" and ask the user before touching it. This skill is safe to rerun: by default it only fills gaps.
5. Populate templates
Templates live in assets/templates/ (see reference table below). For each one you're using:
- Grep it for its actual placeholder set:
grep -oE '\{\{[A-Z_0-9]+\}\}' assets/templates/<name>.md | sort -u - Map every placeholder to a value from step 1/2's verified findings. Never leave a placeholder as a literal
{{TOKEN}}in the output. - Templates mark some sections as conditional with an HTML comment ("delete if...", "only if evidenced"). Where the codebase gives no evidence for that section, delete the whole section (heading included, not just the placeholder text).
- After writing the file, grep it for
\{\{[A-Z_0-9]+\}\}again. Zero matches. If any remain, resolve or delete them before moving on.
Worked example (a FastAPI + PostgreSQL service):
$ grep -oE '\{\{[A-Z_0-9]+\}\}' assets/templates/architecture.md | sort -u
{{COMPONENT_DEPENDENCIES}}
{{COMPONENT_DESCRIPTION}}
{{COMPONENT_NAME}}
{{DATA_FLOW}}
{{DATE}}
{{DEPLOYMENT_SUMMARY}}
...Map each to a verified finding: {{TECHNOLOGY_STACK}} becomes "Python 3.12, FastAPI 0.115, PostgreSQL 16 via SQLAlchemy", read from pyproject.toml and the model files, not assumed. If security.md's Compliance section has no GDPR/HIPAA evidence in the codebase (no consent flow, no PHI handling), delete that whole section rather than fill it with a guess.
6. Write the files
Create docs/ (and docs/adr/, docs/rfc/ if needed). Write each file that isn't being skipped.
7. Validate the diagrams render
Skip if none of the files you wrote has a ```mermaid block. Otherwise you need mmdc: install with npm i -g @mermaid-js/mermaid-cli, or run it ad hoc by defining mmdc() { npx -y -p @mermaid-js/mermaid-cli mmdc "$@"; } first. If Chromium refuses to launch in a sandbox, add -p with a puppeteer config of {"args":["--no-sandbox"]}.
Run this on the files you wrote; each FAIL <name>-N.mmd names the doc and the Nth mermaid block in it:
d=$(mktemp -d)
for md in <the docs/ files you wrote>; do
awk -v out="$d/${md//\//__}" '/^```mermaid/{f=out "-" ++n ".mmd"; next} /^```/{f=""} f{print > f}' "$md"
done
for f in "$d"/*.mmd; do mmdc -q -i "$f" -o "${f%.mmd}.svg" || echo "FAIL $f"; doneFix each failing block using its parser error, then re-run until nothing prints FAIL. Cap at 3 rounds, then report the blocks that still fail. If mmdc can't be installed (no Node, offline), say so in the report and fall back to a careful syntax review of each diagram.
8. Report
List what was created, what was skipped (already existed), diagram validation result (rendered, or still failing, or unvalidated), and next steps.
Template Reference
| Document | Template | Generated when |
| Architecture | architecture.md | always |
| Onboarding | onboarding.md | always |
| First ADR | inline (Nygard format) | always |
| Data Model | data-model.md | database/ORM detected |
| Deployment | deployment.md | deployment config detected |
| Security | security.md | deployment config detected |
| Contributing | contributing.md | collaborative project |
Detection Commands
Run these directly (or hand them to the Explore agent from step 1):
# Language/framework
find . -name "package.json" -o -name "pyproject.toml" -o -name "go.mod" -o -name "Cargo.toml" | head -5
# Database/ORM
find . -name "*models.py" -o -name "*schema.prisma" -o -name "*entity.ts" | head -5
# Infrastructure
find . -name "Dockerfile" -o -name "docker-compose.yml" -o -name "*.k8s.yaml" | head -5
# Project name and description
basename "$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
head -20 README.md 2>/dev/nullUsage Examples
docs-init
docs-init for Python FastAPI microservice
docs-init for Next.js SaaS applicationExample Output
Documentation Initialization Complete
Created:
docs/architecture.md - System architecture overview
docs/onboarding.md - Developer onboarding guide
docs/adr/0001-record-architecture-decisions.md - Meta-ADR
docs/data-model.md - Database schema (SQLAlchemy detected)
docs/deployment.md - Deployment guide (Docker detected)
Skipped (already exists):
docs/contributing.md
Next steps:
1. Review and customize the generated docs
2. docs-diagram er / docs-diagram arch for standalone diagrams
3. docs-adr "Decision Title" for future ADRsNotes
- Safe to rerun: only fills gaps, asks before overwriting existing files.
- User-supplied context (e.g. "for a FastAPI microservice") steers detection but doesn't replace verification: still confirm the stack from the actual files.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

