Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
pixel-process-ug avatar

Tech Docs Generator

  • 70 installs
  • 1 repo stars
  • Updated March 16, 2026
  • pixel-process-ug/superkit-agents

Helps with ai & agent building tasks.

About

tech-docs-generator is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted development.

  • tech-docs-generator
  • AI & Agent Building
  • AI-coding skill

Tech Docs Generator by the numbers

  • 70 all-time installs (skills.sh)
  • +4 installs in the week ending Aug 4, 2026 (Skillselion tracking)
  • Ranked #5,726 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
  • Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/pixel-process-ug/superkit-agents --skill tech-docs-generator

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs70
repo stars1
Last updatedMarch 16, 2026
Repositorypixel-process-ug/superkit-agents

What it does

Helps with ai & agent building tasks.

Files

SKILL.mdMarkdownGitHub ↗

Technical Documentation Generator

Overview

Generate comprehensive technical documentation by analyzing the actual codebase. Produces API references, architecture overviews, getting started guides, and component documentation with real examples extracted from project code, not invented ones.

Announce at start: "I'm using the tech-docs-generator skill to create documentation."

Phase 1: Codebase Analysis

Scan the codebase to identify what needs documenting. Deploy parallel subagents via the Agent tool (up to 500, with subagent_type="Explore") to analyze:

Analysis TargetWhat to Capture
Exported functions/classesPublic API surface, signatures, return types
API routes/endpointsREST, GraphQL, tRPC definitions with methods
ConfigurationEnv vars, config files, feature flags
Database schemasModels, migrations, relationships
Component hierarchyUI components and their props/interfaces
Type definitionsInterfaces, types, Zod schemas, enums
Entry pointsCLI commands, main files, server bootstrap
DependenciesExternal packages and their roles

STOP after analysis — present a summary of what was found and ask which documentation types are needed.

Phase 2: Documentation Type Selection

TypeWhen to UseOutput PathTypical Size
API ReferenceDocumenting endpoints or public functionsdocs/api-reference.md200-1000 lines
Architecture OverviewExplaining system design and data flowdocs/architecture.md100-300 lines
Getting StartedOnboarding new developersdocs/getting-started.md50-150 lines
Component DocsDocumenting UI componentsdocs/components/[name].md50-200 lines
Contributing GuideExplaining how to contributedocs/contributing.md50-100 lines
Configuration GuideDocumenting config optionsdocs/configuration.md50-200 lines
Migration GuideDocumenting version upgradesdocs/migration/v[X]-to-v[Y].md50-150 lines

Ask the user which type(s) they need if not specified. If multiple types are requested, dispatch parallel subagents via the Agent tool — one per doc type.

Phase 3: Generate Documentation

Dispatch doc-generator agent with:

  • File analysis results from Phase 1
  • Documentation type selected in Phase 2
  • Existing documentation (to update, not replace)
  • Project context from memory files

STOP after generation — present each section for review before saving.

Documentation Format Standards

API Reference format:

## `functionName(param1, param2)`

Description of what this function does.

**Parameters:**
| Name | Type | Required | Description |
|------|------|----------|-------------|
| param1 | `string` | Yes | What it does |
| param2 | `Options` | No | Configuration options |

**Returns:** `Promise<Result>`

**Example:**

const result = await functionName('value', { option: true });


**Throws:** `ValidationError` if param1 is empty

Architecture Overview format:

## System Architecture

### Overview
[High-level description with ASCII diagram]

### Components
| Component | Responsibility | Key Files |
|-----------|---------------|-----------|

### Data Flow
[How data moves through the system — request lifecycle]

### Key Decisions
| Decision | Rationale | Alternatives Considered |
|----------|-----------|------------------------|

Getting Started format:

## Prerequisites
[Required tools, versions, accounts]

## Installation
[Step-by-step with copy-pasteable commands]

## Configuration
[Required env vars and config]

## First Run
[How to start the app and verify it works]

## Next Steps
[Links to deeper documentation]

Phase 4: Review and Save

Present documentation section by section:

1. Ask after each section: "Does this accurately describe the code?" 2. Cross-reference with actual code to verify accuracy 3. Include real examples from the codebase — never invented ones 4. After approval, save to docs/ directory 5. Commit with message: docs(<scope>): add/update <doc-type>

Accuracy Verification Checklist

CheckHow to Verify
Function signatures match codeRead the source file
Examples actually workTrace the code path
Config options are currentCheck actual config files
Dependencies listed are installedCheck package.json / requirements
File paths referenced existGlob for the files

Anti-Patterns / Common Mistakes

MistakeWhy It Is WrongWhat To Do Instead
Inventing code examplesReaders copy-paste and get errorsExtract real examples from the codebase
Documenting internal/private APIsCreates coupling to implementationOnly document public/exported surface
Writing docs that duplicate source codeGoes stale immediatelyReference behavior, not implementation
Giant monolithic doc fileHard to navigate and maintainSplit by concern (API, architecture, config)
Documenting aspirational behaviorMisleads users about current capabilitiesDocument what actually works today
Skipping the analysis phaseMiss important APIs or get signatures wrongAlways analyze code first
Not verifying examples compile/runBroken docs worse than no docsTest every code example

Anti-Rationalization Guards

  • Do NOT generate documentation without first analyzing the actual code
  • Do NOT invent examples — every code snippet must come from or be verified against the codebase
  • Do NOT document private/internal APIs unless explicitly requested
  • Do NOT skip the review phase — present each section for user verification
  • Do NOT duplicate information already covered in other docs — reference instead

Integration Points

SkillRelationship
prd-generationUpstream: PRD defines what needs documenting
self-learningParallel: both analyze codebase; self-learning populates memory files used here
api-designUpstream: API design specs inform API reference docs
spec-writingParallel: specs define behavior; docs explain usage
reverse-engineering-specsUpstream: reverse-engineered specs provide behavioral understanding
code-reviewDownstream: reviewer checks if docs were updated alongside code changes

Verification Gate

Before claiming documentation is complete:

1. VERIFY all public APIs are documented with correct signatures 2. VERIFY code examples actually work (not invented) 3. VERIFY cross-references link to existing content 4. VERIFY documentation matches current code state 5. VERIFY the user has approved each section 6. RUN any documented commands to confirm they work

Concrete Example: API Reference Entry

Given this source code:

export async function createUser(data: CreateUserInput): Promise<User> {
  // validates, hashes password, inserts into DB
}

Generate this documentation:

## `createUser(data)`

Create a new user account with the provided details.

**Parameters:**
| Name | Type | Required | Description |
|------|------|----------|-------------|
| data | `CreateUserInput` | Yes | User registration data |

**`CreateUserInput` shape:**
| Field | Type | Required | Constraints |
|-------|------|----------|-------------|
| email | `string` | Yes | Valid email format |
| password | `string` | Yes | Minimum 8 characters |
| name | `string` | Yes | 1-100 characters |

**Returns:** `Promise<User>` — the created user object (password excluded)

**Throws:**
- `ValidationError` — if input fails validation
- `ConflictError` — if email already exists

Skill Type

Flexible — Adapt documentation depth and format to project needs while preserving the analyze-first principle and accuracy verification.

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.