Documentation generator. Analyzes a module's structure and generates README.md and DESIGN.md skeletons. Use when the user mentions generating docs, creating a README, creating a DESIGN doc, doc skeletons, or doc templates. Auto-triggers when a new module is started.
Installs into .claude/skills of the current project.
Are you the author of Gen Docs?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/me-cedric-gen-docs)
---
name: gen-docs
description: Documentation generator. Analyzes a module's structure and generates README.md and DESIGN.md skeletons. Use when the user mentions generating docs, creating a README, creating a DESIGN doc, doc skeletons, or doc templates. Auto-triggers when a new module is started.
license: MIT
compatibility: node>=18
user-invocable: true
disable-model-invocation: false
allowed-tools: Bash, Read, Write, Glob
argument-hint: <module-path> [--force]
risk_level: medium
writes_files: false
requires_tools: []
---
# π Doc Gate Β· Documentation Generator
## Core principle
```
No documentation, no module.
Documentation is the module's identity card.
A module without one does not ship.
```
## Automatic generation
Run the doc generation script (cross-platform):
```bash
# from the skill directory
node scripts/doc_generator.cjs <module-path>
node scripts/doc_generator.cjs <module-path> --force # overwrite existing docs
node scripts/doc_generator.cjs <module-path> --json # JSON output
```
## What it generates
### README.md skeleton
The generated README.md includes:
- **Module name** β extracted from the directory name
- **Description** β extracted from code docstrings (when present)
- **Feature list** β to fill in
- **Dependencies** β extracted from requirements.txt/pyproject.toml
- **Usage** β base template
- **API overview** β class and function list extracted from code
- **Directory structure** β generated by scanning
### DESIGN.md skeleton
The generated DESIGN.md includes:
- **Design overview** β goals and non-goals template
- **Architecture** β architecture diagram placeholder
- **Core components** β class list extracted from code
- **Design decisions** β decision-record table template
- **Technology choices** β language and dependencies auto-detected
- **Trade-offs** β known limitations and tech-debt template
- **Security considerations** β threat model and mitigations template
- **Cross-cutting concerns** β security, privacy, observability, cost
- **Open questions** β the undecided points, and who decides each
- **Change history** β initial version entry
`verify-module` blocks delivery on this section list. Change the generator, this
list, and the [`verify-module`](../verify-module/SKILL.md) checklist in the same
commit.
## Analysis
### Supported languages
| Language | Analysis capability |
|------|----------|
| **Python** | Classes, functions, docstrings, dependencies |
| **Go** | Directory structure, dependencies |
| **TypeScript** | Directory structure, dependencies |
| **Rust** | Directory structure, dependencies |
| **Other** | Basic directory structure |
### Extracted information
- Module name (directory name)
- Primary language
- Code file list
- Class and function definitions (Python)
- Docstrings (Python)
- Dependency list
- Entry-point files
## Auto-trigger moments
| Scenario | Trigger |
|------|----------|
| New module | When module creation starts |
| Missing docs | When a module without docs is detected |
## Workflow
```
1. Run doc_generator.cjs to generate the skeletons
2. Fill in the TODO-marked content
3. Add design decisions and their rationale
4. Add usage examples
5. Run /verify-module to check completeness
```
## Post-generation checklist
### README.md
- [ ] Fill in the module description
- [ ] Complete the feature list
- [ ] Add usage examples
- [ ] Confirm dependencies are complete
### DESIGN.md
- [ ] State the design goals
- [ ] Record design decisions
- [ ] Justify technology choices
- [ ] List known limitations
---