ドキュメント作成スキル

When to Use

以下の状況で自動発動：

•「ドキュメント」「記録」「説明を書いて」等のキーワード
•意思決定の背景説明が必要な時
•新機能完成後の記録

When NOT to Use

•コード内のコメント追加（CLAUDE.md: コメント最小限）
•一時的なメモ
•自明な内容の記録

ドキュメント種類の判断

code

何を記録したいか？
├─ 機能の仕組み → 技術ドキュメント
├─ なぜこの方法を選んだか → ADR
└─ APIの使い方 → APIドキュメント

テンプレート

1. 技術ドキュメント

出力先: docs/features/ または docs/architecture/

markdown

# [機能名]

## 概要

[1-2文で機能の概要]

## アーキテクチャ

[図やフローの説明]

## 主要コンポーネント

| コンポーネント | 責務 | ファイル  |
| -------------- | ---- | --------- |
| ...            | ...  | `src/...` |

## 使い方

[コード例]

## 注意点

- ...

2. ADR（Architecture Decision Record）

出力先: docs/decisions/ ファイル名: YYYYMMDD-[タイトル].md

markdown

# [タイトル]

## ステータス

採用 / 提案中 / 廃止

## コンテキスト

[この決定が必要になった背景]

## 検討した選択肢

| 選択肢 | メリット | デメリット |
| ------ | -------- | ---------- |
| A      | ...      | ...        |
| B      | ...      | ...        |

## 決定

[採用した選択肢とその理由]

## 結果

[この決定による影響]

3. APIドキュメント

出力先: docs/api/

markdown

# [Router名] API

## `[router].[procedure]`

**種類**: Query / Mutation
**認証**: 必要 / 不要

**入力**:

```typescript
{
  id: string;
}
```

出力:

typescript

{ data: { ... } }

使用例:

typescript

const { data } = api.[router].[procedure].useQuery({ id });

code


## 既存ドキュメント構造

docs/ ├── architecture/ # システム全体 ├── features/ # 機能ごと ├── api/ # APIドキュメント ├── decisions/ # ADR ├── development/ # 開発ガイド（CLAUDE.md等） ├── design-system/ # Storybookに移行済み └── releases/ # リリースチェックリスト

code


**参考**: 既存ドキュメントのフォーマットに合わせること

## Dayopt固有ルール

1. **日本語で記述**（グローバル展開時は英語も検討）
2. **`docs/`ディレクトリに配置**
3. **過度に詳細にしない**（メンテナンスコストを考慮）
4. **コードが自明なら書かない**（型定義で十分な場合も多い）