菜单
Capture architectural decisions made during Claude Code sessions as structured ADRs. Auto-detects decision moments, records context, alternatives considered, and rationale. Maintains an ADR log so future developers understand why the codebase is shaped the way it is.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
キャプチャ、診断、抑制されたリカバリ、内省レポートを用いた、AI エージェント障害向けの体系的なセルフデバッグワークフローです。
リポジトリ認識の並列レビューパスを使用してスキル、コマンド、ルール、フック、その他を DAILY と LIBRARY のバケットに分類することで、特定のリポジトリ向けにエビデンスに基づく ECC インストールプランを構築します。フルバンドルをロードするのではなく、プロジェクトが実際に必要とするものに ECC をトリミングすべき場合に使用します。
対象リポジトリの既存の統合パターンに正確に合わせて新しい API コネクタやプロバイダを構築します。第二のアーキテクチャを発明することなく、もう一つの統合を追加する場合に使用します。
Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
ECC 向けのエビデンスファーストな自動化インベントリと重複監査のワークフローです。何かを修正する前に、どのジョブ、フック、コネクタ、MCP サーバー、またはラッパーがライブ、壊れている、冗長、または欠落しているかをユーザーが知りたい場合に使用します。
CodeTour の `.tour` ファイルを作成します。実際のファイルと行のアンカーを持つペルソナ対象のステップバイステップウォークスルーです。オンボーディングツアー、アーキテクチャウォークスルー、PR ツアー、RCA ツアー、および構造化された「これがどのように動作するか説明して」というリクエストに使用します。
| name | architecture-decision-records |
| description | Capture architectural decisions made during Claude Code sessions as structured ADRs. Auto-detects decision moments, records context, alternatives considered, and rationale. Maintains an ADR log so future developers understand why the codebase is shaped the way it is. |
| origin | ECC |
コーディングセッション中に行われたアーキテクチャ上の決定を記録します。決定が Slack スレッド、PR コメント、誰かの記憶の中だけに存在するのではなく、このスキルはコードと共存する構造化された ADR ドキュメントを生成します。
Michael Nygard が提唱した軽量 ADR フォーマットを、AI 支援開発向けに適応して使用します:
# ADR-NNNN: [Decision Title]
**Date**: YYYY-MM-DD
**Status**: proposed | accepted | deprecated | superseded by ADR-NNNN
**Deciders**: [who was involved]
## Context
この決定や変更を動機付けている問題は何か？
[状況、制約、作用している力を説明する2-5文]
## Decision
提案している、または実行している変更は何か？
[決定を明確に述べる1-3文]
## Alternatives Considered
### Alternative 1: [Name]
- **Pros**: [利点]
- **Cons**: [欠点]
- **Why not**: [却下された具体的な理由]
### Alternative 2: [Name]
- **Pros**: [利点]
- **Cons**: [欠点]
- **Why not**: [却下された具体的な理由]
## Consequences
この変更により、何がやりやすくなり、何がやりにくくなるか？
### Positive
- [メリット 1]
- [メリット 2]
### Negative
- [トレードオフ 1]
- [トレードオフ 2]
### Risks
- [リスクと軽減策]
決定の瞬間が検出された場合:
docs/adr/ が存在しない場合、ディレクトリの作成、インデックステーブルヘッダーをシードした README.md（以下の ADR Index Format を参照）、手動使用のための空の template.md の作成についてユーザーに確認を求めます。明示的な同意なしにファイルを作成しないでください。docs/adr/ の既存 ADR をスキャンしてインクリメントdocs/adr/NNNN-decision-title.md に書き込みます。ユーザーが却下した場合、ファイルを書き込まずにドラフトを破棄します。docs/adr/README.md に追記ユーザーが「なぜ X を選んだのか？」と質問した場合:
docs/adr/ が存在するか確認 — 存在しない場合は以下のように応答: 「このプロジェクトに ADR は見つかりませんでした。アーキテクチャ上の決定の記録を始めますか？」docs/adr/README.md のインデックスから関連するエントリをスキャンdocs/
└── adr/
├── README.md ← すべての ADR のインデックス
├── 0001-use-nextjs.md
├── 0002-postgres-over-mongo.md
├── 0003-rest-over-graphql.md
└── template.md ← 手動使用のための空テンプレート
# Architecture Decision Records
| ADR | Title | Status | Date |
|-----|-------|--------|------|
| [0001](0001-use-nextjs.md) | Use Next.js as frontend framework | accepted | 2026-01-15 |
| [0002](0002-postgres-over-mongo.md) | PostgreSQL over MongoDB for primary datastore | accepted | 2026-01-20 |
| [0003](0003-rest-over-graphql.md) | REST API over GraphQL | accepted | 2026-02-01 |
会話中にアーキテクチャ上の決定を示す以下のパターンに注目してください:
明示的なシグナル
暗黙的なシグナル（ADR の記録を提案 — ユーザーの確認なしに自動作成しない）
proposed → accepted → [deprecated | superseded by ADR-NNNN]
| カテゴリ | 例 |
|---|---|
| 技術選択 | フレームワーク、言語、データベース、クラウドプロバイダー |
| アーキテクチャパターン | モノリス vs マイクロサービス、イベントドリブン、CQRS |
| API 設計 | REST vs GraphQL、バージョニング戦略、認証メカニズム |
| データモデリング | スキーマ設計、正規化の決定、キャッシュ戦略 |
| インフラストラクチャ | デプロイモデル、CI/CD パイプライン、モニタリングスタック |
| セキュリティ | 認証戦略、暗号化アプローチ、シークレット管理 |
| テスト | テストフレームワーク、カバレッジ目標、E2E vs インテグレーションのバランス |
| プロセス | ブランチ戦略、レビュープロセス、リリースケイデンス |