@k2works/claude-code-booster 1.13.0 → 2.0.0

package/lib/assets/.claude/skills/analyzing-requirements/SKILL.md

@@ -1,89 +1,91 @@
 ---
 name: analyzing-requirements
-description: 要件定義を支援。RDRA 2.0 に基づくシステム価値、外部環境、境界の分析。要件定義やシステム分析の検討時に使用。
+description: RDRA 2.0 に基づく体系的な要件定義を支援。システム価値→外部環境→境界→内部構造の 4 層で要件を整理。「要件定義を始めたい」「システムの要求を整理したい」「RDRA で分析したい」「業務フローを整理したい」「システムコンテキストを作りたい」といった場面で発動する。要件を体系的に整理することで、開発フェーズでの「何を作ればいいかわからない」問題を防ぐ。
 ---
 
-# 要件定義支援
+# 要件定義
 
-RDRA モデルに基づいた体系的な要件定義を作成します。
+RDRA 2.0（リレーションシップ駆動要件分析）に基づき、システム価値→外部環境→境界→内部構造の 4 層で要件を体系的に整理する。
 
-## Instructions
+RDRA の価値は、要件を「何となくの要望リスト」ではなく「なぜそれが必要か」の根拠付きで構造化できること。各層の出力が次の層の入力になるため、トレーサビリティが自然に確保される。
 
-### 1. 参照ドキュメント
+## 参照ドキュメントとテンプレート
 
-- @docs/reference/要件定義支援.md - 要件定義の進め方ガイド
-- @docs/analysis/business_architecture.md
-- @docs/analysis/inception_deck.md
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/要件定義ガイド.md | RDRA 2.0 の進め方詳細 |
+| テンプレート | @docs/template/要件定義.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/analysis/business_architecture.md | ビジネスアーキテクチャ分析書 |
+| 入力 | @docs/analysis/inception-deck.md | インセプションデッキ |
+| 成果物 | `docs/requirements/requirements_definition.md` | テンプレートを基に作成 |
 
-### 2. テンプレート
+## RDRA の 4 層構造
 
-- @docs/template/要件定義.md - 要件定義テンプレート（**編集禁止**）
+各層は上から下に向かって具体化されていく。上位層が曖昧だと下位層の定義がブレるため、この順序で進めることが重要。
 
-### 3. 成果物
+### 層 1: システム価値
 
-- @docs/requirements/requirements_definition.md
+「なぜこのシステムが必要か」を明確にする。インセプションデッキの「なぜやるのか」をシステムの文脈で具体化する。
 
-### 4. 作業内容
+- **システムコンテキスト図**: システムとアクター（人・外部システム）の関係を PlantUML で図示
+- **要求モデル**: ステークホルダーの要求を構造化して一覧化
 
-#### システム価値の明確化
+### 層 2: システム外部環境
 
-- システムコンテキスト図の作成
-- 要求モデルの定義
+「どのような業務の中でシステムが使われるか」を整理する。ビジネスアーキテクチャ分析書のバリューストリームや組織マップが入力になる。
 
-#### システム外部環境の分析
+- **ビジネスコンテキスト**: 業務の全体像とシステムの位置づけ
+- **ビジネスユースケース**: 業務レベルのユースケース識別
+- **業務フロー**: 業務プロセスの可視化（PlantUML アクティビティ図）
+- **利用シーン**: ユーザーがシステムを使う具体的な場面
 
-- ビジネスコンテキストの把握
-- ビジネスユースケースの識別
-- 業務フローの整理
-- 利用シーンの特定
+### 層 3: システム境界
 
-#### システム境界の定義
+「システムの内と外の接点は何か」を定義する。外部環境の分析結果から、システムが担う範囲を確定する。
 
-- ユースケース複合図の作成
-- 画面・帳票モデルの定義
-- イベントモデルの設計
+- **ユースケース複合図**: システムユースケースとアクターの関係
+- **画面・帳票モデル**: ユーザーインターフェースの概要定義
+- **イベントモデル**: システムが受け取る・発信するイベント
 
-#### システム内部構造の設計
+### 層 4: システム内部構造
 
-- 情報モデルの作成
-- 状態モデルの定義
+「システム内部でどのような情報をどう扱うか」を設計する。後続のデータモデル設計・ドメインモデル設計の基礎になる。
 
-### 5. 注意事項
+- **情報モデル**: システムが扱う主要なエンティティとリレーション
+- **状態モデル**: 主要エンティティの状態遷移
 
-- **前提条件**: @docs/requirements/requirements_definition.md が無ければ新規要件定義を開始
-- **制限事項**: テンプレート @docs/template/要件定義.md は絶対に編集しないこと
-- **推奨事項**: ステークホルダーとの合意形成を行いながら進める
+## 作成の進め方
 
-### 6. 記述ルール
+### 新規作成
 
-タスク項目などは一行開けて記述する。
+1. 入力ドキュメント（ビジネスアーキテクチャ分析書、インセプションデッキ）の有無を確認する。なければ基本情報をヒアリングする
+2. テンプレート（@docs/template/要件定義.md）を読み込む
+3. 層 1 から順に 4 層を作成する。各層で PlantUML を活用して視覚化する
+4. `docs/requirements/requirements_definition.md` として出力する
 
-OK:
+### 途中から再開・更新
 
-```markdown
-**受入条件**:
+既存の `docs/requirements/requirements_definition.md` がある場合は、まずその内容を確認する。不足している層や更新が必要な部分のみを修正する。
 
-- [ ] システムコンテキスト図が作成されている
-- [ ] 要求モデルが定義されている
-```
-
-NG:
+**Example:**
 
-```markdown
-**受入条件**:
-- [ ] システムコンテキスト図が作成されている
-- [ ] 要求モデルが定義されている
+```
+ユーザー: 「システムコンテキストは作った。業務フローを整理したい」
+回答: 層 2（システム外部環境）の業務フロー作成に進む。
+      既存のシステムコンテキスト図のアクターを起点に、
+      各アクターの業務プロセスを PlantUML アクティビティ図で可視化する。
 ```
 
-## Examples
-
-### 新規プロジェクトで要件定義を開始
+## 注意事項
 
-1. プロジェクトの基本情報を確認
-2. @docs/reference/要件定義支援.md に基づいて RDRA モデルで要件定義
-3. テンプレートの構造に従って成果物を作成
+- 入力ドキュメントが未作成でも、プロジェクト情報から直接作成可能。完璧な入力を待つより進める方が効果的
+- テンプレートは編集禁止。コピーして成果物を作成する
+- 各層の成果物には PlantUML を活用し、テキストだけでなく図で表現する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
 
-### 既存要件の詳細化
+## 関連スキル
 
-1. 既存の @docs/requirements/requirements_definition.md を読み込む
-2. 不足している項目を分析し改善提案を作成
+- `analyzing-business` — 前段のビジネスアーキテクチャ分析
+- `analyzing-inception-deck` — 前段のインセプションデッキ
+- `analyzing-usecases` — 後続のユースケース・ユーザーストーリー詳細化
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内

package/lib/assets/.claude/skills/analyzing-tech-stack/SKILL.md

@@ -1,102 +1,101 @@
 ---
 name: analyzing-tech-stack
-description: 技術スタック選定を支援。フレームワーク、ライブラリ、インフラの選定と評価。技術選定や構成の検討時に使用。
+description: アーキテクチャ設計に基づく技術スタックの選定と表形式の一覧作成を支援。「技術スタックを選定したい」「フレームワークを決めたい」「使用ライブラリを整理したい」「バージョンを確認したい」「技術構成を一覧化したい」といった場面で発動する。技術スタックを事前に選定・一覧化することで、開発中の「バージョン不整合」「サポート切れ」問題を防ぐ。
 ---
 
-# 技術スタック選定支援
+# 技術スタック選定
 
-表形式の技術スタック一覧を作成します。
+アーキテクチャ設計に基づき、バックエンド・フロントエンド・インフラの各レイヤーに最適な技術を選定し、表形式の技術スタック一覧を作成する。
 
-## Instructions
+技術スタックの選定はプロジェクトの生産性と保守性に直結する。LTS バージョンの選択、サポート期限の把握、アップグレード計画の策定を怠ると、プロジェクト後半でセキュリティリスクと移行コストが膨らむ。
 
-### 1. 入力
+## 参照ドキュメントとテンプレート
 
-- @docs/design/architecture_backend.md - バックエンドアーキテクチャ
-- @docs/design/architecture_frontend.md - フロントエンドアーキテクチャ
-- @docs/design/architecture_infrastructure.md - インフラストラクチャアーキテクチャ
+| 種類 | パス | 備考 |
+|------|------|------|
+| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
+| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
+| 入力 | @docs/design/architecture_infrastructure.md | インフラストラクチャアーキテクチャ |
+| 成果物 | `docs/design/tech_stack.md` | 技術スタック一覧 |
 
-### 2. 成果物
+## バックエンド技術スタック
 
-- @docs/design/tech_stack.md - 技術スタック一覧
+アーキテクチャパターンに適合する技術を選定する。チームの習熟度とコミュニティの活性度も考慮せよ。
 
-### 3. 作業内容
+- **言語・フレームワーク**: アーキテクチャパターンのサポート状況を確認して選定する
+- **ORM・データベースドライバ**: データアクセス層の要件に合った技術を選定する
+- **テストフレームワーク**: TDD に必要なモック・アサーションライブラリを含めて選定する
+- **ビルドツール**: ビルド速度とプラグインエコシステムを考慮して選定する
 
-#### バックエンド技術スタック
+## フロントエンド技術スタック
 
-- 言語・フレームワーク
-- ORM・データベースドライバ
-- テストフレームワーク
-- ビルドツール
+UI 設計とフロントエンドアーキテクチャの要件に基づいて選定する。
 
-#### フロントエンド技術スタック
+- **フレームワーク**: SPA/SSR/SSG の要件に合ったフレームワークを選定する
+- **状態管理ライブラリ**: アプリケーションの状態の複雑さに応じて選定する
+- **UI コンポーネントライブラリ**: デザインシステムとの整合性を考慮する
+- **テストフレームワーク**: ユニットテスト・E2E テストの両方をカバーする
+- **ビルドツール**: バンドルサイズ最適化とビルド速度を考慮する
 
-- フレームワーク
-- 状態管理ライブラリ
-- UI コンポーネントライブラリ
-- テストフレームワーク
-- ビルドツール
+## インフラ技術スタック
 
-#### インフラ技術スタック
+非機能要件（可用性・スケーラビリティ）を実現する技術を選定する。
 
-- クラウドサービス
-- コンテナ技術
-- CI/CD ツール
-- 監視ツール
+- **クラウドサービス**: コスト・リージョン・サービス充実度で選定する
+- **コンテナ技術**: オーケストレーション方式を含めて選定する
+- **CI/CD ツール**: パイプラインの柔軟性と既存ツールとの連携を考慮する
+- **監視ツール**: 非機能要件の監視項目をカバーできるツールを選定する
 
-#### バージョン管理
+## バージョン管理
 
-- 各技術のバージョン
-- サポート期限
-- アップグレード計画
+すべての技術に対してバージョンとサポート期限を記録する。サポート切れの技術を使い続けることはセキュリティリスクに直結する。
 
-### 4. 出力フォーマット
+- **各技術のバージョン**: LTS バージョンを優先して選定する
+- **サポート期限**: EOL（End of Life）日を記録する
+- **アップグレード計画**: メジャーバージョンアップの時期と影響を事前に把握する
+
+## 出力フォーマット
 
 ```markdown
-| カテゴリ | 技術 | バージョン | 用途 |
-|---------|------|-----------|------|
-| 言語 | Java | 25 | バックエンド開発 |
-| フレームワーク | Spring Boot | 4.x | Web アプリケーション |
-| ORM | MyBatis | 3.x | データアクセス |
-| DB | PostgreSQL | 16 | データストア |
-| テスト | JUnit 5 | 5.11+ | ユニットテスト |
+| カテゴリ | 技術 | バージョン | 用途 | サポート期限 |
+|---------|------|-----------|------|-------------|
+| 言語 | Java | 25 | バックエンド開発 | 2028-09 |
+| フレームワーク | Spring Boot | 4.x | Web アプリケーション | - |
+| ORM | MyBatis | 3.x | データアクセス | - |
+| DB | PostgreSQL | 16 | データストア | 2028-11 |
+| テスト | JUnit 5 | 5.11+ | ユニットテスト | - |
 ```
 
-### 5. 注意事項
-
-- **前提条件**: アーキテクチャ設計が完了していること
-- **制限事項**: LTS バージョンを優先して選定すること
-- **推奨事項**: セキュリティパッチの適用計画を含める
+## 作成の進め方
 
-### 6. 記述ルール
+1. アーキテクチャドキュメント（バックエンド・フロントエンド・インフラ）を確認する
+2. 各レイヤーに最適な技術を選定し、選定理由を記録する
+3. 表形式で `docs/design/tech_stack.md` として出力する
 
-タスク項目などは一行開けて記述する。
+## 途中から再開する場合
 
-OK:
+既存の `docs/design/tech_stack.md` がある場合は、まずその内容を確認する。追加が必要な技術や、バージョン更新が必要な部分のみを修正する。
 
-```markdown
-**受入条件**:
+**Example:**
 
-- [ ] 技術スタック一覧が作成されている
-- [ ] バージョン情報が記載されている
 ```
-
-NG:
-
-```markdown
-**受入条件**:
-- [ ] 技術スタック一覧が作成されている
-- [ ] バージョン情報が記載されている
+ユーザー: 「バックエンドの技術スタックは決めた。フロントエンドを選定したい」
+回答: 既存の tech_stack.md のバックエンド技術を確認し、
+      バックエンド API との連携を考慮してフロントエンド技術を選定する。
+      フレームワーク→状態管理→UI ライブラリ→テスト→ビルドの順で選定する。
 ```
 
-## Examples
-
-### アーキテクチャに基づく技術スタック選定
+## 注意事項
 
-1. アーキテクチャドキュメントを読み込む
-2. 各レイヤーに最適な技術を選定
-3. 表形式で技術スタック一覧を作成
+- アーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
+- LTS バージョンを優先し、セキュリティパッチの適用計画を含める
+- 既存プロジェクトの場合は `package.json` や `pom.xml` を確認し、現状を把握してから提案する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
 
-### 既存技術スタックの整理
+## 関連スキル
 
-1. `package.json` や `pom.xml` を確認
-2. 現在の技術スタックを整理し最新化提案を作成
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+- `analyzing-architecture` — 前段のアーキテクチャ設計（技術選定の基盤）
+- `analyzing-test-strategy` — テストフレームワーク選定との整合性
+- `managing-operations` — 選定技術の環境構築

package/lib/assets/.claude/skills/analyzing-test-strategy/SKILL.md

@@ -1,87 +1,89 @@
 ---
 name: analyzing-test-strategy
-description: テスト戦略を策定。テストピラミッド設計、テスト種別の定義、カバレッジ目標の設定。テスト計画や品質戦略の検討時に使用。
+description: テストピラミッド設計、テスト種別の定義、カバレッジ目標の設定を含むテスト戦略を策定。「テスト戦略を決めたい」「テスト計画を立てたい」「カバレッジ目標を設定したい」「テストピラミッドを設計したい」「TDD/BDD の方針を決めたい」といった場面で発動する。テスト戦略を先に策定することで、開発中の「何をどこまでテストすべきか」の迷いを排除する。
 ---
 
-# テスト戦略策定支援
+# テスト戦略策定
 
-ピラミッド型・ダイヤモンド型・逆ピラミッド型テストの選択を支援します。
+アーキテクチャパターンに適合するテスト形状（ピラミッド型・ダイヤモンド型・逆ピラミッド型）を選択し、テスト戦略を策定する。
 
-## Instructions
+テスト戦略はアーキテクチャと表裏一体。レイヤードアーキテクチャならピラミッド型、マイクロサービスならダイヤモンド型が適合しやすい。テスト形状を間違えると、テストの実行時間が爆発するか、品質保証が不十分になる。
 
-### 1. 参照ドキュメント
+## 参照ドキュメントとテンプレート
 
-- @docs/reference/テスト戦略ガイド.md - テスト戦略の進め方
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/テスト戦略ガイド.md | テスト戦略の進め方詳細 |
+| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
+| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
+| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
+| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
+| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
+| 成果物 | `docs/design/test_strategy.md` | テスト戦略 |
 
-### 2. 入力
+## テスト形状の選択
 
-- @docs/requirements/requirements_definition.md - 要件定義
-- @docs/requirements/business_usecase.md - ビジネスユースケース
-- @docs/requirements/system_usecase.md - システムユースケース
-- @docs/requirements/user_story.md - ユーザーストーリー
-- @docs/design/architecture_backend.md - バックエンドアーキテクチャ
-- @docs/design/architecture_frontend.md - フロントエンドアーキテクチャ
+アーキテクチャパターンとシステム特性に基づいてテスト形状を選択する。形状の選択理由を明記せよ。
 
-### 3. 成果物
+- **ピラミッド型（ユニット重視）**: ビジネスロジックが複雑でドメイン層が厚い場合に適する。ユニットテストを土台に高速なフィードバックを得る
+- **ダイヤモンド型（統合テスト重視）**: マイクロサービスや外部連携が多い場合に適する。サービス間の結合点を重点的にテストする
+- **逆ピラミッド型（E2E 重視）**: UI 中心のアプリケーションやレガシーシステムの保護に適する。ただし実行時間とメンテナンスコストが高いことを認識せよ
 
-- @docs/design/test_strategy.md - テスト戦略
+## テストレベルの定義
 
-### 4. 作業内容
+各テストレベルの責務を明確に定義する。テストレベル間で検証内容が重複すると、テストスイート全体の実行時間が不必要に増える。
 
-#### テスト形状の選択
+- **ユニットテスト**: 単一クラス/関数の振る舞いを検証する。外部依存はモックする
+- **統合テスト**: コンポーネント間の連携を検証する。DB やメッセージキューとの結合を含む
+- **E2E テスト**: ユーザーシナリオに基づいてシステム全体を検証する
+- **受け入れテスト**: ユーザーストーリーの受入条件を検証する
 
-- ピラミッド型（ユニット重視）
-- ダイヤモンド型（統合テスト重視）
-- 逆ピラミッド型（E2E 重視）
+## テスト戦略の策定
 
-#### テストレベルの定義
+具体的な数値目標とツール選定を行う。曖昧な「十分にテストする」ではなく、測定可能な基準を設定せよ。
 
-- ユニットテスト
-- 統合テスト
-- E2E テスト
-- 受け入れテスト
+- **カバレッジ目標**: テストレベルごとのカバレッジ目標を設定する（例: ユニット 80%、統合 60%）
+- **テストツールの選定**: 技術スタックに適合するテストツールを選定する
+- **CI/CD との連携**: テスト実行のタイミングと失敗時の振る舞いを定義する
 
-#### テスト戦略の策定
+## トレーサビリティの確保
 
-- カバレッジ目標
-- テストツールの選定
-- CI/CD との連携
+要件からテストケースまでの追跡を可能にする。「この機能はどのテストで保証されているか」を常に回答可能にせよ。
 
-#### トレーサビリティの確保
+- **要件とテストケースのマッピング**: ユーザーストーリーの受入条件とテストケースを対応づける
 
-- 要件とテストケースのマッピング
+## 作成の進め方
 
-### 5. 注意事項
+1. アーキテクチャドキュメント（バックエンド・フロントエンド）を確認する
+2. @docs/reference/テスト戦略ガイド.md を読み込む
+3. テスト形状→テストレベル→カバレッジ目標→ツール選定の順に策定する
+4. `docs/design/test_strategy.md` として出力する
 
-- **前提条件**: アーキテクチャ設計が完了していること
-- **制限事項**: テスト戦略はアーキテクチャパターンに適合させること
-- **推奨事項**: TDD/BDD の適用を検討する
+## 途中から再開する場合
 
-### 6. 記述ルール
+既存の `docs/design/test_strategy.md` がある場合は、まずその内容を確認する。不足しているテストレベルの定義や更新が必要な部分のみを修正する。
 
-タスク項目などは一行開けて記述する。
+**Example:**
 
-OK:
-
-```markdown
-**受入条件**:
-
-- [ ] テスト形状が選択されている
-- [ ] カバレッジ目標が設定されている
 ```
-
-NG:
-
-```markdown
-**受入条件**:
-- [ ] テスト形状が選択されている
-- [ ] カバレッジ目標が設定されている
+ユーザー: 「テスト形状はピラミッド型に決めた。カバレッジ目標を設定したい」
+回答: 既存の test_strategy.md のテスト形状を確認し、
+      ピラミッド型に基づいてテストレベルごとのカバレッジ目標を設定する。
+      ユニット→統合→E2E の順に目標値と測定方法を定義する。
 ```
 
-## Examples
+## 注意事項
+
+- アーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
+- テスト戦略はアーキテクチャパターンに適合させる。パターンとの不整合は無駄なテストを生む
+- TDD/BDD の適用を検討し、開発プロセスとテスト戦略を一体化する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
 
-### アーキテクチャに適したテスト戦略の策定
+## 関連スキル
 
-1. バックエンド・フロントエンドのアーキテクチャを読み込む
-2. @docs/reference/テスト戦略ガイド.md に基づいてテスト戦略を策定
-3. テスト形状、テストレベル、カバレッジ目標を定義
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+- `analyzing-architecture` — テスト形状選択の基盤となるアーキテクチャ設計
+- `analyzing-tech-stack` — テストツール選定との整合性
+- `analyzing-non-functional` — 性能テストの基準となる非機能要件

package/lib/assets/.claude/skills/analyzing-ui-design/SKILL.md

@@ -1,86 +1,80 @@
 ---
 name: analyzing-ui-design
-description: UI 設計を支援。画面遷移図、画面イメージ、コンポーネント設計。UI/UX 設計やフロントエンド画面の検討時に使用。
+description: PlantUML を使用した画面遷移図・画面イメージ（salt 図）の作成と UI 設計を支援。「画面設計をしたい」「画面遷移図を作りたい」「UI を設計したい」「ワイヤーフレームを作りたい」「画面一覧を整理したい」といった場面で発動する。UI を先に設計することで、フロントエンド実装時の「画面が決まっていない」手戻りを防ぐ。
 ---
 
-# UI 設計支援
+# UI 設計
 
-画面遷移図と画面イメージを PlantUML で設計します。
+PlantUML のステートチャート図（画面遷移）と salt 図（画面イメージ）を使用して UI を設計する。
 
-## Instructions
+UI 設計はユーザーとシステムの接点を定義する活動。ユースケースが「何ができるか」を定義するのに対し、UI 設計は「どのように操作するか」を定義する。画面遷移と画面レイアウトを先に決めることで、フロントエンド実装の方向性が確定する。
 
-### 1. 参照ドキュメント
+## 参照ドキュメントとテンプレート
 
-- @docs/reference/UI設計ガイド.md - UI 設計の進め方
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/UI設計ガイド.md | UI 設計の進め方詳細 |
+| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
+| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
+| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
+| 入力 | @docs/design/architecture_backend.md | バックエンドアーキテクチャ |
+| 入力 | @docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
+| 成果物 | `docs/design/ui_design.md` | UI 設計 |
 
-### 2. 入力
+## 画面一覧作成
 
-- @docs/requirements/requirements_definition.md - 要件定義
-- @docs/requirements/business_usecase.md - ビジネスユースケース
-- @docs/requirements/system_usecase.md - システムユースケース
-- @docs/requirements/user_story.md - ユーザーストーリー
-- @docs/design/architecture_backend.md - バックエンドアーキテクチャ
-- @docs/design/architecture_frontend.md - フロントエンドアーキテクチャ
+ユースケースから必要な画面を網羅的に識別する。画面の漏れはフロントエンド実装の後半で発覚しやすいため、この段階で徹底的に洗い出せ。
 
-### 3. 成果物
+- **ユースケースからの画面識別**: 各ユースケースのアクターが操作する画面を列挙する
+- **画面の目的と機能の定義**: 各画面で「何を見る」「何を操作する」を明確にする
 
-- @docs/design/ui_design.md - UI 設計
+## 画面遷移図作成
 
-### 4. 作業内容
+PlantUML のステートチャート図を使用して画面間の遷移を定義する。遷移条件（ボタンクリック、バリデーション成功等）を必ず明記せよ。
 
-#### 画面一覧作成
+## 画面イメージ作成
 
-- ユースケースから必要な画面を識別
-- 画面の目的と機能を定義
+PlantUML の salt 図を使用して画面レイアウトを定義する。入力項目・ボタン・表示項目の配置を決定する。ピクセル単位の精度は不要だが、情報の優先順位とグルーピングを正確に表現せよ。
 
-#### 画面遷移図作成
+## インタラクション設計
 
-- PlantUML のステートチャート図を使用
-- 画面間の遷移条件を定義
+ユーザー操作フローとシステムのフィードバックを定義する。エラー時のユーザー体験は正常時以上に重要。
 
-#### 画面イメージ作成
+- **ユーザー操作フローの定義**: 主要な操作シナリオをステップバイステップで記述する
+- **エラー処理・フィードバックの設計**: バリデーションエラー、通信エラー、タイムアウト時の表示と回復方法を定義する
 
-- PlantUML の salt 図を使用
-- 入力項目・ボタン・表示項目のレイアウト
+## 作成の進め方
 
-#### インタラクション設計
+1. 入力ドキュメント（ユーザーストーリー、フロントエンドアーキテクチャ）を確認する
+2. @docs/reference/UI設計ガイド.md を読み込む
+3. 画面一覧→画面遷移図→画面イメージ→インタラクション設計の順に作成する
+4. `docs/design/ui_design.md` として出力する
 
-- ユーザー操作フローの定義
-- エラー処理・フィードバックの設計
+## 途中から再開する場合
 
-### 5. 注意事項
+既存の `docs/design/ui_design.md` がある場合は、まずその内容を確認する。不足している画面や更新が必要な遷移のみを修正する。
 
-- **前提条件**: 要件定義とユースケースが完了していること
-- **制限事項**:
-  - 画面遷移には PlantUML のステートチャート図を使用すること
-  - 画面イメージには PlantUML の salt 図を使用すること
-- **推奨事項**: ユーザビリティを考慮し、一貫性のある UI を設計する
+**Example:**
 
-### 6. 記述ルール
-
-タスク項目などは一行開けて記述する。
-
-OK:
-
-```markdown
-**受入条件**:
-
-- [ ] 画面一覧が作成されている
-- [ ] 画面遷移図が作成されている
 ```
-
-NG:
-
-```markdown
-**受入条件**:
-- [ ] 画面一覧が作成されている
-- [ ] 画面遷移図が作成されている
+ユーザー: 「画面一覧は作った。画面遷移図を作りたい」
+回答: 既存の ui_design.md の画面一覧を確認し、
+      各画面間の遷移を PlantUML ステートチャート図で定義する。
+      遷移条件（ボタン操作・バリデーション結果）を明記する。
 ```
 
-## Examples
+## 注意事項
+
+- 要件定義とユースケースが完了していることが前提。未完了でも進めて構わない
+- 画面遷移には PlantUML のステートチャート図、画面イメージには PlantUML の salt 図を使用する
+- ユーザビリティを考慮し、一貫性のある UI を設計する。操作パターンの統一が使いやすさの基本
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
 
-### ユーザーストーリーに基づく画面設計
+## 関連スキル
 
-1. ユーザーストーリーとフロントエンドアーキテクチャを読み込む
-2. @docs/reference/UI設計ガイド.md に基づいて設計
-3. 画面一覧、画面遷移図、画面イメージを作成
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+- `analyzing-usecases` — 入力となるユースケース・ユーザーストーリー
+- `analyzing-architecture` — フロントエンドアーキテクチャとの整合性
+- `developing-frontend` — 後続のフロントエンド TDD 実装