@k2works/claude-code-booster 0.16.2 → 0.17.0

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/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.17.0",
   "description": "AI Agent Development Support Tool",
   "main": "main.js",
   "bin": {