@k2works/claude-code-booster 4.8.0 → 4.11.0

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

@@ -1,174 +1,174 @@
----
-name: analyzing-review
-description: 分析成果物のマルチパースペクティブレビューを実施。XP エージェント（プロダクトマネージャー、アーキテクト、インタラクションデザイナー、テスター、ユーザー代表）を並列起動し、専門的視点からフィードバックを収集・統合する。「分析ドキュメントをレビューしたい」「要件定義をレビューして」「アーキテクチャ設計のレビューをお願い」「設計ドキュメントにフィードバックがほしい」「分析結果を検証したい」「ユースケースをチェックして」といった場面で発動する。分析フェーズの成果物に対するレビュー依頼があれば積極的に使用すること。
----
-
-# 分析成果物レビュー
-
-分析フェーズの成果物（要件定義、アーキテクチャ設計、データモデル、ドメインモデル、UI 設計、テスト戦略、非機能要件、運用要件など）を複数の XP エージェントで並列レビューし、多角的なフィードバックを統合する。
-
-## レビューの価値
-
-分析成果物のレビューは、開発フェーズに入る前に問題を発見する最も効果的な手段。1 人の視点では見落としがちな矛盾や不足を、異なる専門性を持つエージェントが同時に検証することで、手戻りコストを大幅に削減できる。
-
-## レビューエージェント
-
-各エージェントは独自の専門的視点でレビューを行う。全エージェントを並列起動し、独立したフィードバックを収集する。
-
-| エージェント | 視点 | 着眼点 |
-|:---|:---|:---|
-| `xp-product-manager` | ビジネス価値 | 要件の完全性、ビジネス価値との整合性、ストーリーの INVEST 基準、優先順位の妥当性 |
-| `xp-architect` | 技術的実現性 | アーキテクチャの妥当性、非機能要件の実現可能性、技術的リスク、変更容易性 |
-| `xp-interaction-designer` | ユーザー体験 | UI/UX の一貫性、ユーザーの心理モデルとの整合、アクセシビリティ、画面遷移の自然さ |
-| `xp-tester` | テスト可能性 | 要件のテスト可能性、受入基準の明確さ、エッジケースの網羅性、テスト戦略との整合 |
-| `xp-user-representative` | 利用者視点 | 実際の業務での使いやすさ、業務フローとの整合性、ユーザーが本当に必要としている機能か |
-
-## レビュー対象と重点エージェント
-
-成果物の種類に応じて、特に重要なエージェントが異なる。ただし全エージェントを起動して多角的な視点を確保する。
-
-| 成果物 | 重点エージェント |
-|:---|:---|
-| 要件定義・ユースケース | xp-product-manager, xp-user-representative, xp-tester |
-| アーキテクチャ設計 | xp-architect, xp-tester |
-| データモデル・ドメインモデル | xp-architect, xp-product-manager |
-| UI 設計 | xp-interaction-designer, xp-user-representative |
-| テスト戦略 | xp-tester, xp-architect |
-| 非機能要件・運用要件 | xp-architect, xp-tester |
-
-## レビューワークフロー
-
-### 1. レビュー対象の特定
-
-レビュー対象のドキュメントを特定する。ユーザーが明示的に指定しない場合は `docs/design/` 配下を確認し、対象を提案する。
-
-### 2. エージェントの並列起動
-
-Agent ツールを使い、5 つのエージェントを **同一メッセージで並列起動** する。各エージェントには以下を指示する。
-
-```
-あなたは {エージェント名} です。
-.claude/agents/{エージェント名}.md の定義に従ってレビューしてください。
-
-## レビュー対象
-{ドキュメントパスとその内容の要約}
-
-## レビュー対象の種類
-{成果物カテゴリ: 要件定義 / アーキテクチャ設計 / データモデル / UI 設計 等}
-
-## レビュー観点
-{エージェント固有の着眼点}
-
-## 出力形式
-以下の形式でフィードバックを返してください：
-
-### 評価サマリー
-（1-2 文で全体評価）
-
-### 良い点
-- （具体的に）
-
-### 改善提案
-- 【重要度: 高/中/低】（具体的な改善提案と理由）
-
-### 懸念事項
-- （リスクや見落とされている観点）
-
-### スコープ外の発見
-- （レビュー対象外だが報告すべき問題）
-```
-
-#### Agent ツールが利用できない場合のフォールバック
-
-Agent ツールが利用できない環境では、5 つの視点を逐次的にシミュレートする。各エージェントの定義ファイル（`.claude/agents/{エージェント名}.md`）を読み、その視点でレビューを順次実施する。出力形式は同一のテンプレートに従う。
-
-### 3. フィードバックの統合
-
-全エージェントのフィードバックを受け取った後、以下の形式で統合レポートを作成する。
-
-```markdown
-## レビュー結果
-
-### レビュー対象
-- {ドキュメント名}
-
-### 総合評価
-（全エージェントの評価を統合した 2-3 文の評価）
-
-### 改善提案（重要度順）
-
-#### 高
-| # | 提案 | 指摘元 | 理由 |
-|---|------|--------|------|
-
-#### 中
-| # | 提案 | 指摘元 | 理由 |
-|---|------|--------|------|
-
-#### 低
-| # | 提案 | 指摘元 | 理由 |
-|---|------|--------|------|
-
-### 矛盾事項
-
-複数エージェントの指摘が相反する場合、ここに記載する。
-
-| # | 視点 A | 視点 B | 論点 | 推奨判断 |
-|---|--------|--------|------|----------|
-
-### エージェント別フィードバック詳細
-
-<details>
-<summary>xp-product-manager（高: N / 中: N / 低: N）</summary>
-（フィードバック全文）
-</details>
-
-<details>
-<summary>xp-architect（高: N / 中: N / 低: N）</summary>
-（フィードバック全文）
-</details>
-
-<details>
-<summary>xp-interaction-designer（高: N / 中: N / 低: N）</summary>
-（フィードバック全文）
-</details>
-
-<details>
-<summary>xp-tester（高: N / 中: N / 低: N）</summary>
-（フィードバック全文）
-</details>
-
-<details>
-<summary>xp-user-representative（高: N / 中: N / 低: N）</summary>
-（フィードバック全文）
-</details>
-```
-
-### 4. 改善アクションの提案
-
-統合レポートに基づき、具体的な改善アクションを提案する。改善は重要度「高」から着手することを推奨する。
-
-### 5. レビュー結果の保存
-
-統合レポートを `docs/review/{対象名}_review_{YYYYMMDD}.md` に保存する。過去のレビュー結果と比較できるようにし、改善のトレーサビリティを確保する。
-
-## レビュー完了条件
-
-以下をすべて満たした場合にレビュー完了とする。
-
-- 全エージェントのフィードバックが収集済み
-- 統合レポートが作成済み
-- 重要度「高」の指摘について対応方針（修正する / 許容する / 保留する）が決定済み
-- レビュー結果がドキュメントとして保存済み
-
-## 注意事項
-
-- レビューは成果物の品質向上が目的であり、批判が目的ではない
-- レビュー対象が複数ドキュメントにまたがる場合は、関連性の高いものをまとめてレビューする
-- TDD サイクルの遵守状況（テストが先に書かれているか）もレビュー観点に含める
-
-## 関連スキル
-
-- `orchestrating-analysis` — 分析フェーズの全体ワークフロー
-- `analyzing-*` — 各分析工程のスキル
-- `git-commit` — レビュー結果の保存後のコミット
+---
+name: analyzing-review
+description: 分析成果物のマルチパースペクティブレビューを実施。XP エージェント（プロダクトマネージャー、アーキテクト、インタラクションデザイナー、テスター、ユーザー代表）を並列起動し、専門的視点からフィードバックを収集・統合する。「分析ドキュメントをレビューしたい」「要件定義をレビューして」「アーキテクチャ設計のレビューをお願い」「設計ドキュメントにフィードバックがほしい」「分析結果を検証したい」「ユースケースをチェックして」といった場面で発動する。分析フェーズの成果物に対するレビュー依頼があれば積極的に使用すること。
+---
+
+# 分析成果物レビュー
+
+分析フェーズの成果物（要件定義、アーキテクチャ設計、データモデル、ドメインモデル、UI 設計、テスト戦略、非機能要件、運用要件など）を複数の XP エージェントで並列レビューし、多角的なフィードバックを統合する。
+
+## レビューの価値
+
+分析成果物のレビューは、開発フェーズに入る前に問題を発見する最も効果的な手段。1 人の視点では見落としがちな矛盾や不足を、異なる専門性を持つエージェントが同時に検証することで、手戻りコストを大幅に削減できる。
+
+## レビューエージェント
+
+各エージェントは独自の専門的視点でレビューを行う。全エージェントを並列起動し、独立したフィードバックを収集する。
+
+| エージェント | 視点 | 着眼点 |
+|:---|:---|:---|
+| `xp-product-manager` | ビジネス価値 | 要件の完全性、ビジネス価値との整合性、ストーリーの INVEST 基準、優先順位の妥当性 |
+| `xp-architect` | 技術的実現性 | アーキテクチャの妥当性、非機能要件の実現可能性、技術的リスク、変更容易性 |
+| `xp-interaction-designer` | ユーザー体験 | UI/UX の一貫性、ユーザーの心理モデルとの整合、アクセシビリティ、画面遷移の自然さ |
+| `xp-tester` | テスト可能性 | 要件のテスト可能性、受入基準の明確さ、エッジケースの網羅性、テスト戦略との整合 |
+| `xp-user-representative` | 利用者視点 | 実際の業務での使いやすさ、業務フローとの整合性、ユーザーが本当に必要としている機能か |
+
+## レビュー対象と重点エージェント
+
+成果物の種類に応じて、特に重要なエージェントが異なる。ただし全エージェントを起動して多角的な視点を確保する。
+
+| 成果物 | 重点エージェント |
+|:---|:---|
+| 要件定義・ユースケース | xp-product-manager, xp-user-representative, xp-tester |
+| アーキテクチャ設計 | xp-architect, xp-tester |
+| データモデル・ドメインモデル | xp-architect, xp-product-manager |
+| UI 設計 | xp-interaction-designer, xp-user-representative |
+| テスト戦略 | xp-tester, xp-architect |
+| 非機能要件・運用要件 | xp-architect, xp-tester |
+
+## レビューワークフロー
+
+### 1. レビュー対象の特定
+
+レビュー対象のドキュメントを特定する。ユーザーが明示的に指定しない場合は `docs/design/` 配下を確認し、対象を提案する。
+
+### 2. エージェントの並列起動
+
+Agent ツールを使い、5 つのエージェントを **同一メッセージで並列起動** する。各エージェントには以下を指示する。
+
+```
+あなたは {エージェント名} です。
+.claude/agents/{エージェント名}.md の定義に従ってレビューしてください。
+
+## レビュー対象
+{ドキュメントパスとその内容の要約}
+
+## レビュー対象の種類
+{成果物カテゴリ: 要件定義 / アーキテクチャ設計 / データモデル / UI 設計 等}
+
+## レビュー観点
+{エージェント固有の着眼点}
+
+## 出力形式
+以下の形式でフィードバックを返してください：
+
+### 評価サマリー
+（1-2 文で全体評価）
+
+### 良い点
+- （具体的に）
+
+### 改善提案
+- 【重要度: 高/中/低】（具体的な改善提案と理由）
+
+### 懸念事項
+- （リスクや見落とされている観点）
+
+### スコープ外の発見
+- （レビュー対象外だが報告すべき問題）
+```
+
+#### Agent ツールが利用できない場合のフォールバック
+
+Agent ツールが利用できない環境では、5 つの視点を逐次的にシミュレートする。各エージェントの定義ファイル（`.claude/agents/{エージェント名}.md`）を読み、その視点でレビューを順次実施する。出力形式は同一のテンプレートに従う。
+
+### 3. フィードバックの統合
+
+全エージェントのフィードバックを受け取った後、以下の形式で統合レポートを作成する。
+
+```markdown
+## レビュー結果
+
+### レビュー対象
+- {ドキュメント名}
+
+### 総合評価
+（全エージェントの評価を統合した 2-3 文の評価）
+
+### 改善提案（重要度順）
+
+#### 高
+| # | 提案 | 指摘元 | 理由 |
+|---|------|--------|------|
+
+#### 中
+| # | 提案 | 指摘元 | 理由 |
+|---|------|--------|------|
+
+#### 低
+| # | 提案 | 指摘元 | 理由 |
+|---|------|--------|------|
+
+### 矛盾事項
+
+複数エージェントの指摘が相反する場合、ここに記載する。
+
+| # | 視点 A | 視点 B | 論点 | 推奨判断 |
+|---|--------|--------|------|----------|
+
+### エージェント別フィードバック詳細
+
+<details>
+<summary>xp-product-manager（高: N / 中: N / 低: N）</summary>
+（フィードバック全文）
+</details>
+
+<details>
+<summary>xp-architect（高: N / 中: N / 低: N）</summary>
+（フィードバック全文）
+</details>
+
+<details>
+<summary>xp-interaction-designer（高: N / 中: N / 低: N）</summary>
+（フィードバック全文）
+</details>
+
+<details>
+<summary>xp-tester（高: N / 中: N / 低: N）</summary>
+（フィードバック全文）
+</details>
+
+<details>
+<summary>xp-user-representative（高: N / 中: N / 低: N）</summary>
+（フィードバック全文）
+</details>
+```
+
+### 4. 改善アクションの提案
+
+統合レポートに基づき、具体的な改善アクションを提案する。改善は重要度「高」から着手することを推奨する。
+
+### 5. レビュー結果の保存
+
+統合レポートを `docs/review/{対象名}_review_{YYYYMMDD}.md` に保存する。過去のレビュー結果と比較できるようにし、改善のトレーサビリティを確保する。
+
+## レビュー完了条件
+
+以下をすべて満たした場合にレビュー完了とする。
+
+- 全エージェントのフィードバックが収集済み
+- 統合レポートが作成済み
+- 重要度「高」の指摘について対応方針（修正する / 許容する / 保留する）が決定済み
+- レビュー結果がドキュメントとして保存済み
+
+## 注意事項
+
+- レビューは成果物の品質向上が目的であり、批判が目的ではない
+- レビュー対象が複数ドキュメントにまたがる場合は、関連性の高いものをまとめてレビューする
+- TDD サイクルの遵守状況（テストが先に書かれているか）もレビュー観点に含める
+
+## 関連スキル
+
+- `orchestrating-analysis` — 分析フェーズの全体ワークフロー
+- `analyzing-*` — 各分析工程のスキル
+- `git-commit` — レビュー結果の保存後のコミット

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` — 選定技術の環境構築