Docs logo

Docs

Organization
Rune-kit
docs

Auto-generate and maintain project documentation. Creates README, API docs, architecture docs, changelogs, and keeps them in sync with code changes. The "docs are never outdated" skill.

Overview

PublisherRune-kit
Repositoryrune
Skill namedocs
Stars
88
Forks
26
Bundled files
Instructions only
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by Rune-kit on GitHub. Read the source before you install it.

Installation

Install the Docs AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/Rune-kit/rune/tree/master/skills/docs
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/Rune-kit/rune.git /tmp/rune
mkdir -p .claude/skills
cp -r /tmp/rune/skills/docs .claude/skills/docs
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Docs in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Docs on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Docs is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

docs

Purpose

Documentation lifecycle manager. Generates initial project documentation, keeps docs in sync with code changes, produces API references, and auto-generates changelogs. Solves the #1 documentation problem: docs that exist but are outdated.

Triggers

  • Called by scaffold Phase 7 for initial documentation generation
  • Called by cook post-Phase 7 to update docs after feature implementation
  • Called by launch pre-deploy to ensure docs are current
  • /rune docs init — first-time documentation generation
  • /rune docs update — sync docs with recent code changes
  • /rune docs api — generate API documentation
  • /rune docs changelog — auto-generate changelog from git history

Calls (outbound)

  • scout (L2): scan codebase for documentation targets (routes, exports, components, configs)
  • doc-processor (L3): generate PDF/DOCX exports if requested
  • git (L3): read commit history for changelog generation

Called By (inbound)

  • scaffold (L1): Phase 7 — generate initial docs for new project
  • cook (L1): post-implementation — update docs for changed modules
  • launch (L1): pre-deploy — verify docs are current
  • mcp-builder (L2): generate MCP server documentation
  • User: /rune docs direct invocation

Modes

Init Mode — /rune docs init

First-time documentation generation for a project.

Update Mode — /rune docs update

Incremental sync — update only docs affected by recent code changes.

API Mode — /rune docs api

Generate or update API documentation specifically.

Changelog Mode — /rune docs changelog

Auto-generate changelog from git commit history.

Executable Steps

Init Mode

Step 1 — Scan Codebase

Invoke rune:scout to extract:

  • Project name, description, tech stack
  • Directory structure and key files
  • Entry points (main, index, app)
  • Public API surface (exports, routes, components)
  • Configuration files (.env.example, config patterns)
  • Existing docs (if any — merge, don't overwrite)
Step 2 — Generate README.md

Structure:

markdown
# [Project Name]
[One-line description]

## Quick Start
[3-5 commands to get running: install, configure, start]

## Features
[Bullet list extracted from code — routes, components, capabilities]

## Tech Stack
[Detected from package.json, requirements.txt, Cargo.toml, etc.]

## Project Structure
[Key directories with one-line descriptions]

## Configuration
[Environment variables from .env.example with descriptions]

## Development
[Dev server, test, lint, build commands]

## API Reference
[Link to API.md if applicable, or inline summary]

## License
[Detected from LICENSE file or package.json]
Step 3 — Generate ARCHITECTURE.md (if project has 10+ files)

Structure:

markdown
# Architecture

## Overview
[System diagram in text/mermaid — components and data flow]

> The ARCHITECTURE overview may call `rune:diagram` for a designed system figure (type `architecture`) instead of raw Mermaid — `suggested_next: diagram`.

## Key Decisions
[Detected patterns: framework choice, state management, DB, auth approach]

## Module Map
[Each top-level directory: purpose, key files, dependencies]

## Data Flow
[Request lifecycle or data pipeline description]
Step 4 — Generate API.md (if routes/endpoints detected)

Scan route files and extract:

  • HTTP method + path
  • Request parameters (path, query, body)
  • Response shape
  • Authentication requirements
  • Error responses

Format as markdown table or OpenAPI-compatible reference.

Step 5 — Report

Present generated docs to user with summary:

  • Files generated: [list]
  • Coverage: [what's documented vs what exists]
  • Gaps: [code areas without docs — suggest next steps]

Update Mode

Step 1 — Detect Changes

Read git diff since last docs update (tracked via git log on doc files or .rune/docs-sync.json).

Identify:

  • New files/modules → need new doc sections
  • Changed functions/routes → need doc updates
  • Deleted code → need doc removal
  • New configuration → need config doc update
Step 2 — Update Affected Sections

For each changed area:

  1. Read the changed code
  2. Find corresponding doc section
  3. Update doc to match current code
  4. If doc section doesn't exist → create it
  5. If code was deleted → remove or mark as deprecated in docs
Step 3 — Generate Changelog Entry

Delegate to rune:git changelog to produce a changelog entry from commits since last docs update.

Step 4 — Cross-Doc Consistency Pass

Cross-document consistency prevents the second-most-common docs problem: docs that exist but contradict each other.

After updating any doc, verify consistency across all project documentation:

CheckFilesWhat to Compare
Version numbersREADME, CLAUDE.md, package.json, CHANGELOGMust all match current version
Feature listsREADME, landing page, CLAUDE.mdSame features listed (may differ in detail level)
StatsREADME, CLAUDE.md, landing page, dashboardSkill count, test count, signal count must match
CommandsREADME, CLAUDE.md, docs/Same commands with same flags
Tech stackREADME, ARCHITECTURE.md, CLAUDE.mdConsistent framework/library references
Cross-Doc Consistency:
- [x] README.md ↔ CLAUDE.md: versions match, commands match
- [x] README.md ↔ docs/index.html: stats match, features match
- [ ] README.md says "62 skills" but CLAUDE.md says "59" → FIX CLAUDE.md

Fix inconsistencies immediately — don't just report them. Update the stale doc to match the source of truth (usually the code or the most recently updated doc).

Step 5 — Report

Show user: what was updated, what was added, what was flagged for review. Include Cross-Doc Consistency results.

API Mode

Step 1 — Detect API Framework
FrameworkRoute PatternFile Pattern
Expressrouter.get/post/put/deleteroutes/*.ts, *.router.ts
FastAPI@app.get/post/put/deleterouters/*.py, main.py
NestJS@Get/@Post/@Put/@Delete*.controller.ts
Next.js Appexport async function GET/POSTapp/**/route.ts
Next.js Pagesexport default function handlerpages/api/**/*.ts
SvelteKitexport function GET/POSTsrc/routes/**/+server.ts
Honoapp.get/post/put/deletesrc/*.ts
Step 2 — Extract Endpoints

For each detected route:

  • Method (GET, POST, PUT, DELETE, PATCH)
  • Path (with parameters highlighted)
  • Request: params, query, body shape (from Zod schemas, TypeScript types, Pydantic models)
  • Response: shape (from return type or response helper)
  • Auth: required? (detect middleware like authMiddleware, @UseGuards)
  • Description: from JSDoc/docstring if available
Step 3 — Generate API Reference

Format as markdown:

markdown
# API Reference

## Authentication
[Auth mechanism description]

## Endpoints

### `POST /api/auth/login`
**Description**: Authenticate user and return tokens
**Auth**: None
**Request Body**:
| Field | Type | Required | Description |
|-------|------|----------|-------------|
| email | string | yes | User email |
| password | string | yes | User password |

**Response** (200):
```json
{ "token": "string", "refreshToken": "string" }

Errors:

  • 401: Invalid credentials
  • 422: Validation error

#### Step 4 — Output

Save to `docs/API.md` or project-specific location. If OpenAPI requested, generate `openapi.yaml`.

### Changelog Mode

#### Step 1 — Delegate to Git

Invoke `rune:git changelog` to group commits by type and format as Keep a Changelog.

#### Step 2 — Enhance

Add context to raw changelog:
- Link PR numbers to actual descriptions
- Group related changes under feature headers
- Highlight breaking changes prominently

#### Step 3 — Output

Append to or update `CHANGELOG.md`.

## Output Format

### Init Mode Output
Files generated in project root:
- `README.md` — Quick Start, Features, Tech Stack, Structure, Config, Dev Commands
- `ARCHITECTURE.md` — Overview diagram, Key Decisions, Module Map, Data Flow (if 10+ files)
- `docs/API.md` — Endpoint reference with method, path, params, response, auth (if routes detected)

### Update Mode Output
Modified doc sections with change summary:

Docs Update Report:

  • Updated: [list of doc sections modified]
  • Added: [new sections for new code]
  • Flagged: [stale sections referencing deleted code]
  • Changelog: [entry appended to CHANGELOG.md]

### API Mode Output
`docs/API.md` — markdown reference per endpoint:

METHOD /path/:param

Description: [from JSDoc/docstring] Auth: [required/none] Request: [params, query, body table] Response: [shape with status codes] Errors: [error codes and descriptions]


### Changelog Mode Output
`CHANGELOG.md` — Keep a Changelog format grouped by: Added, Fixed, Changed, Removed.

## Constraints

1. MUST generate docs from actual code — never invent features or APIs that don't exist
2. MUST preserve existing docs — update sections, don't overwrite entire files
3. MUST detect doc staleness — flag sections that reference deleted/changed code
4. MUST include Quick Start in every README — users need to get running in < 2 minutes
5. MUST NOT generate docs for code that doesn't exist yet (unless explicitly creating spec docs)
6. API docs MUST match actual route signatures — wrong API docs are worse than no docs

## Returns

| Artifact | Format | Location |
|----------|--------|----------|
| README.md | Markdown | project root |
| ARCHITECTURE.md | Markdown | project root (if 10+ files) |
| API reference | Markdown | `docs/API.md` |
| Changelog entry | Markdown (Keep a Changelog) | `CHANGELOG.md` |
| Docs update report | Markdown | inline (chat output) |

**Scope guardrail:** Documents only what exists in the codebase — never invents features, endpoints, or APIs.

## Sharp Edges

| Failure Mode | Severity | Mitigation |
|---|---|---|
| Inventing API endpoints that don't exist | CRITICAL | Constraint 1: scan actual route files, not guess |
| Overwriting user-written README sections | HIGH | Constraint 2: merge, don't overwrite — detect custom sections |
| Stale docs after code changes | HIGH | Update mode detects diffs and updates affected sections |
| API docs with wrong request/response shapes | HIGH | Extract from Zod/Pydantic/TypeScript types, not from memory |
| Missing Quick Start section | MEDIUM | Constraint 4: every README has Quick Start |
| Changelog with orphan PR links | LOW | Validate PR numbers exist before linking |
| Cross-document inconsistency (README says X, CLAUDE.md says Y) | HIGH | Step 7: Cross-Doc Consistency Pass — verify stats, versions, and feature lists match across all docs |
| Updating one doc but not others (stats drift) | HIGH | After any doc update, sweep all related docs for stale stats — especially README ↔ CLAUDE.md ↔ landing page |

## Done When

### Init Mode
- Codebase scanned with scout
- README.md generated with Quick Start, Features, Tech Stack, Structure
- ARCHITECTURE.md generated (if 10+ files)
- API.md generated (if routes detected)
- Coverage report presented to user

### Update Mode
- Changes since last doc update detected
- Affected doc sections updated
- Changelog entry generated
- Update report presented to user

### API Mode
- API framework detected
- All endpoints extracted with method, path, request, response
- API reference generated in markdown
- Saved to docs/API.md

### Changelog Mode
- Commits grouped by type
- Formatted as Keep a Changelog
- CHANGELOG.md updated

## Cost Profile

~2000-5000 tokens input, ~1000-3000 tokens output. Sonnet — documentation requires understanding code patterns but not deep architectural reasoning.

Frequently asked questions

What does the Docs AI skill do?

Auto-generate and maintain project documentation. Creates README, API docs, architecture docs, changelogs, and keeps them in sync with code changes. The "docs are never outdated" skill.

Why use Docs on TypingMind?

Because you install it once and use it with any model. Docs is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Docs in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/Rune-kit/rune/tree/master/skills/docs. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Docs?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Docs?

As many as you like. As long as a model supports skills, you can use Docs with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Docs AI skill free?

Yes. It is published on GitHub by Rune-kit under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇