architect-implement

Name: architect-implement
Author: tikalk

github.com/tikalk開発143189 回インストール今日更新

architect-implement について

複数エージェントによる DAG ワークフローで、Architecture Decision Records（ADR）から統合 Architecture Description（AD.md）を作成するスキルです。承認済みの決定を基にシステム構成を文書化するチーム向けです。

主な機能

01ADR の分析とサブシステムの特定
02カスタマイズ可能なビュー生成 DAG の計画
03依存関係のコンテキストを使ったビュー生成
04ビュー生成時のパースペクティブ適用
05ビューの統合とサブシステム間の競合解決
06ワークフロー状態と ADR 状態の検証

活用シーン

01ADR 承認後のアーキテクチャ文書作成
02新たな決定後の AD.md 再生成
03デプロイメントビューや運用ビューの作成
04エージェントセッションをまたいだ文書作業の再開

インストール

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

$npx skills add https://github.com/tikalk/adlc-team-skills --skill architect-implement

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

詳細

architect-implement

このスキルでできること

マルチエージェント DAG オーケストレーションのアプローチを使用して、Architecture Decision Records（ADR）から完全なアーキテクチャ記述（AD.md）を生成します。

Plan Agent：ADR を分析し、サブシステムを検出し、カスタマイズされた DAG を生成して、ユーザーの承認を得ます。
Execute Agent：DAG に従ってサブシステムごとにアーキテクチャビューを生成し、依存関係のコンテキストを引き継ぎます。
Summarize Agent：すべてのビューを集約し、サブシステム間の競合を解決して、統一された AD.md を生成します。

重要なポイント：ADR には決定がなされた理由が記録されます。アーキテクチャ記述には、その決定の結果としてシステムがどのようなものになったかが記述されます。

使用するタイミング

/architect-specify または /architect-clarify の後：議論して承認された ADR から AD を生成します。
/architect-init の後：既存システムのアーキテクチャを文書化します。
ADR の更新時：新しい決定の後に AD.md を再生成します。
ドキュメント作成スプリント：包括的なアーキテクチャドキュメントを作成します。

使用しないタイミング

ADR がない場合：まず /architect-specify または /architect-init を使用します。
機能レベルの場合：機能の AD は、このスキルではなく機能の計画フェーズで生成されます。
軽微な更新の場合：小さな変更には直接編集を使用します。

プロセス

ユーザー入力

$ARGUMENTS

入力が空でない場合は、先に進む前にユーザー入力を必ず考慮してください。

ユーザー入力の例：

"デプロイメントと運用のビューに重点を置いてください。インフラストラクチャのドキュメントが必要です"
"セキュリティの観点を重視して、すべてのビューを生成してください"
"最近の決定による新しい ADR を使って、既存の AD.md を更新してください"
空の入力：すべての ADR から完全なアーキテクチャ記述を生成します

フラグ

--views VIEWS：生成するアーキテクチャビュー
- core（デフォルト）：コンテキスト、機能、情報、開発、デプロイメント（コアビュー 5 つ）
- all：並行性ビューと運用ビューを含む 7 つのビューすべて
- カスタム：カンマ区切り（例：concurrency,operational）。コアビューは常に含まれます
--sequential（デフォルト）：品質を最大限に高めるため、ビューを順次実行します
- 推奨：機能ビューの後にチェックポイントを設けられます
--parallel：依存関係のチェーンが許す場合、並列実行を許可します
- 警告：ビュー間の一貫性が低下する可能性があります。時間が限られている場合にのみ使用してください
--no-checkpoint：機能ビューのチェックポイントをスキップします（非推奨）
- 警告：機能ビューは他のすべてのビューを形作る「礎」です
--force：ワークフローの状態検証を回避します（緊急時のみ使用）
- 警告：リスクを理解している場合にのみ使用してください
- clarify Phase 5.5 の完了チェックをスキップします
- 実行前の ADR ステータス検証をスキップします
- 不完全または一貫性のないアーキテクチャになる可能性があります

重要：--views が core（デフォルト）の場合、並行性ビュー（3.4）と運用ビュー（3.7）は完全にスキップしてください。--views all または --views concurrency,operational で明示的に指定された場合にのみ生成してください。

Rozanski & Woods の方法論との整合性

このコマンドは、Nick Rozanski と Eoin Woods による Software Systems Architecture（第 2 版）のビューポイントとパースペクティブのフレームワークを実装しています。

基本原則

機能ビューは礎です

「機能ビューは、ほとんどの AD の礎です……通常は、情報構造、並行性構造、デプロイメント構造など、他のシステム構造の形を決定します。」 — Rozanski & Woods
ビューは相互に関連しており、独立していません

「あるビューで下された決定は、他のビューに大きな影響を与えることがあります。こうした影響を理解させることは、アーキテクトの仕事の大部分を占めます。」
パースペクティブはビューに適用されます

「パースペクティブを単独で扱うことはありません。各ビューと組み合わせて使用し、アーキテクチャの品質を分析し、検証します。」
速度より品質を重視します アーキテクチャ上の誤りは、修正に多大なコストがかかります。品質を確保するため、チェックポイントを設けた順次実行をデフォルトとしています。

視点の依存関係グラフ

                    ┌──────────┐
                    │ Context  │  (System boundaries)
                    └────┬─────┘
                         │
                         ▼
                 ┌───────────────┐
                 │  FUNCTIONAL   │  ★ CORNERSTONE ★
                 │  (Drives all  │  USER CHECKPOINT
                 │   other views)│  REQUIRED HERE
                 └───────┬───────┘
                         │
         ┌───────────────┼───────────────┐
         │               │               │
         ▼               ▼               ▼
   ┌───────────┐   ┌───────────┐   ┌───────────┐
   │Information│   │Concurrency│   │Development│
   │           │   │(optional) │   │           │
   └─────┬─────┘   └─────┬─────┘   └─────┬─────┘
         │               │               │
         └───────────────┼───────────────┘
                         │
                         ▼
                  ┌────────────┐
                  │ Deployment │
                  └──────┬─────┘
                         │
                         ▼
                  ┌────────────┐
                  │ Operational│  (optional)
                  └────────────┘

動的な視点とパースペクティブの選択

視点とパースペクティブは、システムの特性に基づいて動的に選択されます。

カテゴリ	常に含まれる項目	自動検出（任意）
視点	コンテキスト、機能	情報、並行性、開発、デプロイ、運用
パースペクティブ	セキュリティ、パフォーマンス	アクセシビリティ、可用性、進化、国際化、場所、規制、ユーザビリティ、開発リソース

参考: https://www.viewpoints-and-perspectives.info/

目標

アーキテクチャ意思決定記録（ADR）を、マルチエージェント DAG オーケストレーションのアプローチを用いて、包括的なアーキテクチャ記述（AD.md）に変換します。

計画エージェント：ADR を分析し、サブシステムを検出して、カスタマイズされた DAG を生成し、ユーザーの承認を得ます
実行エージェント：DAG に従い、依存関係のコンテキストを踏まえて、サブシステムごとのビューを生成します
要約エージェント：すべてのビューを集約し、競合を解決して、統一された AD.md を生成します

役割とコンテキスト

あなたは、複数フェーズにわたるドキュメント生成ワークフローを管理するアーキテクチャオーケストレーターとして動作します。役割は次のとおりです。

サブシステム分析に基づいて生成 DAG を計画する
適切な依存関係の順序でビュー生成を実行する
ビューを統一されたアーキテクチャ記述に要約する
AI エージェントのセッションをまたいで再開できるよう、状態を永続化する

アーキテクチャドキュメントの階層

ドキュメント	目的	場所
`{REPO_ROOT}/.adlc/drafts/adr/`	根拠を含むアーキテクチャ上の意思決定（個別ファイル形式）	入力
`{REPO_ROOT}/.adlc/architect/state.json`	DAG の実行状態	状態
`{REPO_ROOT}/docs/adlc/architect/views/{subsystem}/{view}.md`	ビューごとの出力	参照
`{REPO_ROOT}/docs/adlc/architect/AD.md`	完全なアーキテクチャ記述	出力
`{REPO_ROOT}/docs/adlc/memory/constitution.md`（旧 `.adlc/memory/constitution.md` をフォールバックとして使用）	ガバナンス原則	制約

重要 — パスの解決：

セットアップスクリプトは REPO_ROOT を出力します。これを使用して正しいパスを特定してください
REPO_ROOT は、現在のディレクトリから上位へ検索し、.adlc ディレクトリを見つけて特定します
.adlc/drafts/adr.md のような相対パスは絶対に使用しないでください。常に {REPO_ROOT}/.adlc/drafts/adr/ADR-{NNN}.md を使用してください
セットアップスクリプトは adr/ ディレクトリから個別の ADR ファイルを読み取ります
サブプロジェクトのディレクトリなどのサブディレクトリから実行する場合、.adlc が親ディレクトリにあることがあります

ビューテンプレート

スキルの templates/ ディレクトリにあります。

テンプレート	目的
`templates/views/context.md`	コンテキストビューのテンプレート
`templates/views/functional.md`	機能ビューのテンプレート
`templates/views/information.md`	情報ビューのテンプレート
`templates/views/concurrency.md`	並行性ビューのテンプレート（任意）
`templates/views/development.md`	開発ビューのテンプレート
`templates/views/deployment.md`	デプロイビューのテンプレート
`templates/views/operational.md`	運用ビューのテンプレート（任意）

パースペクティブテンプレート（全 10 種）
`templates/perspectives/security.md`
`templates/perspectives/performance.md`
`templates/perspectives/accessibility.md`
`templates/perspectives/availability.md`
`templates/perspectives/evolution.md`
`templates/perspectives/internationalization.md`
`templates/perspectives/location.md`
`templates/perspectives/regulation.md`
`templates/perspectives/usability.md`
`templates/perspectives/development-resource.md`

3 フェーズの DAG ワークフロー

┌─────────────────────────────────────────────────────────────────────────────┐
│                          PHASE 1: PLAN                                      │
│  ┌─────────────┐    ┌─────────────────┐    ┌─────────────────────────────┐ │
│  │ Load ADRs   │───▶│ Detect Sub-     │───▶│ Generate DAG per Sub-system │ │
│  │             │    │ systems         │    │ (apply customization rules) │ │
│  └─────────────┘    └─────────────────┘    └──────────────┬──────────────┘ │
│                                                           │                 │
│                                            ┌──────────────▼──────────────┐ │
│                                            │ Present Plan for Approval   │ │
│                                            │ (user confirms or modifies) │ │
│                                            └──────────────┬──────────────┘ │
│                                                           │                 │
│                                            ┌──────────────▼──────────────┐ │
│                                            │ Write state.json            │ │
│                                            └─────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                          PHASE 2: EXECUTE                                   │
│  ┌─────────────────────────────────────────────────────────────────────┐   │
│  │  For each sub-system, execute DAG in topological order:             │   │
│  │                                                                      │   │
│  │  ┌─────────┐    ┌────────────┐    ┌─────────────┐    ┌───────────┐ │   │
│  │  │ Context │───▶│ Functional │───▶│ Information │───▶│Development│ │   │
│  │  └─────────┘    └────────────┘    └─────────────┘    └───────────┘ │   │
│  │                        │                                    │       │   │
│  │                        ▼                                    ▼       │   │
│  │               ┌─────────────┐                      ┌────────────┐  │   │
│  │               │ Concurrency │                      │ Deployment │  │   │
│  │               │ (optional)  │                      └────────────┘  │   │
│  │               └─────────────┘                             │        │   │
│  │                                                           ▼        │   │
│  │                                                   ┌─────────────┐  │   │
│  │                                                   │ Operational │  │   │
│  │                                                   │ (optional)  │  │   │
│  │                                                   └─────────────┘  │   │
│  └─────────────────────────────────────────────────────────────────────┘   │
│                                                                             │
│  Each view: Read dependencies → Generate content (with perspectives inline)
│             → Update state.json with progress                               │
└─────────────────────────────────────────────────────────────────────────────┘
                                      │
                                      ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                          PHASE 3: SUMMARIZE                                 │
│  ┌──────────────────┐    ┌─────────────────────┐    ┌──────────────────┐   │
│  │ Read all view    │───▶│ Detect cross-       │───▶│ Resolve conflicts│   │
│  │ files            │    │ subsystem conflicts │    │ using ADRs       │   │
│  └──────────────────┘    └─────────────────────┘    └────────┬─────────┘   │
│                                                               │             │
│  ┌──────────────────┐                       ┌──────────────▼───────────┐ │
│  │ Move Accepted    │◀─────────────────────────│ Aggregate into            │ │
│  │ ADRs to memory   │                         │ unified AD.md (views include│ │
│  └──────────────────┘                         │ perspective sections)     │ │
│                                             └───────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘

注：パースペクティブ（セキュリティ、パフォーマンスなど）は、フェーズ 3 の独立したステップではなく、フェーズ 2 のビュー生成中に適用されるようになりました。これは、R&W の原則「アーキテクチャの品質を分析・検証するために、各ビューで使用する」に沿ったものです。

事前検証（必須 - 厳格に適用）

重大：これらの検証は厳格に適用されます。チェックに失敗すると、実行は停止します。 --force フラグは、リスクを十分に理解したうえで、緊急時にのみ使用してください。

フェーズ 1 を開始する前に、前提条件を必ず検証してください。

ワークフロー状態のチェック（`--force` を除く）

state.json で clarify の完了を確認する：

{REPO_ROOT}/.adlc/architect/state.json を読み込む
workflow.clarify_completed フィールドを確認する

値が false またはフィールドが存在しない場合：

❌ WORKFLOW VALIDATION FAILED

The implement command requires ADRs to be approved via /architect-clarify first.

Current workflow state: clarify_completed = false

Required: Run /architect-clarify and complete Phase 5.5 (ADR Approval)

Options:
1. Run /architect-clarify to approve ADRs
2. Use --force to bypass (NOT RECOMMENDED - may cause inconsistent architecture)

⚠️  Using --force skips important validation steps and may result in:
   - Processing unapproved ADRs
   - Missing critical architectural decisions
   - Incomplete architecture documentation

実行を停止する（--force フラグが指定されている場合を除く）

ADR ステータスのチェック

ADR の存在を確認する：{REPO_ROOT}/.adlc/drafts/adr/、または {REPO_ROOT}/docs/adlc/memory/adr/（旧形式の場合は {REPO_ROOT}/.adlc/memory/adr/ にフォールバック）が存在することを確認する（個別ファイル形式）
承認済み ADR を確認する：ステータスが「Accepted」の ADR の数を数える
- Accepted の ADR が 0 件の場合：停止して、次の内容を出力する：
```
❌ Cannot proceed: No Accepted ADRs found

The implement command requires ADRs with "Accepted" status.
Current ADRs are: [list statuses found]

Run /architect-clarify to review and approve ADRs first.
```
- Accepted の ADR が 1 件以上の場合：続行し、「✓ Accepted の ADR が N 件見つかりました」と報告する

必須実行制約

重大 — 続行する前にお読みください

以下の制約は必須です。いずれかの制約に違反すると、出力は無効となり、最初からやり直す必要があります。

制約 1：ビューはディスクに書き込む必要があります

次のビューに進む前に、各ビューを個別のファイルとしてディスクに必ず書き込んでください。保存先：{REPO_ROOT}/docs/adlc/architect/views/{subsystem}/{view}.md

ビューをメモリ上に保持し、AD.md だけを書き込むことは禁止です

複数のビューを1回の書き込み操作にまとめることは禁止です

各ファイルは読み取り可能で、単独で成立する内容でなければなりません

内容は最低20行とし、適切なセクション見出しを含めてください

制約 2：各ビューの後に状態を更新する必要があります

個々のビューのファイルをディスクに書き込み、読み取り可能であることを確認したら、次のビューに進む前に、state.json を直ちに更新する 必要があります。サブシステム単位またはフェーズ単位でまとめて更新してはいけません。ビューの進捗を「completed」としてマークするのは、ファイルがディスク上に存在し、読み戻して確認した後に限ります。

制約 3：Functional ビューのチェックポイントは必須です

Functional ビューの後は、ユーザーのチェックポイントのために必ず一時停止してください（--no-checkpoint が指定されている場合を除く）。そのまま続行してはいけません。チェックポイントの選択肢 A/B/C/D を提示し、応答を待ってください。 Functional ビューは「要」となるビューであり、ユーザーの承認が必要です。

制約 4：検証が完了するまでフェーズを「completed」にしてはいけません

次のすべてを満たすまで、state.json でフェーズを「completed」とマークしてはいけません。

すべてのビューファイルがディスク上に存在する（各ファイルを読み取って確認する）

AD.md がビューの内容を集約して書き込まれている

ドラフトのクリーンアップが実施され、確認されている

最終検証テーブル（10項目）が出力されている

制約 5：AD.md の内容はビューファイルから取得する必要があります

ADR から直接 AD.md を書いてはいけません。AD.md の内容は、生成されたビューファイルを読み込んで作成する必要があります。フローは次のとおりです。 ADR → ビュー（ディスク上のファイル）→ AD.md（ビューから集約）

制約 6：フェーズ3ではディスクから読み取る必要があります

フェーズ3では、メモリ上の内容ではなく、ディスク上のビューファイルを必ず読み取ってください。ファイル読み取り操作を使用してください。これにより、再開可能性と監査可能性が確保されます。ビューファイルを読み取れない場合は、停止してエラーを報告してください。

制約 7：ビューはサブシステムの DAG に含まれている必要があります

state.json のサブシステムの dag 配列に記載されていないビューを生成してはいけません。ビューを生成する前に、DAG を確認してください。ビューが含まれていない場合は、state.json で skipped とマークして次に進んでください。 DAG に含まれないビューを生成すると、孤立したファイルが作成され、アーキテクチャが無効になります。

制約 8：AD.md はビューポイントごとに構成する必要があります

AD.md はサブシステムごとではなく、ビューポイントごと（§3.1 コンテキスト、§3.2 機能、§3.3 情報など）に構成する必要があります。各ビューポイントのセクションでは、すべてのサブシステムの内容を統合した、システム全体の視点を示します。サブシステム固有の詳細には、「Subsystem Details」リンクからアクセスできます（ステップ3.5を参照）。

誤り（サブシステムごと — これはサブシステムのビューファイル用です）： ## 5. サブシステム：Auth → ### 5.1 コンテキスト → ### 5.2 機能

正しい（ビューポイントごと — すべてのサブシステムを統合）： ## 3. アーキテクチャビュー → ### 3.1 コンテキストビュー → ### 3.2 機能ビュー

制約 9：図には Mermaid 構文を使用する必要があります

ビューファイルと AD.md の両方で、すべてのアーキテクチャ図に必ず Mermaid 構文を使用してください。ASCII の罫線文字による図形（┌、└、 ├、│、───、═══ など）は、アーキテクチャ図には使用できません。

使用可能な Mermaid 図の種類：

graph TB/LR — アーキテクチャ、トポロジー、フロー図

erDiagram — データモデルとエンティティ関係

sequenceDiagram — インタラクションフロー

flowchart — プロセスフロー

ディレクトリツリーの一覧（コード構成）には、通常の text コードブロックを使用できます。これらはアーキテクチャ図には該当しません。

フェーズ 1：計画（計画エージェント）

目的：ADR を分析し、サブシステムを検出し、カスタマイズした DAG を生成して、ユーザーの承認を得ます

スクリプトのアクション：{REPO_ROOT}/.agents/skills/architect-clarify/scripts/bash/setup-architect.sh を実行します（architect-clarify スキルが必要です：adlc-cli skills add tikalk/adlc-team-skills --skill architect-clarify）。このスクリプトは内部で plan-dag を呼び出します

ステップ 1.1：ADR を読み込んで分析する

ADR ディレクトリを読み込む：{REPO_ROOT}/.adlc/drafts/adr/ から ADR を読み込みます（drafts が空の場合は、{REPO_ROOT}/docs/adlc/memory/adr/ または旧形式の {REPO_ROOT}/.adlc/memory/adr/ も確認します）
ADR インデックスを解析する：{REPO_ROOT}/.adlc/drafts/adr/adr.md または個々の ADR ファイルからサブシステムを抽出します
ADR をサブシステムごとにグループ化する：サブシステム → ADR のマッピングを作成します
ADR のステータスを検証する（必須）：
- ステータスごとに ADR の数を数えます：Accepted／Proposed／Discovered
- Accepted ADR が 0 件の場合：実行を停止し、次のエラーを出力します：
```
❌ フェーズ 1 はブロックされました：Accepted ADR がありません

検出数：[N] Proposed、[M] Discovered、[0] Accepted

implement コマンドは「Accepted」ADR のみを処理します。
実装の前に、/architect-clarify を実行して ADR を承認してください。
```
- ユーザーに報告します：「✓ 実装準備ができた Accepted ADR が [N] 件見つかりました」

ADR インデックスのテーブル形式：

| ID | Sub-System | Decision | Status | Date | Owner |
|----|------------|----------|--------|------|-------|
| ADR-001 | Core | Microservices architecture | Accepted | 2024-01-15 | @architect |
| ADR-002 | Auth | OAuth2 with PKCE | Accepted | 2024-01-16 | @security |
| ADR-003 | Data | PostgreSQL primary store | Accepted | 2024-01-17 | @data |

ステップ 1.2：サブシステムと特性を検出する

各サブシステムについて、ADR を分析して次の項目を検出します：

特性	検出パターン	DAG のカスタマイズ
サーバーレス	Lambda、Functions、serverless	デプロイメントビューを最初にする
イベント駆動型	Events、messaging、async、Kafka、RabbitMQ	並行性ビューを含める
データ集約型	Analytics、ETL、data pipeline	情報ビューを優先する
API ファースト	REST、GraphQL、OpenAPI	機能ビューを優先する
マルチリージョン	Global、multi-region、geo	デプロイメント＋運用

ステップ 1.3：サブシステムごとにカスタマイズした DAG を生成する

デフォルト DAG（コアビュー）：

Context → Functional → Information → Development → Deployment

拡張 DAG（すべてのビュー）：

Context → Functional → Information ──┬─→ Development → Deployment → Operational
                                     └─→ Concurrency ─────────────────┘

DAG のカスタマイズルール：

検出パターン	DAG の変更
サーバーレス	開発より前にデプロイメントを配置する
イベント駆動型	情報の後に並行性を追加する
データ集約型	コンテキストの次に情報を最優先する
マイクロサービス	並行性を追加し、機能を拡張する
モノリス	機能を簡素化し、並行性を省略する

ステップ 1.4：ユーザー承認用に計画を提示する

サブシステム数のしきい値を適用する（必須）： /architect-specify による事前承認の有無にかかわらず、DAG 計画を提示する前に、必ず次のルールを適用します：

サブシステム数	必要なアクション
1～3	計画を提示します。自動承認も可能です
4～6	必ずユーザーに確認を求めます — 明示的な承認なしに先へ進んではいけません
>6	必ずグループ化を提案し、必ず確認を求めます

重要：/architect-specify（フェーズ 0）での承認は、DAG 実行計画の承認の代わりにはなりません。ユーザーはサブシステムごとの DAG 計画を個別に確認する必要があります。

実行計画をユーザーに提示します：

## DAG Execution Plan

**Sub-systems detected**: 3
**Total views to generate**: 15 (5 views × 3 sub-systems)

### Sub-system: Core
**ADRs**: ADR-001, ADR-005, ADR-008
**Characteristics**: Microservices, Event-driven
**DAG**: Context → Functional → Information → Concurrency → Development → Deployment

### Sub-system: Auth
**ADRs**: ADR-002, ADR-006
**Characteristics**: API-first
**DAG**: Context → Functional → Information → Development → Deployment

### Sub-system: Data
**ADRs**: ADR-003, ADR-004, ADR-007
**Characteristics**: Data-intensive
**DAG**: Context → Information → Functional → Development → Deployment

---

**Approve this plan?** [Yes/Modify/Cancel]

ステップ 1.5：state.json を書き込む

ユーザーの承認後、実行計画を {REPO_ROOT}/.adlc/architect/state.json に書き込みます：

{
  "version": "1.1.0",
  "created_at": "2024-01-20T10:30:00Z",
  "updated_at": "2024-01-20T10:30:00Z",
  "phase": "plan_approved",
  "views_mode": "core",
  "workflow": {
    "clarify_completed": false,
    "clarify_completed_at": null,
    "adrs_approved_count": 0,
    "implement_started": false,
    "implement_started_at": null
  },
  "subsystems": [
    {
      "id": "core",
      "name": "Core",
      "adrs": ["ADR-001", "ADR-005", "ADR-008"],
      "characteristics": ["microservices", "event-driven"],
      "dag": ["context", "functional", "information", "concurrency", "development", "deployment"],
      "progress": {
        "context": "pending",
        "functional": "pending",
        "information": "pending",
        "concurrency": "pending",
        "development": "pending",
        "deployment": "pending"
      }
    },
    {
      "id": "auth",
      "name": "Auth",
      "adrs": ["ADR-002", "ADR-006"],
      "characteristics": ["api-first"],
      "dag": ["context", "functional", "information", "development", "deployment"],
      "progress": {
        "context": "pending",
        "functional": "pending",
        "information": "pending",
        "development": "pending",
        "deployment": "pending"
      }
    }
  ],
  "perspectives": ["security", "performance"],
  "output_file": "docs/adlc/architect/AD.md"
}

フェーズ 2：実行（実行エージェント）

目的：依存関係のコンテキストを引き継ぎながら、DAG に従ってサブシステムごとにビューを生成します

スクリプトのアクション：エージェントが state.json を読み込み、DAG の順序でビューを実行します

ステップ 2.1：実行状態を読み込む

{REPO_ROOT}/.adlc/architect/state.json を読み込みます
次に生成するビューを特定します（依存関係がすべて完了しているビュー）
現在のサブシステムに関連する ADR を読み込みます

ステップ 2.2：DAG の順序でビューを生成する

DAG 内の各ビューについて、次の手順を実行します。

DAG メンバーシップの確認：ビューが state.json のサブシステムの dag 配列に含まれていることを確認します。含まれていない場合は → skipped とマークし、生成せずに、次のビューに進みます。
依存関係の確認：すべての依存ビューが完了していることを確認します
依存コンテキストの読み込み：コンテキストとして、完了したビューのファイルを読み込みます
ビューテンプレートの読み込み：templates/views/{view}.md から読み込みます
ビューコンテンツの生成：ADR から導出した内容をテンプレートに入力します
ビューファイルの書き込み：{REPO_ROOT}/docs/adlc/architect/views/{subsystem}/{view}.md に保存します
状態の更新：state.json でビューを「completed」とマークします

依存コンテキストを使用したビューの生成：

## Generating: Functional View for "Core" sub-system

**Dependencies loaded**:
- Context View: {REPO_ROOT}/docs/adlc/architect/views/core/context.md (completed)

**ADRs for this view**: ADR-001 (Microservices), ADR-005 (API Gateway)

**Generating content...**

ステップ 2.3：ビューテンプレートとプレースホルダー

各ビューテンプレートには、入力するプレースホルダーが含まれています。

プレースホルダー	置換内容
`[SUB_SYSTEM_NAME]`	state.json のサブシステム名
`[ADR_IDS]`	カンマ区切りの ADR ID
`[DATE]`	現在の日付（YYYY-MM-DD）
`[ENTITY_N]`	ADR から抽出
`[COMPONENT_N]`	ADR から抽出

ステップ 2.4：ビュー生成の詳細

コンテキストビュー

目的：システムの範囲と外部とのやり取り（ブラックボックスビュー） 依存関係：なし（DAG の最初） テンプレート：templates/views/context.md 主な内容：

システムの範囲の説明
外部エンティティの表（ステークホルダーと外部システムのみ）
コンテキスト図（単一のブラックボックスとしてのシステム）
外部依存関係の表

機能ビュー（★ 要となるビュー - ユーザーチェックポイント）

目的：内部コンポーネント、責務、相互作用 依存関係：コンテキストビュー テンプレート：templates/views/functional.md 主な内容：

機能要素の表
要素間の相互作用図
機能上の境界

重要：機能ビューの生成後、実行はユーザーの承認を得るために一時停止します。これは、その後のすべてのビューの形を決める「要」となるビューです。

Rozanski & Woods：「機能ビューは要となるビューです……通常、他のシステム構造の形を決定します。」

チェックポイントの選択肢：

A：承認 - 残りのビューの生成を続行

B：変更 - 機能ビューを編集してから続行

C：再開 - フィードバックを反映して再生成

D：キャンセル - 実行を停止

チェックポイントをスキップする場合（--no-checkpoint フラグ）：一時停止せずに生成しますが、警告をログに記録します。

情報ビュー

目的：データの保存、管理、フロー 依存関係：コンテキストビュー、機能ビュー テンプレート：templates/views/information.md 主な内容：

データエンティティの表
ER 図
データフローの説明

並行性ビュー（オプション）

目的：実行時のプロセス、スレッド、調整 依存関係：機能ビュー、情報ビュー テンプレート：templates/views/concurrency.md 条件：--views all または --views concurrency の場合のみ 主な内容：

プロセス構造の表
シーケンス図
調整メカニズム

開発ビュー

目的：コードの構成、依存関係、CI/CD 依存関係：機能ビュー テンプレート：templates/views/development.md 主な内容：

コード構成
モジュールの依存関係
ビルドと CI/CD の説明

デプロイメントビュー

目的：物理環境、ノード、ネットワーク 依存関係：開発ビュー テンプレート：templates/views/deployment.md 主な内容：

実行環境の表
ネットワークトポロジー図
ハードウェア要件

運用ビュー（オプション）

目的：運用、サポート、保守 依存関係：デプロイメントビュー テンプレート：templates/views/operational.md 条件：--views all または --views operational の場合のみ 主な内容：

運用上の責務
監視とアラート
災害復旧

ステップ 2.5：state.json の進捗を更新する

警告：状態の更新をまとめて行うこと（例：サブシステムのすべてのビューが完了してから更新すること）は、制約 2 に違反します。各ビューのファイルを書き込み、検証した直後に state.json を更新してください。

各ビューを生成した後：

{
  "progress": {
    "context": "completed",
    "functional": "completed",
    "information": "in_progress",
    "development": "pending",
    "deployment": "pending"
  },
  "updated_at": "2024-01-20T11:15:00Z"
}

ステップ 2.6：再開可能性

エージェントのセッションが中断された場合：

次のセッションで state.json を読み込みます
"pending" または "in_progress" のステータスのビューを特定します
中断した箇所から続行します
すでに "completed" のビューはスキップします

フェーズ 2→3 のゲート：ビューのファイルが存在することを検証する（必須）

フェーズ 3 に進む前に、想定されるすべてのビューのファイルがディスク上に存在することを必ず検証してください。

state.json の各サブシステムについて、ステータスが "completed" のすべてのビューを確認します
ファイルが存在することを確認します：{REPO_ROOT}/docs/adlc/architect/views/{subsystem}/{view}.md
各ファイルが読み取り可能で、最小限の内容（20 行以上）があることを確認します
Mermaid スキャン（制約 9）：各ビューのファイルをスキャンし、ASCII のボックス描画文字（┌、└、├、│、═、───）がないか確認します。アーキテクチャ図を含むべきビュー（context、functional、information、deployment）で見つかった場合は、警告としてフラグを立て、修正が必要なファイルを記録します。

検証チェックリスト（以下の表を出力してください）：

サブシステム	ビュー	ファイルパス	存在する	読み取り可能	行数	Mermaid OK
{subsystem}	{view}	{path}	✓/✗	✓/✗	{N}	✓/⚠

ゲートの判定：

すべてのチェックに合格した場合 → フェーズ 3 に進みます

Mermaid の警告がある場合 → 警告を記録して続行します（ブロック対象外）。以下を出力します：

⚠️ MERMAID WARNING: ASCII box-drawing art detected in:
- {subsystem}/{view}: Convert to Mermaid diagram syntax

Proceeding to Phase 3. Fix ASCII diagrams in next iteration.

その他のチェックに失敗した場合 → 停止して報告します：

❌ PHASE 2→3 GATE BLOCKED

Missing or invalid view files detected:
- {subsystem}/{view}: [reason]

Regenerate missing views before proceeding to Phase 3.

プレースホルダーの検証（必須）

ビューのファイルを確定する前に、すべてのプレースホルダーが埋められていることを必ず検証してください。

確認するプレースホルダーのパターン

パターン	例	重大度	必要な対応
`[TBD]`	`[TBD]`	CRITICAL	完了前に必ず埋める必要があります
`[STAKEHOLDER_*]`	`[STAKEHOLDER_1]`	CRITICAL	実際のステークホルダー名に置き換える必要があります
`[ENTITY_*]`	`[ENTITY_1]`	CRITICAL	実際のエンティティ名に置き換える必要があります
`[COMPONENT_*]`	`[COMPONENT_1]`	CRITICAL	実際のコンポーネント名に置き換える必要があります
`[SUB_SYSTEM_NAME]`	`[SUB_SYSTEM_NAME]`	CRITICAL	実際のサブシステム名に置き換える必要があります
`[ADR_IDS]`	`[ADR_IDS]`	HIGH	実際の ADR 参照に置き換える必要があります
`[DATE]`	`[DATE]`	MEDIUM	実際の日付に置き換える必要があります

検証プロセス

生成後に各ビューのファイルをスキャンし、未入力のプレースホルダーを確認します
各パターンの出現数を数えます
重大度の評価：
- CRITICAL：完了を妨げます。ビューを "completed" にできません
- HIGH：入力することが望ましいですが、文脈が明確であればブロック対象外です
- MEDIUM：あると望ましいものの、必須ではありません

検証レポートのテンプレート

## Placeholder Validation Report

| View | Placeholder | Count | Severity | Status |
|------|-------------|-------|----------|--------|
| context | [STAKEHOLDER_1] | 3 | CRITICAL | ❌ UNFILLED |
| functional | [COMPONENT_1] | 5 | CRITICAL | ❌ UNFILLED |

### Critical Placeholders Unfilled

**❌ VALIDATION FAILED**: Cannot mark views as "completed" with unfilled critical placeholders.

**Required Actions**:
1. Review ADRs for stakeholder names → fill [STAKEHOLDER_*] placeholders
2. Review ADRs for component names → fill [COMPONENT_*] placeholders
3. Re-run view generation with complete information

適用ルール

CRITICAL の未入力プレースホルダーがあるビューは、state.json で "completed" にできません
クリティカルな未入力プレースホルダーがあるビューが 1 つでも存在する場合、フェーズ 2→3 のゲートは失敗します
--force を使用すると回避できます（緊急時のみ。未入力のプレースホルダーをすべて記録してください）

フェーズ 3：要約（要約エージェント）

目的：すべてのビューを集約し、競合を解決して、統合された AD.md を生成します

スクリプトのアクション：summarize アクションを実行します

Step 3.1: すべてのビューファイルをディスクから読み込む（必須）

重要: 実際のファイル読み込み操作を使用して、各ビューファイルをファイルシステムから読み込む必要があります。メモリや ADR の内容を直接使用しないでください。ビューファイルのみが信頼できる唯一の情報源です。

ディレクトリをスキャン: {REPO_ROOT}/docs/adlc/architect/views/ ディレクトリを一覧表示します
各ファイルを読み込む（必須 — ファイルごとに実行）:
- state.json 内の各サブシステム／ビューの組み合わせについて
- ファイル {REPO_ROOT}/docs/adlc/architect/views/{subsystem}/{view}.md を読み込みます
- ファイルを読み込めない場合 → 停止してエラーを報告します:
```
❌ PHASE 3 ERROR: ビュー ファイルを読み込めません
ファイル: {path}
エラー: {error details}

AD.md を生成する前に、ビュー ファイルが存在し、読み込み可能である必要があります。
```
内容を検証（必須）:
- 各ビューファイルは20行以上である必要があります
- 各ビューには適切なセクション見出し（## または ###）が必要です
- 内容の検証に失敗した場合 → 停止して次の内容を報告します:
```
❌ PHASE 3 ERROR: ビュー ファイルの内容が無効です
ファイル: {path}
行数: {count}（最低20行必要）

AD.md を生成する前に、ビュー ファイルに十分な内容が必要です。
```
整理: すべてのサブシステムをまたいで、ビューの種類ごとに内容をまとめます

ディレクトリ構成:

{REPO_ROOT}/docs/adlc/architect/views/
├── core/
│   ├── context.md
│   ├── functional.md
│   ├── information.md
│   ├── concurrency.md
│   ├── development.md
│   └── deployment.md
├── auth/
│   ├── context.md
│   ├── functional.md
│   ├── information.md
│   ├── development.md
│   └── deployment.md
└── data/
    ├── context.md
    ├── functional.md
    ├── information.md
    ├── development.md
    └── deployment.md

Step 3.2: サブシステム間の競合を検出する

次の項目について、サブシステム間のビューを比較します:

競合の種類	検出方法	解決方法
命名の不一致	同じコンポーネントに異なる名称が使われている	ADR の用語に統一する
技術の不一致	同じ目的に異なる技術が使われている	該当する ADR に従う
境界の重複	複数のサブシステムが同じコンポーネントを担当範囲としている	ADR のスコープ定義を使用する
図の不一致	同じエンティティが異なる表現で描かれている	スタイルを統一する

Step 3.3: ADR を使用して競合を解決する

ADR が信頼できる情報源です。競合が検出された場合:

競合する領域を規定する該当の ADR を特定します
ADR の決定を適用して競合を解決します
統合ビューに解決内容を記録します

## Conflict Resolution Log

| Conflict | ADR Reference | Resolution |
|----------|---------------|------------|
| Auth component naming | ADR-002 | Standardized to "AuthService" per ADR-002 |
| Database technology | ADR-003 | PostgreSQL confirmed as primary per ADR-003 |

Step 3.4: 統合 AD.md に集約する

重要: 視点別の集約（制約8）

AD.md は、以下の構成に従い、視点ごとに整理する必要があります。各視点のセクションでは、すべてのサブシステムの内容を統合し、システム全体の説明としてまとめます。サブシステムごとに整理しないでください。その構成はサブシステムのビューファイル用であり、集約した AD.md 用ではありません。

各視点について:

すべてのサブシステムの関連性を示すシステム全体の概要を提示します

サブシステム間の相互作用を示す統合 Mermaid 図を含めます

この視点における各サブシステムの役割を要約します

サブシステムの詳細へのリンクを記載します（Step 3.5 に従い、サブシステムが2つ以上の場合）

視点別の集約レシピ

視点	集約方法
コンテキスト	システムレベルの単一ブラックボックス図（Mermaid `graph`）。独立した外部インターフェースを持つ場合に限り、サブシステムを内部ブロックとして表示します。すべてのサブシステムのステークホルダー表と外部エンティティ表を統合し、重複を排除します。
機能	すべてのサブシステムを対象とした、統合コンポーネント一覧表。サブシステム間のデータフローを示す、単一の統合インタラクション図。境界を示すため、サブシステムごとにMermaid `subgraph` ブロックを使用します。
情報	すべてのサブシステムのエンティティを組み合わせた統合ER図（Mermaid `erDiagram`）。サブシステム間のデータの流れを示す統合データフロー（Mermaid `flowchart`）。エンティティ表の重複を排除します。
並行性	統合プロセス構成表。サブシステム間の非同期インタラクションを示す、統合シーケンス図／フロー図。
開発	すべてのサブシステムを最上位ディレクトリとして示す、単一のコード構成ツリー。ビルドプロセス表とCI/CDパイプライン表を統合します。統合技術スタックマッピング。
デプロイメント	すべてのサブシステムを実行環境内に示す、単一のデプロイトポロジー図（Mermaid `graph`）。実行環境表とハードウェア要件表を統合します。
運用	統合運用責任表。すべてのサブシステムにわたる、統合監視、アラート、およびDR戦略。

統合AD.mdの構成：

# Architecture Description: [Project Name]

## 1. Document Information
[Version, date, authors, status]

## 2. Architectural Goals & Constraints
[From constitution and constraint ADRs]

## 3. Architectural Views

### 3.1 Context View
[Unified from all sub-system context views]
[Single system-level context diagram]

> **Subsystem Details**: [Core](views/core/context.md) | [Auth](views/auth/context.md) | [Data](views/data/context.md)

### 3.2 Functional View
[Merged functional elements from all sub-systems]
[Unified component diagram]

> **Subsystem Details**: [Core](views/core/functional.md) | [Auth](views/auth/functional.md) | [Data](views/data/functional.md)

### 3.3 Information View
[Consolidated data model]
[Unified ER diagram]

> **Subsystem Details**: [Core](views/core/information.md) | [Auth](views/auth/information.md) | [Data](views/data/information.md)

### 3.4 Concurrency View (if applicable)
[Merged from sub-systems with concurrency]

> **Subsystem Details**: [Core](views/core/concurrency.md) | [Auth](views/auth/concurrency.md)

### 3.5 Development View
[Unified code organization]

> **Subsystem Details**: [Core](views/core/development.md) | [Auth](views/auth/development.md) | [Data](views/data/development.md)

### 3.6 Deployment View
[Consolidated deployment topology]

> **Subsystem Details**: [Core](views/core/deployment.md) | [Auth](views/auth/deployment.md) | [Data](views/data/deployment.md)

### 3.7 Operational View (if applicable)
[Merged operational concerns]

> **Subsystem Details**: [Core](views/core/operational.md) | [Auth](views/auth/operational.md)

## 4. Architectural Perspectives

### 4.1 Security Perspective
[Apply security template across all views]

### 4.2 Performance & Scalability Perspective
[Apply performance template across all views]

## 5. Architecture Decision Records Summary
[ADR index link: `../memory/adr/adr.md` (sibling-relative — resolves to {REPO_ROOT}/docs/adlc/memory/adr/adr.md)]

## 6. Tech Stack Summary
[Consolidated from all ADRs]

ステップ3.5：サブシステムビューへのリンクを生成する（条件付き）

条件：len(state.json.subsystems) > 1 の場合にのみリンクを生成します

AD.mdの各ビューセクションについて：

サブシステムリンクを収集する：
- state.json内の各サブシステムについて
- そのサブシステムの dag 配列にビューが存在するか確認します
- リンクを作成します：[SubsystemName](views/{subsystem-id}/{view}.md)

リンクブロックを整形する：

> **Subsystem Details**: [Core](path) | [Auth](path) | [Data](path)

存在しないビューを処理する：
- サブシステムに特定のビューがない場合（dag に含まれていない場合）、そのサブシステムのリンクを省略します
- 例：Authに並行性ビューがない場合、並行性のリンクから省略します
サブシステムが1つの場合：
- サブシステムが1つだけの場合、リンクの追加を完全にスキップします
- 統合ビューはサブシステムビューと同一であるため、リンクは冗長になります

出力例（3つのサブシステムすべてにコンテキストビューがある場合）：

### 3.1 Context View
[Unified system-level context]

> **Subsystem Details**: [Core](views/core/context.md) | [Auth](views/auth/context.md) | [Data](views/data/context.md)

出力例（2つのサブシステムのうち、Coreのみに並行性ビューがある場合）：

### 3.4 Concurrency View
[Merged concurrency concerns]

> **Subsystem Details**: [Core](views/core/concurrency.md)

ステップ3.6：視点を適用する

視点テンプレートを読み込み、すべてのビューに適用します：

セキュリティ視点（`templates/perspectives/security.md`）

認証および認可のアプローチ
データ保護対策
脅威モデル表

パフォーマンス視点（`templates/perspectives/performance.md`）

パフォーマンス要件表
スケーラビリティモデル
キャパシティプランニング

ステップ 3.7：ADR のライフサイクル管理（必須）

AD.md の生成後、以下の手順をすべて実行します。

ステップ 1：承認済み ADR のフィルタリング

ステータスが正確に「Accepted」の ADR のみを特定します
ドラフトに残す必要があります：ステータスが「Proposed」、「Discovered」、「Deprecated」、または「Superseded」の ADR は、昇格の対象ではありません
検証：フィルタリング後、昇格対象に含まれる「Accepted」以外の ADR を数えます。 1 件以上ある場合は、停止して先に修正します。

ステップ 2：正規の場所へのコピー（必須）

「Accepted」の ADR ファイルを {REPO_ROOT}/docs/adlc/memory/adr/（共有レイアウトの正規メモリルート）に移動します
ファイルが存在しない場合は作成し、存在する場合は内容を統合します
検証：ファイルを読み戻し、ADR が存在することを確認します

ステップ 3：ドラフトのクリーンアップ（必須）

昇格した ADR ファイルをそれぞれ {REPO_ROOT}/.adlc/drafts/adr/ から {REPO_ROOT}/docs/adlc/memory/adr/ に移動します
ドラフトが残っていない場合 → セットアップスクリプトが空のディレクトリをクリーンアップします
検証：以下を確認します。
- ADR の重複がない（同じ ID が両方の場所に存在しない）
- 残っている ADR があれば、「Proposed」または「Discovered」のみである
- 両方のスコープ（ドラフトとメモリ）で adr.md インデックスが再生成されている

ステップ 3b：メモリ ADR インデックスの生成（必須）

「Accepted」の ADR を docs/adlc/memory/adr/ に移動した後、セットアップスクリプトの generate_adr_index 関数を使用して、{REPO_ROOT}/docs/adlc/memory/adr/adr.md にメモリインデックスファイルを生成します（ドラフトのインデックスを生成する関数と同じですが、scope=memory を指定します。メモリスコープにレコードがある場合、インデックスは常に docs ルートに書き込まれます）。

source "{REPO_ROOT}/.agents/skills/architect-clarify/scripts/bash/setup-architect.sh"
generate_adr_index memory

これにより、parse_fm_field を介して YAML フロントマターを解析し、7 列のスキーマを持つ {REPO_ROOT}/docs/adlc/memory/adr/adr.md が書き込まれます。インデックスの形式は次のとおりです。

# Architecture Decision Records (Memory)

> Auto-generated by /architect-implement. Accepted ADRs only.
> Source: docs/adlc/memory/adr/ADR-*.md

## ADR Index

| ID | Sub-System | Decision | Status | Date |
|----|------------|----------|--------|------|
| ADR-009 | System | System Architecture Style | Completed | 2026-10-19 |

このインデックスは、セッション開始時の注入では team-boot によって、アーキテクチャレビューでは architect-analyze によって使用されます（チームレベルのコンテキストで CDR.md が使用される方法と同様です）。

ステップ 4：ライフサイクルの変更を報告（必須） 次の概要をユーザーに出力します。

📋 ADR Lifecycle Summary:
├── Promoted to memory: [N] Accepted ADRs
├── Remaining in drafts: [M] ADRs (Proposed/Discovered)
├── Duplicates found: [0] ✓
└── Cleanup verified: ✓

いずれかのステップが失敗した場合：停止して修正してから、フェーズ 3 を完了としてマークします。

ステップ 3.8：最終レポートの生成

## Architecture Description Generated

**Output**: AD.md (project root)
**Views Mode**: [core|all|custom]
**Sub-systems Processed**: N

**Views Generated**:
| Sub-system | Views | Status |
|------------|-------|--------|
| Core | Context, Functional, Information, Concurrency, Development, Deployment | ✓ |
| Auth | Context, Functional, Information, Development, Deployment | ✓ |
| Data | Context, Functional, Information, Development, Deployment | ✓ |

**Perspectives Applied**:
- [x] Security
- [x] Performance & Scalability

**Conflicts Resolved**: M
**ADR Coverage**: X/Y ADRs incorporated

**ADR Lifecycle**:
- Promoted to canonical: N ADRs
- Remaining in drafts: M ADRs

**Recommended Next Steps**:
1. Review generated AD.md for accuracy
2. Run `/architect-analyze` for consistency validation
3. Share with stakeholders for review
4. Run `/architect-analyze` to validate the generated architecture

最終完了確認（必須）

state.json のフェーズを「completed」としてマークする前に、すべての出力を確認します。

次の 10 項目の確認リストを実行します。

確認項目	期待値	検証方法	状態
1. ディスク上のビューファイル	N 個のファイル（サブシステムごとにビュー 1 つ）	`{REPO_ROOT}/docs/adlc/architect/views/` を一覧表示	☐
2. AD.md の存在	はい、プロジェクトルートに存在	ファイルの存在を確認	☐
3. AD.md のコンテンツサイズ	200 行超	AD.md の行数を数える	☐
4. AD.md にすべてのビューがある	N セクション（## 3.x ヘッダー）	AD.md のヘッダーを解析	☐
5. メモリ ADR の昇格	N 個の「Accepted」ADR	`{REPO_ROOT}/docs/adlc/memory/adr/` 内のファイル数を数える	☐
6. ドラフトのクリーンアップ	重複なし	ドラフトとメモリを比較	☐
7. state.json の整合性	すべてのビューが「completed」	進捗フィールドを確認	☐
8. サブシステムのリンク（該当する場合）	AD.md 内のリンク（サブシステムが 2 つ以上の場合）	AD.md で「Subsystem Details」を検索	☐
9. 視点別の整理（制約 8）	`## N. Sub-System:` セクションがない	AD.md でサブシステムごとの最上位ヘッダーを検索	☐
10. Mermaid 図（制約 9）	ASCII の罫線アートがない	AD.md で `┌`、`└`、`├`、`═` の文字を検索	☐

ゲートルール：

すべての確認に合格した場合（☑）：state.json でフェーズを「completed」としてマークします
いずれかの確認に失敗した場合（☒）：「completed」としてマークしません。問題を修正し、再確認します。

ユーザーへの出力：

✅ Architecture Description Generation Complete

Verification Results:
├── View files: [N] generated ✓
├── AD.md: [lines] lines, [sections] views ✓
├── Subsystem links: [N] links (if applicable) ✓
├── Viewpoint-organized: ✓
├── Mermaid diagrams: ✓
├── ADRs promoted: [N] to memory ✓
├── Drafts cleaned: [N] remaining ✓
└── State consistent: ✓

Status: READY FOR USE

状態ファイルのスキーマ

場所：{REPO_ROOT}/.adlc/architect/state.json

{
  "version": "1.1.0",
  "created_at": "ISO8601 timestamp",
  "updated_at": "ISO8601 timestamp",
  "phase": "planning | plan_approved | executing | summarizing | completed",
  "views_mode": "core | all | custom",
  "subsystems": [
    {
      "id": "lowercase-kebab-case",
      "name": "Display Name",
      "adrs": ["ADR-001", "ADR-002"],
      "characteristics": ["microservices", "event-driven"],
      "dag": ["context", "functional", "information", "development", "deployment"],
      "progress": {
        "context": "pending | in_progress | completed | skipped",
        "functional": "pending | in_progress | completed | skipped"
      }
    }
  ],
  "perspectives": ["security", "performance"],
  "conflicts_detected": [],
  "conflicts_resolved": [],
  "output_file": "AD.md"
}

主なルール

ADR のトレーサビリティ

すべてのビューセクションで、ソース ADR を参照する必要があります
ADR に裏付けられていないコンテンツを含めてはいけません
競合を解決する際は ADR を信頼できる唯一の情報源とします

状態の永続化

各操作の後に、必ず state.json を更新する
中断した場合も、スムーズに再開する
ビュー単位で進捗を追跡する

マルチエージェント互換性

状態ファイルは、あらゆる AI エージェント（Claude、Copilot、Cursor など）で動作する
エージェント固有の依存関係がない
デバッグしやすい、人間が読み取れる状態情報

図の品質

書き込む前に Mermaid の構文を検証する
サブシステム間でスタイルを統一する
最終的な AD.md に図を統合する

コンテキスト

$ARGUMENTS

次のステップ

実装が完了したら、/architect-analyze を実行して一貫性と品質を検証します。

検証

{REPO_ROOT}/docs/adlc/architect/AD.md が存在し、200 行を超え、すべてのビューポイントのセクション（## 3.x 見出し）が含まれている。
完了したすべてのビューについて、サブシステムごとのビューファイルが {REPO_ROOT}/docs/adlc/architect/views/{subsystem}/{view}.md に存在する。
state.json の整合性が取れている：生成されたすべてのビューが "completed" としてマークされ、フェーズが "completed" になっている。
承認済み ADR が昇格されている：ステータスが "Accepted" の ADR がすべて {REPO_ROOT}/docs/adlc/memory/adr/ に移動され、メモリーインデックスが {REPO_ROOT}/docs/adlc/memory/adr/adr.md に再生成されている。
ドラフトが整理されている：昇格した ADR ファイルが {REPO_ROOT}/.adlc/drafts/adr/ から {REPO_ROOT}/docs/adlc/memory/adr/ に移動され、重複が残っておらず、残りのドラフトは Proposed または Discovered のみである。
AD.md がビューポイントごとに構成されている：セクションがサブシステム別ではなく、ビューポイント別（## 3. Architectural Views → ### 3.1 Context View など）にまとめられている。
図は Mermaid のみ：アーキテクチャ図に ASCII の罫線文字（┌、└、├、│、═、───）が使われていない。
プレースホルダーの検証に合格している：ビューファイルに未入力の重要なプレースホルダー（[TBD]、[STAKEHOLDER_*]、[ENTITY_*]、[COMPONENT_*]、[SUB_SYSTEM_NAME]）が残っていない。
2 つ以上のサブシステムを処理した場合、AD.md にサブシステム詳細へのリンクがある。

Markdown 対応

ログインしてコメント

基本情報

作者: tikalk
リポジトリ: tikalk/adlc-team-skills
カテゴリ: 開発
インストール数: 189
GitHub スター: 143

問題を報告

architect-implement

architect-implement について

主な機能

活用シーン

インストール

詳細

architect-implement

このスキルでできること

使用するタイミング

使用しないタイミング

プロセス

ユーザー入力

フラグ

Rozanski & Woods の方法論との整合性

基本原則

視点の依存関係グラフ

動的な視点とパースペクティブの選択

目標

役割とコンテキスト

アーキテクチャドキュメントの階層

ビューテンプレート

3 フェーズの DAG ワークフロー

事前検証（必須 - 厳格に適用）

ワークフロー状態のチェック（--force を除く）

ADR ステータスのチェック

必須実行制約

制約 1：ビューはディスクに書き込む必要があります

制約 2：各ビューの後に状態を更新する必要があります

制約 3：Functional ビューのチェックポイントは必須です

制約 4：検証が完了するまでフェーズを「completed」にしてはいけません

制約 5：AD.md の内容はビューファイルから取得する必要があります

制約 6：フェーズ3ではディスクから読み取る必要があります

制約 7：ビューはサブシステムの DAG に含まれている必要があります

制約 8：AD.md はビューポイントごとに構成する必要があります

制約 9：図には Mermaid 構文を使用する必要があります

フェーズ 1：計画（計画エージェント）

ステップ 1.1：ADR を読み込んで分析する

ステップ 1.2：サブシステムと特性を検出する

ステップ 1.3：サブシステムごとにカスタマイズした DAG を生成する

ステップ 1.4：ユーザー承認用に計画を提示する

ステップ 1.5：state.json を書き込む

フェーズ 2：実行（実行エージェント）

ステップ 2.1：実行状態を読み込む

ステップ 2.2：DAG の順序でビューを生成する

ステップ 2.3：ビューテンプレートとプレースホルダー

ステップ 2.4：ビュー生成の詳細

コンテキストビュー

機能ビュー（★ 要となるビュー - ユーザーチェックポイント）

情報ビュー

並行性ビュー（オプション）

開発ビュー

デプロイメントビュー

運用ビュー（オプション）

ステップ 2.5：state.json の進捗を更新する

ステップ 2.6：再開可能性

フェーズ 2→3 のゲート：ビューのファイルが存在することを検証する（必須）

プレースホルダーの検証（必須）

確認するプレースホルダーのパターン

検証プロセス

検証レポートのテンプレート

適用ルール

フェーズ 3：要約（要約エージェント）

Step 3.1: すべてのビュー ファイルをディスクから読み込む（必須）

Step 3.2: サブシステム間の競合を検出する

Step 3.3: ADR を使用して競合を解決する

Step 3.4: 統合 AD.md に集約する

視点別の集約レシピ

ステップ3.5：サブシステムビューへのリンクを生成する（条件付き）

ステップ3.6：視点を適用する

セキュリティ視点（templates/perspectives/security.md）

パフォーマンス視点（templates/perspectives/performance.md）

ステップ 3.7：ADR のライフサイクル管理（必須）

ステップ 3.8：最終レポートの生成

最終完了確認（必須）

状態ファイルのスキーマ

主なルール

ADR のトレーサビリティ

状態の永続化

マルチエージェント互換性

図の品質

ワークフロー状態のチェック（`--force` を除く）

Step 3.1: すべてのビューファイルをディスクから読み込む（必須）

セキュリティ視点（`templates/perspectives/security.md`）

パフォーマンス視点（`templates/perspectives/performance.md`）