@k2works/claude-code-booster 0.22.0 → 1.0.0

package/lib/assets/.claude/commands/analysis.md

@@ -1,103 +0,0 @@
-## Analysis Command
-
-分析フェーズ全体の作業を支援するコマンド。要件定義から非機能要件まで包括的な分析ワークフローを表示します。
-
-### 使い方
-
-```bash
-/analysis
-```
-
-### 基本例
-
-```bash
-# 分析フェーズ全体のワークフロー表示
-/analysis
-「分析フェーズの全体的な進め方と各工程の説明」
-```
-
-### 詳細機能
-
-#### 分析フェーズの全体像
-
-分析フェーズは以下の工程で構成されます：
-
-1. **要件定義** (`/analysis-requirements`)
-   - システム価値の明確化
-   - システム外部環境の分析
-   - システム境界の定義
-
-2. **ユースケース作成** (`/analysis-usecases`)
-   - ビジネスユースケースの抽出
-   - システムユースケースの定義
-   - ユーザーストーリーの作成
-
-3. **アーキテクチャ設計** (`/analysis-architecture`)
-   - バックエンドアーキテクチャ
-   - フロントエンドアーキテクチャ
-   - インフラストラクチャアーキテクチャ
-
-4. **データモデル設計** (`/analysis-data-model`)
-   - ER 図の作成
-   - テーブル定義
-
-5. **ドメインモデル設計** (`/analysis-domain-model`)
-   - エンティティ定義
-   - 値オブジェクト定義
-   - 集約の設計
-
-6. **UI 設計** (`/analysis-ui-design`)
-   - 画面遷移図
-   - 画面イメージ
-
-7. **テスト戦略** (`/analysis-test-strategy`)
-   - テストピラミッド設計
-   - テスト種別の定義
-
-8. **非機能要件** (`/analysis-non-functional`)
-   - 性能要件
-   - セキュリティ要件
-
-9. **運用要件** (`/analysis-operation`)
-   - 運用フロー
-   - 監視設計
-
-10. **技術スタック** (`/analysis-tech-stack`)
-    - 技術選定
-    - バージョン管理
-
-### Claude との連携
-
-```bash
-# プロジェクト情報の確認後に分析開始
-ls -la docs/
-cat README.md
-/analysis
-「プロジェクトの現状を踏まえた分析フェーズの進め方を提案」
-```
-
-### 注意事項
-
-- **前提条件**: プロジェクトの基本的な背景情報の把握が必要
-- **制限事項**: 分析結果は開発フェーズで継続的に見直し・改善が必要
-- **推奨事項**: 各工程の成果物を文書化し、チーム内で共有することを推奨
-
-### ベストプラクティス
-
-1. **段階的分析**: 要件定義から始めて段階的に詳細化する
-2. **チーム連携**: 分析結果をチーム全体で共有し、合意形成を行う
-3. **継続的改善**: 開発フェーズでのフィードバックを基に分析結果を見直す
-4. **文書化**: 分析結果は PlantUML や Markdown で視覚的に文書化する
-
-### 関連コマンド
-
-- `/analysis-requirements` : 要件定義関連の作業支援
-- `/analysis-usecases` : ユースケース・ユーザーストーリー作成支援
-- `/analysis-architecture` : アーキテクチャ設計支援
-- `/analysis-data-model` : データモデル設計支援
-- `/analysis-domain-model` : ドメインモデル設計支援
-- `/analysis-ui-design` : UI 設計支援
-- `/analysis-test-strategy` : テスト戦略策定支援
-- `/analysis-non-functional` : 非機能要件定義支援
-- `/analysis-operation` : 運用要件定義支援
-- `/analysis-tech-stack` : 技術スタック選定支援

package/lib/assets/.claude/commands/dev-backend.md

@@ -1,144 +0,0 @@
-## Backend Development Guide Reference
-
-バックエンド開発のためのコーディングとテストガイドを参照し、TDD サイクルに従った開発を支援します。
-
-### 使い方
-
-```bash
-/dev-backend [オプション]
-```
-
-### オプション
-
-- なし : ガイド全体の要約と TDD サイクルの説明
-- `--tdd` : TDD の Red-Green-Refactor サイクルの詳細
-- `--approach` : インサイドアウト/アウトサイドインアプローチの選択指針
-- `--checklist` : コミット前の品質チェックリスト表示
-- `--refactor` : リファクタリングパターンの一覧
-- `--test` : テスト作成のベストプラクティス
-
-### 基本例
-
-```bash
-# TDD サイクルの開始
-/dev-backend --tdd
-「現在のタスクに対して Red-Green-Refactor サイクルを開始」
-
-# アプローチ戦略の確認
-/dev-backend --approach
-「実装アプローチ（インサイドアウト/アウトサイドイン）の選択を支援」
-
-# 品質チェックの実行
-/dev-backend --checklist
-「コミット前の必須確認事項を順次実行」
-
-# リファクタリング支援
-/dev-backend --refactor
-「現在のコードに適用可能なリファクタリングパターンを提案」
-```
-
-### 詳細機能
-
-#### TDD サイクルの実践
-
-Red-Green-Refactor サイクルを厳密に実行：
-
-1. **Red フェーズ**: 失敗するテストを最初に書く
-2. **Green フェーズ**: テストを通す最小限のコードを実装
-3. **Refactor フェーズ**: 重複を除去し設計を改善
-4. @docs/reference/コーディングとテストガイド.md のワークフローに従う
-
-```bash
-# 新機能の TDD 実装開始
-/dev-backend --tdd
-「User エンティティのテストから開始します」
-```
-
-#### 参照ドキュメント
-
-- @docs/design/architecture_backend.md を参照
-- @docs/design/data-model.md を参照
-- @docs/design/domain-model.md を参照
-- @docs/design/tech_stack.md を参照
-- @docs/design/test_strategy.md を参照
-- 作業完了後に対象のイテレーション @docs/development/iteration_plan-N.md の進捗を更新する
-
-#### アプローチ戦略の選択
-
-プロジェクトの状態に応じた最適なアプローチを選択：
-
-- **インサイドアウト**: データ層から開始し上位層へ展開（推奨）
-- **アウトサイドイン**: API から開始しドメインロジックを段階的に実装
-
-### テストコマンド
-
-```bash
-# 全テスト実行
-cd apps/backend && ./gradlew test
-
-# 特定テストクラス実行
-cd apps/backend && ./gradlew test --tests "UserServiceTest"
-
-# テストカバレッジ確認
-cd apps/backend && ./gradlew jacocoTestReport
-```
-
-### API ドキュメント
-
-バックエンドには Swagger UI が組み込まれており、API ドキュメントをブラウザで確認できます。
-
-```bash
-# バックエンドを起動
-cd apps/backend && ./gradlew bootRun
-
-# ブラウザでアクセス
-# Swagger UI: http://localhost:8080/swagger-ui.html
-# OpenAPI JSON: http://localhost:8080/v3/api-docs
-# OpenAPI YAML: http://localhost:8080/api-docs.yaml
-```
-
-#### Swagger UI の機能
-
-- **API 仕様の確認**: 全エンドポイントの詳細を表示
-- **リクエスト実行**: ブラウザから直接 API をテスト
-- **認証サポート**: JWT トークンを設定して認証付き API をテスト
-- **スキーマ確認**: リクエスト/レスポンスの型定義を確認
-
-### Claude との連携
-
-```bash
-# 現在のコードを分析してリファクタリング提案
-cat apps/backend/src/main/java/com/example/User.java
-/dev-backend --refactor
-「このクラスに適用可能なリファクタリングパターンを分析」
-
-# テストカバレッジを確認してテスト追加
-cd apps/backend && ./gradlew jacocoTestReport
-/dev-backend --test
-「カバレッジが低い箇所のテストを追加」
-
-# コミット前の品質確認
-git status
-/dev-backend --checklist
-「全ての品質基準を満たすまで確認を実行」
-```
-
-### 注意事項
-
-- **前提条件**: Java/Gradle のテスト環境が設定済みであること
-- **制限事項**: TDD の三原則を厳密に守る（テストなしでプロダクションコードを書かない）
-- **推奨事項**: コミット前に必ず品質チェックリストを実行
-
-### ベストプラクティス
-
-1. **TODO 駆動開発**: タスクを細かい TODO に分割してから実装開始
-2. **小さなサイクル**: Red-Green-Refactor を 10-15 分で完了させる
-3. **継続的コミット**: 各サイクル完了時に動作する状態でコミット
-4. **Rule of Three**: 同じコードが 3 回現れたらリファクタリング
-
-### 関連コマンド
-
-- `/dev-frontend` : フロントエンド開発ガイド
-- `/task` : タスク管理と TODO リストの作成
-- `/review` : コードレビューの実施
-- `/test` : テスト実行と結果確認

package/lib/assets/.claude/commands/dev-frontend.md

@@ -1,126 +0,0 @@
-## Frontend Development Guide Reference
-
-フロントエンド開発のためのコーディングとテストガイドを参照し、TDD サイクルに従った開発を支援します。
-
-### 使い方
-
-```bash
-/dev-frontend [オプション]
-```
-
-### オプション
-
-- なし : ガイド全体の要約と TDD サイクルの説明
-- `--tdd` : TDD の Red-Green-Refactor サイクルの詳細
-- `--approach` : インサイドアウト/アウトサイドインアプローチの選択指針
-- `--checklist` : コミット前の品質チェックリスト表示
-- `--refactor` : リファクタリングパターンの一覧
-- `--test` : テスト作成のベストプラクティス
-
-### 基本例
-
-```bash
-# TDD サイクルの開始
-/dev-frontend --tdd
-「現在のタスクに対して Red-Green-Refactor サイクルを開始」
-
-# アプローチ戦略の確認
-/dev-frontend --approach
-「実装アプローチ（インサイドアウト/アウトサイドイン）の選択を支援」
-
-# 品質チェックの実行
-/dev-frontend --checklist
-「コミット前の必須確認事項を順次実行」
-
-# リファクタリング支援
-/dev-frontend --refactor
-「現在のコードに適用可能なリファクタリングパターンを提案」
-```
-
-### 詳細機能
-
-#### TDD サイクルの実践
-
-Red-Green-Refactor サイクルを厳密に実行：
-
-1. **Red フェーズ**: 失敗するテストを最初に書く
-2. **Green フェーズ**: テストを通す最小限のコードを実装
-3. **Refactor フェーズ**: 重複を除去し設計を改善
-4. @docs/reference/コーディングとテストガイド.md のワークフローに従う
-
-```bash
-# 新機能の TDD 実装開始
-/dev-frontend --tdd
-「LoginForm コンポーネントのテストから開始します」
-```
-
-#### 参照ドキュメント
-
-- @docs/design/architecture_frontend.md を参照
-- @docs/design/ui-design.md を参照
-- @docs/design/tech_stack.md を参照
-- @docs/design/test_strategy.md を参照
-- 作業完了後に対象のイテレーション @docs/development/iteration_plan-N.md の進捗を更新する
-
-#### アプローチ戦略の選択
-
-プロジェクトの状態に応じた最適なアプローチを選択：
-
-- **アウトサイドイン**: UI から開始しロジックを段階的に実装（推奨）
-- **インサイドアウト**: ユーティリティ/hooks から開始し上位層へ展開
-
-### テストコマンド
-
-```bash
-# 全テスト実行
-cd apps/frontend && npm run test
-
-# ウォッチモードでテスト実行
-cd apps/frontend && npm run test:watch
-
-# テストカバレッジ確認
-cd apps/frontend && npm run test:coverage
-
-# E2E テスト実行
-cd apps/frontend && npm run test:e2e
-```
-
-### Claude との連携
-
-```bash
-# 現在のコードを分析してリファクタリング提案
-cat apps/frontend/src/components/User.tsx
-/dev-frontend --refactor
-「このコンポーネントに適用可能なリファクタリングパターンを分析」
-
-# テストカバレッジを確認してテスト追加
-cd apps/frontend && npm run test:coverage
-/dev-frontend --test
-「カバレッジが低い箇所のテストを追加」
-
-# コミット前の品質確認
-git status
-/dev-frontend --checklist
-「全ての品質基準を満たすまで確認を実行」
-```
-
-### 注意事項
-
-- **前提条件**: Node.js/npm のテスト環境が設定済みであること
-- **制限事項**: TDD の三原則を厳密に守る（テストなしでプロダクションコードを書かない）
-- **推奨事項**: コミット前に必ず品質チェックリストを実行
-
-### ベストプラクティス
-
-1. **TODO 駆動開発**: タスクを細かい TODO に分割してから実装開始
-2. **小さなサイクル**: Red-Green-Refactor を 10-15 分で完了させる
-3. **継続的コミット**: 各サイクル完了時に動作する状態でコミット
-4. **Rule of Three**: 同じコードが 3 回現れたらリファクタリング
-5. **コンポーネント分割**: 単一責任の原則に従いコンポーネントを小さく保つ
-
-### 関連コマンド
-
-- `/dev-backend` : バックエンド開発ガイド
-- `/task` : タスク管理と TODO リストの作成
-- `/review` : コードレビューの実施
-- `/test` : テスト実行と結果確認

package/lib/assets/.claude/commands/docs.md

@@ -1,335 +0,0 @@
-## Docs Command
-
-設計ドキュメントの一覧表示、進捗確認、内容参照を行うコマンド。
-
-### 使い方
-
-```bash
-/docs [オプション]
-```
-
-### オプション
-
-- なし : ドキュメント一覧と進捗状況を表示
-- `--list` : ドキュメント一覧のみを表示
-- `--status` : ドキュメントの作成状況を詳細表示
-- `--read <ファイル名>` : 指定したドキュメントの内容を表示
-- `--summary` : 全ドキュメントの概要を表示
-- `--update` : `docs/index.md` と `mkdocs.yml` を現在のドキュメント構成に合わせて更新
-- `--update-index` : `docs/index.md` のみを更新
-- `--update-mkdocs` : `mkdocs.yml` のみを更新
-- `--lint` : Markdown フォーマットをチェックし、違反を自動修正
-
-### 基本例
-
-```bash
-# ドキュメント一覧と進捗確認
-/docs
-「設計ドキュメントの一覧と作成状況を確認」
-
-# 一覧のみ表示
-/docs --list
-「docs/design/ と docs/requirements/ のファイル一覧を表示」
-
-# 詳細な進捗状況
-/docs --status
-「各ドキュメントの完成度や更新日時を含む詳細情報を表示」
-
-# 特定ドキュメントの参照
-/docs --read tech_stack
-「技術スタック選定ドキュメントの内容を表示」
-
-# 全ドキュメントの概要
-/docs --summary
-「全ドキュメントの目的と主要な内容を要約表示」
-
-# docs/index.md と mkdocs.yml を更新
-/docs --update
-「現在のドキュメント構成に合わせて両ファイルを更新」
-
-# docs/index.md のみ更新
-/docs --update-index
-「docs/index.md を現在のドキュメント構成に合わせて更新」
-
-# mkdocs.yml のみ更新
-/docs --update-mkdocs
-「mkdocs.yml の nav セクションを現在のドキュメント構成に合わせて更新」
-
-# Markdown フォーマットをチェック・修正
-/docs --lint
-「タスク項目の前に空行がないなどのフォーマット違反を検出し自動修正」
-```
-
-### 詳細機能
-
-#### ドキュメント構成
-
-本プロジェクトのドキュメントは以下の構成で管理されています：
-
-**要件定義ドキュメント** (`docs/requirements/`)
-- `requirements_definition.md` : 要件定義書（RDRA 2.0）
-- `business_usecase.md` : ビジネスユースケース
-- `system_usecase.md` : システムユースケース
-- `user_story.md` : ユーザーストーリー
-
-**設計ドキュメント** (`docs/design/`)
-- `architecture_backend.md` : バックエンドアーキテクチャ
-- `architecture_frontend.md` : フロントエンドアーキテクチャ
-- `architecture_infrastructure.md` : インフラストラクチャ
-- `data-model.md` : データモデル設計
-- `domain-model.md` : ドメインモデル設計
-- `ui-design.md` : UI 設計
-- `test_strategy.md` : テスト戦略
-- `non_functional.md` : 非機能要件
-- `operation.md` : 運用要件
-- `tech_stack.md` : 技術スタック選定
-
-#### ドキュメント参照
-
-以下のコマンドで特定のドキュメントを参照できます：
-
-```bash
-# 技術スタックを参照
-/docs --read tech_stack
-
-# アーキテクチャを参照
-/docs --read architecture_backend
-
-# 要件定義を参照
-/docs --read requirements_definition
-```
-
-#### ドキュメント更新機能
-
-`--update` オプションを使用すると、現在のドキュメント構成に合わせて `docs/index.md` と `mkdocs.yml` を自動更新できます。
-
-**docs/index.md の更新内容**:
-- ドキュメント一覧をカテゴリ別に整理
-- 各ドキュメントへのリンクと説明を生成
-- 「まずこれを読もうリスト」形式で構成
-
-**mkdocs.yml の更新内容**:
-- `nav` セクションを現在のドキュメント構成に合わせて更新
-- 要件定義、設計、開発、運用などのカテゴリで階層化
-- 新しいドキュメントを自動的にナビゲーションに追加
-
-```bash
-# 更新前に差分を確認
-/docs --status
-「現在のドキュメント構成を確認」
-
-# 両ファイルを更新
-/docs --update
-「docs/index.md と mkdocs.yml を更新」
-```
-
-#### Lint 機能
-
-`--lint` オプションを使用すると、Markdown ドキュメントのフォーマットをチェックし、違反を自動修正できます。
-
-**チェックルール**:
-
-- タスク項目（リスト）の前には空行が必要
-- 番号付きリストのサブリスト前にも空行が必要
-- コロンで終わる行の直後にリストがある場合も空行が必要
-- 太字ラベル（半角・全角コロン両方）の直後にリストがある場合も空行が必要
-
-**NG 例 1** - ラベルの直後にリスト:
-
-```markdown
-**受入条件**:
-- [ ] ログアウトボタンをクリックするとログアウトできる
-- [ ] ログアウト後、ログイン画面に遷移する
-```
-
-**OK 例 1**:
-
-```markdown
-**受入条件**:
-
-- [ ] ログアウトボタンをクリックするとログアウトできる
-- [ ] ログアウト後、ログイン画面に遷移する
-```
-
-**NG 例 2** - 番号付きリストの直後にサブリスト:
-
-```markdown
-1. **対処**: SMB バージョンを確認
-   - コントロールパネル > ファイルサービス > SMB で設定
-```
-
-**OK 例 2**:
-
-```markdown
-1. **対処**: SMB バージョンを確認
-
-   - コントロールパネル > ファイルサービス > SMB で設定
-```
-
-**NG 例 3** - コロンで終わる行の直後にリスト:
-
-```markdown
-PMD はカスタム設定で以下をチェック：
-- マジックナンバーの使用
-- 空の catch ブロック
-- 循環複雑度が 7 を超えるメソッド
-```
-
-**OK 例 3**:
-
-```markdown
-PMD はカスタム設定で以下をチェック：
-
-- マジックナンバーの使用
-- 空の catch ブロック
-- 循環複雑度が 7 を超えるメソッド
-```
-
-**NG 例 4** - 太字ラベル（全角コロン）の直後にリスト:
-
-```markdown
-**タイプの種類：**
-- `feat`: 新機能の追加
-- `fix`: バグ修正
-```
-
-**OK 例 4**:
-
-```markdown
-**タイプの種類：**
-
-- `feat`: 新機能の追加
-- `fix`: バグ修正
-```
-
-**実行手順**:
-
-1. `docs/` 配下の全 Markdown ファイルをスキャン
-2. 上記ルールに違反する箇所を検出
-3. 違反箇所を自動修正
-4. 修正結果を報告
-
-```bash
-# Lint を実行
-/docs --lint
-「docs/ 配下の Markdown ファイルをチェックし、フォーマット違反を修正」
-```
-
-### 出力例
-
-```
-設計ドキュメント一覧
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-📁 docs/requirements/
-├─ ✅ requirements_definition.md (要件定義書)
-├─ ✅ business_usecase.md (ビジネスユースケース)
-├─ ✅ system_usecase.md (システムユースケース)
-└─ ✅ user_story.md (ユーザーストーリー)
-
-📁 docs/design/
-├─ ✅ architecture_backend.md (バックエンドアーキテクチャ)
-├─ ✅ architecture_frontend.md (フロントエンドアーキテクチャ)
-├─ ✅ architecture_infrastructure.md (インフラストラクチャ)
-├─ ✅ data-model.md (データモデル設計)
-├─ ✅ domain-model.md (ドメインモデル設計)
-├─ ✅ ui-design.md (UI 設計)
-├─ ✅ test_strategy.md (テスト戦略)
-├─ ✅ non_functional.md (非機能要件)
-├─ ✅ operation.md (運用要件)
-└─ ✅ tech_stack.md (技術スタック選定)
-
-進捗: 14/14 ドキュメント完成 (100%)
-```
-
-#### --update 実行時の出力例
-
-```
-ドキュメント更新
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-📝 docs/index.md を更新しています...
-   ✅ 要件定義セクションを追加
-   ✅ 設計ドキュメントセクションを追加
-   ✅ 開発ドキュメントセクションを追加
-   ✅ 運用ドキュメントセクションを追加
-
-📝 mkdocs.yml を更新しています...
-   ✅ nav セクションを更新
-   ✅ 14 件のドキュメントをナビゲーションに追加
-
-更新完了！
-```
-
-#### --lint 実行時の出力例
-
-```
-Markdown Lint
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-🔍 docs/ 配下をスキャン中...
-
-📄 docs/development/iteration_plan-1.md
-   ⚠️  Line 52: リストの前に空行がありません
-   ✅ 修正しました
-
-📄 docs/requirements/user_story.md
-   ⚠️  Line 128: リストの前に空行がありません
-   ⚠️  Line 156: リストの前に空行がありません
-   ✅ 2 箇所を修正しました
-
-結果: 14 ファイルをスキャン、2 ファイルで 3 箇所を修正
-```
-
-### Claude との連携
-
-```bash
-# ドキュメント状況確認後に分析
-/docs --status
-「不足しているドキュメントがあれば作成を提案」
-
-# 特定ドキュメントを参照して修正
-/docs --read tech_stack
-「技術スタックの内容を確認して改善点を提案」
-
-# 全体概要を確認してレビュー
-/docs --summary
-「ドキュメント全体の整合性をレビュー」
-
-# 新しいドキュメント作成後にインデックスを更新
-/docs --update
-「docs/index.md と mkdocs.yml を最新のドキュメント構成に同期」
-
-# MkDocs でドキュメントサイトをプレビュー
-/docs --update-mkdocs
-「mkdocs.yml を更新後、mkdocs serve でプレビュー確認」
-
-# ドキュメントのフォーマットをチェック・修正
-/docs --lint
-「Markdown フォーマットの一貫性を確保」
-```
-
-### 注意事項
-
-- **前提条件**: `docs/` ディレクトリが存在すること
-- **制限事項**: Markdown 形式のドキュメントのみ対応
-- **推奨事項**: 定期的にドキュメントの進捗を確認し、最新の状態を維持すること
-- **更新時の注意**: `--update` 実行前に現在の `docs/index.md` と `mkdocs.yml` をバックアップすることを推奨
-- **MkDocs 依存**: `--update-mkdocs` を使用する場合、MkDocs がインストールされている必要がある
-
-### ベストプラクティス
-
-1. **定期確認**: 開発フェーズ移行前にドキュメントの完成度を確認する
-2. **整合性維持**: コード変更時は関連ドキュメントも更新する
-3. **レビュー活用**: チームレビュー前にドキュメント概要を共有する
-4. **バージョン管理**: ドキュメントの変更は Git でコミットする
-5. **インデックス同期**: 新しいドキュメント作成後は `--update` でインデックスを同期する
-6. **プレビュー確認**: `--update-mkdocs` 後は `mkdocs serve` でナビゲーションを確認する
-7. **フォーマット統一**: コミット前に `--lint` でフォーマットの一貫性を確保する
-
-### 関連コマンド
-
-- `/analysis` : 分析フェーズ全体の作業支援
-- `/analysis-requirements` : 要件定義関連の作業支援
-- `/analysis-architecture` : アーキテクチャ設計支援
-- `/progress` : プロジェクト全体の進捗確認