agentsclimarketplace

Documentation

Skill dewitt4/claude-code-template/.claude/skills/documentation

Use this template to launch a Claude Code development workflow with project plan, skills, plug-ins, and MCP servers

Install
npx -y skills add dewitt4/claude-code-template --skill documentation

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

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 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

Create and maintain technical documentation including README files, API docs, inline comments, architecture diagrams, and user guides

SKILL.md

5.2 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it

Documentation Skill

When creating or updating documentation, follow these comprehensive guidelines:

Documentation Types

1. README Files

Essential for every project and major module:

Structure

# Project Name
Brief description (1-2 sentences)

## Features
- Key feature 1
- Key feature 2

## Installation
Step-by-step setup instructions

## Usage
Basic examples and common use cases

## Configuration
Environment variables, config files

## API Reference (if applicable)
Link to detailed API docs

## Contributing
How to contribute to the project

## License
License information

2. Code Comments

When to Comment

  • Complex Logic: Algorithms, business rules, non-obvious decisions
  • Why, Not What: Explain reasons, not obvious actions
  • Public APIs: Document parameters, return values, exceptions
  • TODOs: Track future work with context
  • Warnings: Note gotchas, limitations, performance considerations

Comment Style

// Good: Explains why
// Using binary search here because the array is always sorted
// and can contain millions of items (requirements doc §3.2)

// Bad: States the obvious
// Loop through the array

3. API Documentation

For each endpoint/function:

  • Purpose: What it does
  • Parameters: Name, type, required/optional, description, constraints
  • Return Value: Type, structure, possible values
  • Errors: What can go wrong, error codes
  • Examples: Real-world usage examples
  • Authentication: Required permissions/tokens
  • Rate Limits: If applicable

Example Format (REST API)

### GET /api/users/:id

Retrieve a user by ID.

**Parameters:**
- `id` (string, required): User UUID

**Response:** 200 OK
```json
{
  "id": "abc123",
  "name": "John Doe",
  "email": "[email protected]"
}

Errors:

  • 404: User not found
  • 401: Unauthorized

Example:

curl -H "Authorization: Bearer token" https://api.example.com/api/users/abc123

### 4. Architecture Documentation

#### Key Elements
- **System Overview**: High-level architecture diagram
- **Components**: Major system components and responsibilities
- **Data Flow**: How data moves through the system
- **Dependencies**: External services, databases, libraries
- **Deployment**: How the system is deployed
- **Security**: Authentication, authorization, data protection
- **Scalability**: How the system scales

#### Document Patterns
- Architecture patterns used (MVC, microservices, etc.)
- Design patterns and where they're applied
- Important architectural decisions and rationale

### 5. User Guides

For end-users:
- **Getting Started**: Quick start guide
- **Tutorials**: Step-by-step walkthroughs
- **How-To Guides**: Task-oriented instructions
- **Troubleshooting**: Common issues and solutions
- **FAQ**: Frequently asked questions
- **Glossary**: Term definitions

## Documentation Best Practices

### Writing Style
- **Clear**: Use simple language, short sentences
- **Concise**: Remove unnecessary words
- **Active Voice**: "The function returns" not "is returned by"
- **Present Tense**: "Creates a user" not "will create"
- **Consistent**: Use same terms throughout
- **Accessible**: Avoid jargon, or explain it

### Structure
- **Progressive Disclosure**: Start simple, add detail
- **Logical Flow**: Organize information intuitively
- **Scannable**: Use headings, lists, code blocks
- **Search-Friendly**: Use clear, descriptive headings

### Maintenance
- **Keep Updated**: Update docs with code changes
- **Version Control**: Track docs with code
- **Review**: Include docs in code reviews
- **Test**: Verify examples and instructions work

### Visual Aids
- **Diagrams**: Architecture, flow charts, sequence diagrams
- **Screenshots**: UI documentation
- **Code Examples**: Realistic, working examples
- **Tables**: Comparisons, parameter lists

## Tools and Formats

### Documentation Tools
- **Markdown**: README, general docs (.md)
- **JSDoc/JavaDoc**: Inline code documentation
- **Swagger/OpenAPI**: API specifications
- **Mermaid**: Diagrams in markdown
- **Docusaurus/GitBook**: Documentation sites

### Diagram Tools
- **Mermaid**: Text-based diagrams in markdown
- **PlantUML**: UML diagrams from text
- **Draw.io**: Visual diagramming

## Documentation Checklist

When creating documentation:

- [ ] Purpose is clear
- [ ] Audience is appropriate
- [ ] Examples are included
- [ ] Prerequisites are listed
- [ ] Steps are numbered and clear
- [ ] Common issues are addressed
- [ ] Links are working
- [ ] Code examples are tested
- [ ] Spelling and grammar checked
- [ ] Diagrams are clear and labeled
- [ ] Contact info or support channel included

## Output Format

When generating documentation:

1. **Determine the type**: What kind of documentation is needed?
2. **Understand the audience**: Developers, end-users, admins?
3. **Structure appropriately**: Use the right format for the content
4. **Include examples**: Real, working examples
5. **Add visuals**: Diagrams or code snippets where helpful
6. **Review for clarity**: Is this understandable to the target audience?

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.