| name | architecture |
| description | Designs system architecture from Japanese requirement notes and generates architecture.md. Triggers: architecture, アーキテクチャ, システム設計, 構成設計, レイヤー設計. Source-code read-only — never modifies source code or test files. Outputs structured architecture document to output/design/ (requires Write permission to output/design/). Takes a file path as argument: /architecture <file-path>
|
| context | fork |
Architecture Designer
日本語の要求メモ・要件メモ・PRDファイルを入力として、Claude Codeが理解しやすい
構造化されたシステムアーキテクチャドキュメントを設計・生成するスキル。
ソースコードは一切変更しない。
前提条件
前提ファイルなし。このスキルが docs/architecture.md と docs/project.md を生成する側である。
入力: project-config.md §1〜§4 + 要求メモファイル。
基本姿勢
- 読み取り専用（ソースコード変更禁止）
- 入力ファイルの要件を忠実にアーキテクチャへ落とし込む
- 技術選定は選択肢と根拠を提示し、決定はユーザーに委ねる
- 曖昧な設計判断は「【要確認】」として明示し、選択肢を提示する
- 出力は人間がレビュー・承認するためのもの
- 過剰設計を避け、要件に対して必要十分な構成を設計する
使い方
/architecture <要求メモファイルのパス>
引数のファイルパスは絶対パス・相対パスどちらも可。
複数ファイルを指定する場合はスペース区切りで列挙する。
例
/architecture input/requirements/REQ_001.md
/architecture output/prd/PRD_auth.md
/architecture memo1.md memo2.md
出力先
- デフォルト:
output/design/ARCH_<機能名>.md（output/ディレクトリが存在する場合）
- フォールバック:
docs/architecture.md
ワークフロー
Phase 1: 入力分析
- ファイル読み込み — 引数で渡されたファイルを
Read ツールで読み込む
- 要件抽出 — アーキテクチャに影響する要件を分類する:
- 機能要件（画面数、データ種別、処理フロー）
- 非機能要件（パフォーマンス、スケーラビリティ、セキュリティ）
- 技術的制約（使用技術の指定、既存システムとの連携）
- 運用要件（デプロイ、監視、バックアップ）
- 規模感の把握 — システムの規模・複雑さを見積もる
Phase 2: 既存コードベース調査（既存プロジェクトの場合）
- ディレクトリ構成 — 現在のソース構造を
Glob / Read で把握する
- 依存関係 — パッケージ・モジュール間の依存を確認する
- 既存パターン — 使用中のアーキテクチャパターンを特定する
- 既存ドキュメント —
docs/ 配下の関連情報を確認する
Phase 3: アーキテクチャ設計
- レイヤー設計 — 責務分離とレイヤー間の依存方向を定義する
- モジュール分割 — 機能ごとのモジュール境界を決定する
- データフロー設計 — データの流れと状態管理方針を定義する
- 技術選定 — 各レイヤーの技術候補と選定理由を整理する
- 整合性チェック — 要件との対応漏れがないか確認する
Phase 4: 出力
- ファイル出力 —
output/design/ARCH_<機能名>.md に書き出す（output/ が存在しない場合は docs/architecture.md）
- サマリー提示 — アーキテクチャの概要と設計判断のポイントをユーザーに提示する
出力フォーマット
# アーキテクチャ: [システム/プロジェクト名]
> 生成元: [入力ファイル名]
> 生成日: [YYYY-MM-DD]
> ステータス: Draft
## 1. アーキテクチャ概要
### 1.1 設計方針
[アーキテクチャの基本方針と採用理由]
### 1.2 システム構成図
[テキストベースの構成図。ASCII or Mermaid形式]
### 1.3 主要な設計判断
| # | 判断事項 | 決定内容 | 理由 |
| - | -------- | -------- | ---- |
| 1 | [判断事項] | [採用した方針] | [根拠] |
## 2. 技術スタック
| カテゴリ | 技術 | バージョン | 選定理由 |
| -------- | ---- | ---------- | -------- |
| 言語 | ... | ... | ... |
| フレームワーク | ... | ... | ... |
## 3. レイヤー構成
### 3.1 レイヤー定義
| レイヤー | 責務 | 依存可能な対象 |
| -------- | ---- | -------------- |
| [レイヤー名] | [責務] | [依存先] |
### 3.2 依存方向ルール
[禁止される依存方向を箇条書きで明示]
### 3.3 検証方法
[依存方向の検証コマンド・ツール]
## 4. ディレクトリ構成
[ツリー形式で記述。各ディレクトリにコメントで責務を付記]
## 5. モジュール設計
### 5.1 機能モジュール一覧
| モジュール | 責務 | 主要コンポーネント | 依存ストア |
| ---------- | ---- | ------------------ | ---------- |
| [name] | [責務] | [コンポーネント名] | [ストア名] |
### 5.2 モジュール間連携
[モジュール間のデータフローや連携方法]
## 6. 状態管理設計
### 6.1 ストア一覧
| ストア | 責務 | 永続化 | ストレージキー |
| ------ | ---- | ------ | -------------- |
| [name] | [責務] | あり/なし | [キー名] |
### 6.2 永続化方針
### 6.3 ストア間の参照ルール
## 7. データフロー
### 7.1 データの流れ
### 7.2 バリデーション戦略
## 8. ルーティング設計
| パス | ページ | 機能 |
| ---- | ------ | ---- |
| [path] | [PageComponent] | [機能名] |
## 9. UI設計方針
### 9.1 コンポーネント設計
### 9.2 スタイリング方針
### 9.3 ダークモード対応
## 10. テスト戦略
### 10.1 テスト構成
| 種別 | ツール | 対象 | 配置 |
| ---- | ------ | ---- | ---- |
| ユニット | [ツール名] | [対象] | [配置] |
### 10.2 テスト方針
## 11. エントリーポイントとプロバイダー構成
## 12. セキュリティ設計
## 13. 開発環境・ツールチェーン
### 13.1 コマンド一覧
| ファイル | 責務 |
| -------- | ---- |
| docs/project.md | 技術スタック・コマンド・ルーティング・ストア一覧 |
| docs/architecture.md | ディレクトリ構成・レイヤー設計・テスト構成 |
| docs/data-model.md | スキーマ定義・フィールド仕様・バリデーション |
| docs/development-patterns.md | コード規約・落とし穴・アンチパターン |
| # | 項目 | 選択肢 | 影響範囲 |
| - | ---- | ------ | -------- |
出力契約
セクション定義
| # | セクション | 必須 | 制約 |
|---|
| 1 | アーキテクチャ概要（設計方針, 構成図, 主要判断） | ✅ | 構成図はASCII or Mermaid形式 |
| 2 | 技術スタック | ✅ | テーブル形式。選定理由を各行に付記 |
| 3 | レイヤー構成（定義, 依存方向, 検証方法） | ✅ | 禁止依存を箇条書きで明示 |
| 4 | ディレクトリ構成 | ✅ | textコードブロックのツリー形式。各ディレクトリに # コメント |
| 5 | モジュール設計（一覧, 連携） | ✅ | テーブルで責務・コンポーネント・依存ストアを列挙 |
| 6 | 状態管理設計（ストア一覧, 永続化, 参照ルール） | ✅ | 永続化パターンを明記 |
| 7 | データフロー | ✅ | ユーザー操作→UI→Store→Storageの流れ |
| 8 | ルーティング設計 | ✅ | テーブル形式（パス, ページ, 機能） |
| 9 | UI設計方針 | ✅ | Container/Presentational, スタイリング, ダークモード |
| 10 | テスト戦略 | ✅ | テーブル形式（種別, ツール, 対象, 配置） |
| 11 | エントリーポイントとプロバイダー構成 | ✅ | プロバイダー順序を明記 |
| 12 | セキュリティ設計 | ✅ | XSS対策, データ保護, バリデーション |
| 13 | 開発環境・ツールチェーン | ✅ | コマンド一覧, Git Hooks |
| 14 | ドキュメント体系 | ✅ | テーブル形式（ファイル, 責務） |
| 15 | 要確認事項 | 条件付き | 設計判断が必要な箇所がある場合 |
| 16 | 今後の拡張ポイント | 条件付き | 将来的な考慮事項がある場合 |
語彙制約
| 用語 | 定義 |
|---|
| レイヤー | 依存方向が制御されたコードの分類単位 |
| モジュール | 特定のビジネス機能を実現する、アーキテクチャパターンに応じた機能モジュールのディレクトリ |
| 永続化パターン | データをストレージに保存する方式 |
| 【要確認】 | ユーザー判断が必要な設計判断。選択肢を併記する |
構造制約
- セクションは番号順（1〜16）で出力
- テーブルのセルは空欄不可（該当なしの場合は
— を記入）
- ディレクトリツリーは
text コードブロック内に記述
- 各ディレクトリに
# コメント で責務を付記
- 技術選定は決定せず、選択肢と根拠を提示する
設計原則
責務分離
- 各レイヤー・モジュールの責務を単一かつ明確に定義する
- 依存方向は上位→下位の一方向のみ許可する
- 機能モジュール間の直接依存を禁止し、shared層で連携する
Claude Code可読性
- テーブル形式の多用 — 一覧性の高い情報はテーブルで記述する
- ディレクトリツリー —
text コードブロックでツリー構造を明示する
- コメント付記 — ツリー内の各ディレクトリに
# でコメントを付ける
- パス表記の統一 —
src/... 形式で統一する
- 依存ルールの明示 — 禁止事項を箇条書きで列挙する
- セクション番号付き — セクションに番号を付けて参照しやすくする
最小十分の原則
- 要件に対して必要十分な複雑さで設計する
- 「将来必要になるかもしれない」抽象化は行わない
- 拡張ポイントは明示するが、現時点では実装しない
品質チェックリスト
出力ファイル
output/design/ ディレクトリが存在する場合: output/design/ARCH_<機能名>.md- フォールバック:
docs/architecture.md
- すでに存在する場合: ユーザーに選択肢を提示する（上書き / 別名保存 / 差分マージ）
調査で使用するツール
Glob / Grep — ファイル・コード検索Read — ファイル内容の確認- 依存方向チェックコマンド（
project-config.md に記載されている場合）
他スキルとの連携
| 前工程 | 本スキル | 後工程 |
|---|
/prd で要件定義 | /architecture で設計 | /plan でタスク分解 → /implementing-features で実装 |
禁止事項
- ソースコードの変更（テストファイルも含む）
- 入力メモにない要件の追加（推測で機能を膨らませない）
- 技術選定の最終決定（選択肢と根拠の提示にとどめる）
- プロジェクト固有のデータ（ID、パスワード等）をドキュメントに含めること
- 既存の
docs/ 配下ファイルの無断変更
