Skill

Pass

Audit score 90

documentation-templates

sickn33/antigravity-awesome-skills

Ready-to-use templates for README, API docs, code comments, and AI-friendly documentation.

What is documentation-templates?

Provides structured templates and guidelines for common documentation types including README files, API endpoints, code comments, changelogs, and architecture decisions. Use this when you need consistent, scannable documentation that works well with AI tools and human readers.

README structure with essential sections in priority order
Per-endpoint API documentation template with parameters and responses
JSDoc/TSDoc code comment guidelines with examples
Changelog template following Keep a Changelog format
Architecture Decision Record (ADR) template for design decisions
AI-friendly documentation templates (llms.txt and MCP-ready formats)

How to install documentation-templates

npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill documentation-templates

Claude Code

Cursor

Windsurf

Cline

How to use documentation-templates

1.Choose the documentation type you need (README, API docs, code comments, etc.)
2.Copy the relevant template from the skill
3.Adapt the template structure to your project's specific needs
4.Follow the guidelines for when and what to document
5.Ensure documentation maintains the scannable, example-first format
6.Keep documentation up-to-date alongside code changes

Use cases

Good for

Creating a new project README from scratch with standard sections
Documenting REST API endpoints consistently across a codebase
Establishing code comment standards for a team
Recording architectural decisions and trade-offs
Preparing documentation for AI agent indexing and RAG systems

Who it's for

Backend and full-stack developers
API maintainers and library authors
Technical writers and documentation leads
Open-source project maintainers
Teams adopting AI-assisted development tools

documentation-templates FAQ

Should I use all these templates for every project?

No. Templates are starting points. Use what fits your project's scope. A simple script might only need a README; a complex API needs full API documentation and ADRs.

How detailed should code comments be?

Comment the 'why' and non-obvious behavior, not the 'what'. Avoid commenting every line. Focus on business logic, complex algorithms, and API contracts.

What is AI-friendly documentation?

Documentation structured with clear hierarchy (H1-H3), JSON/YAML examples, Mermaid diagrams, and self-contained sections that AI tools can index and understand via RAG systems.

How often should I update the changelog?

Update it with each release or significant change. Use the 'Unreleased' section for ongoing work, then promote to a version number when releasing.

What is an ADR and when do I need one?

An Architecture Decision Record documents important design decisions, their context, and trade-offs. Use them for decisions that affect multiple teams or have long-term consequences.

Full instructions (SKILL.md)

Source of truth, from sickn33/antigravity-awesome-skills.

name: documentation-templates description: "Documentation templates and structure guidelines. README, API docs, code comments, and AI-friendly documentation." risk: safe source: community date_added: "2026-02-27"

Documentation Templates

Templates and structure guidelines for common documentation types.

1. README Structure

Essential Sections (Priority Order)

Section	Purpose
Title + One-liner	What is this?
Quick Start	Running in <5 min
Features	What can I do?
Configuration	How to customize
API Reference	Link to detailed docs
Contributing	How to help
License	Legal

README Template

# Project Name

Brief one-line description.

## Quick Start

[Minimum steps to run]

## Features

- Feature 1
- Feature 2

## Configuration

| Variable | Description | Default |
|----------|-------------|---------|
| PORT | Server port | 3000 |

## Documentation

- API Reference
- Architecture

## License

MIT

2. API Documentation Structure

Per-Endpoint Template

## GET /users/:id

Get a user by ID.

**Parameters:**
| Name | Type | Required | Description |
|------|------|----------|-------------|
| id | string | Yes | User ID |

**Response:**
- 200: User object
- 404: User not found

**Example:**
[Request and response example]

3. Code Comment Guidelines

JSDoc/TSDoc Template

/**
 * Brief description of what the function does.
 * 
 * @param paramName - Description of parameter
 * @returns Description of return value
 * @throws ErrorType - When this error occurs
 * 
 * @example
 * const result = functionName(input);
 */

When to Comment

✅ Comment	❌ Don't Comment
Why (business logic)	What (obvious)
Complex algorithms	Every line
Non-obvious behavior	Self-explanatory code
API contracts	Implementation details

4. Changelog Template (Keep a Changelog)

# Changelog

## [Unreleased]
### Added
- New feature

## [1.0.0] - 2025-01-01
### Added
- Initial release
### Changed
- Updated dependency
### Fixed
- Bug fix

5. Architecture Decision Record (ADR)

# ADR-001: [Title]

## Status
Accepted / Deprecated / Superseded

## Context
Why are we making this decision?

## Decision
What did we decide?

## Consequences
What are the trade-offs?

6. AI-Friendly Documentation (2025)

llms.txt Template

For AI crawlers and agents:

# Project Name
> One-line objective.

## Core Files
- [src/index.ts]: Main entry
- [src/api/]: API routes
- [docs/]: Documentation

## Key Concepts
- Concept 1: Brief explanation
- Concept 2: Brief explanation

MCP-Ready Documentation

For RAG indexing:

Clear H1-H3 hierarchy
JSON/YAML examples for data structures
Mermaid diagrams for flows
Self-contained sections

7. Structure Principles

Principle	Why
Scannable	Headers, lists, tables
Examples first	Show, don't just tell
Progressive detail	Simple → Complex
Up to date	Outdated = misleading

Remember: Templates are starting points. Adapt to your project's needs.

When to Use

This skill is applicable to execute the workflow or actions described in the overview.

Limitations

Use this skill only when the task clearly matches the scope described above.
Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.