doc-gen
Documentation generator with three modes: function-level (JSDoc/docstrings), module-level (directory READMEs), and API reference (endpoints/exports).
Skill by mayankjain1815-commits
Install
Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.
npx agentmarket install skill/mayankjain1815-commits-doc-gen
Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.
Get the weekly diff
The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.
About
Use cases: documents, backend
Reviews
Write a reviewNo reviews yet. Installed it? Reviews come from verified installers only. How reviews work
Permissions
What this skill can do and what it asks for, from its SKILL.md. Checked Oct 25, 2026.
- Tools
- No tools found
- Secrets
- None asked for
- Install scripts
- None found
Network hosts it talks to 1
codeload.github.com· found in install command
Files it touches
~/.claude/skills/doc-gen
What's inside
- Skill name
doc-gen- Description
- Documentation generator with three modes: function-level (JSDoc/docstrings), module-level (directory READMEs), and API reference (endpoints/exports). Reads existing project doc style and matches it. Never generates docs that just restate what the signature already says.
- License
- MIT
- Instructions
- 113 lines in SKILL.md · view on GitHub
Files (3)
- SKILL.md
- generate-readme.md · __benchmarks__/
- no-source-files.md · __benchmarks__/
SKILL.md (first lines)
# /doc-gen — Documentation Generator
## When to Use
- Add JSDoc/docstrings to functions in a file or set of files
- Write a README for a module or directory
- Document an HTTP API or exported library surface
Mode auto-detected from target:
- **File path** → function-level mode
- **Directory path** → module-level mode
- **Route file or API directory** → API reference mode
- **Explicit override**: `/doc-gen --mode function|module|api [target]`
## Commands
| Command | Behavior |
|---|---|
| `/doc-gen [file]` | Function-level docs for a file |
| `/doc-gen [directory]` | Module-level README for a directory |
| `/doc-gen --api [target]` | API reference for endpoints or exports |
| `/doc-gen --mode [mode] [target]` | Force a specific mode |
| `/doc-gen --dry-run [target]` | Show what would be documented without writing |
## Protocol
### Phase 1: DETECT STYLE
1. Read CLAUDE.md for doc conventions
2. Search for existing doc comments in the target area — note density, tone, tags used, and line length
3. Default when no existing docs: JSDoc (`@param`, `@returns`, `@throws`, `@example`) for TS/JS; Google-style for Python; idiomatic format for others
Apply detected style consistently across all generated docs.
### Phase 2: ANALYZE TARGET
#### Function-Level Mode
For each function:
1. Read the full body, not just the signature
2. Classify:
- **Trivial**: simple getters/setters, one-line wrappers with obvious names — SKIP
- **Non-trivial**: document purpose, parameter semantics (not types — TS has those), return guarantees, throws/errors, side effects, non-obvious edge cases, and `@example` when usage is non-obvious
3. Write using detected style
**Core rule:** every doc must add information beyond what the signature already says. If you cannot, skip it.
#### Module-Level Mode
1. Read all files in the directory (one level deep)
2. Identify: problem space, key exports, internal files, external dependencies, and what imports this module
3. README schema: `# {Module Name}` | one-paragraph description | `## Key Exports` table (name, description) | `## Architecture` (only if non-obvious internal structure) | `## Usage` (real import paths) | `## Dependencies` (non-obvious only)
4. If a README already exists, update rather than replace — preserve sections not covered by your analysis
#### API Reference Mode
For HTTP endpoints: method + path, description, path/query/body params (with types), response shape and status codes, errors, auth level, and a curl/fetch example for non-trivial endpoints.
For exported libraries: name and kind (function/class/constant/type), description, parameters/properties with semantics, return type with guarantees, import and usage example.
Structure as a single reference document with a table of contents.
### Phase 3: WRITE
1. Apply detected style consistently
2. Function-level: insert doc comments above each function
3. Module-level: write or update README.md in the target directory
4. API reference: write to `docs/api/` or adjacent to route files
5. Run typecheck after writing (malformed JSDoc can cause TS errors)
### Phase 4: VERIFY
Re-read every doc comment. For each: "Does this add information beyond the signature?" If not, delete it. Check accuracy: parameter names, return types, side effects, and that examples would actually compile/run.
## Contextual Gates
**Disclosure:** "Generating documentation for [target]. Source files will be modified."
**Reversibility:** amber — adds JSDoc/docstrings to source files; undo with `git checkout` on modified files.
**Trust gates:**
- Any: additive doc generation on undocumented functions.
- Familiar (5+ sessions): rewriting existing docstrings that may discard prior content.
## Quality Gates
- Every doc comment adds information beyond the signature; if not, delete it
- Docs match actual code behavior — wrong docs are worse than no docs
- Style matches the project's existing convention throughout
- No `@param name - The name` filler; omit parameters when their name is self-explanatory
- Typecheck passes after insertion
- At least some functions skipped as trivial — if every function was documented, you over-documented
## Exit Protocol
```
=== Doc-Gen Report ===
Mode: {function-level | module-level | api-reference}
Target: {path}
Style: {detected style}
Documented: {N functions ({M} skipped as trivial) | README.md ({N} exports) | {N} endpoints}
Skipped: {item}: {reason}
```
```
---HANDOFF---
- Generated {mode} docs for {target}
- Matched existing {style} convention
- {what was skipped and why}
- Reversibility: amber — undo with `git checkout` on modified source files
---
```From mayankjain1815-commits/CITADEL, MIT.
More from mayankjain1815-commits/CITADEL
- 0.519score
create-skill
mayankjain1815-commits
Creates new skills from the user's repeating patterns.
SkillCFreshness: C★ 4Claude Code +9 - 0.519score
daemon
mayankjain1815-commits
Continuous autonomous operation mode.
SkillCFreshness: C★ 4Claude Code +9 - 0.519score
grill
mayankjain1815-commits
Relentless one-question-at-a-time interview that sharpens a vague plan or design into shared understanding before any build.
SkillCFreshness: C★ 4Claude Code +9 - 0.519score
evolve
mayankjain1815-commits
Research-driven multi-cycle improvement director.
SkillCFreshness: C★ 4Claude Code +9 - 0.519score
decision-map
mayankjain1815-commits
Turn a loose idea into a git-tracked, session-resumable map of typed investigation tickets, then drive them to resolution one at a time.
SkillCFreshness: C★ 4Claude Code +9 - 0.519score
fleet
mayankjain1815-commits
Parallel campaign orchestrator.
SkillCFreshness: C★ 4Claude Code +9 - 0.516score
deploy-steward
mayankjain1815-commits
Mainline deploy steward.
SkillCFreshness: C★ 4Claude Code +9 - 0.516score
design
mayankjain1815-commits
Generates and maintains a design manifest for visual consistency.
SkillCFreshness: C★ 4Claude Code +9 - 0.516score
do
mayankjain1815-commits
Unified router that auto-routes user intent to the right orchestrator or skill.
SkillCFreshness: C★ 4Claude Code +9 - 0.516score
experiment
mayankjain1815-commits
Automated optimization loop with scalar fitness function.
SkillCFreshness: C★ 4Claude Code +9 - 0.516score
architect
mayankjain1815-commits
Given a PRD, produces an implementation architecture: file tree, component breakdown, data model, and a phased build plan with end conditions that Archon can…
SkillCFreshness: C★ 4Claude Code +9 - 0.516score
archon
mayankjain1815-commits
Autonomous multi-session campaign agent.
SkillCFreshness: C★ 4Claude Code +9
Signals
- Stars
- 4
- Forks
- 0
- Open issues
- 0
- Last commit (this folder)
- Jun 11, 2026 (4 months ago)
From GitHub (fetched Oct 24, 2026).
Details
- License
- MIT
- First seen
- Oct 24, 2026
- Last checked
- Oct 24, 2026
- Source
- GitHubgithub-graphql
Same skill elsewhere
Copies of this SKILL.md published by others; search shows only one of them.
More from mayankjain1815-commits
- 0.519score
decision-map
mayankjain1815-commits
Turn a loose idea into a git-tracked, session-resumable map of typed investigation tickets, then drive them to resolution one at a time.
SkillCFreshness: C★ 4Claude Code +9 - 0.519score
fleet
mayankjain1815-commits
Parallel campaign orchestrator.
SkillCFreshness: C★ 4Claude Code +9 - 0.519score
create-skill
mayankjain1815-commits
Creates new skills from the user's repeating patterns.
SkillCFreshness: C★ 4Claude Code +9 - 0.519score
daemon
mayankjain1815-commits
Continuous autonomous operation mode.
SkillCFreshness: C★ 4Claude Code +9 - 0.519score
evolve
mayankjain1815-commits
Research-driven multi-cycle improvement director.
SkillCFreshness: C★ 4Claude Code +9 - 0.519score
grill
mayankjain1815-commits
Relentless one-question-at-a-time interview that sharpens a vague plan or design into shared understanding before any build.
SkillCFreshness: C★ 4Claude Code +9
Cite this page
doc-gen skill. Agent Mart. https://agentmart.dev/skills/mayankjain1815-commits-doc-gen (last updated 2026-10-24)