Generate docs

Skill viknesh20-20/claude-code-tool-kit/.claude/skills/generate-docs

Production-ready Claude Code configuration. 12 original agents, 200+ slash-command skills, 45+ MCP servers, 14 plugins, design + 3D + WebGPU + GSAP + RAG tooling. One-command Node.js installer for premium websites, SaaS apps, AI agents. Free, MIT, stack-agnostic.

Install

npx -y skills add viknesh20-20/claude-code-tool-kit --skill generate-docs

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Generates documentation matching the project's style — README files, API docs, inline documentation, or architecture docs. Auto-detects the documentation format in use.

SKILL.md

2.9 KB, as published. Nobody here has run it

Generate Documentation

Detect Documentation Style

!find . -name "README*" -o -name "CONTRIBUTING*" -o -name "CHANGELOG*" -o -name "docs" -type d 2>/dev/null | grep -v node_modules | grep -v .git | head -10 !ls docs/ doc/ documentation/ wiki/ 2>/dev/null

Detect Code Documentation Format

!grep -r "\/\*\*" --include="*.ts" --include="*.js" --include="*.java" -l 2>/dev/null | head -3 !grep -r '"""' --include="*.py" -l 2>/dev/null | head -3 !grep -r "\/\/\/" --include="*.rs" --include="*.cs" --include="*.go" -l 2>/dev/null | head -3

Documentation Types

Type 1: README Generation

If "readme" is specified, generate a complete README.md with:

Project name and one-line description
Badges (build status, coverage, version — if CI is configured)
Table of contents
Features list
Prerequisites and installation
Quick start / usage examples
Configuration options
API reference (if applicable)
Contributing guidelines
License

Type 2: API Documentation

If "api" is specified:

Find all public endpoints/routes/handlers
Document each with: method, path, description, parameters, request body, response body, error codes
Generate in the format matching existing docs (OpenAPI, Markdown, or inline)

Type 3: Module/File Documentation

If a file or module is specified:

Read the code completely
Add inline documentation following the project's convention:
- JavaScript/TypeScript: JSDoc (/** ... */)
- Python: Docstrings ("""...""")
- Go: GoDoc comments (// FunctionName ...)
- Rust: Doc comments (/// ...)
- Java: Javadoc (/** ... */)
- C#: XML comments (/// <summary>)
- Ruby: YARD (# @param, # @return)

For each public function/method/class, document:

Brief description of what it does
Parameters with types and descriptions
Return value with type and description
Exceptions/errors that can be thrown
Usage example (for complex APIs)

Type 4: Architecture Documentation

If "architecture" is specified:

Map the high-level system components
Create ASCII or Mermaid diagrams
Document data flow between components
List external dependencies and integrations
Note key design decisions and trade-offs

Rules

Match existing style — if the project uses JSDoc, don't add Python docstrings
Don't over-document — skip obvious getters/setters/constructors
Document the why — explain intent and gotchas, not just parameters
Keep it current — documentation that lies is worse than no documentation
Show don't tell — include usage examples for complex APIs