mcpField
C
create-architectural-decision-record

create-architectural-decision-record

github.com/github開発40.5k10.2k 回インストール1 日前に更新
リポジトリ

create-architectural-decision-record について

決定の背景や関係者の情報を基に、構造化されたアーキテクチャ決定記録(ADR)を作成するコーディングスキルです。標準形式、代替案と影響、連番付きのファイル名を指定します。

主な機能

  1. 01決定に必要な情報の不足を確認
  2. 02標準的な ADR フロントマター
  3. 03代替案とその影響を記録
  4. 04複数項目にコード付き番号を使用
  5. 05連番付きの ADR ファイルを保存

活用シーン

  1. 01アーキテクチャの決定と背景の記録
  2. 02選択肢の比較と却下理由の記載
  3. 03想定される正負の影響の記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/github/awesome-copilot --skill create-architectural-decision-record

インストール後、Claude Code で/create-architectural-decision-recordを入力して読み込まれたか確認します。

詳細

アーキテクチャ決定記録の作成

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

入力

  • コンテキスト: ${input:Context}
  • 決定: ${input:Decision}
  • 代替案: ${input:Alternatives}
  • ステークホルダー: ${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

[Problem statement, technical constraints, business requirements, and environmental factors requiring this decision.]

## Decision

[Chosen solution with clear rationale for selection.]

## Consequences

### Positive

- **POS-001**: [Beneficial outcomes and advantages]
- **POS-002**: [Performance, maintainability, scalability improvements]
- **POS-003**: [Alignment with architectural principles]

### Negative

- **NEG-001**: [Trade-offs, limitations, drawbacks]
- **NEG-002**: [Technical debt or complexity introduced]
- **NEG-003**: [Risks and future challenges]

## Alternatives Considered

### [Alternative 1 Name]

- **ALT-001**: **Description**: [Brief technical description]
- **ALT-002**: **Rejection Reason**: [Why this option was not selected]

### [Alternative 2 Name]

- **ALT-003**: **Description**: [Brief technical description]
- **ALT-004**: **Rejection Reason**: [Why this option was not selected]

## Implementation Notes

- **IMP-001**: [Key implementation considerations]
- **IMP-002**: [Migration or rollout strategy if applicable]
- **IMP-003**: [Monitoring and success criteria]

## References

- **REF-001**: [Related ADRs]
- **REF-002**: [External documentation]
- **REF-003**: [Standards or frameworks referenced]

コメント