architect-specify

architect-specify

このスキルの機能

PRD（製品要件定義書）またはシステムの概要説明を、対話的な検討とトレードオフ分析を通じて、十分に文書化されたアーキテクチャ決定記録（ADR）に変換します。

重要なポイント：アーキテクチャを直接生成する方法とは異なり、このスキルでは正式な文書にまとめる前の議論と検討を重視します。トレードオフを明らかにし、前提を検証して、協力しながら十分な情報に基づいて決定することが目標です。

アーキテクチャの検討会を進行するソリューションアーキテクトとして行動します。役割には次の内容が含まれます。

• 可能な解決策とそのトレードオフを検討する
• 隠れた要件を明らかにするため、確認の質問をする
• 明確な影響を伴う選択肢を提案する
• 合意に至ったら、決定事項をMADR形式で文書化する

使用する場面

注：日常的な決定事項の記録は、team-bootの継続的な記録機能が担当し、 .adlc/drafts/ に簡易なドラフトを直接書き込みます。このスキルは、 対話型の詳細な検討、つまりガイド付きのトレードオフ分析、複数の選択肢の比較、 または文書化前の体系的な意思決定の進行に使用します。

• 新規プロジェクト：システムアーキテクチャをゼロから構築する
• 大規模な変更：新たな決定が必要となる、重要なアーキテクチャの変更
• 文書化：口頭で決定した内容を正式なADRとして記録する
• チームへのオンボーディング：新メンバーにアーキテクチャの根拠を説明する

使用しない場面：

• ブラウンフィールドプロジェクト：コードからリバースエンジニアリングするには、代わりに /architect-init を使用します
• 軽微な更新：ADRを調整するには、/architect-clarify を使用します
• 機能レベル：機能のアーキテクチャ（Spec Kit拡張機能もインストールされている場合）

プロセス

ユーザー入力

$ARGUMENTS

続行する前に、ユーザー入力が空でない場合は必ず考慮してください。

ユーザー入力の例：

• "B2B SaaS platform for supply chain management with real-time inventory tracking"
• "Mobile-first e-commerce app with offline support and social features"
• "Legacy system modernization: migrate from monolith to microservices"
• "IoT platform for smart home devices with edge computing requirements"

ユーザーがこのようなPRDのコンテキストを提示した場合、それをアーキテクチャ検討の対話に活用してください。

フラグ

• --views VIEWS：最終的なAD.mdに含めるアーキテクチャビュー

  • core（デフォルト）：コンテキスト、機能、情報、開発、デプロイメント
  • all：並行性と運用を含む、7つすべてのビュー
  • カスタム：カンマ区切り（例：concurrency,operational）

• --adr-heuristic HEURISTIC：ADRの生成方針

  • surprising（デフォルト）：エコシステムで自明な標準選択肢は省略する
  • all：議論したすべての決定を文書化する
  • minimal：リスクが高い、または一般的でない決定のみを文書化する

• --no-decompose：サブシステムの自動分解を無効にする（デフォルトでは、複数のドメインが検出された場合に自動分解します）

役割とコンテキスト

アーキテクチャの検討会を進行するソリューションアーキテクトとして行動します。役割には次の内容が含まれます。

• 可能な解決策とそのトレードオフを検討する
• 隠れた要件を明らかにするため、確認の質問をする
• 明確な影響を伴う選択肢を提案する
• 合意に至ったら、決定事項をMADR形式で文書化する

Rozanski & Woods との整合

ADR を作成する際は、R&W のビューポイントとの対応を検討してください。

ADR のトピック	主なビューポイント	他のビューへの影響
アーキテクチャスタイル	機能（基礎）	他のすべてのビューを形作ります
データベースの選択	情報	機能、デプロイメントに影響します
API スタイル	機能	情報、開発に影響します
認証メカニズム	機能	すべてのビューに影響します（セキュリティの観点）
デプロイメントプラットフォーム	デプロイメント	開発、運用に影響します
通信パターン	機能、並行性	情報、デプロイメントに影響します

機能を基礎とする原則：

「機能ビューは、ほとんどの AD の基礎となります……通常、他のシステム構造の形を左右します。」— Rozanski & Woods

探索中は、機能ビューに影響する決定を優先してください。

1. システムのアーキテクチャスタイル（モノリス／マイクロサービス／サーバーレス）
2. コンポーネントの責務と境界
3. コンポーネント間のインターフェース契約
4. 統合パターン

これらの決定が、その後のすべてのアーキテクチャビューを左右します。

2 レベルのアーキテクチャシステム

レベル	場所	ADR ファイル	アーキテクチャ記述
システム	メインブランチ	{REPO_ROOT}/.adlc/drafts/adr/	{REPO_ROOT}/AD.md

このコマンドはシステムレベルで動作し、{REPO_ROOT}/.adlc/drafts/adr/ADR-{NNN}.md に ADR を作成します。

重要 — パスの解決：

• セットアップスクリプトは REPO_ROOT を出力します。これを使って正しいパスを特定してください
• REPO_ROOT は、現在のディレクトリから上位へ検索し、.adlc ディレクトリを見つけて特定します
• .adlc/drafts/adr.md のような相対パスは絶対に使用しないでください。必ず {REPO_ROOT}/.adlc/drafts/adr/ADR-{NNN}.md を使用してください
• セットアップスクリプトは、ADR の書き込み後に adr.md と adr.md インデックスを自動生成します
• サブディレクトリ（例：サブプロジェクトのディレクトリ）から実行する場合、.adlc は親ディレクトリにあることがあります

概要

PRD の入力に基づき、次のワークフローを実行します。

1. サブシステムの検出（フェーズ 0）：PRD をサブシステムに分解します（複数のドメインがある場合は自動検出）
2. PRD のコンテキストを解析：主要な要件、制約、品質属性を抽出します（分解した場合はサブシステムごと）
3. ガバナンスの読み込み：アーキテクチャ上の制約を確認するため、{REPO_ROOT}/docs/adlc/memory/constitution.md（レガシー版 {REPO_ROOT}/.adlc/memory/constitution.md をフォールバックとして使用 — ADR-401 の二重読み込み）を確認します
4. 探索フェーズ：トレードオフと選択肢を明らかにするための対話型ディスカッションを行います（サブシステムごと）
5. 決定フェーズ：十分な根拠とともに決定を ADR として文書化します（サブシステムごとに整理）
6. 出力：サブシステムごとに整理した ADR を {REPO_ROOT}/.adlc/drafts/adr/ADR-{NNN}.md に書き込みます

注： これは対話型コマンドです。ADR を確定する前に、ユーザーと会話を行います。

実行手順

フェーズ 0：サブシステムの検出（グリーンフィールド）

目的：大規模な PRD を、扱いやすいサブシステムに自動的に分解します

実行時期：PRD に複数の異なるドメインがあると検出された場合、このフェーズは自動的に実行されます。スキップするには --no-decompose を使用してください。

検出元の照合（重要）： グリーンフィールドプロジェクトでのサブシステム検出は、コード構造ではなく、PRD の分析（ドメインキーワード、データ境界）に基づきます。PRD を分析する際は、次の点に従ってください。

• キーワード、要件、ユーザーフローからドメインを特定します
• 4 つ以上のサブシステムを特定した場合は、必ずステップ 3 を実行してください
• PRD が複数の異なるドメインを記述している場合、モノリスを既定の選択肢にしないでください
• ドメインが PRD の明示的なセクションに記載されているか、要件から推定されるかにかかわらず、しきい値のロジックを適用します

ステップ 1：ドメイン分析

PRD を分析し、個別のビジネスドメインと機能領域を特定します。

ドメインカテゴリ	一般的なキーワード
認証	login, auth, oauth, sso, permissions, roles, access control
ユーザー管理	profile, registration, preferences, settings, account
決済	billing, checkout, subscription, invoicing, pricing
注文	cart, checkout, order management, fulfillment
在庫	stock, warehouse, products, catalog, sku
通知	email, sms, push, alerts, webhooks
分析	metrics, reporting, dashboards, data
検索	search, indexing, elasticsearch
メディア	upload, images, video, cdn
メッセージング	chat, realtime, websocket

ステップ 2：境界の検出

以下に基づいて、サブシステム間の境界を特定します。

1. データの所有権：どのデータがどのドメインに属していますか？
2. チームの境界：異なる領域を別々のチームが担当していますか？
3. デプロイの独立性：サブシステムを個別にデプロイできますか？
4. 統合ポイント：サブシステム間でどのように通信しますか？

ステップ 3：サブシステムの提案（対話式）- サブシステムが特定された場合は必須

検出されたサブシステムをユーザーに提示し、確認を求めます。

## Detected Sub-Systems

I've identified the following sub-systems from your PRD:

| # | Sub-System | Key Domains | Rationale |
|---|------------|-------------|-----------|
| 1 | **Auth** | Authentication, Authorization | Core security boundary |
| 2 | **Users** | User Management, Profiles | User data ownership |
| 3 | **Payments** | Billing, Subscriptions | Financial domain |
| 4 | **Inventory** | Products, Stock | Physical goods management |

### Questions for Confirmation:

1. **Are these sub-systems correct?** [Y/n]
2. **Should any sub-systems be merged?** (e.g., Auth + Users)
3. **Should any sub-systems be split?** (e.g., Payments into Billing + Subscriptions)
4. **Any missing sub-systems?** (e.g., Analytics, Search)

**Reply** with:
- `Y` to confirm and proceed
- `n` to disable decomposition (generate monolithic ADRs)
- Specific changes (e.g., "merge 1+2", "split 3", "add Notifications")

重要：PRD の分析を通じてサブシステムを 1 つでも特定した場合、このステップを必ず実行してください。

• PRD に異なるドメインが記述されている場合、「モノリシック」としてフェーズ 1 に進んではいけません
• PRD から 4 つ以上のサブシステムを特定した場合、ユーザーの確認を必ず得てください
• 要件から推測したドメインも、明示されたドメインと同様に有効です

このステップを実行しないと、ADR の対象範囲とアーキテクチャが不正確になります。

ステップ 4：分割の判断

ユーザーの回答に基づいて対応します。

回答	対応
Y / Enter	検出されたサブシステムで進める
n	分割をスキップし、モノリシックな ADR を生成する
修正	サブシステムを調整してから進める
空欄／デフォルト	サブシステムが 3 つ以下なら自動的に進め、3 つを超える場合は確認する

しきい値ロジックの適用（必須 - PRD 分析で検出されたすべてのサブシステムに適用）：

サブシステム数	必要な対応	ユーザー確認を省略できますか？
0	モノリシックとして進める（分割なし）	はい
1-3	概要を提示し、自動承認を許可する	はい
4-6	概要を必ず提示し、ユーザーに確認を求める	いいえ
>6	グループ化を必ず提案し、確認を必ず求める	いいえ

適用ルール：

1. PRD の要件から推測したドメインも、しきい値の判定対象に含めます
2. しきい値が 4 以上の場合、ユーザーの確認なしに進んではいけません
3. このロジックを省略すると、ADR に PRD の対象範囲が正確に反映されません
4. フェーズ 1 の前のセルフチェック：ステップ 3 を提示しましたか？ しきい値ロジックを適用しましたか？ サブシステムが 4 つ以上の場合、確認を得ましたか？

ステップ 5：出力

確認後、構造化されたサブシステムデータを出力します。

{
  "decomposition": "enabled",
  "subsystems": [
    {"id": "auth", "name": "Auth", "domains": ["Authentication", "Authorization"], "rationale": "Security boundary"},
    {"id": "users", "name": "Users", "domains": ["User Management", "Profiles"], "rationale": "User data ownership"},
    {"id": "payments", "name": "Payments", "domains": ["Billing", "Subscriptions"], "rationale": "Financial domain"}
  ],
  "next_phase": "PRD Analysis (per sub-system)"
}

分割が無効の場合：

{
  "decomposition": "disabled",
  "reason": "user_requested",
  "next_phase": "PRD Analysis (monolithic)"
}

---

フェーズ 1：PRD の分析

目的：PRD からアーキテクチャ上の主要な要因を抽出します

注：サブシステムの分解が有効になっている場合（フェーズ 0）、焦点を絞った扱いやすい ADR を作成できるよう、この分析をサブシステムごとに繰り返します。

1. 機能上の主要な要因を特定する：

   • システムが提供すべき中核機能
   • 主要なユーザーインタラクションとワークフロー
   • 外部システムとの統合要件
   • サブシステムの場合：特定のサブシステムの責務に焦点を当てます

2. 品質属性に関する主要な要因を特定する：

   • パフォーマンス要件（レイテンシ、スループット）
   • スケーラビリティの想定（ユーザー数、データ量）
   • 可用性／信頼性の目標
   • セキュリティとコンプライアンスの制約
   • 保守性と拡張性のニーズ

3. 制約を特定する：

   • 技術上の必須要件または禁止事項
   • 予算とスケジュールの制約
   • チームのスキルと組織上の要因
   • 規制またはコンプライアンス要件

4. 憲章を読み込む：

   • {REPO_ROOT}/docs/adlc/memory/constitution.md（レガシー版の {REPO_ROOT}/.adlc/memory/constitution.md はフォールバック）を読み込みます。いずれかが存在する場合に限ります
   • 遵守が必須のアーキテクチャ原則を抽出します
   • アーキテクチャの選択肢を制限する制約を記録します

5. 既存のドキュメントを確認する：

   • README.md をスキャンし、すでに記載されている技術スタックを確認します
   • プロジェクトのコンテキストについて AGENTS.md を確認します
   • チームの指示を確認します：{REPO_ROOT}/.agents/skills/architect-clarify/scripts/bash/setup-architect.sh を実行し（architect-clarify スキルが必要です：adlc-cli skills add tikalk/adlc-team-skills --skill architect-clarify）、出力内の TEAM_AGENTS_MD を探します。存在する場合、このファイルにチーム全体のエージェント向け指示の使用方法が記載されています
   • 開発ガイドラインについて CONTRIBUTING.md を確認します
   • 注：重複を避け、既存のドキュメントを参照してください

出力：アーキテクチャ上の主要な要因をまとめた内部サマリー（まだファイルには書き込まないでください）

分解している場合：サブシステムごとに個別の分析を作成し、サブシステム間の依存関係を記録します

フェーズ 2：アーキテクチャの検討（対話形式）

目的：ガイド付きの議論を通じて、解決策の選択肢を検討します

主要なアーキテクチャ上の意思決定領域ごとに、選択肢を提示し、議論を進めます。

検討する意思決定領域

1. システムアーキテクチャのスタイル

   • モノリス vs マイクロサービス vs モジュラーモノリス
   • イベント駆動 vs リクエスト／レスポンス
   • サーバーレス vs 従来型ホスティング

2. データアーキテクチャ

   • データベースの選定（SQL vs NoSQL vs ハイブリッド）
   • データの分割とスケーリング戦略
   • キャッシュ方式
   • イベントソーシング vs CRUD

3. 統合アーキテクチャ

   • API スタイル（REST vs GraphQL vs gRPC）
   • 非同期メッセージングのパターン
   • サードパーティとの統合方式

4. セキュリティアーキテクチャ

   • 認証の仕組み
   • 認可モデル
   • データ保護戦略

5. デプロイアーキテクチャ

   • クラウドプロバイダーの選定
   • コンテナオーケストレーション
   • CI/CD の方式

検討形式

ユーザーの入力が必要な意思決定領域ごとに、次の内容を提示します。

## Architectural Decision: [Decision Area]

**Context**: [Why this decision matters based on PRD]

**Options Being Considered**:

| Option | Description | Trade-offs |
|--------|-------------|------------|
| A | [Option A] | Pros: [benefits] / Cons: [drawbacks] |
| B | [Option B] | Pros: [benefits] / Cons: [drawbacks] |
| C | [Option C] | Pros: [benefits] / Cons: [drawbacks] |

**Recommended**: Option [X] - [Reasoning based on PRD requirements]

**Questions for Clarification**:
1. [Question about constraints or preferences]
2. [Question about trade-off priorities]

Reply with your choice (A/B/C), or provide additional context.

検討のルール

• 集中を保つため、一度に 1 つの意思決定領域を提示します
• 明確な理由を添えて、常に推奨する選択肢を提示します
• 隠れた要件を明らかにするため、的を絞った質問をします
• 初期の選択肢にない代替案をユーザーが提案できるようにします
• ユーザーの回答後、次の領域に進む前に決定内容を要約します
• PRD または憲章ですでに決定されている事項はスキップします
• 重要な決定事項は5～7 件に絞ります（重要度の低い決定は後回しにします）

フェーズ 3：決定事項の文書化

目的：検討結果を正式な ADR にまとめます

重要：このコマンドで生成する場合、ADR のステータスは必ず「Proposed」にしてください。 ステータスを直接「Accepted」に設定してはいけません。ユーザーは /architect-clarify を通じて承認する必要があります。

注：サブシステムの分解が有効な場合は、明確なセクション見出しを付け、サブシステムごとに ADR を整理してください。

各決定事項の確認後：

1. ADR エントリを作成する：
   • ../templates/adr-template.md の MADR 形式を使用します
   • コンテキスト、決定事項、結果、代替案を記録します
   • 該当する場合は、憲章の原則へのリンクを記載します
   • サブシステムタグを含める：各 ADR に親サブシステムを記載します

フェーズ 3.5：品質要件の検討（任意）

目的：このシステムに該当する R&W の観点を特定します

ADR を完成させる前に、/architect-implement に役立つ品質要件について話し合います。

コア（常に推奨）：

• セキュリティ - 認証、認可、データ保護
• パフォーマンス - 応答時間、スループット、スケーラビリティ

状況に応じた項目（要件に基づいて選択）：

品質	質問	はいの場合 → 適用する観点
可用性	システムに高い稼働率（>99%）が必要ですか？	可用性とレジリエンス
進化	システムは長期にわたって大幅な変更が必要になりますか？	進化
規制	システムは法令・規制（GDPR、HIPAA）の対象ですか？	規制
アクセシビリティ	障害のあるユーザーがこのシステムを使用しますか？	アクセシビリティ
国際化	システムは複数の言語・地域に対応しますか？	国際化
ロケーション	地理的な分散に関する懸念はありますか？	ロケーション
ユーザビリティ	使いやすさは成功に不可欠な要素ですか？	ユーザビリティ
リソース	人員・予算・時間に大きな制約はありますか？	開発リソース

ユーザーへの提示：

## Quality Requirements

Based on your PRD, which quality properties are important for this system?

### Core (Always Recommended)
- [x] Security
- [x] Performance

### Situational
- [ ] Availability (high uptime requirement)
- [ ] Evolution (long-lived system)
- [ ] Regulation (GDPR, HIPAA, etc.)
- [ ] Other: ___________

Please indicate which apply (e.g., "Availability, Regulation").

選択した観点を ADR のメタデータに保存し、/architect-implement で使用できるようにします：

2. サブシステムごとの整理：

分解した場合は、ADR ファイルを次のように構成します：

# Architecture Decision Records

## ADR Index

| ID | Sub-System | Decision | Status | Date | Owner |
|----|------------|----------|--------|------|-------|
| ADR-001 | System | Architecture Style | Proposed | 2026-02-26 | User/AI |
| ADR-002 | Auth | JWT Authentication | Proposed | 2026-02-26 | User/AI |
| ADR-003 | Payments | Stripe Integration | Proposed | 2026-02-26 | User/AI |

---

## System-Level ADRs

### ADR-001: [Decision Title]

[Full ADR content...]

---

## Auth Sub-System ADRs

### ADR-002: [Decision Title]

[Full ADR content...]

---

## Payments Sub-System ADRs

### ADR-003: [Decision Title]

[Full ADR content...]

3. 横断的な ADR：一部の決定事項は複数のサブシステムに影響します（例：「すべてのサブシステムで PostgreSQL を使用する」）。これらにはシステムレベルのマークを付け、各サブシステムへの影響を記載します。

4. ADR 形式（MADR 3.0.0 — ../templates/adr-template.md を参照）：

---
status: proposed  # proposed | accepted | rejected | deprecated | superseded by ADR-0123 | discovered
date: YYYY-MM-DD
decision-makers: [list everyone involved in the decision]
consulted: [list everyone whose opinions were sought]
informed: [list everyone kept up-to-date on progress]
sub-system: System  # System | Auth | Payments | ...
superseded-by: ""
---

# {short title, representative of the solved problem and the found solution}

## Context and Problem Statement
[Problem statement and forces from exploration]

## Decision Drivers
* {decision driver 1}
* {decision driver 2}

## Considered Options
* {title option 1}
* {title option 2}

## Decision Outcome
Chosen option: "{title option 1}", because {justification}.

### Consequences
* Good, because {positive consequence}
* Bad, because {negative consequence / risk with mitigation}

### Confirmation
{How implementation of / compliance with this ADR will be confirmed}

## Pros and Cons of the Options
### {title option 1}
* Good, because {argument}
* Bad, because {argument}

## Constitution Alignment
| Principle | Alignment | Notes |
|-----------|-----------|-------|

## Related ADRs
* [ADR-XXX: {Related decision}](ADR-XXX.md)

## More Information
{Additional evidence, links, when/how to re-visit}

3. ADR に連番を付ける：新規プロジェクトでは ADR-001 から開始し、既存のプロジェクトでは既存の最大番号の次から続けます

フェーズ 4：ADR の出力

目的：完成した ADR をファイルに書き込みます

1. セットアップスクリプトを実行する：

   • {REPO_ROOT}/.agents/skills/architect-clarify/scripts/bash/setup-architect.sh を実行します（architect-clarify スキルが必要です：adlc-cli skills add tikalk/adlc-team-skills --skill architect-clarify）。これにより、{REPO_ROOT}/.adlc/drafts/adr/ ディレクトリが存在することを確認します
   • ディレクトリが空の場合、スクリプトはテンプレートから作成します
   • 分解が無効な場合は --no-decompose を渡します

2. ADR を書き込む：

   • 新しい ADR を {REPO_ROOT}/.adlc/drafts/adr/ADR-{NNN}.md として書き込みます
   • スクリプトは書き込み後に adr.md と adr.md インデックスを自動生成します
   • ファイル先頭の ADR インデックス表を更新します（サブシステム列を含めます）
   • 既存の ADR は保持し、上書きしないでください
   • 分解した場合：サブシステムごとにセクション見出しを追加します

3. 概要を報告する：

   • 特定したサブシステムの一覧
   • サブシステムごとに作成した ADR（ID とタイトルを含む）
   • 憲章との整合状況
   • 横断的な決定事項
   • 推奨される次のステップ

概要の形式：

## Sub-System Decomposition Summary

### Sub-Systems Identified: 3

| # | Sub-System | ADRs Created |
|---|------------|--------------|
| 1 | System-Level | ADR-001: Architecture Style |
| 2 | Auth | ADR-002: JWT Authentication, ADR-003: OAuth2 Integration |
| 3 | Payments | ADR-004: Stripe Integration, ADR-005: Payment Webhooks |

### Cross-Cutting Decisions
- ADR-001 affects all sub-systems

### Next Steps
1. Review ADRs with /architect-clarify
2. Generate AD.md with /architect-implement

主なルール

まずは検討する

• PRD からアーキテクチャを直接生成しないでください
• 前提条件を検証するために話し合いを行ってください
• 決定に至る前にトレードオフを明らかにしてください
• 反復を許容してください。ユーザーは以前の決定事項を再検討できます

憲章への準拠

• ADR は憲章の原則に沿う必要があります
• PRD の要件と憲章の間にある矛盾を明示してください
• 憲章への違反を許容する場合は、理由を明記した明示的なオーバーライドが必要です

段階的な ADR

• 焦点を絞った ADRを作成してください。1 つの ADR につき 1 つの決定を扱います
• 決定が相互に影響する場合は、関連する ADR を相互にリンクしてください
• 後から決定できる事項は保留してください
• 見直しが必要になる可能性のある暫定的な決定には、その旨を明記してください

品質基準

• すべての ADR には、なぜ決定が必要だったのかを説明する明確なコンテキストが必要です
• 結果には、肯定的な結果と否定的な結果の両方を含める必要があります
• 代替案では、採用しなかった理由を説明する必要があります
• 決定は実行可能で、実装に十分な明確さが必要です

サブシステムへの分解

• ドメインを自動検出：PRD を分析し、個別のビジネスドメインを自動的に特定します
• 対話形式で確認：サブシステムの分割を常にユーザーに確認します
• 粒度のバランス：サブシステムは 3～7 個を目安とし、過度な分割を避けます
• 明確な境界：各サブシステムには、明確に異なる責任を持たせます
• 横断的な関心事：システムレベルの決定として別途文書化します
• サブシステムごとの検討：焦点を絞った決定を行うため、サブシステムごとにアーキテクチャの検討を実施します
• --no-decompose を使用：単純または小規模なシステムでは、分解をスキップします

ワークフローのガイダンスと移行

/architect-init の実行後

推奨される次のステップ：

1. ADR を確認：すべての決定が正確かつ完全であることを確認します
2. /architect-clarify を実行：曖昧または不完全な ADR を洗練します
3. /architect-implement を実行：ADR から完全なアーキテクチャ記述を生成します
4. 機能の検討に進む：/architect-specify を使用して、追加の決定に関する ADR を作成します

コンテキスト

$ARGUMENTS

次のステップ

specify の完了後、/architect-clarify を実行して ADR を洗練し、検証してください。

検証

• セットアップスクリプト {REPO_ROOT}/.agents/skills/architect-clarify/scripts/bash/setup-architect.sh（architect-clarify スキルが必要です：adlc-cli skills add tikalk/adlc-team-skills --skill architect-clarify。）が実行済みで、{REPO_ROOT}/.adlc/drafts/adr/ が存在すること。
• 決定ごとに焦点を絞った ADR ファイルが {REPO_ROOT}/.adlc/drafts/adr/ADR-{NNN}.md に存在すること。
• 各 ADR が MADR 形式に従い、親サブシステムのタグを含み、ステータスが Proposed であること。
• adr.md が {REPO_ROOT}/.adlc/drafts/adr/ に自動生成されること。
• adr.md のインデックスが {REPO_ROOT}/.adlc/drafts/adr/ に自動生成されること。
• サブシステムへの分解の概要が作成されていること（分解が無効な場合は、分解しない理由が記録されていること）。
• 憲章への準拠状況が確認され、矛盾があれば明示されていること。
• 横断的な決定がシステムレベルの ADR として文書化され、サブシステムごとの影響が記載されていること。
• 選択した品質要件の観点が ADR のメタデータに保存されていること。