decisions

決定事項

概要

このスキルは、重要なプロジェクトの決定事項を時系列で docs/decisions.md に記録します。特にトレードオフを伴う重要なアーキテクチャや設計上の決定を記録し、重要な選択を行った理由を恒久的に残します。

このスキルを使用するタイミング

積極的な提案（慎重に）： 次のような、明らかに重要なアーキテクチャ上の選択があった場合にのみ、決定事項の記録を提案します。

• データベースシステムの選択（例：SQLite と PostgreSQL の比較）
• 主要なフレームワークやライブラリの選定
• 中核となるアーキテクチャパターンの決定（例：モノリスかマイクロサービスか、レンダリング方式）
• プロジェクトの長期的な方向性を左右する基本的な設計上の選択

積極的に提案しないもの：

• 細かな実装の詳細
• 通常のコーディング上の判断
• 小規模なリファクタリングの選択
• 些細な技術上の選択

手動での記録： ユーザーから次のようなフレーズで明示的に依頼された場合、決定事項を記録します。

• 「この決定を記録して」
• 「これを決定ログに記録して」
• 「これを decisions.md に追加して」

決定事項の記録

ステップ 1：決定事項を特定する

会話の文脈から、次の内容を特定します。

• どのような決定がなされたか
• なぜその決定が必要だったか（背景）
• どのような代替案が検討されたか（該当する場合）
• 評価された主なトレードオフ（該当する場合）
• 最終的な選択の根拠

ステップ 2：詳細度を決める

決定の複雑さに応じて詳細度を調整します。

簡潔（単純な決定）：

• タイトルと 1～2 文の要約
• 例：実績のあるライブラリの選択

標準（一般的な決定）：

• 決定の説明
• 簡単な背景（なぜ必要だったか）
• 選択した内容

詳細（複雑な決定）：

• 決定の説明
• 背景と動機
• 検討した代替案
• 評価した主なトレードオフ
• 最終的な選択の根拠

ステップ 3：記録項目を整形する

次の形式を使用します。

## YYYY-MM-DD: [Decision Title]

[Description paragraph(s) adapted to the complexity level]

例（簡潔）：

## 2025-10-23: Use httprouter for HTTP routing

Chose httprouter for its simplicity and performance. It's a well-established library that fits our needs without unnecessary complexity.

例（詳細）：

## 2025-10-23: Choose SQLite for primary database

After evaluating PostgreSQL and SQLite, we chose SQLite for the following reasons:

Context: Need a reliable database for the application that handles moderate traffic (< 1000 concurrent users) and simple relational data.

Alternatives considered:
- PostgreSQL: More features and better for high concurrency, but adds operational complexity
- SQLite: Simpler deployment, embedded database, sufficient performance for our scale

Tradeoffs: SQLite has limitations with high write concurrency and some advanced features, but offers zero-configuration deployment and excellent read performance. Given our expected load and preference for operational simplicity, these tradeoffs favor SQLite.

Decision: Use SQLite with WAL mode enabled for improved concurrency. We can migrate to PostgreSQL later if scaling needs change.

ステップ 4：ファイルに書き込む

1. docs/ ディレクトリが存在するか確認し、必要に応じて作成します
2. docs/decisions.md が存在するか確認します。
   • 存在しない場合は、次のヘッダーを付けて作成します。

     # Project Decisions
     
     This document records significant architectural and design decisions made throughout the project's development.
     
     

   • 存在する場合は、現在の内容を読み込みます
3. 新しい決定事項をファイルの末尾に追加します
4. 適切な間隔を確保します（新しい項目の前に空行を入れます）

ステップ 5：ユーザーに確認する

決定事項を記録した後、記録した内容を簡潔に伝えます。例：

• 「SQLite を使用する決定を docs/decisions.md に記録しました」
• 「ルーティングに関する決定を決定ログに追加しました」

積極的な提案のパターン

会話中に重要なアーキテクチャ上の決定を検出した場合、記録を提案します。

This seems like a significant architectural decision. Would you like me to record it in docs/decisions.md?

記録する前に、ユーザーの確認を待ちます。

重要な注意事項

• 常にファイルの末尾に追加します（古いものから新しいものへ時系列順に記録）
• 新しい項目には今日の日付を使用します（YYYY-MM-DD 形式）
• 既存の項目との書式の一貫性を保ちます
• 同じ決定事項を重複して記録しないでください
• docs/ ディレクトリが存在しない場合は作成します
• 長期的なアーキテクチャへの影響がない些細な決定事項は記録しないでください