iyuanm/weft_agent/upstream
Claude Code and agent skill by iyuanm/weft_agent
- community
Checking that the SKILL.md file is still in the repository.
Use this skill when the user requests to generate, create, or improve documentation for code, APIs, libraries, repositories, or software projects. Supports README generation, API reference documentation, inline code comments, architecture documentation, changelog generation, and developer guides. Trigger on requests like "document this code", "create a README", "generate API docs", "write developer guide", or when analyzing codebases for documentation purposes.
Install
npx vskill@latest install iyuanm/weft_agent/upstreamSKILL.md
Code Documentation Skill
Overview
This skill generates professional, comprehensive documentation for software projects, codebases, libraries, and APIs. It follows industry best practices from projects like React, Django, Stripe, and Kubernetes to produce documentation that is accurate, well-structured, and useful for both new contributors and experienced developers.
The output ranges from single-file READMEs to multi-document developer guides, always matched to the project's complexity and the user's needs.
Core Capabilities
- Generate comprehensive README.md files with badges, installation, usage, and API reference
- Create API reference documentation from source code analysis
- Produce architecture and design documentation with diagrams
- Write developer onboarding and contribution guides
- Generate changelogs from commit history or release notes
- Create inline code documentation following language-specific conventions
- Support JSDoc, docstrings, GoDoc, Javadoc, and Rustdoc formats
- Adapt documentation style to the project's language and ecosystem
When to Use This Skill
Always load this skill when:
- User asks to "document", "create docs", or "write documentation" for any code
- User requests a README, API reference, or developer guide
- User shares a codebase or repository and wants documentation generated
- User asks to improve or update existing documentation
- User needs architecture documentation, including diagrams
- User requests a changelog or migration guide
Documentation Workflow
Phase 1: Codebase Analysis
Before writing any documentation, thoroughly understand the codebase.
Step 1.1: Project Discovery
Identify the project fundamentals:
| Field | How to Determine | |
|---|---|---|
| Language(s) | Check file extensions, package.json, pyproject.toml, go.mod, Cargo.toml, etc. | |
| Framework | Look at dependencies for known frameworks (React, Django, Express, Spring, etc.) | |
| Build System | Check for Makefile, CMakeLists.txt, webpack.config.js, build.gradle, etc. | |
| Package Manager | npm/yarn/pnpm, pip/uv/poetry, cargo, go modules, etc. | |
| Project Structure | Map out the directory tree to understand the architecture | |
| Entry Points | Find main files, CLI entry points, exported modules | |
| Existing Docs | Check for existing README, docs/, wiki, or inline documentation |
Step 1.2: Code Structure Analysis
Use sandbox tools to explore the codebase:
Step 1.3: Identify Documentation Scope
Based on analysis, determine what documentation to produce:
| Project Size | Recommended Documentation | |
|---|---|---|
| Single file / script | Inline comments + usage header | |
| Small library | README with API reference | |
| Medium project | README + API docs + examples | |
| Large project | README + Architecture + API + Contributing + Changelog |
Phase 2: Documentation Generation
Step 2.1: README Generation
Every project needs a README. Follow this structure:
Step 2.2: API Reference Generation
For each public API surface, document:
Function / Method Documentation:
Class Documentation:
Step 2.3: Architecture Documentation
For medium-to-large projects, include architecture documentation:
Step 2.4: Inline Code Documentation
Generate language-appropriate inline documentation:
Python (Docstrings — Google style):
TypeScript (JSDoc / TSDoc):
Go (GoDoc):
Phase 3: Quality Assurance
Step 3.1: Documentation Completeness Check
Verify the documentation covers:
- [ ] What it is — Clear project description that a newcomer can understand
- [ ] Why it exists — Problem it solves and value proposition
- [ ] How to install — Copy-paste-ready installation commands
- [ ] How to use — At least one minimal working example
- [ ] API surface — All public functions, classes, and types documented
- [ ] Configuration — All environment variables, config files, and options
- [ ] Error handling — Common errors and how to resolve them
- [ ] Contributing — How to set up dev environment and submit changes
Step 3.2: Quality Standards
| Standard | Check | |
|---|---|---|
| Accuracy | Every code example must actually work with the described API | |
| Completeness | No public API surface left undocumented | |
| Consistency | Same formatting and structure throughout | |
| Freshness | Documentation matches the current code, not an older version | |
| Accessibility | No jargon without explanation, acronyms defined on first use | |
| Examples | Every complex concept has at least one practical example |
Step 3.3: Cross-reference Validation
Ensure:
- All mentioned file paths exist in the project
- All referenced functions and classes exist in the code
- All code examples use the correct function signatures
- Version numbers match the project's actual version
- All links (internal and external) are valid
Documentation Style Guide
Writing Principles
- Lead with the "why" — Before explaining how something works, explain why it exists
- Progressive disclosure — Start simple, add complexity gradually
- Show, don't tell — Prefer code examples over lengthy explanations
- Active voice — "The function returns X" not "X is returned by the function"
- Present tense — "The server starts on port 8080" not "The server will start on port 8080"
- Second person — "You can configure..." not "Users can configure..."
Formatting Rules
- Use ATX-style headers (
#,##,###) - Use fenced code blocks with language specification (
`python,`bash) - Use tables for structured information (parameters, options, configuration)
- Use admonitions for important notes, warnings, and tips
- Keep line length readable (wrap prose at ~80-100 characters in source)
- Use
code formattingfor function names, file paths, variable names, and CLI commands
Language-Specific Conventions
This is the start of the file. Read the full SKILL.md on GitHub.
Security
- Security scanPassed, 90 of 100Pattern checks on the skill's files.
- Model reviewPassed
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingskills/code-documentation/upstream/SKILL.md
Popularity
- Repository stars
- 101
- 7-day trend score
- 0
Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/iyuanm/weft_agent/upstream)