ドキュメント生成

$ARGUMENTS

ドキュメントを生成または更新します。

使い方

/docs [type] [target]

このコマンドで実行される内容

1. コード構造を分析します
2. ドキュメント情報を抽出します
3. ドキュメントファイルを生成します
4. 既存のドキュメントを更新します

ドキュメントの種類

種類	説明
readme	README を生成/更新
api	API ドキュメント
architecture-note	アーキテクチャノート
changelog	チェンジログを生成
comments	コードコメントを追加
kb	ナレッジベース記事（KB構造を強制）

KB ドキュメント規則（必須）

kb/ ディレクトリ内のドキュメントを作成または更新する場合は、documentation-standards ナレッジスキル（自動読み込み）に従ってください。主な規則：

• 7つの必須フロントマター項目: title、category、service、tags、created、last_updated、description
• 6つの有効なカテゴリ: reference、howto、procedures、troubleshooting、best-practices、planning
• カテゴリはディレクトリと一致すること（例：category: howto → kb/howto/）
• 英語のみ。例外はありません。
• validate.sh は有効なフロントマターのないドキュメントを拒否します。

完全な仕様：app/skills/documentation-standards/SKILL.md を参照してください。

テンプレート

README 生成

# [プロジェクト名]

[自動生成された説明]

## インストール
[パッケージマネージャーから検出]

## 使い方
[コード/例から抽出]

## API
[コードから抽出]

## ライセンス
[検出]

アーキテクチャノートテンプレート

# Architecture Note: [タイトル]

## Status
Proposed

## Context
[問題は何ですか?]

## Decision
[何が決定されましたか?]

## Consequences
[結果は何ですか?]

## Date
[本日の日付]

出力形式

## ドキュメント報告書

### 生成済み
- [ファイル 1]
- [ファイル 2]

### 更新済み
- [ファイル 3]: [変更内容]

### スキップ
- [ファイル 4]: [理由]

### 次のステップ
- [ ] 生成されたドキュメントをレビューする
- [ ] 不足している詳細情報を追加する
- [ ] 変更をコミットする

一般的な言い訳と反論

言い訳	なぜそれが間違っているのか
「コードは自己説明的である」	コードは「どのように」を示すが、「なぜ」は示さない — 決定、制約、コンテキストは文章で説明が必要
「どうせ誰も読まない」	人は悪いドキュメントは読まない — 良いドキュメントは最初に参照されるもの
「安定してから文書化しよう」	不安定なコードこそドキュメントが必要 — 意図を文書化することで他人が貢献できる
「コメントはすぐに古くなる」	それはドキュメントをスキップする理由ではなく、メンテナンスする理由
「テストがドキュメント」	テストは動作を検証するが、アーキテクチャ、トレードオフ、セットアップの説明にはならない

設定

ドキュメント設定は以下の場所にあります：

• .claude/settings.json
• プロジェクトのドキュメント設定

コミット前のレビュー

生成されたドキュメントはレビューが必要です。 AI がコンテキストを見落とすか、仮定をしてしまう可能性があります。

ドキュメントインベントリ

バンドルされたスクリプトを実行して、ドキュメント対応範囲を監査し、ギャップを見つけます：

python3 ${CLAUDE_SKILL_DIR}/scripts/doc-inventory.py .

並列ドキュメント化（大規模コードベース）

インベントリスクリプトが doc_coverage_percent < 50 を報告し、プロジェクトに複数のモジュールがある場合は、エージェントチームを使用して並列ドキュメント化を実行します：

ドキュメント化のためのエージェントチームを作成：
- チームメイト 1（documenter）: 「[module-1] ディレクトリをドキュメント化してください。すべての公開関数のドキュメント文字列を生成してください。」Sonnet を使用。
- チームメイト 2（documenter）: 「[module-2] ディレクトリをドキュメント化してください。すべての公開関数のドキュメント文字列を生成してください。」Sonnet を使用。
- チームメイト 3（documenter）: 「README セクションを生成してください：インストール、使い方、API リファレンス。」Opus を使用。
チームメイトは重複してはいけません — 各自が割り当てられたスコープを担当します。

関連スキル

• アーキテクチャ決定をドキュメント化しますか? → 最初に多角的な分析のために /council を使用
• コードベースを探索する必要がありますか? → ドキュメント化する前に構造を理解するために /explore を使用
• PRD を書いていますか? → 構造化された製品要件のために /write-a-prd を使用
• 既存のドキュメントを監査していますか? → カバレッジギャップについては /analyze を使用