アーキテクチャルディシジョンレコード(ADR)の作成

構造化フォーマットを使用して、${input:DecisionTitle} のための ADR ドキュメントを作成します。このフォーマットは AI による消費と人間による可読性に最適化されています。

入力

• Context: ${input:Context}
• Decision: ${input:Decision}
• Alternatives: ${input:Alternatives}
• Stakeholders: ${input:Stakeholders}

入力検証

必要な入力のいずれかが提供されていない、または会話履歴から判断できない場合は、ADR の生成を進める前に、ユーザーに不足している情報の提供を依頼してください。

要件

• 正確で曖昧さのない言語を使用する
• 前付情報を含む標準化された ADR フォーマットに従う
• 正と負の両方の結果を含める
• 却下の根拠を含めて代替案を文書化する
• 機械パースおよび人間参照向けの構造化
• 複数項目セクションでは、コード化された箇条書き (3～4 文字のコード + 3 桁の数字) を使用する

ADR は /docs/adr/ ディレクトリに保存される必要があります。命名規則は adr-NNNN-[title-slug].md です。NNNN は次の通し番号 4 桁です (例: adr-0001-database-selection.md)。

必須ドキュメント構造

ドキュメントファイルは以下のテンプレートに従い、すべてのセクションが適切に入力されていることを確認してください。markdown の前付情報は次の例に従って正しく構造化される必要があります:

---
title: "ADR-NNNN: [Decision Title]"
status: "Proposed"
date: "YYYY-MM-DD"
authors: "[Stakeholder Names/Roles]"
tags: ["architecture", "decision"]
supersedes: ""
superseded_by: ""
---

# ADR-NNNN: [Decision Title]

## Status

**Proposed** | Accepted | Rejected | Superseded | Deprecated

## Context

[この決定に必要な問題陳述、技術的制約、ビジネス要件、および環境要因。]

## Decision

[明確な選択根拠を伴う選択されたソリューション。]

## Consequences

### Positive

- **POS-001**: [有益な結果と利点]
- **POS-002**: [パフォーマンス、保守性、スケーラビリティの改善]
- **POS-003**: [アーキテクチャ原則との整合性]

### Negative

- **NEG-001**: [トレードオフ、制限事項、欠点]
- **NEG-002**: [導入される技術的負債または複雑性]
- **NEG-003**: [リスクおよび将来の課題]

## Alternatives Considered

### [Alternative 1 Name]

- **ALT-001**: **Description**: [簡潔な技術説明]
- **ALT-002**: **Rejection Reason**: [このオプションが選択されなかった理由]

### [Alternative 2 Name]

- **ALT-003**: **Description**: [簡潔な技術説明]
- **ALT-004**: **Rejection Reason**: [このオプションが選択されなかった理由]

## Implementation Notes

- **IMP-001**: [主要な実装上の考慮事項]
- **IMP-002**: [該当する場合のマイグレーションまたはロールアウト戦略]
- **IMP-003**: [モニタリングと成功基準]

## References

- **REF-001**: [関連する ADR]
- **REF-002**: [外部ドキュメント]
- **REF-003**: [参照された標準またはフレームワーク]