@k2works/claude-code-booster 0.8.0 → 0.9.0

package/lib/assets/.claude/README.md

@@ -1,9 +1,8 @@
-# Claude Code Cookbook
+# Claude Code Booster - Basic Template
 
-Claude Code をもっと便利に使うための設定集です。
+Claude Code をより効率的に使うための基本設定テンプレートです。
 
-細かい確認を省いて自動的に作業を進めてくれるので、本来やりたいことに集中できます。
-コードの修正やテストの実行、ドキュメントの更新など、よくある作業は Claude Code が判断して実行します。
+このテンプレートは最小限の構成で、プロジェクトに合わせてカスタマイズできる基盤を提供します。
 
 ## 主要機能
 
@@ -19,157 +18,76 @@ Claude Code をもっと便利に使うための設定集です。
 
 ### Commands（カスタムコマンド）
 
-`/commands` ディレクトリ内の Markdown ファイルとして保存されています。`/` に続けてファイル名を入力すると実行できます。
-
-| コマンド                    | 説明                                                          |
-|:------------------------|:------------------------------------------------------------|
-| `/analyze-dependencies` | プロジェクトの依存関係を分析し、循環依存や構造的な問題を視覚化する。                          |
-| `/analyze-performance`  | アプリケーションのパフォーマンス問題を分析し、技術的負債の観点から改善策を提案する。                  |
-| `/check-fact`           | プロジェクト内のコードベース、ドキュメントを参照し、与えられた情報の正誤を確認する。                  |
-| `/check-github-ci`      | GitHub Actions の CI 状況を監視し、完了まで追跡する。                        |
-| `/check-prompt`         | 現在のプロンプトの内容をレビューし、改善案を提示する。                                 |
-| `/commit-message`       | 変更内容に基づいてコミットメッセージだけを生成する。                                  |
-| `/context7`             | Context7 MCP を使用してコンテキスト管理を行う。                              |
-| `/design-patterns`      | デザインパターンに基づいた実装を提案・レビューする。                                  |
-| `/explain-code`         | 選択されたコードの機能やロジックを分かりやすく説明する。                                |
-| `/fix-error`            | エラーメッセージを元に、コードの修正案を提示する。                                   |
-| `/multi-role`           | 複数の役割（Role）を組み合わせて、同じ対象を並行分析し統合レポートを生成する。                   |
-| `/plan`                 | 実装前の計画立案モードを起動し、詳細な実装戦略を策定する。                               |
-| `/pr-auto-update`       | Pull Request の内容（説明、ラベル）を自動で更新する。                           |
-| `/pr-create`            | Git 変更分析に基づく自動 PR 作成で効率的な Pull Request ワークフローを実現する。         |
-| `/pr-feedback`          | Pull Request のレビューコメントを効率的に対応し、エラー分析 3 段階アプローチで根本解決を図る。     |
-| `/pr-issue`             | 現在のリポジトリのオープン Issue 一覧を優先順位付きで表示する。                         |
-| `/pr-list`              | 現在のリポジトリのオープン PR 一覧を優先順位付きで表示する。                            |
-| `/pr-review`            | Pull Request の体系的レビューでコード品質とアーキテクチャの健全性を確保する。               |
-| `/refactor`             | 安全で段階的なコードリファクタリングを実施し、SOLID 原則の遵守状況を評価する。                  |
-| `/role-debate`          | 複数の役割（Role）で、特定のテーマについて討論させる。                               |
-| `/role-help`            | 利用可能な Role の一覧と説明を表示する。                                     |
-| `/role`                 | 指定した役割（Role）として振る舞う。                                        |
-| `/screenshot`           | 画面のスクリーンショットを取得し解析する                                        |
-| `/search-gemini`        | Gemini を使って Web 検索を行う。                                      |
-| `/semantic-commit`      | 大きな変更を意味のある最小単位に分割し、セマンティックなコミットメッセージで順次コミットする。             |
-| `/sequential-thinking`  | Sequential Thinking MCP を使用して複雑な問題を順を追って段階的に考え、結論を導き出す。     |
-| `/show-plan`            | 現在の実行計画を表示する。                                               |
-| `/smart-review`         | 高度なレビューを行い、コード品質を向上させる。                                     |
-| `/spec`                 | 要求事項から、Kiro の spec-driven development に準拠した詳細な仕様書を段階的に作成する。 |
-| `/style-ai-writing`     | AI が生成したような不自然な文章を検出し、修正する。                                 |
-| `/task`                 | 専用エージェントを起動して、複雑な検索・調査・分析タスクを自律的に実行する。                      |
-| `/tech-debt`            | プロジェクトの技術的負債を分析し、優先順位付けされた改善計画を作成する。                        |
-| `/ultrathink`           | 複雑な課題や重要な決定に対して、段階的で構造化された思考プロセスを実行する。                      |
-| `/update-dart-doc`      | Dart ファイルの DartDoc コメントを体系的に管理し、高品質な日本語ドキュメントを維持する。         |
-| `/update-doc-string`    | 複数言語対応のドキュメント文字列を統一的に管理・更新する。                               |
-| `/update-flutter-deps`  | Flutter プロジェクトの依存関係を安全に更新する。                                |
-| `/update-node-deps`     | Node.js プロジェクトの依存関係を安全に更新する。                                |
-| `/update-rust-deps`     | Rust プロジェクトの依存関係を安全に更新する。                                   |
-| `/progress`             | 進捗確認をする。                                                    |
-| `/next`                 | 次タスクを確認する。                                                  |
-| `/analysis`             | 開発標準の分析ワークフローを実行する。                                         |
-| `/dev`                  | 開発標準の開発ワークフローを実行する。                                         |
-| `/ops`                  | 開発標準の運用ワークフローを実行する。                                         |
+`commands/` ディレクトリ内の Markdown ファイルとして保存されています。`/` に続けてファイル名を入力すると実行できます。
 
+| コマンド       | 説明                                                         |
+| :------------- | :----------------------------------------------------------- |
+| `/analysis`    | 開発標準の分析ワークフローを実行する。要件定義からアーキテクチャ設計まで支援。 |
+| `/dev`         | TDD サイクルに従った開発ワークフローを実行する。             |
+| `/git-commit`  | 意味のある変更単位ごとにコミットを作成する。                 |
+| `/kill`        | 開発サーバーや Node.js プロセスを強制終了する。              |
+| `/ops`         | 環境構築・ビルド・デプロイなど運用ワークフローを実行する。   |
+| `/plan`        | リリース計画とイテレーション計画を作成・管理する。           |
+| `/progress`    | プロジェクトの開発進捗を包括的に確認する。                   |
 
 ### Roles（役割設定）
 
-`agents/roles/` ディレクトリ内の Markdown ファイルで定義されています。Claude に専門家の視点を持たせて、より的確な回答を得られます。
+`agents/roles/` ディレクトリ内の Markdown ファイルで定義されます。
 
-各ロールは**サブエージェントとして独立実行**することも可能です。`--agent` オプションを使用すると、メインの会話コンテキストを妨げることなく、大規模な分析や専門的な処理を並列実行できます。
-
-| ロール | 説明 |
-| :--- | :--- |
-| `/role analyzer` | システム分析の専門家として、コードやアーキテクチャの分析を行う。 |
-| `/role architect` | ソフトウェアアーキテクトとして、設計に関するレビューや提案を行う。 |
-| `/role backend` | バックエンド開発の専門家として、API 設計、マイクロサービス、クラウドネイティブ、サーバーレスアーキテクチャに関する助言をする。 |
-| `/role frontend` | フロントエンドの専門家として、UI/UX やパフォーマンスに関する助言をする。 |
-| `/role mobile` | モバイルアプリ開発の専門家として、iOS/Android のベストプラクティスに基づいた回答をする。 |
-| `/role performance` | パフォーマンス最適化の専門家として、速度やメモリ使用量の改善を提案する。 |
-| `/role qa` | QA エンジニアとして、テスト計画や品質保証の観点からレビューする。 |
-| `/role reviewer` | コードレビュアーとして、可読性や保守性の観点からコードを評価する。 |
-| `/role security` | セキュリティ専門家として、脆弱性やセキュリティリスクを指摘する。 |
-
-#### サブエージェント実行例
-
-```bash
-# 通常モード（メインコンテキストで実行）
-/role security
-「このプロジェクトのセキュリティチェック」
-
-# サブエージェントモード（独立コンテキストで実行）
-/role security --agent
-「プロジェクト全体のセキュリティ監査を実行」
-
-# 複数ロールの並列分析
-/multi-role security,performance --agent
-「システム全体のセキュリティとパフォーマンスを包括的に分析」
-```
+現在、このテンプレートにはロールが含まれていません。必要に応じて `.md` ファイルを追加してください。
 
 ### Hooks（自動化スクリプト）
 
 `settings.json` で設定して、開発作業を自動化できます。
 
-| 実行スクリプト | イベント | 説明 |
-| :--- | :--- | :--- |
-| `deny-check.sh` | `PreToolUse` | `rm -rf /` のような危険なコマンドの実行を未然に防ぐ。 |
-| `check-ai-commit.sh` | `PreToolUse` | `git commit` でコミットメッセージに AI の署名が含まれている場合にエラーを出す。 |
-| `preserve-file-permissions.sh` | `PreToolUse` / `PostToolUse` | ファイル編集前に元の権限を保存し、編集後に復元する。Claude Code が権限を変更するのを防ぐ。 |
-| `ja-space-format.sh` | `PostToolUse` | ファイル保存時に、日本語と英数字の間のスペースを自動で整形する。 |
-| `auto-comment.sh` | `PostToolUse` | 新規ファイル作成時や大幅な編集時に、docstring や API ドキュメントの追加を促す。 |
-| `notify-waiting` | `Notification` | Claude がユーザーの確認を待っている時に、macOS の通知センターでお知らせする。 |
-| `check-continue.sh` | `Stop` | タスク完了時に、継続可能なタスクがないか確認する。 |
-| `(osascript)` | `Stop` | 全タスク完了時に、macOS の通知センターで完了を知らせる。 |
-
----
-
-## 開発フローとコマンド使用ガイド
-
-### 一般的な開発フローでのコマンド活用例
+| 実行スクリプト                 | イベント      | 説明                                                                 |
+| :----------------------------- | :------------ | :------------------------------------------------------------------- |
+| `deny-check.sh`                | `PreToolUse`  | `rm -rf /` のような危険なコマンドの実行を未然に防ぐ。                |
+| `check-ai-commit.sh`           | `PreToolUse`  | `git commit` でコミットメッセージに AI の署名が含まれている場合にエラーを出す。 |
+| `preserve-file-permissions.sh` | `PreToolUse` / `PostToolUse` | ファイル編集前に元の権限を保存し、編集後に復元する。 |
+| `ja-space-format.sh`           | `PostToolUse` | ファイル保存時に、日本語と英数字の間のスペースを自動で整形する。     |
+| `auto-comment.sh`              | `PostToolUse` | 新規ファイル作成時や大幅な編集時に、docstring の追加を促す。         |
+| `(osascript)`                  | `Notification` | Claude がユーザーの確認を待っている時に、macOS の通知センターでお知らせする。 |
+| `check-continue.sh`            | `Stop`        | タスク完了時に、継続可能なタスクがないか確認する。                   |
+| `(osascript)`                  | `Stop`        | 全タスク完了時に、macOS の通知センターで完了を知らせる。             |
 
-```mermaid
-flowchart TB
-    Start([タスク確認]) --> PRList["/pr-list<br/>オープン PR 一覧"]
-    Start --> PRIssue["/pr-issue<br/>オープン Issue 一覧"]
+**注意**: スクリプトファイルは `scripts/` ディレクトリに配置する必要があります。このテンプレートには `.gitkeep` のみが含まれているため、実際のスクリプトは `~/.claude/scripts/` から参照するか、プロジェクトに合わせて作成してください。
 
-    PRList --> TaskType{種類は？}
-    PRIssue --> TaskType
-
-    TaskType -->|新機能| Plan["/spec<br/>要件定義・設計"]
-    TaskType -->|バグ修正| Fix["/fix-error<br/>エラー分析"]
-    TaskType -->|リファクタリング| Refactor["/refactor<br/>改善"]
-    TaskType -->|レビュー| Review["/pr-review<br/>レビュー"]
-
-    Plan --> Design["/role architect<br/>/role-debate<br/>設計相談"]
-    Design --> Implementation[実装・テスト]
-    Fix --> Implementation
-    Refactor --> Implementation
-    Review --> Implementation
-
-    Implementation --> Check["/smart-review<br/>品質チェック"]
-    Check --> Commit["/semantic-commit<br/>目的単位でコミット"]
-    Commit --> PR["/pr-create<br/>PR 自動作成"]
-    PR --> CI["/check-github-ci<br/>CI 状況確認"]
-
-    CI --> Status{問題あり？}
-    Status -->|はい| Feedback["修正対応<br/>/pr-feedback<br/>/fix-error"]
-    Status -->|いいえ| End([完了])
-
-    Feedback --> Implementation
-
-    classDef commandBox fill:#e0f2fe,stroke:#0369a1,stroke-width:2px,rx:5,ry:5,color:#0c4a6e
-    classDef processBox fill:#f0f9ff,stroke:#0ea5e9,stroke-width:1px,rx:5,ry:5,color:#075985
-    classDef decisionBox fill:#fef3c7,stroke:#f59e0b,stroke-width:2px,rx:5,ry:5,color:#78350f
-    classDef startEnd fill:#86efac,stroke:#22c55e,stroke-width:2px,rx:20,ry:20,color:#14532d
+---
 
-    class PRList,PRIssue,Plan,Fix,Refactor,Review,Design,Check,CI,Commit,PR,Feedback commandBox
-    class Implementation processBox
-    class TaskType,Status decisionBox
-    class Start,End startEnd
+## ディレクトリ構造
 
-    %%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#e0f2fe', 'primaryTextColor':'#0c4a6e', 'primaryBorderColor':'#0369a1', 'lineColor':'#64748b', 'secondaryColor':'#f0f9ff', 'background':'#ffffff', 'mainBkg':'#ffffff', 'fontSize': '14px'}}}%%
+```
+.claude/
+├── agents/
+│   └── roles/           # 役割定義ファイル（.md）
+├── assets/              # 通知音などのアセット
+├── commands/            # カスタムコマンド（.md）
+│   ├── analysis.md
+│   ├── dev.md
+│   ├── git-commit.md
+│   ├── kill.md
+│   ├── ops.md
+│   ├── plan.md
+│   └── progress.md
+├── scripts/             # Hooks 用スクリプト
+├── .gitignore
+├── .mcp.json            # MCP サーバー設定
+├── COMMAND_TEMPLATE.md  # コマンド作成テンプレート
+├── README.md
+├── settings.json        # Claude Code 設定
+└── settings.local.json  # ローカル環境用設定
 ```
 
 ---
 
-### カスタマイズ
+## カスタマイズ
 
 - **コマンドの追加**: `commands/` に `.md` ファイルを追加するだけです
 - **ロールの追加**: `agents/roles/` に `.md` ファイルを追加するだけです
 - **Hooks の編集**: `settings.json` を編集して、自動化処理を変更できます
+- **スクリプトの追加**: `scripts/` にシェルスクリプトを追加し、`settings.json` で参照します
+
+## 完全版について
+
+より多くのコマンドやロール、スクリプトを含む完全版は `samples/.claude/` ディレクトリを参照してください。

package/lib/assets/.claude/commands/git-commit.md

@@ -0,0 +1,47 @@
+---
+allowed-tools: Bash(git:*), Bash(npm:*), Read(*.md), Fetch(*)
+description: "ワーキングディレクトリでの変更をコミットします"
+---
+
+意味のある変更単位ごとにコミットを行うことは、コードの履歴を明確にし、将来の変更を追跡しやすくするために重要です。
+
+以下の手順に従って、ワーキングディレクトリでの変更をコミットします。
+
+### 1. 変更を確認する
+
+まず、現在のワーキングディレクトリでの変更を確認します。以下のコマンドを実行してください：
+
+```bash
+git status
+```
+
+### 2. 変更をステージングする
+
+変更をコミットする前に、ステージングエリアに追加する必要があります。以下のコマンドを使用して、すべての変更をステージングします：
+
+```bash
+git add 対象ファイルやディレクトリ
+```
+
+意味のある変更単位ごとにファイルを指定すること。無条件にすべての変更を追加しないでください。
+
+### 3. コミットメッセージを作成する
+
+コミットメッセージは、変更内容を簡潔に説明する重要な部分です。以下のコマンドを使用して、コミットを作成します：
+
+```bash
+git commit -m "コミットメッセージをここに入力"
+```
+
+- コミットメッセージは日本語で記述してください。
+- Conventional Commitsのルールに従ってください。
+- co-authorやコミットメッセージに"Claude Code"のキーワードは含めないこと。
+
+### 4. コミットを確認する
+コミットが正しく行われたかを確認するために、以下のコマンドを実行します：
+
+```bash
+git log --oneline
+```
+
+これにより、最近のコミットの一覧が表示され、コミットメッセージとハッシュが確認できます。

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

@@ -38,15 +38,15 @@
 
 # Java開発環境の構築
 /ops --setup Java
-「プロジェクト名と作成場所（デフォルト app/backend）を対話式で確認後、docs/reference/Javaアプリケーション環境構築ガイド.md、@docs/design/tech_stack.md、@docs/design/architecture_backend.md を基にしたJava開発環境の統合セットアップ」
+「プロジェクト名と作成場所（デフォルト apps/backend）を対話式で確認後、docs/reference/Javaアプリケーション環境構築ガイド.md、@docs/design/tech_stack.md、@docs/design/architecture_backend.md を基にしたJava開発環境の統合セットアップ」
 
 # TypeScript/React開発環境の構築
 /ops --setup FrontEnd
-「プロジェクト名と作成場所（デフォルト app/frontend）を対話式で確認後、docs/reference/TypeScriptアプリケーション環境構築ガイド.md、@docs/design/tech_stack.md、@docs/design/architecture_frontend.md を基にしたTypeScript/React開発環境の統合セットアップ」
+「プロジェクト名と作成場所（デフォルト apps/frontend）を対話式で確認後、docs/reference/TypeScriptアプリケーション環境構築ガイド.md、@docs/design/tech_stack.md、@docs/design/architecture_frontend.md を基にしたTypeScript/React開発環境の統合セットアップ」
 
 # C# WPF開発環境の構築
 /ops --setup C#WPF
-「プロジェクト名と作成場所（デフォルト app/wpfapp）を対話式で確認後、@docs/design/tech_stack.md、@docs/design/architecture_backend.md、@docs/design/architecture_frontend.md を基にしたC# WPF + Clean Architecture開発環境の統合セットアップ」
+「プロジェクト名と作成場所（デフォルト apps/wpfapp）を対話式で確認後、@docs/design/tech_stack.md、@docs/design/architecture_backend.md、@docs/design/architecture_frontend.md を基にしたC# WPF + Clean Architecture開発環境の統合セットアップ」
 
 # プロダクション環境へのデプロイ
 /ops --deploy production
@@ -107,12 +107,12 @@
 - プロジェクト名の確認（例: meeting-room-system）
 - パッケージ名の確認（例: com.example.{project-name}）
 - グループID・アーティファクトIDの設定確認
-- 作成場所の確認（デフォルト: `app/backend/`配下）
+- 作成場所の確認（デフォルト: `apps/backend/`配下）
 
 **注意点**
 - `docs/reference/Javaアプリケーション環境構築ガイド.md`: のGradle プロジェクトの初期化部分は参考にしない
-- app/backend/app のような構成にしてはいけない
-- app/backend/{project-name} のような構成すること
+- apps/backend/app のような構成にしてはいけない
+- apps/backend/{project-name} のような構成すること
 - ディレクトリだけの場合もコミットしたいので `.gitkeep` を入れる
 
 **構築される環境の詳細**:
@@ -175,12 +175,12 @@
 🎯 **対話式プロジェクト設定**:
 - プロジェクト名の確認（例: AdventureWorks.PurchasingSystem）
 - ソリューション名の確認（例: AdventureWorks）
-- 作成場所の確認（デフォルト: `app/`配下）
+- 作成場所の確認（デフォルト: `apps/`配下）
 - データベース接続文字列の確認
 
 **注意点**
-- app/app のような構成にしてはいけない
-- app/{solution-name} のような構成すること
+- apps/app のような構成にしてはいけない
+- apps/{solution-name} のような構成すること
 - tech_stack.md の ディレクトリ構成詳細にしたがうこと
 - ディレクトリだけの場合もコミットしたいので `.gitkeep` を入れる
 - Javaの `src` や `tests` のようなディレクトリ構成にしないこと
@@ -230,13 +230,13 @@
 🎯 **対話式プロジェクト設定**:
 - プロジェクト名の確認（例: meeting-room-reservation-ui）
 - パッケージ名の確認（例: @mrs/frontend）
-- 作成場所の確認（デフォルト: `app/frontend/`配下）
+- 作成場所の確認（デフォルト: `apps/frontend/`配下）
 - 開発ポートの確認（デフォルト: 3000）
 
 **注意点**
 - `docs/reference/TypeScriptアプリケーション環境構築ガイド.md`: のVite プロジェクトの初期化部分は参考にしない
-- app/frontend/app のような構成にしてはいけない
-- app/frontend/{project-name} のような構成すること
+- apps/frontend/app のような構成にしてはいけない
+- apps/frontend/{project-name} のような構成すること
 - ディレクトリだけの場合もコミットしたいので `.gitkeep` を入れる
 
 **構築される環境の詳細**:
@@ -434,7 +434,7 @@ git status
 「最新コミットを含めたステージング環境へのデプロイ実行」
 
 # ログ分析と組み合わせた障害対応
-tail -100 /var/log/app.log
+tail -100 /var/log/apps.log
 /ops --rollback production
 「エラーログ分析に基づく緊急ロールバック実行」
 
@@ -450,7 +450,7 @@ cat docs/design/tech_stack.md
 cat docs/design/architecture_backend.md
 /ops --setup Java
 # → プロジェクト名入力: "meeting-room-system"
-# → 作成場所確認: "app/backend/" (Enter でデフォルト採用)
+# → 作成場所確認: "apps/backend/" (Enter でデフォルト採用)
 # → パッケージ名確認: "com.example.meetingroomsystem" (自動生成)
 ./gradlew build
 「設計ドキュメント確認後、対話式でプロジェクト設定を確認し、Java環境構築と初回ビルド実行」
@@ -461,7 +461,7 @@ cat docs/design/tech_stack.md
 cat docs/design/architecture_frontend.md
 /ops --setup FrontEnd
 # → プロジェクト名入力: "meeting-room-reservation-ui"
-# → 作成場所確認: "app/frontend/" (Enter でデフォルト採用)
+# → 作成場所確認: "apps/frontend/" (Enter でデフォルト採用)
 # → パッケージ名確認: "@mrs/frontend" (自動生成)
 # → 開発ポート確認: "3000" (Enter でデフォルト採用)
 npm run dev
@@ -474,7 +474,7 @@ cat docs/design/architecture_frontend.md
 /ops --setup C#WPF
 # → ソリューション名入力: "AdventureWorks"
 # → プロジェクト名確認: "AdventureWorks.PurchasingSystem" (自動生成)
-# → 作成場所確認: "app/wpfapp/" (Enter でデフォルト採用)
+# → 作成場所確認: "apps/wpfapp/" (Enter でデフォルト採用)
 # → 接続文字列確認: "Server=(localdb)\\mssqllocaldb;..." (デフォルト採用)
 dotnet build
 「設計ドキュメント確認後、対話式でプロジェクト設定を確認し、C# WPF + Clean Architecture環境構築と初回ビルド実行」

package/lib/assets/README.md

@@ -59,6 +59,80 @@ claude mcp add github npx -y @modelcontextprotocol/server-github -s project
 
 ### 運用
 
+#### ドキュメントの編集
+
+1. ローカル環境でMkDocsサーバーを起動
+   ```
+   docker-compose up mkdocs
+   ```
+   または、Gulpタスクを使用:
+   ```
+   npm run docs:serve
+   ```
+
+2. ブラウザで http://localhost:8000 にアクセスして編集結果をプレビュー
+
+3. `docs/`ディレクトリ内のMarkdownファイルを編集
+
+4. 変更をコミットしてプッシュ
+   ```
+   git add .
+   git commit -m "ドキュメントの更新"
+   git push
+   ```
+
+#### Gulpタスクの使用
+
+プロジェクトには以下のGulpタスクが用意されています：
+
+##### MkDocsタスク
+
+- MkDocsサーバーの起動:
+  ```
+  npm run docs:serve
+  ```
+  または
+  ```
+  npx gulp mkdocs:serve
+  ```
+
+- MkDocsサーバーの停止:
+  ```
+  npm run docs:stop
+  ```
+  または
+  ```
+  npx gulp mkdocs:stop
+  ```
+
+- MkDocsドキュメントのビルド:
+  ```
+  npm run docs:build
+  ```
+  または
+  ```
+  npx gulp mkdocs:build
+  ```
+
+##### 作業履歴（ジャーナル）タスク
+
+- すべてのコミット日付の作業履歴を生成:
+  ```
+  npm run journal
+  ```
+  または
+  ```
+  npx gulp journal:generate
+  ```
+
+- 特定の日付の作業履歴を生成:
+  ```
+  npx gulp journal:generate:date --date=YYYY-MM-DD
+  ```
+  (例: `npx gulp journal:generate:date --date=2023-04-01`)
+
+生成された作業履歴は `docs/journal/` ディレクトリに保存され、各ファイルには指定された日付のコミット情報が含まれます。
+
 #### GitHub Container Registry
 
 このプロジェクトでは、GitHub Container Registry（GHCR）を使用して開発コンテナイメージを管理しています。
@@ -79,13 +153,13 @@ GHCR からイメージを取得して実行するには：
 
 ```bash
 # イメージをプル
-docker pull ghcr.io/k2works/grokkingfp-excersice:latest
+docker pull ghcr.io/k2works/{project_name}:latest
 
 # または特定バージョン
 docker pull ghcr.io/k2works/grokkingfp-excersice:0.0.1
 
 # コンテナを実行
-docker run -it -v $(pwd):/srv ghcr.io/k2works/grokkingfp-excersice:latest
+docker run -it -v $(pwd):/srv ghcr.io/k2works/{project_name}:latest
 ```
 
 認証が必要な場合は、以下のコマンドでログインします：

package/package.json

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