doc-generator

モード：認知／プロンプト駆動 — 単独で実行するユーティリティスクリプトはありません。エージェントのコンテキストを通じて使用してください。

ドキュメント生成スキル - API ドキュメント、開発者ガイド、アーキテクチャドキュメント、ユーザーマニュアルなど、コード、API、仕様から包括的なドキュメントを生成します。 - API ドキュメントの生成 - 開発者ガイドの作成 - アーキテクチャのドキュメント化 - ユーザーマニュアルの作成 - OpenAPI/Swagger 仕様の生成 - 既存ドキュメントの更新

ステップ 1：ドキュメントの種類を特定する

ドキュメントの種類を判断します。

• API ドキュメント：エンドポイントのリファレンス
• 開発者ガイド：セットアップと使用方法
• アーキテクチャドキュメント：システムの概要
• ユーザーマニュアル：機能ガイド

ステップ 2：情報を抽出する

ドキュメントの内容を収集します。

• コードとコメントを読む
• API エンドポイントを分析する
• 例を抽出する
• アーキテクチャを理解する

ステップ 3：ドキュメントを生成する

ドキュメントを作成します。

• ドキュメントのテンプレートに従う
• 例を含める
• トラブルシューティングを追加する
• 明確な構成を作る

ステップ 4：ドキュメントを検証する

品質を検証します。

• 完全性を確認する
• 例が動作することを確認する
• 明確さを確保する
• リンクを検証する </execution_process>

**テクニカルライターエージェントとの連携**： - このスキルを使用してドキュメントを生成します - ドキュメントの品質を確保します - 完全性を検証します

開発者エージェントとの連携：

• API ドキュメントを生成します
• インラインドキュメントを作成します
• コードの変更に合わせてドキュメントを更新します

<best_practices>

1. コードから抽出する：コードを信頼できる唯一の情報源として使用します
2. 例を含める：動作する例を提供します
3. 最新の状態に保つ：ドキュメントをコードと同期させます
4. 明確な構成にする：論理的に整理します
5. ユーザーを重視する：システムではなく、ユーザーに向けて書きます </best_practices>

**API ドキュメント**

# Users API

## Endpoints

### GET /api/users

List all users with pagination.

**Query Parameters:**

- `page` (number): Page number (default: 1)
- `limit` (number): Items per page (default: 10)

**Response:**

```json
{
  "data": [
    {
      "id": "uuid",
      "email": "[email protected]",
      "name": "User Name"
    }
  ],
  "pagination": {
    "page": 1,
    "limit": 10,
    "total": 100
  }
}
```

例：

curl -X GET "http://localhost:3000/api/users?page=1&limit=10"

</formatting_example>

<formatting_example>
**Developer Guide**

```markdown
# Developer Guide

## Getting Started

### Prerequisites
- Node.js 18+
- pnpm 8+

### Installation
```bash
pnpm install

開発

pnpm dev

アーキテクチャ

[アーキテクチャの概要]

開発ワークフロー

[開発プロセス]

</formatting_example>
</examples>

<examples>
<usage_example>
**Example Commands**:

API ドキュメントを生成する

app/api/users の API ドキュメントを生成する

開発者ガイドを生成する

このプロジェクトの開発者ガイドを生成する

アーキテクチャドキュメントを生成する

アーキテクチャドキュメントを生成する

OpenAPI 仕様を生成する

API ルートから OpenAPI 仕様を生成する

</usage_example>
</examples>

## Iron Laws

1. **ALWAYS** extract documentation from code as the source of truth — never write documentation that describes how you wish the code worked rather than how it actually works.
2. **NEVER** publish documentation with non-runnable examples — every code example must be copy-paste ready and verified to work before the documentation is written.
3. **ALWAYS** structure documentation with the progressive disclosure pattern (Setup → Quick Start → Reference → Troubleshooting) — readers need orientation before details.
4. **NEVER** document internal implementation details that consumers don't need to know — documentation of private internals creates false contracts and maintenance burden.
5. **ALWAYS** regenerate documentation when the code it describes changes — stale documentation is worse than no documentation because it actively misleads users.

## Anti-Patterns

| Anti-Pattern | Why It Fails | Correct Approach |
|---|---|---|
| No working code examples | Users can't understand how to use the API without runnable examples | Include minimal copy-paste examples verified to work for every public API |
| Aspirational documentation (describes intended behavior) | Creates false contracts; users file bugs when docs don't match code | Read the actual implementation first; document only observed behavior |
| Documenting private/internal APIs | Creates implicit dependencies; refactoring breaks "documented" behavior | Only document public APIs; mark internal functions with `@internal` if needed |
| Monolithic reference dumps without Quick Start | Users abandon before finding what they need | Always include a Quick Start section with the simplest possible working example |
| Documentation in a separate PR from code change | Docs drift immediately; often abandoned | Require documentation updates in the same PR as API changes |

## Memory Protocol (MANDATORY)

**Before starting:**
Read `.claude/context/memory/learnings.md`

**After completing:**
- New pattern -> `.claude/context/memory/learnings.md`
- Issue found -> `.claude/context/memory/issues.md`
- Decision made -> `.claude/context/memory/decisions.md`

> ASSUME INTERRUPTION: If it's not in memory, it didn't happen.