/generate-docs
Generate comprehensive documentation for the current project or a specified module.
$ npx -y skills add rohitg00/awesome-claude-code-toolkit --agent claude-codeHow it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/generate-docs
Context preview
What this command does when you run it.
Generate comprehensive documentation for the current project or a specified module.
Command definition
generate-docs.md/doc-forge:generate-docs
Generate comprehensive documentation for the current project or a specified module.
Process
1. Survey the project to understand its architecture:
- Read the entry point (main.ts, index.js, app.py, main.go, src/lib.rs)
- Identify the module structure and public API surface
- Check for existing documentation (docs/ directory, JSDoc, docstrings, rustdoc)
- Read package.json, pyproject.toml, or Cargo.toml for project metadata
2. Generate documentation for each public module:
Module Overview
- Purpose: one paragraph explaining what this module does and when to use it
- Dependencies: what this module requires and what depends on it
- Architecture notes: key design decisions and patterns used
Function/Method Documentation
- For each exported function, document:
- Purpose in one sentence
- Parameters with types, descriptions, and default values
- Return type and description
- Exceptions/errors that can be thrown and under what conditions
- Usage example showing the most common invocation
- Edge cases: behavior with null inputs, empty collections, boundary values
Type/Interface Documentation
- For each exported type, document:
- Purpose and when to use this type
- Each field with its type, description, and constraints
- Relationships to other types (extends, implements, references)
- Construction patterns (factory functions, builders, constructors)
Configuration Documentation
- Environment variables with descriptions, types, defaults, and required/optional status
- Configuration file formats with annotated examples
- Feature flags and their effects on behavior
3. Generate usage examples:
- Quick start: minimal code to get the module working
- Common patterns: 3-5 typical use cases with complete code snippets
- Advanced usage: composition with other modules, custom configuration
- Error handling: how to properly handle failures from this module
4. Create a table of contents linking all documented modules.
5. Format the documentation appropriate to the language:
- TypeScript/JavaScript: JSDoc comments in source files + markdown guides
- Python: docstrings (Google style) in source files + markdown guides
- Go: godoc comments in source files
- Rust: rustdoc comments with examples that compile
Output
Write documentation files to a `docs/` directory. For inline documentation, add it directly to source files. Present a summary of all files created or modified.
Rules
- Documentation must be accurate: verify claims by reading the actual implementation
- Use concrete examples, not abstract descriptions ("Pass a user ID" not "Pass an identifier")
- Keep examples runnable: they should work if copied into a project
- Do not document private/internal functions unless they are complex and critical
- Match the existing documentation style if the project already has docs
- Avoid restating what the code obviously does; focus on why and when
- Include a "Getting Started" section for top-level project documentation
- Update the table of contents and any index files when adding new documentation
Read more
/doc-forge:generate-docs
Generate comprehensive documentation for the current project or a specified module.
Process
1. Survey the project to understand its architecture:
- Read the entry point (main.ts, index.js, app.py, main.go, src/lib.rs)
- Identify the module structure and public API surface
- Check for existing documentation (docs/ directory, JSDoc, docstrings, rustdoc)
- Read package.json, pyproject.toml, or Cargo.toml for project metadata
2. Generate documentation for each public module:
Module Overview
- Purpose: one paragraph explaining what this module does and when to use it
- Dependencies: what this module requires and what depends on it
- Architecture notes: key design decisions and patterns used
Function/Method Documentation
- For each exported function, document:
- Purpose in one sentence
- Parameters with types, descriptions, and default values
- Return type and description
- Exceptions/errors that can be thrown and under what conditions
- Usage example showing the most common invocation
- Edge cases: behavior with null inputs, empty collections, boundary values
Type/Interface Documentation
- For each exported type, document:
- Purpose and when to use this type
- Each field with its type, description, and constraints
- Relationships to other types (extends, implements, references)
- Construction patterns (factory functions, builders, constructors)
Configuration Documentation
- Environment variables with descriptions, types, defaults, and required/optional status
- Configuration file formats with annotated examples
- Feature flags and their effects on behavior
3. Generate usage examples:
- Quick start: minimal code to get the module working
- Common patterns: 3-5 typical use cases with complete code snippets
- Advanced usage: composition with other modules, custom configuration
- Error handling: how to properly handle failures from this module
4. Create a table of contents linking all documented modules.
5. Format the documentation appropriate to the language:
- TypeScript/JavaScript: JSDoc comments in source files + markdown guides
- Python: docstrings (Google style) in source files + markdown guides
- Go: godoc comments in source files
- Rust: rustdoc comments with examples that compile
Output
Write documentation files to a `docs/` directory. For inline documentation, add it directly to source files. Present a summary of all files created or modified.
Rules
- Documentation must be accurate: verify claims by reading the actual implementation
- Use concrete examples, not abstract descriptions ("Pass a user ID" not "Pass an identifier")
- Keep examples runnable: they should work if copied into a project
- Do not document private/internal functions unless they are complex and critical
- Match the existing documentation style if the project already has docs
- Avoid restating what the code obviously does; focus on why and when
- Include a "Getting Started" section for top-level project documentation
- Update the table of contents and any index files when adding new documentation
The most comprehensive toolkit for Claude Code -- 135 agents, 35 curated skills (+400,000 via SkillKit), 42 commands, 176+ plugins, 20 hooks, 15 rules, 7 templates, 15 MCP configs, 26 companion apps, 53 ecosystem entries, and more.
Repo: rohitg00/awesome-claude-code-toolkit
Other commands on rohitg00-claude-code-toolkit.
- /adr
Write an Architecture Decision Record documenting a significant technical decision.
Open command - /design-review
Conduct a structured design review of a module, feature, or system component.
Open command - /diagram
Generate Mermaid diagrams from codebase analysis or description.
Open command - /migrate
Plan and execute a framework or library migration incrementally.
Open command - /plan
Create a structured implementation plan for the requested feature or change.
Open command - /refactor
Perform a systematic refactoring of the specified code area.
Open command

