npm - @k2works/claude-code-booster - Versions diffs - 0.23.0 → 1.0.0 - Mend

@k2works/claude-code-booster 0.23.0 → 1.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (59) hide show

package/lib/assets/.claude/{commands/dev.md → skills/orchestrating-development/SKILL.md} RENAMED Viewed

@@ -1,56 +1,56 @@
-## Development Guide Reference
+---
+name: orchestrating-development
+description: 開発フェーズ全体の TDD ワークフローをオーケストレーション。バックエンド・フロントエンド開発の進め方、Codex 分業体制を案内。開発フェーズの開始や開発手法の確認時に使用。
+---
-開発フェーズ全体の作業を支援するコマンド。TDD サイクルに従った開発ワークフローを表示します。
+# 開発フェーズオーケストレーション
-### 使い方
+開発フェーズ全体の作業を支援します。TDD サイクルに従った開発ワークフローを提供します。
-```bash
-/dev [オプション]
-```
+## Instructions
-### オプション
+### 1. オプション
 - なし : 開発フェーズ全体のワークフローを表示
 - `--codex` : Claude（計画・設計・受入）と Codex（実装）の分業体制で開発
-### 基本例
+### 2. 基本例
 ```bash
 # 開発フェーズ全体のワークフロー表示
-/dev
-「開発フェーズの全体的な進め方と TDD サイクルの説明」
+# 「開発フェーズの全体的な進め方と TDD サイクルの説明」
 # Claude と Codex の分業体制で開発
-/dev --codex
-「US-103 お知らせ管理を開始。計画・設計は Claude、実装は Codex が担当」
+# --codex
+# 「US-103 お知らせ管理を開始。計画・設計は Claude、実装は Codex が担当」
 ```
-### 詳細機能
+### 3. 開発フェーズの全体像
-#### 開発フェーズの全体像
+開発フェーズは以下の工程で構成されます:
-開発フェーズは以下の工程で構成されます：
+1. **バックエンド開発** (Skill: `developing-backend`)
-1. **バックエンド開発** (`/dev-backend`)
    - 実装
    - ビルド・テスト
    - インサイドアウトアプローチ推奨
-2. **フロントエンド開発** (`/dev-frontend`)
+2. **フロントエンド開発** (Skill: `developing-frontend`)
    - 実装
    - ビルド・テスト
    - アウトサイドインアプローチ推奨
-#### TDD サイクルの実践
+### 4. TDD サイクルの実践
-Red-Green-Refactor サイクルを厳密に実行：
+Red-Green-Refactor サイクルを厳密に実行:
 1. **Red フェーズ**: 失敗するテストを最初に書く
 2. **Green フェーズ**: テストを通す最小限のコードを実装
 3. **Refactor フェーズ**: 重複を除去し設計を改善
 4. @docs/reference/コーディングとテストガイド.md のワークフローに従う
-#### 参照ドキュメント
+### 5. 参照ドキュメント
 - @docs/reference/CodexCLIMCPアプリケーション開発フロー.md を参照
 - @docs/design/architecture.md を参照
@@ -63,18 +63,19 @@ Red-Green-Refactor サイクルを厳密に実行：
 - @docs/design/test_strategy.md を参照
 - 作業完了後に対象のイテレーション @docs/development/iteration_plan-N.md の進捗を更新する
-#### アプローチ戦略の選択
+### 6. アプローチ戦略の選択
-プロジェクトの状態に応じた最適なアプローチを選択：
+プロジェクトの状態に応じた最適なアプローチを選択:
 - **インサイドアウト**: データ層から開始し上位層へ展開（バックエンド推奨）
 - **アウトサイドイン**: UI から開始しドメインロジックを段階的に実装（フロントエンド推奨）
-#### Codex を活用した開発モード（--codex）
+### 7. Codex を活用した開発モード（--codex）
 `--codex` オプションを指定すると、Claude と Codex の分業体制で開発を進めます。
 **前提条件**:
 - Codex MCP サーバーが設定済みであること
 - @docs/reference/CodexCLIMCPサーバー設定手順.md を参照
 - @docs/reference/CodexCLIMCPアプリケーション開発フロー.md を参照
@@ -120,9 +121,9 @@ graph LR
 | 粒度 | 推奨度 | 説明 |
 |------|--------|------|
-| タスク単位（1-3 ファイル） | ✅ 推奨 | 1 つのコンポーネントや機能単位 |
-| 機能単位（3-5 ファイル） | ⚠️ 注意 | 進捗確認を頻繁に行う |
-| ユーザーストーリー単位 | ❌ 非推奨 | タスクに分割して実行 |
+| タスク単位（1-3 ファイル） | 推奨 | 1 つのコンポーネントや機能単位 |
+| 機能単位（3-5 ファイル） | 注意 | 進捗確認を頻繁に行う |
+| ユーザーストーリー単位 | 非推奨 | タスクに分割して実行 |
 **Codex が書き込みできない場合の対処**:
@@ -130,32 +131,28 @@ graph LR
 2. ユーザーに状況を報告し、確認を待つ
 3. ユーザーの許可を得てから代替手段を実行
-### 開発フローの実践
-`/dev --codex` を使用した開発フローの実践例：
+### 8. 開発フローの実践
-#### 1. 計画フェーズ（Claude）
+`--codex` を使用した開発フローの実践例:
-```bash
-# イテレーションのユーザーストーリー開始
-/dev --codex
-「US-103 お知らせ管理を開始。計画・設計は Claude、実装は Codex が担当」
-```
+#### 計画フェーズ（Claude）
 Claude の活動:
 1. イテレーション計画を読み込み
 2. 受入条件を確認
 3. 既存コードを調査（API、フロントエンド構造）
 4. タスクリストを作成
-#### 2. 設計フェーズ（Claude）
+#### 設計フェーズ（Claude）
 Claude の活動:
 1. API エンドポイント設計を確認
 2. フロントエンドコンポーネント設計
 3. Codex への詳細指示を作成
-#### 3. 実装フェーズ（Codex）
+#### 実装フェーズ（Codex）
 **Codex への指示例**:
@@ -171,12 +168,6 @@ mcp__codex__codex
     ## タスク
     1. AuthContext に role と canManageAnnouncements を追加
     2. API クライアントに create/update/delete 関数を追加
-    3. ConfirmDialog コンポーネントを作成
-    4. AnnouncementForm コンポーネントを作成
-    ## 既存パターン参照
-    - API クライアント: src/lib/api.ts
-    - フォームコンポーネント: src/components/ui/Input.tsx
     ## 完了条件
     - ESLint エラーなし
@@ -196,36 +187,38 @@ mcp__codex__codex-reply
   prompt: "テストを実行して結果を確認してください"
 ```
-#### 4. 受入フェーズ（Claude）
+#### 受入フェーズ（Claude）
 Claude の活動:
 1. 設計レビュー: 実装が設計に準拠しているか確認
 2. E2E テスト作成: 成功基準に基づくテストを作成
 3. E2E テスト実行: 機能が正しく動作することを検証
 4. バグ修正: 問題があれば修正
 **受入基準**:
 - [ ] すべての受入条件が満たされている
 - [ ] E2E テストがすべてパス
 - [ ] ESLint エラーがない
 - [ ] 既存テストが壊れていない
-### 注意事項
+### 9. 注意事項
 - **前提条件**: プロジェクトのテスト環境が設定済みであること
 - **制限事項**: TDD の三原則を厳密に守る（テストなしでプロダクションコードを書かない）
 - **推奨事項**: コミット前に必ず品質チェックリストを実行
-### ベストプラクティス
+### 10. ベストプラクティス
 1. **TODO 駆動開発**: タスクを細かい TODO に分割してから実装開始
 2. **小さなサイクル**: Red-Green-Refactor を 10-15 分で完了させる
 3. **継続的コミット**: 各サイクル完了時に動作する状態でコミット
 4. **Rule of Three**: 同じコードが 3 回現れたらリファクタリング
-### 関連コマンド
+### 関連スキル / ドキュメント
-- `/dev-backend` : バックエンド開発ガイド
-- `/dev-frontend` : フロントエンド開発ガイド
+- Skill: `developing-backend` : バックエンド開発ガイド
+- Skill: `developing-frontend` : フロントエンド開発ガイド
 - @docs/reference/CodexCLIMCPアプリケーション開発フロー.md : アプリケーション開発フロー
 - @docs/reference/CodexCLIMCPサーバー設定手順.md : Codex MCP サーバー設定手順