@k2works/claude-code-booster 0.16.2 → 0.18.0

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

@@ -23,13 +23,13 @@
 開発フェーズは以下の工程で構成されます：
 
 1. **バックエンド開発** (`/dev-backend`)
-   - Java/Kotlin での実装
-   - Gradle によるビルド・テスト
+   - 実装
+   - ビルド・テスト
    - インサイドアウトアプローチ推奨
 
 2. **フロントエンド開発** (`/dev-frontend`)
-   - TypeScript/React での実装
-   - npm によるビルド・テスト
+   - 実装
+   - ビルド・テスト
    - アウトサイドインアプローチ推奨
 
 #### TDD サイクルの実践
@@ -43,6 +43,7 @@ Red-Green-Refactor サイクルを厳密に実行：
 
 #### 参照ドキュメント
 
+- @docs/design/architecture.md を参照
 - @docs/design/architecture_backend.md を参照
 - @docs/design/architecture_frontend.md を参照
 - @docs/design/data-model.md を参照

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

@@ -18,6 +18,7 @@
 - `--update` : `docs/index.md` と `mkdocs.yml` を現在のドキュメント構成に合わせて更新
 - `--update-index` : `docs/index.md` のみを更新
 - `--update-mkdocs` : `mkdocs.yml` のみを更新
+- `--lint` : Markdown フォーマットをチェックし、違反を自動修正
 
 ### 基本例
 
@@ -53,6 +54,10 @@
 # mkdocs.yml のみ更新
 /docs --update-mkdocs
 「mkdocs.yml の nav セクションを現在のドキュメント構成に合わせて更新」
+
+# Markdown フォーマットをチェック・修正
+/docs --lint
+「タスク項目の前に空行がないなどのフォーマット違反を検出し自動修正」
 ```
 
 ### 詳細機能
@@ -118,6 +123,98 @@
 「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 ファイルをチェックし、フォーマット違反を修正」
+```
+
 ### 出力例
 
 ```
@@ -164,6 +261,26 @@
 更新完了！
 ```
 
+#### --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
@@ -186,6 +303,10 @@
 # MkDocs でドキュメントサイトをプレビュー
 /docs --update-mkdocs
 「mkdocs.yml を更新後、mkdocs serve でプレビュー確認」
+
+# ドキュメントのフォーマットをチェック・修正
+/docs --lint
+「Markdown フォーマットの一貫性を確保」
 ```
 
 ### 注意事項
@@ -204,6 +325,7 @@
 4. **バージョン管理**: ドキュメントの変更は Git でコミットする
 5. **インデックス同期**: 新しいドキュメント作成後は `--update` でインデックスを同期する
 6. **プレビュー確認**: `--update-mkdocs` 後は `mkdocs serve` でナビゲーションを確認する
+7. **フォーマット統一**: コミット前に `--lint` でフォーマットの一貫性を確保する
 
 ### 関連コマンド
 

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

@@ -16,6 +16,7 @@
 - `--iteration <番号>` : 特定イテレーションの進捗確認
 - `--technical` : 技術的な実装状況に焦点
 - `--docs` : ドキュメント更新状況の確認
+- `--update` : `docs/development/` 内のドキュメントを現在の進捗に合わせて更新
 
 ### 基本例
 
@@ -43,6 +44,10 @@
 # ドキュメント状況
 /progress --docs
 「計画・仕様・READMEなどのドキュメント更新状況を確認」
+
+# 進捗をドキュメントに反映
+/progress --update
+「release_plan.md と iteration_plan-*.md を現在の進捗に合わせて更新」
 ```
 
 ### 詳細機能
@@ -81,6 +86,61 @@ netstat -tlnp | grep -E ":3000|:5150"
 - **性能指標**: レスポンス時間・スループット測定
 - **セキュリティ**: 脆弱性スキャン結果
 
+#### --update オプションの詳細
+
+`--update` オプションは `docs/development/` 内のドキュメントを現在の進捗に合わせて自動更新します。
+
+**更新対象ファイル**:
+
+- `docs/development/release_plan.md` - リリース計画
+- `docs/development/iteration_plan-*.md` - イテレーション計画
+
+**release_plan.md の更新内容**:
+
+1. **進捗状況テーブル**: 各イテレーションの実績 SP、達成率、状態を更新
+2. **リリース条件チェックボックス**: 完了した条件にチェックを入れる
+3. **バーンダウンチャート**: 実績値を反映
+
+**iteration_plan-*.md の更新内容**:
+
+1. **成功基準チェックボックス**: 達成した基準にチェックを入れる
+2. **タスク分解の状態**: 完了したタスクのチェックボックスを更新
+3. **完了条件（DoD）**: 達成した条件にチェックを入れる
+4. **振り返りセクション**: メトリクス実績値を記入
+
+**更新判定の情報源**:
+
+```bash
+# Git コミット履歴から実装状況を分析
+git log --oneline --since="2 weeks ago"
+
+# テスト実行結果から品質指標を取得
+dotnet test --logger trx
+npm test -- --coverage
+
+# ディレクトリ構造から機能実装状況を確認
+ls -la apps/backend/src/
+ls -la apps/frontend/src/
+```
+
+**出力例**:
+
+```
+ドキュメント更新
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+📝 docs/development/release_plan.md を更新しています...
+   ✅ イテレーション 1 の進捗状況を更新
+   ✅ Release 1.0 のリリース条件を更新
+
+📝 docs/development/iteration_plan-1.md を更新しています...
+   ✅ 成功基準のチェック状態を更新 (3/5 完了)
+   ✅ タスク分解の状態を更新 (15/21 完了)
+   ✅ メトリクス実績値を更新
+
+更新完了！
+```
+
 ### 出力例
 
 ```
@@ -150,6 +210,15 @@ dotnet test --logger trx
 find docs/ -name "*.md" -newer docs/development/イテレーション計画1.md
 /progress --docs
 「最新のドキュメント更新を含めた文書整備状況の確認」
+
+# 進捗をドキュメントに反映
+/progress --update
+「現在の実装状況を分析し、release_plan.md と iteration_plan-*.md を更新」
+
+# イテレーション完了時のドキュメント更新
+git log --oneline -20
+/progress --update
+「イテレーション完了時に振り返りセクションを含む全ドキュメントを更新」
 ```
 
 ### 注意事項
@@ -157,6 +226,7 @@ find docs/ -name "*.md" -newer docs/development/イテレーション計画1.md
 - **前提条件**: Git リポジトリ内で実行、プロジェクト構造を理解
 - **情報取得**: 実行時点での動的な状況を総合的に分析
 - **推奨事項**: 重要な節目や問題発生時の定期的な進捗確認
+- **--update 使用時**: 更新前に Git でコミットしておくことを推奨（変更のロールバック用）
 
 ### ベストプラクティス
 
@@ -164,9 +234,12 @@ find docs/ -name "*.md" -newer docs/development/イテレーション計画1.md
 2. **問題発見**: 遅延や品質低下の早期発見に活用
 3. **ステークホルダー報告**: 詳細レポートを会議資料として活用
 4. **改善指標**: 進捗データを基にした開発プロセス改善
+5. **ドキュメント同期**: イテレーション完了時に `--update` で docs/development を同期
+6. **振り返り記録**: `--update` 実行後、KPT セクションを手動で記入して振り返りを完了
 
 ### 関連コマンド
 
-- `/semantic-commit` : 進捗に合わせた適切なコミット実行
-- `/test` : テスト実行状況の詳細確認（将来実装）
-- `/deploy` : デプロイ準備状況の確認（将来実装）
+- `/docs` : ドキュメント一覧と進捗状況の確認
+- `/docs --update` : docs/index.md と mkdocs.yml の更新
+- `/git-commit` : 進捗に合わせた適切なコミット実行
+- `/plan` : イテレーション計画の作成・更新

package/lib/assets/docs/reference/CodexCLIMCP/343/202/265/343/203/274/343/203/220/343/203/274/350/250/255/345/256/232/346/211/213/351/240/206.md

@@ -0,0 +1,214 @@
+# Codex CLI MCP サーバー設定手順
+
+## 概要
+
+Codex CLI を MCP（Model Context Protocol）サーバーとして動作させ、Claude Code からプロジェクトのコンテキストを効率的に検索・参照できるようにする手順です。
+
+## 前提条件
+
+- Node.js 18 以降がインストールされていること
+- npm が利用可能であること
+- Claude Code がインストールされていること
+
+## 手順
+
+### 1. Codex CLI のインストール
+
+Codex CLI をグローバルにインストールします。
+
+```bash
+npm install -g @openai/codex
+```
+
+インストール確認:
+
+```bash
+codex --version
+```
+
+### 2. Codex MCP サーバーの起動確認
+
+Codex CLI には MCP サーバーとして動作する機能が組み込まれています。以下のコマンドで動作確認します。
+
+```bash
+codex mcp-server
+```
+
+サーバーが待機状態になることを確認したら `Ctrl+C` で停止します。
+
+**注意**: `codex mcp-server` は stdio transport で動作します。
+
+### 3. Claude Code への MCP サーバー設定
+
+Claude Code の MCP 設定ファイルに Codex MCP サーバーを登録します。
+
+#### 設定ファイルの場所
+
+- **グローバル設定**: `~/.claude/.mcp.json`
+- **プロジェクト設定**: `.claude/.mcp.json`
+
+#### 設定内容（推奨: npx 経由）
+
+`.claude/.mcp.json` ファイルの `mcpServers` に以下を追加します:
+
+```json
+{
+  "mcpServers": {
+    "codex": {
+      "command": "npx",
+      "args": ["@openai/codex", "mcp-server"]
+    }
+  }
+}
+```
+
+#### Claude CLI から直接追加する方法（推奨）
+
+```bash
+# ユーザーレベル（グローバル）に追加
+claude mcp add -s user codex -- npx @openai/codex mcp-server
+
+# プロジェクトレベルに追加
+claude mcp add -s project codex -- npx @openai/codex mcp-server
+```
+
+**注意**: `npx -y` オプションは Claude Code の MCP 設定では使用できません。
+
+#### グローバルインストール済みの場合
+
+```json
+{
+  "mcpServers": {
+    "codex": {
+      "command": "codex",
+      "args": ["mcp-server"]
+    }
+  }
+}
+```
+
+#### Windows 環境でパスが認識されない場合
+
+フルパスを指定します:
+
+```json
+{
+  "mcpServers": {
+    "codex": {
+      "command": "C:\\Users\\<ユーザー名>\\scoop\\shims\\codex.cmd",
+      "args": ["mcp-server"]
+    }
+  }
+}
+```
+
+### 4. Claude Code からの利用
+
+Claude Code を起動します。
+
+```bash
+claude
+```
+
+起動後、Claude は MCP 経由で Codex のツールにアクセスできます。
+
+**利用例**:
+
+- 「このプロジェクトの中で認証処理を行っている箇所を探して」
+- 「API エンドポイントの一覧を教えて」
+- 「User モデルを使用しているファイルを検索して」
+
+## トラブルシューティング
+
+### MCP サーバーが起動しない場合
+
+1. Node.js のバージョンを確認:
+
+   ```bash
+   node --version  # 18 以上が必要
+   ```
+
+2. Codex CLI の再インストール:
+
+   ```bash
+   npm uninstall -g @openai/codex
+   npm install -g @openai/codex
+   ```
+
+### Claude Code から接続できない場合
+
+1. 設定ファイルの JSON 構文を確認
+2. コマンドパスが正しいか確認
+3. Claude Code を再起動
+4. `/mcp` コマンドで MCP サーバーの状態を確認
+
+## ベストプラクティス
+
+1. **プロジェクト固有の設定**: `.claude/settings.json` を使用してプロジェクトごとに設定
+2. **除外設定**: `.gitignore` で不要なファイルを除外（Codex は Git を参照）
+3. **OpenAI API キー**: `codex login` で認証を設定
+
+## Codex MCP ツールの使用方法
+
+Claude Code から Codex MCP サーバーを呼び出す際の主要パラメータを説明します。
+
+### 基本パラメータ
+
+| パラメータ | 説明 | 値の例 |
+|-----------|------|--------|
+| `prompt` | Codex に実行させるタスクの指示（必須） | `"Create a file named hello"` |
+| `sandbox` | 実行環境の権限レベル | `read-only`, `workspace-write`, `danger-full-access` |
+| `approval-policy` | コマンド実行時の承認ポリシー | `untrusted`, `on-failure`, `on-request`, `never` |
+| `cwd` | 作業ディレクトリ | `C:\path\to\project` |
+| `model` | 使用するモデル | `gpt-5.2`, `gpt-5.2-codex` |
+
+### sandbox パラメータ
+
+| 値 | 説明 |
+|----|------|
+| `read-only` | 読み取り専用（デフォルト）。ファイルの作成・編集不可 |
+| `workspace-write` | ワークスペース内のファイル書き込みを許可 |
+| `danger-full-access` | 全アクセス許可（注意して使用） |
+
+### approval-policy パラメータ
+
+| 値 | 説明 |
+|----|------|
+| `untrusted` | すべてのコマンドで承認を要求 |
+| `on-failure` | 失敗時のみ承認を要求 |
+| `on-request` | リクエスト時に承認を要求 |
+| `never` | 承認なしで実行（新規ファイル作成は除く） |
+
+### 使用例
+
+#### ファイル作成
+
+```
+prompt: "Create a file named hello containing Hello World"
+sandbox: danger-full-access
+approval-policy: never
+```
+
+**注意**: 新規ファイル作成は `approval-policy: never` でも確認を求められます。
+
+#### コード検索・分析
+
+```
+prompt: "Find all files that handle authentication"
+sandbox: read-only
+```
+
+### 継続的な対話
+
+`codex-reply` ツールを使用して、既存のスレッドで対話を継続できます:
+
+```
+threadId: "019bca72-76d5-73a1-9c68-88d1835932a9"
+prompt: "はい、作成してください"
+```
+
+## 関連リンク
+
+- [Codex CLI GitHub](https://github.com/openai/codex)
+- [Model Context Protocol](https://modelcontextprotocol.io/)
+- [Claude Code MCP 設定](https://docs.anthropic.com/claude-code/mcp)

package/lib/assets/docs/reference/Java/343/202/242/343/203/227/343/203/252/343/202/261/343/203/274/343/202/267/343/203/247/343/203/263/347/222/260/345/242/203/346/247/213/347/257/211/343/202/254/343/202/244/343/203/211.md

@@ -43,6 +43,7 @@ echo "*.iml" >> .gitignore
 ```
 
 **タイプの種類：**
+
 - `feat`: 新機能の追加
 - `fix`: バグ修正
 - `docs`: ドキュメント変更のみ
@@ -345,6 +346,7 @@ pmd {
 ```
 
 PMD はカスタム設定で以下をチェック：
+
 - マジックナンバーの使用
 - 空の catch ブロック
 - 循環複雑度が 7 を超えるメソッド
@@ -354,6 +356,7 @@ PMD はカスタム設定で以下をチェック：
 ### SpotBugs の設定（デフォルト設定を使用）
 
 SpotBugs は以下のバグパターンを検出：
+
 - Null ポインタ参照
 - リソースリーク
 - セキュリティ脆弱性
@@ -539,28 +542,34 @@ public void method() { }
 ## ベストプラクティス
 
 1. **コミットは小さく頻繁に**
+
    - 機能単位でコミット
    - テストが通る状態でコミット
 
 2. **テストファースト**
+
    - 実装前にテストを書く
    - テストが失敗することを確認してから実装
 
 3. **継続的な品質チェック**
+
    - コミット前に `./gradlew qualityCheck` を実行
    - カバレッジ 80% 以上を目標
    - 循環複雑度を 7 以下に維持
 
 4. **自動化の活用**
+
    - `./gradlew test --continuous` を常に起動
    - IDE の自動テスト機能を活用
 
 5. **リファクタリングの習慣**
+
    - テストが通ったらリファクタリング
    - 重複コードの排除
    - 意図が明確なコード
 
 6. **複雑度の管理**
+
    - メソッドの循環複雑度は 7 以下を維持
    - 複雑なロジックは小さなメソッドに分割
    - 早期リターンやガード節を活用して複雑度を削減

package/lib/assets/docs/reference/TypeScript/343/202/242/343/203/227/343/203/252/343/202/261/343/203/274/343/202/267/343/203/247/343/203/263/347/222/260/345/242/203/346/247/213/347/257/211/343/202/254/343/202/244/343/203/211.md

@@ -44,6 +44,7 @@ echo ".DS_Store" >> .gitignore
 ```
 
 **タイプの種類：**
+
 - `feat`: 新機能の追加
 - `fix`: バグ修正
 - `docs`: ドキュメント変更のみ

package/lib/assets/docs/reference//343/202/242/343/203/274/343/202/255/343/203/206/343/202/257/343/203/201/343/203/243/350/250/255/350/250/210/343/202/254/343/202/244/343/203/211.md

@@ -161,11 +161,13 @@ s3 --> db
 ```
 
 **メリット**:
+
 - 実装が直感的でわかりやすい
 - 開発速度が早い
 - 小規模チームでも扱いやすい
 
 **デメリット**:
+
 - コードの重複が発生しやすい
 - 大規模化すると保守が困難
 - ビジネスロジックが散在する
@@ -229,11 +231,13 @@ Reservation --> db : CRUD操作
 ```
 
 **メリット**:
+
 - オブジェクトとデータベースの対応が明確
 - ORMとの相性が良い
 - 理解しやすい構造
 
 **デメリット**:
+
 - データアクセスとビジネスロジックが密結合
 - テストが困難
 - ドメインロジックが薄くなる傾向
@@ -301,12 +305,14 @@ ReservationUseCase --> ReservationRepository
 ```
 
 **メリット**:
+
 - リッチなドメインモデル
 - ビジネスロジックの集約
 - 高い保守性・拡張性
 - テスト容易性
 
 **デメリット**:
+
 - 初期の学習コストが高い
 - 設計の複雑さ
 - 開発速度が遅い場合がある
@@ -369,12 +375,14 @@ ReservationProjection --> ReadModel : プロジェクション更新
 ```
 
 **メリット**:
+
 - 完全な監査証跡
 - 時系列分析が可能
 - 高いスケーラビリティ
 - 複雑なクエリに対応
 
 **デメリット**:
+
 - 実装の複雑さ
 - 高い学習コスト
 - 結果整合性の考慮が必要
@@ -682,6 +690,7 @@ integration -up-> e2e
 ```
 
 **特徴**:
+
 - ユニットテスト中心（80%）
 - ドメインロジックの徹底検証
 - 高品質なビジネスルール実装
@@ -700,6 +709,7 @@ integration -up-> e2e
 ```
 
 **特徴**:
+
 - 統合テスト中心（60%）
 - データアクセスロジックの重点検証
 - ORMとの連携確認
@@ -718,6 +728,7 @@ integration -up-> e2e
 ```
 
 **特徴**:
+
 - E2Eテスト中心（70%）
 - エンドツーエンドの動作確認
 - シナリオベースの検証
@@ -1420,11 +1431,13 @@ LB --> [アプリケーション]
 ```
 
 **メリット**:
+
 - シンプルな構成
 - 低い運用コスト
 - デプロイが容易
 
 **デメリット**:
+
 - スケーリングの柔軟性が低い
 - 単一障害点
 - 大規模化時の制約
@@ -1467,11 +1480,13 @@ gateway --> [Room Service]
 ```
 
 **メリット**:
+
 - 独立したデプロイとスケーリング
 - 技術スタックの柔軟性
 - 障害の局所化
 
 **デメリット**:
+
 - 複雑な運用
 - 分散システムの課題
 - デバッグの困難さ
@@ -1512,11 +1527,13 @@ package "Kubernetesクラスター" {
 ```
 
 **メリット**:
+
 - 自動スケーリング
 - 高可用性
 - リソース効率化
 
 **デメリット**:
+
 - 高い学習コスト
 - 複雑な設定
 - 運用の複雑さ
@@ -1547,11 +1564,13 @@ lambda3 --> db
 ```
 
 **メリット**:
+
 - 完全なサーバー管理不要
 - 自動スケーリング
 - 従量課金
 
 **デメリット**:
+
 - コールドスタート
 - ベンダーロックイン
 - ローカルテストの困難さ
@@ -2018,11 +2037,13 @@ lb --> blue2
 ```
 
 **メリット**:
+
 - 即座にロールバック可能
 - ゼロダウンタイム
 - 本番環境での検証
 
 **デメリット**:
+
 - リソースが2倍必要
 - データベース移行の複雑さ
 
@@ -2047,11 +2068,13 @@ lb --> canary : 25%
 ```
 
 **メリット**:
+
 - リスク最小化
 - 段階的なロールアウト
 - 問題の早期発見
 
 **デメリット**:
+
 - 複雑な管理
 - バージョン混在期間
 

package/lib/assets/docs/reference//343/202/263/343/203/274/343/203/207/343/202/243/343/203/263/343/202/260/343/201/250/343/203/206/343/202/271/343/203/210/343/202/254/343/202/244/343/203/211.md

@@ -614,11 +614,13 @@ public class UserTestFixture {
 ### リファクタリング実施のタイミング
 
 1. **Rule of Three（3回ルール）**
+
    - 1回目: そのまま実装
    - 2回目: 重複に気づくが我慢
    - 3回目: リファクタリング実施
 
 2. **コードの臭い（Code Smells）を検知したとき**
+
    - 長すぎるメソッド（20行以上）
    - 大きすぎるクラス（200行以上）
    - 長すぎるパラメータリスト（4個以上）

package/lib/assets/docs/reference//343/203/206/343/202/271/343/203/210/346/210/246/347/225/245/343/202/254/343/202/244/343/203/211.md

@@ -1279,21 +1279,25 @@ void 予約数に関係なく検索性能が一定(int reservationCount) {
 ### テスト戦略の要点
 
 1. **アーキテクチャに応じた適切な戦略選択**
+
    - ドメインモデル → ピラミッド形テスト
    - アクティブレコード → ダイヤモンド形テスト
    - トランザクションスクリプト → 逆ピラミッド形テスト
 
 2. **TDD による品質向上**
+
    - Red-Green-Refactor サイクル
    - テストファーストによる設計改善
    - 継続的なリファクタリング
 
 3. **効率的なテスト実行**
+
    - 高速なフィードバックループ
    - 並列実行による時間短縮
    - CI/CD パイプラインとの統合
 
 4. **適切なテスト範囲**
+
    - ドメイン層への重点的な投資
    - 外部依存の適切な分離
    - 実用的なカバレッジ目標

package/lib/assets/docs/reference//343/203/246/343/203/274/343/202/271/343/202/261/343/203/274/343/202/271/344/275/234/346/210/220/343/202/254/343/202/244/343/203/211.md

@@ -278,6 +278,7 @@ title ユースケース作成の段階的詳細化
 **なぜなら**: [ビジネス価値]
 
 **受入条件**:
+
 - [ ] [条件1]
 - [ ] [条件2]
 ```
@@ -509,14 +510,17 @@ note right of US3 : イテレーション単位の\nストーリーに分解
 ### イテレーション計画での利用
 
 1. **リリース計画時**
+
    - 要約レベルのユースケースで全体像を把握
    - 大まかな規模見積もり
 
 2. **イテレーション計画時**
+
    - ユーザー目的レベルをストーリーに分解
    - 詳細な見積もりと優先順位付け
 
 3. **実装時**
+
    - ユースケースを設計ガイドとして利用
    - 受入テストケースの基準
 
@@ -580,6 +584,7 @@ note bottom of TC : 各パスを網羅する\nテストケースを生成
 **テストパス**: 主成功シナリオ/拡張XX
 
 **事前条件**:
+
 - [システムの初期状態]
 - [必要なテストデータ]
 
@@ -588,11 +593,13 @@ note bottom of TC : 各パスを網羅する\nテストケースを生成
 2. [入力データ2]
 
 **期待結果**:
+
 - [期待される出力]
 - [期待される状態変化]
 - [期待される副作用]
 
 **事後条件**:
+
 - [システムの最終状態]
 ```
 
@@ -637,18 +644,22 @@ note bottom of good : ビジネス目的\n実装独立\n価値が明確
 ### ユースケース作成の原則
 
 1. **読みやすさ優先**
+
    - 完璧さより理解しやすさ
    - 自然な言葉で記述
 
 2. **段階的詳細化**
+
    - 広く浅くから始める
    - 必要に応じて深堀り
 
 3. **適切なレベル選択**
+
    - ユーザー目的を中心に
    - サブ機能は最小限に
 
 4. **XPとの統合**
+
    - ユーザーストーリーと連携
    - イテレーション計画で活用
    - テストケースの基準

package/lib/assets/docs/reference//343/203/252/343/203/252/343/203/274/343/202/271/343/203/273/343/202/244/343/203/206/343/203/254/343/203/274/343/202/267/343/203/247/343/203/263/350/250/210/347/224/273/343/202/254/343/202/244/343/203/211.md

@@ -235,8 +235,9 @@ state チームはコミットできるか <<choice>>
 #### デイリースタンドアップ
 
 毎日の進捗確認で以下を共有：
+
 - 昨日やったこと
-- 今日やること  
+- 今日やること
 - 障害・ブロッカー
 
 #### タスクボードの活用

package/lib/assets/docs/reference//351/235/236/346/251/237/350/203/275/350/246/201/344/273/266/345/256/232/347/276/251/343/202/254/343/202/244/343/203/211.md

@@ -1197,21 +1197,25 @@ groups:
 ### 非機能要件定義の要点
 
 1. **品質属性の明確化**
+
    - ISO/IEC 25010 に基づく体系的な分類
    - 測定可能な目標値の設定
    - ステークホルダーとの合意形成
 
 2. **実装と検証の統合**
+
    - アーキテクチャ設計への反映
    - 自動テストによる継続的検証
    - 運用監視との連携
 
 3. **継続的改善**
+
    - 実運用データに基づく評価
    - ユーザーフィードバックの活用
    - 技術進歩に応じた要件見直し
 
 4. **リスク管理**
+
    - 品質属性間のトレードオフの認識
    - 優先順位に基づく段階的実装
    - 早期の問題発見と対策
@@ -1219,11 +1223,13 @@ groups:
 ### 非機能要件がもたらす価値
 
 **短期的価値**:
+
 - システムの安定性と信頼性の確保
 - ユーザー満足度の向上
 - 運用コストの削減
 
 **長期的価値**:
+
 - 保守性による開発効率の維持
 - 拡張性による事業成長への対応
 - セキュリティによるリスク回避

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@k2works/claude-code-booster",
-  "version": "0.16.2",
+  "version": "0.18.0",
   "description": "AI Agent Development Support Tool",
   "main": "main.js",
   "bin": {