@k2works/claude-code-booster 3.5.0 → 3.6.0

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

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

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

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

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

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