@k2works/claude-code-booster 1.0.0 → 1.1.0

package/lib/assets/docs/reference/UI/350/250/255/350/250/210/343/202/254/343/202/244/343/203/211.md

@@ -9,6 +9,7 @@
 ### 4つの主要原則
 
 #### 1. オブジェクトの特定
+
 - ユーザーがシステム内で操作する主要な「モノ」を特定
 - 名詞で表現できるもの（例：生徒、教員、部、イベント、文書、商品など）
 - ドメインモデルと密接に関連
@@ -58,7 +59,8 @@ item1 --> "シングルビュー" : 詳細表示
 @enduml
 ```
 
-**特徴**：
+**特徴**:
+
 - 複数のオブジェクトを一覧表示
 - 検索・フィルタリング機能
 - 新規作成のエントリーポイント
@@ -87,7 +89,8 @@ related1 --> "関連オブジェクトビュー" : 詳細
 @enduml
 ```
 
-**特徴**：
+**特徴**:
+
 - 単一オブジェクトの詳細情報表示
 - 編集・削除などのアクション
 - 関連オブジェクトへのナビゲーション

package/lib/assets/docs/reference//343/202/210/343/201/204/343/202/275/343/203/225/343/203/210/343/202/246/343/202/247/343/202/242/343/201/250/343/201/257.md

@@ -12,9 +12,12 @@ dateCreated: 2025-06-27T09:35:43.840Z
 
 ## ソフトウェアの目的
 
-- 問題解決: 
+- 問題解決:
+
+ 
   - 単なる「動くプログラム」ではなく問題を解決するもの
 - 本質的な目的:
+
   - ユーザーの問題解決: 課題や不便を解消
   - ビジネス価値の創出: 組織やビジネスに利益をもたらす
   - 効率化と自動化: 時間や労力を節約
@@ -22,10 +25,18 @@ dateCreated: 2025-06-27T09:35:43.840Z
   
 ## ソフトウェアの価値
 
-- 機能性: ユーザーの問題をちゃんと解決できるか
-- 使いやすさ: 優れた機能でも使いにくければ意味がない
-- 信頼性: 安定して動作するか
-- 保守性: 長期間にわたって改善・維持できるか
+- 機能性:
+
+  ユーザーの問題をちゃんと解決できるか
+- 使いやすさ:
+
+  優れた機能でも使いにくければ意味がない
+- 信頼性:
+
+  安定して動作するか
+- 保守性:
+
+  長期間にわたって改善・維持できるか
 
 ## よいソフトウェアの必要十分条件
 
@@ -88,12 +99,24 @@ folder "ビジネス" {
 
 ### ソフトウエア開発の3P(プリンシパル・パターン・プラクティス)
 
-- SOLID原則: 単一責任、開放閉鎖、リスコフの置換、インターフェース分離、依存性逆転
-- デザインパターン: 再利用可能な設計ソリューション
-- アーキテクチャパターン：ソフトウェアアーキテクチャで発生する問題の解決策
-- ドメイン駆動設計: ビジネスドメインに焦点を当てた設計
-- テスト駆動開発: テストを先に書いてから実装
-- 継続的デリバリー: 小さな変更を頻繁にリリース
+- SOLID原則:
+
+  単一責任、開放閉鎖、リスコフの置換、インターフェース分離、依存性逆転
+- デザインパターン:
+
+  再利用可能な設計ソリューション
+- アーキテクチャパターン:
+
+  ソフトウェアアーキテクチャで発生する問題の解決策
+- ドメイン駆動設計:
+
+  ビジネスドメインに焦点を当てた設計
+- テスト駆動開発:
+
+  テストを先に書いてから実装
+- 継続的デリバリー:
+
+  小さな変更を頻繁にリリース
 
 ### サークルオブライフ
 

package/lib/assets/docs/reference//343/203/223/343/202/270/343/203/215/343/202/271/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

@@ -0,0 +1,528 @@
+# ビジネスアーキテクチャ設計ガイド
+
+## 概要
+
+本ガイドは、ビジネスアーキテクチャの設計指針を提供します。エンタープライズがどのように価値を生み出し、顧客に提供するかの構造を体系的に整理するための手法とフレームワークを定義します。
+
+## 全体像
+
+```plantuml
+@startmindmap
+
+* ビジネスアーキテクチャ
+** ビジネスアーキテクチャとは
+** ビジネスアーキテクチャを構成する主要な要素
+*** プリンシプル
+**** ガイディングプリンシプル
+***** ビジネスアーキテクチャ
+***** アプリケーションアーキテクチャ
+***** データアーキテクチャ
+***** テクノロジーアーキテクチャ
+**** ビジネスプリンシプル
+*** ビジネスモデル
+**** ビジネスモデルキャンバス
+** ビジネスケイパビリティとは
+*** ビジネスケイパビリティモデル
+**** ビジネスケイパビリティマップ
+**** トップダウンアプローチ
+**** ボトムアップアプローチ
+*** ビジネスケイパビリティとビジネスモデルの対応
+**** 階層化
+**** レベリング
+**** ヒートマッピング
+** バリューストリーム
+*** バリュー（価値）とは
+*** バリューの分析
+*** バリューチェーン
+*** バリューチェーンとバリューストリームの違い
+*** ケイパビリティをバリューストリームのステージにマッピングする
+*** バリューストリームとビジネスケイパビリティモデルの作成順序について
+** 組織マップ
+** 情報マップ
+** ビジネスシナリオ
+*** ビジネスシナリオの作成方法
+*** ビジネスシナリオワークショップ
+** ビジネスアーキテクチャの検討例
+*** ステップ1：ビジネスモデルキャンバスの活用
+*** ステップ2：バリューストリームの作成
+*** ステップ3：ケイパビリティの識別とマッピング
+*** ステップ4：アプリケーションアーキテクチャとデータアーキテクチャの設計
+
+@endmindmap
+```
+
+## ビジネスアーキテクチャとは
+
+> ビジネスアーキテクチャとは、エンタープライズがどのように価値を生み出し、それを顧客に提供するかの構造を表現するもの
+
+## ビジネスアーキテクチャを構成する主要な要素
+
+### プリンシプル
+
+「プリンシプル」とは、原理原則という意味です。
+
+それぞれの人が異なる立場や文化背景から考え方の違いを生じることがあります。そこで、プリンシプルはこのような場合に、考え方を統一するためのものとなります。
+
+#### ガイディングプリンシプル
+
+エンタープライズのビジョン、ミッション、価値観に基づいた基本的な方針や原則
+
+#### ビジネスプリンシプル
+
+ビジネスにおける原則原理を定義するもの
+
+### ビジネスモデル
+
+組織が価値を創造し、提供し、そして獲得する方法を体系的に説明するもの
+
+#### ビジネスモデルキャンバス
+
+ビジネスモデルのスケッチを作成するための直観的な技法
+
+## ビジネスケイパビリティ
+
+ビジネスが「何か」を行う能力
+
+### ビジネスケイパビリティモデル
+
+特定のビジネスや組織が持つ能力
+
+```plantuml
+@startmindmap
+
+* ビジネスケイパビリティマップ
+left side
+** 戦略
+*** ビジネスプラン
+*** マーケティング
+*** サプライヤ管理
+*** 出店計画
+*** 開発管理
+*** アライアンス
+right side
+** コア
+*** 生産管理
+*** 製品管理
+*** 配送管理
+*** 販売管理
+*** 店舗管理
+*** 購買
+** サポート
+*** 財務管理
+*** 教育管理
+*** 資材管理
+*** 人事管理
+*** ヘルプデスク
+*** 調達管理
+
+@endmindmap
+```
+
+### ビジネスケイパビリティとビジネスモデルの対応
+
+#### 階層化
+
+ビジネスケイパビリティを上位層、中間層、下位層の3つのカテゴリに分けるプロセス
+
+#### レベリング
+
+上位レベルのビジネスケイパビリティをより詳細に伝達するために、より下位のレベル（聴衆またはステークホルダにとって適切なレベル）に分解
+
+#### ヒートマッピング
+
+```plantuml
+@startmindmap
+
+* ビジネスケイパビリティマップ
+left side
+** 戦略
+***[#limegreen] ビジネスプラン
+***[#limegreen] マーケティング
+***[#limegreen] サプライヤ管理
+***[#limegreen] 出店計画
+***[#yellow] 開発管理
+***[#red] アライアンス
+right side
+** コア
+***[#yellow] 生産管理
+***[#limegreen] 製品管理
+***[#yellow] 配送管理
+***[#limegreen] 販売管理
+***[#limegreen] 店舗管理
+***[#limegreen] 購買
+** サポート
+***[#yellow] 財務管理
+***[#limegreen] 教育管理
+***[#limegreen] 資材管理
+***[#limegreen] 人事管理
+***[#orange] ヘルプデスク
+***[#limegreen] 調達管理
+@endmindmap
+```
+
+- グリーン：成熟度高
+- イエロー：成熟度中
+- レッド：成熟度低
+- オレンジ：新規に必要
+
+## バリューストリーム
+
+バリューストリームは、顧客への価値を提供する流れを川にたとえ、川上から川下へと価値を増加させる活動を表現したもの
+
+### バリュー（価値）とは
+
+「価値」は、組織が行うすべての活動の基盤です。組織の存在目的の1つは、ステークホルダに価値を提供することです。これはエンタープライズのビジネスモデルの土台であり、エンタープライズが価値を創出、提供、獲得するための理論的な根拠となります。
+
+### バリューの分析
+
+バリューチェーンは経済価値に重点を置いてます。バリューネットワークは価値創造と提供に関与するステークホルダの特定に焦点を合わせています。リーンバリューストリームは主に生産分野のビジネスプロセスの最適化に関しています。
+
+バリューストリームは、顧客やステークホルダからのエンドツーエンドの価値観を作り出すよう設計され、前述の他の手法が提供する財務、組織、運用のモデルよりも、組織のビジネスモデルの実現に密接に関わっています。
+
+### バリューチェーンとバリューストリームの違い
+
+バリューチェーンは企業がどのように価値を創出し、経済的利益を得るかを示すフレームワークであり、主にマクロレベルでの分析に適しています。バリューストリームは、ビジネスプロセスを詳細に分解し、どのようなコアアクティビティがどのようにして価値を生み出しているのかを明確にします。
+これにより、ビジネスアーキテクトやエンタープライズアーキテクトは、組織にケイパビリティを具体的な活動に紐付け、その活動がステークホルダーに有益な結果を提供するために不可欠なツールです。
+
+### ケイパビリティをバリューストリームのステージにマッピングする
+
+- ビジネスケイパビリティの特定
+- ステークホルダーの期待を満たすケイパビリティの評価
+- 不要なケイパビリティの排除
+
+### バリューストリームとビジネスケイパビリティモデルの作成順序について
+
+実践の場では、ビジネスケイパビリティモデルを作成する前に、バリューストリームマップを作成する方が一般的です。
+
+## 組織マップ
+
+```plantuml
+@startmindmap
+
+* A社
+** 研究
+***[#limegreen] 商品開発
+** 財務
+***[#limegreen] 財務管理
+** 法務
+***[#limegreen] 契約管理
+** 人事
+***[#limegreen] 人事管理
+** IT
+***[#limegreen] セキュリティ
+** カスタマーサポート
+***[#red] ヘルプデスク
+** 製造
+***[#yellow] 生産管理
+
+@endmindmap
+```
+
+## 情報マップ
+
+```plantuml
+@startuml
+
+entity "顧客" as customer
+
+entity "顧客ファイル" as customer_file
+
+entity "顧客属性" as customer_attribute
+
+entity "購買履歴" as purchase_history
+
+entity "請求情報" as billing_information
+
+entity "支払管理" as payment_management
+
+customer -- customer_file : 参照する
+customer_file -- customer_attribute
+customer_file -- purchase_history
+customer_file -- billing_information
+billing_information -- payment_management : 更新する
+
+@enduml
+```
+
+## ビジネスシナリオ
+
+ビジネスシナリオは、アーキテクチャが対応しなければならないビジネス要件の特定と理解を助けるための技法です。
+
+### ビジネスシナリオの作成方法
+
+1. 問題を特定し、文書化し、順序付を行う
+2. 問題が発生しているビジネスと技術の環境を高レベルなアーキテクチャモデルとして文書化する
+3. 目指すゴールを特定し、文書化する。また、問題に対処した結果を記述する
+4. ヒューマンアクター（参加者）とビジネスモデル上の位置を特定する
+5. コンピュータアクター（コンピューティングエレメント）とそれらのテクノロジーモデル上の位置を特定する
+6. 目的に対する適合性を確認し、必要であれば精緻化する
+
+```plantuml
+@startuml
+|顧客|
+start
+:店舗訪問;
+|店舗|
+:在庫照会;
+|配送業者|
+:在庫確認;
+|店舗|
+:在庫状況表示;
+|顧客|
+:購買決定;
+|店舗|
+:決済;
+|配送業者|
+:発注;
+|店舗|
+:納期回答;
+|配送業者|
+:配送;
+|顧客|
+:商品受け取り;
+
+@enduml
+```
+
+```plantuml
+@startuml
+left to right direction
+actor 顧客
+actor 配送業者
+actor 店舗
+
+rectangle {
+usecase "店舗訪問" as 店舗訪問
+usecase "商品受け取り" as 商品受け取り
+usecase "購買決定" as 購買決定
+usecase "在庫照会" as 在庫照会
+usecase "在庫確認" as 在庫確認
+usecase "在庫状況表示" as 在庫状況表示
+usecase "決済" as 決済
+usecase "発注" as 発注
+usecase "納期回答" as 納期回答
+usecase "配送" as 配送
+}
+
+顧客 --> 店舗訪問
+顧客 --> 購買決定
+顧客 --> 商品受け取り
+
+在庫照会 <-- 店舗
+在庫状況表示 <-- 店舗
+決済 <-- 店舗
+納期回答 <-- 店舗
+
+在庫確認 <-- 配送業者
+発注 <-- 配送業者
+配送 <-- 配送業者
+@enduml
+```
+
+## ビジネスアーキテクチャの検討例
+
+### ステップ1：ビジネスモデルキャンバスの活用
+
+```plantuml
+@startmindmap
+
+* クレイジークラスト社
+** 顧客
+*** 顧客セグメント
+**** 家族あり世帯
+**** 単身世帯
+**** オフィス
+*** 顧客関係
+**** 持ち帰り半額
+**** クーポン
+** 価値
+*** 価値提案
+**** 提供時間短縮
+**** おいしさ
+**** キャッシュレス
+**** プロモーション
+*** チャネル
+**** メディア報道
+**** ソーシャルメディア
+**** アプリ
+**** 口コミ
+** インフラ
+*** 主要活動
+**** 店舗売上増
+**** 競争力維持
+**** 店舗展開
+**** 顧客満足
+**** データ収集
+**** 分析
+*** 主要リソース
+**** 店員
+**** 店舗
+**** 配送車
+**** 収集データ
+*** 主要パートナー
+**** 店長
+**** 店員
+**** 技術指導員
+**** マーケター
+**** 投資家
+**** 保険会社
+** 資金
+*** 収益源
+*** コスト構造
+
+@endmindmap
+```
+
+### ステップ2：バリューストリームの作成
+
+```plantuml
+@startmindmap
+
+* クレイジークラスト社
+left side
+** 市場調査
+** 商品開発
+** 店舗展開
+** 店舗・アプリ受注
+** 販売提供
+right side
+** マーケティング
+***[#limegreen] マーケティング戦略
+***[#yellow] 市場調査
+** 研究開発
+***[#limegreen] メイン商品開発
+***[#limegreen] キャンペーン商品開発
+** 店舗展開
+***[#yellow] 店舗展開戦略
+***[#limegreen] 不動産
+** 店舗管理
+***[#limegreen] 店舗オーダー
+** アプリ
+***[#orange] 店舗アプリ
+** 店舗
+***[#limegreen] 資材管理
+***[#limegreen] 衛生管理
+***[#limegreen] 製造
+***[#yellow] 配送
+
+@endmindmap
+```
+
+### ステップ3：ケイパビリティの識別とマッピング
+
+```plantuml
+@startmindmap
+
+* クレイジークラスト社
+** マーケティング部門
+***[#yellow] マーケティング戦略
+** R&D部門
+***[#limegreen] 商品開発
+** 物流部門
+***[#yellow] サプライチェーン管理
+** 店舗部門
+***[#limegreen] 運営管理
+***[#limegreen] 資材管理
+***[#limegreen] 衛生管理
+***[#limegreen] 生産管理
+** IT部門
+***[#orange] アプリケーション開発
+** 管理部門
+***[#yellow] 人事管理
+***[#yellow] 財務管理
+***[#yellow] 資産管理
+
+@endmindmap
+```
+
+### ステップ4：アプリケーションアーキテクチャとデータアーキテクチャの設計
+
+#### 情報マップ
+
+```plantuml
+@startuml
+
+entity "顧客" as customer
+
+entity "顧客ファイル" as customer_file
+
+entity "顧客属性" as customer_attribute
+
+entity "購買履歴" as purchase_history
+
+entity "請求情報" as billing_information
+
+entity "支払管理" as payment_management
+
+customer -- customer_file : 参照する
+customer_file -- customer_attribute
+customer_file -- purchase_history
+customer_file -- billing_information
+billing_information -- payment_management : 更新する
+
+@enduml
+```
+
+#### ビジネスシナリオ
+
+```plantuml
+@startuml
+|顧客|
+start
+:店舗訪問;
+|店舗部門|
+:在庫照会;
+|物流部門|
+:在庫確認;
+|店舗部門|
+:在庫状況表示;
+|顧客|
+:購買決定;
+|店舗部門|
+:決済;
+|物流部門|
+:発注;
+|店舗部門|
+:納期回答;
+|物流部門|
+:配送;
+|顧客|
+:商品受け取り;
+
+@enduml
+```
+
+```plantuml
+@startuml
+left to right direction
+actor 顧客
+actor 物流部門
+actor 店舗部門
+
+rectangle {
+usecase "店舗訪問" as 店舗訪問
+usecase "商品受け取り" as 商品受け取り
+usecase "購買決定" as 購買決定
+usecase "在庫照会" as 在庫照会
+usecase "在庫確認" as 在庫確認
+usecase "在庫状況表示" as 在庫状況表示
+usecase "決済" as 決済
+usecase "発注" as 発注
+usecase "納期回答" as 納期回答
+usecase "配送" as 配送
+}
+
+顧客 --> 店舗訪問
+顧客 --> 購買決定
+顧客 --> 商品受け取り
+
+在庫照会 <-- 店舗部門
+在庫状況表示 <-- 店舗部門
+決済 <-- 店舗部門
+納期回答 <-- 店舗部門
+
+在庫確認 <-- 物流部門
+発注 <-- 物流部門
+配送 <-- 物流部門
+@enduml
+```

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

@@ -18,9 +18,15 @@ dateCreated: 2025-09-09T04:06:20.257Z
 
 ### アジャイルな計画づくりの原則
 
-- **計画よりも計画づくりを重視**：計画は生きた文書として継続的に更新
-- **変化を促進**：要件や状況の変化に柔軟に対応
-- **フィーチャ中心**：顧客価値を提供するフィーチャを計画の単位に
+- **計画よりも計画づくりを重視**:
+
+  計画は生きた文書として継続的に更新
+- **変化を促進**:
+
+  要件や状況の変化に柔軟に対応
+- **フィーチャ中心**:
+
+  顧客価値を提供するフィーチャを計画の単位に
 
 ```plantuml
 @startuml
@@ -108,15 +114,25 @@ state 満足条件を満たすか <<choice>>
 @enduml
 ```
 
-#### ステップ1：満足条件の決定
+#### ステップ1:
+
+満足条件の決定
+
+プロダクトオーナーと協力して以下を定義:
 
-プロダクトオーナーと協力して以下を定義：
+- **スコープ**:
 
-- **スコープ**：どんなフィーチャを含むか
-- **スケジュール**：いつまでに完成させるか
-- **リソース**：どのようなチーム構成で開発するか
+  どんなフィーチャを含むか
+- **スケジュール**:
 
-#### ステップ2：ユーザーストーリーの見積もり
+  いつまでに完成させるか
+- **リソース**:
+
+  どのようなチーム構成で開発するか
+
+#### ステップ2:
+
+ユーザーストーリーの見積もり
 
 **ストーリーポイント法を推奨**
 
@@ -131,7 +147,9 @@ state 満足条件を満たすか <<choice>>
 4. 合意に至るまで議論・再見積もり
 ```
 
-#### ステップ3：ベロシティの見積もり
+#### ステップ3:
+
+ベロシティの見積もり
 
 **新チームの場合**
 - 代表的なストーリーをタスクに分解
@@ -146,14 +164,24 @@ state 満足条件を満たすか <<choice>>
   - 業務分野
   - 開発環境
 
-#### ステップ4：優先順位の決定
+#### ステップ4:
+
+優先順位の決定
 
 **4つの評価軸**
 
-1. **金銭価値**：新規売上、効率化効果
-2. **コスト**：開発・運用・サポートコスト
-3. **知識習得**：プロダクトナレッジ・プロジェクトナレッジ
-4. **リスク軽減**：技術的・ビジネス的リスクの低減
+1. **金銭価値**:
+
+   新規売上、効率化効果
+2. **コスト**:
+
+   開発・運用・サポートコスト
+3. **知識習得**:
+
+   プロダクトナレッジ・プロジェクトナレッジ
+4. **リスク軽減**:
+
+   技術的・ビジネス的リスクの低減
 
 ### 1.3 リリース計画の更新
 
@@ -197,13 +225,17 @@ state チームはコミットできるか <<choice>>
 @enduml
 ```
 
-#### ステップ1：イテレーションゴールの設定
+#### ステップ1:
+
+イテレーションゴールの設定
 
 - 1-2行でイテレーションで達成することを記述
 - チーム全員が理解できる明確な目標
 - フィーチャの価値に焦点を当てる
 
-#### ステップ2：ストーリーのタスク分解
+#### ステップ2:
+
+ストーリーのタスク分解
 
 **良いタスクの特徴**
 - 4-16理想時間で完了可能
@@ -216,7 +248,9 @@ state チームはコミットできるか <<choice>>
 - その他（ドキュメント作成、環境構築）
 - スパイク（調査・検証タスク）
 
-#### ステップ3：理想時間での見積もり
+#### ステップ3:
+
+理想時間での見積もり
 
 ```markdown
 # 理想時間の原則

package/lib/assets/docs/reference//350/250/200/350/252/236/345/210/245/351/226/213/347/231/272/343/202/254/343/202/244/343/203/211.md

@@ -9,19 +9,36 @@
 ### 1. バージョン管理 (Git)
 全ての変更は Git で管理し、意味のある単位でコミットします。
 
-- **コミットメッセージ規約（Angular形式）**:
+- **コミットメッセージ規約(Angular形式)**:
+
   `type(scope): subject` の形式で記述します。
-  - `feat`: 新機能
-  - `fix`: バグ修正
-  - `test`: テストの追加・修正
-  - `refactor`: リファクタリング
-  - `chore`: 雑事（設定変更等）
+  - `feat`:
+
+    新機能
+  - `fix`:
+
+    バグ修正
+  - `test`:
+
+    テストの追加・修正
+  - `refactor`:
+
+    リファクタリング
+  - `chore`:
+
+    雑事(設定変更等)
 
 ### 2. テスティング (TDD)
 テスト駆動開発 (Test-Driven Development) を実践します。
-1. **Red**: 失敗するテストを書く
-2. **Green**: テストを通す最小限の実装を書く
-3. **Refactor**: コードをきれいに整理する
+1. **Red**:
+
+   失敗するテストを書く
+2. **Green**:
+
+   テストを通す最小限の実装を書く
+3. **Refactor**:
+
+   コードをきれいに整理する
 
 ### 3. 自動化
 コマンド一つでビルド、テスト、静的解析を実行できるようにします。また、ファイル変更を監視して自動的にテストを実行する「継続的テスト」を活用します。
@@ -30,21 +47,40 @@
 
 ## 共通の開発フロー
 
-1. **環境の起動**: `nix develop .#<language>`
-2. **プロジェクトの初期化**: 各言語のパッケージマネージャで初期化
-3. **Git初期化**: `git init` (まだの場合)
-4. **TDDサイクル**: 継続的テストを回しながら実装
-5. **静的解析**: リンターやフォーマッタでコード品質をチェック
-6. **コミット**: `git add .` -> `git commit -m '...'`
+1. **環境の起動**:
+
+   `nix develop .#<language>`
+2. **プロジェクトの初期化**:
+
+   各言語のパッケージマネージャで初期化
+3. **Git初期化**:
+
+   `git init` (まだの場合)
+4. **TDDサイクル**:
+
+   継続的テストを回しながら実装
+5. **静的解析**:
+
+   リンターやフォーマッタでコード品質をチェック
+6. **コミット**:
+
+   `git add .` -> `git commit -m '...'`
 
 ---
 
 ## 言語別ガイド
 
 ### 1. Node.js / TypeScript
-- **起動コマンド**: `nix develop .#node`
-- **主要ツール**: Node.js (v22), npm, TypeScript, ESLint, Prettier
+
+- **起動コマンド**:
+
+  `nix develop .#node`
+- **主要ツール**:
+
+  Node.js (v22), npm, TypeScript, ESLint, Prettier
 - **初期化**:
+
+
   ```bash
   npm init -y
   ```

package/package.json

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

package/lib/assets/.mcp.json

@@ -1,12 +0,0 @@
-{
-  "mcpServers": {
-    "codex": {
-      "type": "stdio",
-      "command": "npx",
-      "args": [
-        "@modelcontextprotocol/server-memory"
-      ],
-      "env": {}
-    }
-  }
-}