yodogawa 1.0.0 → 1.0.1

package/.windsurf/workflows/a-002-InitializeProject.md

@@ -23,6 +23,7 @@ auto_execution_mode: 1
 ### 1. ドキュメントディレクトリの確認
 
 - `docs/project/requirements/` ディレクトリの存在を確認：
+
   ```bash
   ls -la docs/project/requirements/ 2>/dev/null || echo "ディレクトリが存在しません"
   ```
@@ -30,9 +31,30 @@ auto_execution_mode: 1
 - ディレクトリが存在しない場合：
   - ユーザーに通知：「`docs/project/requirements/` ディレクトリが見つかりません。先に `SetupDocStructure` (a-001) を実行してディレクトリ構造を作成してください。」
 
-### 2. システム概要の作成
+### 2. コードベースの自動分析と提案
+
+1. **コードベースの全体調査**:
+
+   - プロジェクトのルートにある `README.md`, `package.json`, および主要なソースコードを読み込む。
+   - 以下のコマンド等を使用して現状を把握する:
+     ```bash
+     ls -F
+     cat package.json 2>/dev/null
+     cat README.md 2>/dev/null
+     find src app lib -maxdepth 2 2>/dev/null
+     ```
+
+2. **AI による分析と提案**:
+   - 読み込んだ情報を基に、以下の内容を分析・推測し、ユーザーに提示する。
+     - **システム概要**: プロジェクトの目的、主要な技術スタック。
+     - **実装済み機能**: ファイル構造やコードから推測される機能。
+     - **ユーザーストーリー**: 想定されるユーザー像と利用シーン。
+   - この分析結果は、後続のステップ（システム概要の作成、機能一覧の作成など）の基礎情報として活用する。
+
+### 3. システム概要の作成
 
 1. **テンプレートの準備**:
+
    ```bash
    cp ".windsurf/templates/project/01-requirements/01-system-overview.md" "docs/project/requirements/01-system-overview.md"
    ```
@@ -41,24 +63,28 @@ auto_execution_mode: 1
    以下の質問を行い、その回答で `docs/project/requirements/01-system-overview.md` を更新する。
 
    #### 背景
+
    - 「このシステムで解決しようとしている**具体的な問題や課題**は何ですか？」
    - 「その問題はなぜ重要ですか？放置した場合のリスクは？」
    - 「問題の影響を受けるステークホルダー（ユーザー、組織、チームなど）は誰ですか？」
    - 「具体的な数値やデータ（例：作業時間、コスト、離脱率など）があれば教えてください。」
 
    #### 目的
+
    - 「このシステムが提供する**具体的な価値や解決策**は何ですか？」
-   - 「期待される成果や変化を、測定可能な形で表現できますか？（例：作業時間50%削減）」
+   - 「期待される成果や変化を、測定可能な形で表現できますか？（例：作業時間 50%削減）」
    - 「どのように問題を解決するか、具体的なメカニズムや仕組みを教えてください。」
 
-### 3. 実装済み機能一覧の作成
+### 4. 実装済み機能一覧の作成
 
 1. **テンプレートの準備**:
+
    ```bash
    cp ".windsurf/templates/project/01-requirements/02-features-implemented.md" "docs/project/requirements/02-features-implemented.md"
    ```
 
 2. **コードベースの調査と提案**:
+
    - プロジェクト内のソースコードを簡易検索し、実装済みの兆候を探す。
      ```bash
      # 主要なソースディレクトリの構造を確認（例）
@@ -78,78 +104,91 @@ auto_execution_mode: 1
      - **Category 2**（中分類：認証、プロフィールなど）
      - **機能名**（ユーザー視点の名称）
      - **説明**（何ができるか）
-     - **機能ID**（FN-XXX形式、連番）
+     - **機能 ID**（FN-XXX 形式、連番）
 
-### 4. 予定機能一覧の作成
+### 5. 予定機能一覧の作成
 
 1. **テンプレートの準備**:
+
    ```bash
    cp ".windsurf/templates/project/01-requirements/03-features-planned.md" "docs/project/requirements/03-features-planned.md"
    ```
 
 2. **要件ギャップ分析と提案**:
+
    - 「システム概要」で確認した目的・スコープと、「実装済み機能」の差分を分析する。
    - 未実装と思われる主要機能をリストアップし、ユーザーに提案する。
      - 「システム概要で『〇〇機能』への言及がありましたが、まだ実装されていないようです。これを予定機能に追加しますか？」
-     - 「現在の実装には『××』が含まれていますが、これに関連する『△△機能』は将来的に必要になりますか？」
+     - 「現在の実装には『××』が含まれていますが、これに関連する『△△ 機能』は将来的に必要になりますか？」
 
 3. **ヒアリングと記入**:
    提案内容へのフィードバックを含め、以下の質問を行う。回答をテーブル形式で `docs/project/requirements/03-features-planned.md` に記入する。
 
    - 「今後実装予定の機能をリストアップしてください（提案した機能含む）。各機能について以下を明確にします：」
+
      - **Category 1**（大分類）
      - **Category 2**（中分類）
      - **機能名**（アイデア段階でも可）
      - **説明**（目的や価値を中心に）
-     
-     ※テンプレートの方針に従い、**機能ID**や**優先度**はこの段階では確定させず、柔軟性を重視して記載しない。
 
-### 5. 非機能要件一覧の作成
+     ※テンプレートの方針に従い、**機能 ID**や**優先度**はこの段階では確定させず、柔軟性を重視して記載しない。
+
+### 6. 非機能要件一覧の作成
 
 1. **テンプレートの準備**:
+
    ```bash
    cp ".windsurf/templates/project/01-requirements/04-non-functional-requirements.md" "docs/project/requirements/04-non-functional-requirements.md"
    ```
 
 2. **必要性の確認と標準提案**:
+
    - ユーザーに定義の必要性を確認する：
+
      - 「現段階で非機能要件（パフォーマンス、セキュリティなど）を詳細に定義する必要がありますか？『標準的な設定』で仮置きして後で調整することも可能です。」
-   
+
    - 必要または仮置きの場合、一般的なベストプラクティスを提案する：
-     - 「Webアプリケーションの標準的な目標値として、以下を提案します。これで問題ないか確認してください：」
-       - **パフォーマンス**: ページ読み込み3秒以内、API応答500ms以内
-       - **セキュリティ**: HTTPS必須、パスワードはハッシュ化、基本認証/OAuth
-       - **可用性**: 日次バックアップ、稼働率99.5%（平日日中）
+     - 「Web アプリケーションの標準的な目標値として、以下を提案します。これで問題ないか確認してください：」
+       - **パフォーマンス**: ページ読み込み 3 秒以内、API 応答 500ms 以内
+       - **セキュリティ**: HTTPS 必須、パスワードはハッシュ化、基本認証/OAuth
+       - **可用性**: 日次バックアップ、稼働率 99.5%（平日日中）
 
 3. **ヒアリングと記入**:
    提案内容への合意、または独自の要件がある場合、以下の観点で**定量的な目標**を確認し、回答で `docs/project/requirements/04-non-functional-requirements.md` の各テーブルを更新する。
 
    #### パフォーマンス
+
    - 「ページ読み込み時間の目標は？」
-   - 「APIレスポンス時間の目標は？」
+   - 「API レスポンス時間の目標は？」
    - 「想定される同時接続ユーザー数、データ量は？」
 
    #### セキュリティ
+
    - 「認証方式、機密データの扱い、コンプライアンス要件は？」
 
    #### 可用性・信頼性
+
    - 「稼働率目標、許容ダウンタイム、バックアップ要件は？」
 
    #### スケーラビリティ
+
    - 「ユーザー数の成長予測、ピーク時のトラフィック想定は？」
 
    #### ユーザビリティ・保守性
+
    - 「アクセシビリティ、対応言語、デバイス、ブラウザは？」
    - 「ログ・監視要件、デプロイ頻度は？」
 
-### 6. ユーザーストーリーの作成
+### 7. ユーザーストーリーの作成
 
 1. **テンプレートの準備**:
+
    ```bash
    cp ".windsurf/templates/project/01-requirements/05-user-stories.md" "docs/project/requirements/05-user-stories.md"
    ```
 
 2. **分析と提案**:
+
    - ここまで作成した「システム概要」「機能一覧（実装済み/予定）」を分析し、主要なユーザージャーニーを抽出する。
    - ユーザーに代表的なストーリーを提案する：
      - 「『〇〇機能』に基づき、以下のストーリーが考えられますが、いかがでしょうか？」
@@ -161,33 +200,34 @@ auto_execution_mode: 1
    - 「他に主要なユーザージャーニーがあれば教えてください（[役割]として、[目的]がしたい、なぜなら[理由]）。」
    - 各ストーリーの優先度、受け入れ基準を確認する。
 
-### 7. 全体レビュー
+### 8. 全体レビュー
 
 - 作成した全てのドキュメントをユーザーに提示し、内容の正確性を確認する。
   - 「記載内容に誤りや漏れはありませんか？」
   - 「抽象的すぎる記述や、後で解釈が分かれそうな表現はありますか？」
   - 「テンプレートのコメントや不要な例示は適切に処理（残す/削除）されていますか？」
 
-### 8. 完了条件と構造の確認
+### 9. 完了条件と構造の確認
 
 - 以下の完了条件を満たしていて、且つドキュメントの構造が適切であることを確認します。
-  
+
   1. **ファイルの存在と構造確認**:
      各ファイルが存在し、テンプレートの主要な構造（見出しやテーブル）が維持されているか検証する。
+
      ```bash
      # 01-system-overview.md: 主要セクションの確認
      grep "## 背景" docs/project/requirements/01-system-overview.md && echo "OK" || echo "MISSING: 背景"
      grep "## 目的" docs/project/requirements/01-system-overview.md && echo "OK" || echo "MISSING: 目的"
-     
+
      # 02-features-implemented.md: テーブルヘッダーの確認
      grep "| 機能ID | Category 1 |" docs/project/requirements/02-features-implemented.md && echo "OK" || echo "MISSING: Table Header"
-     
+
      # 03-features-planned.md: テーブルヘッダーの確認
      grep "| Category 1 | Category 2 |" docs/project/requirements/03-features-planned.md && echo "OK" || echo "MISSING: Table Header"
-     
+
      # 04-non-functional-requirements.md: テーブルヘッダーの確認
      grep "| カテゴリ | 要件 |" docs/project/requirements/04-non-functional-requirements.md && echo "OK" || echo "MISSING: Table Header"
-     
+
      # 05-user-stories.md: テーブルヘッダーの確認
      grep "| ストーリーID | ストーリー |" docs/project/requirements/05-user-stories.md && echo "OK" || echo "MISSING: Table Header"
      ```
@@ -197,7 +237,7 @@ auto_execution_mode: 1
      - [ ] 各ファイルがテンプレートの基本構造を維持していて、主要なセクションやテーブルが適切に記載されている
      - [ ] プレースホルダーが適切な内容に置き換わっていいる
 
-### 9. Git への追加（オプション）
+### 10. Git への追加（オプション）
 
 - ユーザーに確認：「作成した要件定義ドキュメントを Git に追加しますか？」
 - 「はい」の場合、以下を実行：
@@ -206,6 +246,7 @@ auto_execution_mode: 1
   git status
   ```
 - Git status の結果を表示し、コミットメッセージの提案をする：
+
   ```
   推奨コミットメッセージ:
   docs: 要件定義ドキュメントの作成
@@ -226,4 +267,4 @@ auto_execution_mode: 1
 - 競合する要件や矛盾が発見された場合：
   - 「以下の要件が競合しています：[詳細]。優先順位や調整方針を確認させてください。」と報告する。
 - 想定工数が非現実的に大きい場合：
-  - 「現在の計画では実現が困難です。スコープ縮小や優先度調整を検討しませんか？」と提案する。
+  - 「現在の計画では実現が困難です。スコープ縮小や優先度調整を検討しませんか？」と提案する。

package/README.md

@@ -2,71 +2,69 @@
 
 ## リポジトリ概要
 
-Windsurfで活用するスラッシュコマンドとワークフローの保管庫。調査・要件定義から実装、テスト、デプロイ、Git運用までの開発プロセスを対象としたMarkdownドキュメントを蓄積し、他プロジェクトでも即座に呼び出せるナレッジベースを目指す。
+Windsurf で活用するスラッシュコマンドとワークフローの保管庫。調査・要件定義から実装、テスト、デプロイ、Git 運用までの開発プロセスを対象とした Markdown ドキュメントを蓄積し、他プロジェクトでも即座に呼び出せるナレッジベースを目指す。
 
 ## 目的
 
 - 反復的な開発タスクを標準化し、スラッシュコマンドとして再利用可能にする。
-- 調査、仕様策定、実装支援、デバッグ、レビュー、リリース、Git管理など各フェーズのベストプラクティスを明文化する。
-- 実行可能コードは置かず、Windsurfでのコマンド入力やドキュメント参照に最適化したMarkdown中心の構成を維持する。
+- 調査、仕様策定、実装支援、デバッグ、レビュー、リリース、Git 管理など各フェーズのベストプラクティスを明文化する。
+- 実行可能コードは置かず、Windsurf でのコマンド入力やドキュメント参照に最適化した Markdown 中心の構成を維持する。
 
 ## ディレクトリ構成
 
-- `.windsurf/workflows/` — スラッシュコマンド定義（各種ワークフローMarkdown）
+- `.windsurf/workflows/` — スラッシュコマンド定義（各種ワークフロー Markdown）
   - `a-NNN-*.md` — プロジェクト設計ワークフロー（要件定義、設計、アーキテクチャ）
   - `b-NNN-*.md` — タスク管理ワークフロー（タスク作成、リサーチ、実装計画）
   - `c-NNN-*.md` — 実装実行ワークフロー（ステップバイステップ実装）
   - `x-Object-Action.md` — 補助的なワークフロー（例: `x-Code-Refactor`, `x-CI-Setup`, `x-Repository-PushToGithub`）
   - `z-*.md` — メタワークフロー（ワークフロー作成支援など）
-- `.windsurf/templates/` — テンプレート定義（各種テンプレートMarkdown）
+- `.windsurf/templates/` — テンプレート定義（各種テンプレート Markdown）
   - `project/` — プロジェクトレベルのテンプレート
   - `tasks/task-template/` — タスクレベルのテンプレート
     - `a-definition.md` — タスク定義テンプレート
     - `b-research.md` — リサーチテンプレート
     - `c-implementation.md` — 実装タスクリストテンプレート
 - `README.md` — リポジトリの使い方と方針
-- `CLAUDE.md` — Claude Code向けプロジェクト説明
+- `CLAUDE.md` — Claude Code 向けプロジェクト説明
 - `slash-commands-best-practices.md` - スラッシュコマンドのベストプラクティス
 
-## 使い方
+## インストール
 
-### 基本的な使い方
-
-1. Windsurfで必要なワークフローを参照したいタイミングで該当Markdownを開く。
+1. Windsurf で必要なワークフローを参照したいタイミングで該当 Markdown を開く。
 2. コマンド化したい手順はスラッシュコマンドとしてコピーし、自身のプロジェクトで呼び出して利用する。
-3. 新規ワークフローを追加する際は`.windsurf/workflows/`配下にMarkdownを作成し、ファイル名は用途が想起できるスラッグ形式にする（例: `jira-ticket.md`）。
+3. 新規ワークフローを追加する際は`.windsurf/workflows/`配下に Markdown を作成し、ファイル名は用途が想起できるスラッグ形式にする（例: `jira-ticket.md`）。
 
 ### ワークフロー体系
 
-本リポジトリは開発ライフサイクル全体をカバーする4つのワークフロー系列を提供します：
+本リポジトリは開発ライフサイクル全体をカバーする 4 つのワークフロー系列を提供します：
 
-- **A系列**: プロジェクト設計ワークフロー（要件定義、ドメインモデル、設計）
-- **B系列**: タスク管理ワークフロー（タスク作成、リサーチ、実装計画）
-- **C系列**: 実装実行ワークフロー（ステップバイステップ実装、ドキュメント更新）
-- **X系列**: 補助的なワークフロー（リファクタリング、CI/CD、コード生成など）
+- **A 系列**: プロジェクト設計ワークフロー（要件定義、ドメインモデル、設計）
+- **B 系列**: タスク管理ワークフロー（タスク作成、リサーチ、実装計画）
+- **C 系列**: 実装実行ワークフロー（ステップバイステップ実装、ドキュメント更新）
+- **X 系列**: 補助的なワークフロー（リファクタリング、CI/CD、コード生成など）
 
-## プロジェクト設計ワークフロー（A系列）
+## プロジェクト設計ワークフロー（A 系列）
 
 プロジェクト開始時に一度実行し、要件定義からドメインモデル、設計までを体系的に作成します。
 
-### 実行順序（A系列）
+### 実行順序（A 系列）
 
 **要件・ドメインフェーズ**（a-001 〜 a-006）:
 
 1. `/a-001-SetupDocStructure` — ドキュメント構造のセットアップ
 2. `/a-002-InitializeProject` — プロジェクト初期化（課題、解決策、スコープ）
-3. `/a-003-CreateScenarios` — BDD形式でのシナリオ定義（Gherkin）
+3. `/a-003-CreateScenarios` — BDD 形式でのシナリオ定義（Gherkin）
 4. `/a-004-DefineDomainModel` — ドメインモデル定義（Event Storming）
-5. `/a-005-CreateDomainDiagram` — DDD設計（Bounded Context、Aggregate）
+5. `/a-005-CreateDomainDiagram` — DDD 設計（Bounded Context、Aggregate）
 6. **`/a-006-ReviewRequirementsDomain`** — 要件とドメインモデルのレビュー ⭐
 
 **設計フェーズ**（a-007 〜 a-014）:
 
 1. `/a-007-DefineTechStack` — 技術スタック選定
 2. `/a-008-DefineRepositoryStructure` — リポジトリ構造定義
-3. `/a-009-DefineScreenDesign` — 画面設計（Empty State重視）
+3. `/a-009-DefineScreenDesign` — 画面設計（Empty State 重視）
 4. `/a-010-DefineDataModel` — データモデル設計（ERD）
-5. `/a-011-DefineAPISpec` — API仕様定義
+5. `/a-011-DefineAPISpec` — API 仕様定義
 6. `/a-012-DefineArchitecture` — アーキテクチャ設計（ADR）
 7. `/a-013-DefineInfrastructure` — インフラ設計（RPO/RTO）
 8. **`/a-014-ReviewDesign`** — 設計ドキュメントの一貫性レビュー ⭐
@@ -78,30 +76,34 @@ Windsurfで活用するスラッシュコマンドとワークフローの保管
 
 これらのレビューワークフローにより、実装前にドキュメント間の不整合を検出し、手戻りを防止します。
 
-## タスク管理ワークフロー（B系列）
+## タスク管理ワークフロー（B 系列）
 
 タスクの計画から実装まで、以下のワークフローを順次実行します：
 
 1. **タスクディレクトリ作成**: `/b-000-CreateTaskDirectory`
-   - タスクID自動採番（task000001, task000002, ...）
+
+   - タスク ID 自動採番（task000001, task000002, ...）
    - ディレクトリ作成: `docs/tasks/task000001-{スラッグ}/`
    - テンプレートファイル（a-definition.md, b-research.md, c-implementation.md）を自動コピー
 
 2. **タスク定義**: `/b-001-CreateTaskDefinition`
+
    - 目的の明確化（解決する問題、提供する価値）
    - ユーザーストーリーの定義
    - 変更内容の詳細化（画面、データモデル、API、ビジネスロジック）
    - 受け入れ基準の定義（正常系、異常系、テスト、セキュリティ）
 
 3. **リサーチ**: `/b-002-CreateTaskResearch`
+
    - ベストプラクティスの調査
    - 既存コードの調査と再利用可能性の確認
    - 技術選定（ライブラリ、フレームワーク）
    - 技術的リスクの洗い出しと軽減策
 
 4. **実装計画**: `/b-003-CreateTaskImplementation`
-   - フェーズ分割（1-3日粒度）
-   - ステップ定義（1-3時間粒度）
+
+   - フェーズ分割（1-3 日粒度）
+   - ステップ定義（1-3 時間粒度）
    - 成果物の明確化（具体的なファイル名）
    - フェーズごとの受け入れ基準
 
@@ -114,25 +116,26 @@ Windsurfで活用するスラッシュコマンドとワークフローの保管
 
 ### タスクレビューの重要性
 
-b-004は実装開始前の「最後の砦」として、以下を保証します：
+b-004 は実装開始前の「最後の砦」として、以下を保証します：
 
 - すべての変更内容に実装ステップが存在する（漏れ防止）
 - すべてのユーザーストーリーが実装でカバーされている（要件充足）
 - 技術的リスクの軽減策が計画されている（リスク管理）
 - 既存コンポーネントが再利用されている（車輪の再発明防止）
 
-## 実装実行ワークフロー（C系列）
+## 実装実行ワークフロー（C 系列）
 
 タスクレビュー（b-004）完了後、実装を実行し、完了後にドキュメントを更新します。
 
-### 実行順序（C系列）
+### 実行順序（C 系列）
 
 1. **実装実行**: `/c-001-ImplementTask`
-   - 各ステップを順次実行（speckit.implementスタイル）
+
+   - 各ステップを順次実行（speckit.implement スタイル）
    - 依存関係を尊重、並列実行を最適化（`[P]`マーク）
    - ステップごとにテスト実行とチェックボックス更新
    - フェーズごとに受け入れ基準を確認
-   - 最終テスト、コミット、PR作成
+   - 最終テスト、コミット、PR 作成
 
 2. **ドキュメント更新**: `/c-002-UpdateDocumentation`
    - 実装完了後にドキュメントを実装内容に合わせて更新
@@ -144,17 +147,17 @@ b-004は実装開始前の「最後の砦」として、以下を保証します
 
 ### 実装
 
-c-001は以下の原則に従います：
+c-001 は以下の原則に従います：
 
 - **仕様駆動開発**: タスク定義とリサーチが実行可能な仕様として機能
-- **段階的な実装**: ステップごとに進める（1ステップ = 1-3時間）
+- **段階的な実装**: ステップごとに進める（1 ステップ = 1-3 時間）
 - **依存関係の尊重**: 順序を守り、前ステップ完了を確認
 - **並列実行の最適化**: `[P]`マークで独立ステップを並列実行
 - **継続的な検証**: 各ステップでテスト実行、受け入れ基準を確認
 
-## 補助的なワークフロー（X系列）
+## 補助的なワークフロー（X 系列）
 
-実装中に必要となる補助的なタスクを実行するワークフローです。Object-Action命名規則に従います。
+実装中に必要となる補助的なタスクを実行するワークフローです。Object-Action 命名規則に従います。
 
 ### 主要なワークフロー
 
@@ -172,30 +175,30 @@ c-001は以下の原則に従います：
 **開発環境・CI/CD**:
 
 - `/x-DevEnvironment-Setup` — 開発環境セットアップ
-- `/x-CI-Setup` — CI/CDセットアップ
-- `/x-CI-FixFailure` — CI失敗修正
+- `/x-CI-Setup` — CI/CD セットアップ
+- `/x-CI-FixFailure` — CI 失敗修正
 - `/x-Logging-Add` — ログ実装
 
 **コード生成・最適化**:
 
-- `/x-Component-Create` — UIコンポーネント生成
+- `/x-Component-Create` — UI コンポーネント生成
 - `/x-Migration-Create` — マイグレーション作成
 - `/x-Database-Seed` — データベースシード
 - `/x-Bundle-Optimize` — バンドル最適化
 
 **Git・リポジトリ管理**:
 
-- `/x-Repository-Push` — GitHub/GitLabへのプッシュ（汎用）
-- `/x-Repository-PushToGithub` — GitHubへのプッシュ
+- `/x-Repository-Push` — GitHub/GitLab へのプッシュ（汎用）
+- `/x-Repository-PushToGithub` — GitHub へのプッシュ
 
 **その他**:
 
 - `/x-Dependencies-Update` — 依存関係更新
 - `/x-Accessibility-Check` — アクセシビリティ監査
 
-### X系列の特徴
+### X 系列の特徴
 
-- **フレームワーク非依存**: React/Vue/Svelte、Prisma/TypeORM、Webpack/Viteなど複数の技術に対応
+- **フレームワーク非依存**: React/Vue/Svelte、Prisma/TypeORM、Webpack/Vite など複数の技術に対応
 - **再利用可能**: どのプロジェクトでも即座に利用可能
 - **チェックリスト形式**: 実行漏れを防止
 - **ベストプラクティス統合**: 公式ドキュメントや業界標準を反映
@@ -244,13 +247,13 @@ c-001は以下の原則に従います：
 
 ### レビューワークフローの位置づけ
 
-3つのレビューワークフロー（⭐マーク）が品質を保証します：
+3 つのレビューワークフロー（⭐ マーク）が品質を保証します：
 
-| レビュー | タイミング | 対象 | 効果 |
-|---------|----------|------|------|
-| **a-006** | 要件・ドメイン完成時 | 要件 ↔ シナリオ ↔ ドメインモデル | ドメイン設計の妥当性検証 |
-| **a-014** | 設計完成時 | データモデル ↔ API ↔ 画面 ↔ アーキテクチャ | 設計の一貫性検証 |
-| **b-004** | 各タスク実装前 | タスク定義 ↔ リサーチ ↔ 実装計画 | 実装漏れ防止 |
+| レビュー  | タイミング           | 対象                                       | 効果                     |
+| --------- | -------------------- | ------------------------------------------ | ------------------------ |
+| **a-006** | 要件・ドメイン完成時 | 要件 ↔ シナリオ ↔ ドメインモデル           | ドメイン設計の妥当性検証 |
+| **a-014** | 設計完成時           | データモデル ↔ API ↔ 画面 ↔ アーキテクチャ | 設計の一貫性検証         |
+| **b-004** | 各タスク実装前       | タスク定義 ↔ リサーチ ↔ 実装計画           | 実装漏れ防止             |
 
 ### タスクディレクトリ構造の例
 
@@ -271,10 +274,10 @@ docs/
         └── c-implementation.md
 ```
 
-各タスクディレクトリには3つのドキュメントが含まれ、タスクの計画から実装まで一貫して管理できます。
+各タスクディレクトリには 3 つのドキュメントが含まれ、タスクの計画から実装まで一貫して管理できます。
 
 ## 更新ポリシー
 
 - 各ドキュメントは最新の開発手法に合わせて継続的に改善する。
-- 重複や冗長な情報は統合し、DRY原則を徹底する。
-- 追加の開発フェーズや管理領域が生じた場合は、該当するスラッシュコマンドを新設してREADMEにも追記する。
+- 重複や冗長な情報は統合し、DRY 原則を徹底する。
+- 追加の開発フェーズや管理領域が生じた場合は、該当するスラッシュコマンドを新設して README にも追記する。

package/bin/cli.js

@@ -1,35 +1,45 @@
 #!/usr/bin/env node
 
-const fs = require("fs-extra");
-const path = require("path");
-const prompts = require("prompts");
-const { bold, green, cyan, red } = require("kleur");
+const fs = require('fs-extra');
+const path = require('path');
+const prompts = require('prompts');
+const { bold, green, cyan, red } = require('kleur');
 
 async function main() {
-  console.log(
-    bold().cyan("\n🚀 Welcome to Yodogawa Slash Commands Installer!\n")
-  );
+  console.log(bold().cyan('\n🚀 Welcome to Yodogawa Slash Commands Installer!\n'));
 
   const response = await prompts({
-    type: "select",
-    name: "type",
-    message: "Which configuration would you like to install?",
+    type: 'select',
+    name: 'type',
+    message: 'Which configuration would you like to install?',
     choices: [
-      { title: "Windsurf (.windsurf)", value: "windsurf" },
-      { title: "Antigravity (.agent)", value: "antigravity" },
-    ],
+      { title: 'Windsurf (.windsurf)', value: 'windsurf' },
+      { title: 'Antigravity (.agent)', value: 'antigravity' },
+      { title: 'Cursor (.cursor)', value: 'cursor' },
+      { title: 'Claude Code (.claude)', value: 'claude' }
+    ]
   });
 
   if (!response.type) {
-    console.log(red("✖ Operation cancelled."));
+    console.log(red('✖ Operation cancelled.'));
     process.exit(0);
   }
 
   // Determine source directory (where the package is installed)
-  const sourceDir = path.join(__dirname, "..", ".windsurf");
-
+  const sourceDir = path.join(__dirname, '..', '.windsurf');
+  
   // Determine target directory (current working directory of the user)
-  const targetDirName = response.type === "windsurf" ? ".windsurf" : ".agent";
+  let targetDirName;
+  if (response.type === 'windsurf') {
+    targetDirName = '.windsurf';
+  } else if (response.type === 'antigravity') {
+    targetDirName = '.agent';
+  } else if (response.type === 'cursor') {
+    targetDirName = '.cursor';
+  } else {
+    targetDirName = '.claude';
+  }
+  
   const targetDir = path.join(process.cwd(), targetDirName);
 
   if (!fs.existsSync(sourceDir)) {
@@ -41,14 +51,14 @@ async function main() {
   try {
     if (fs.existsSync(targetDir)) {
       const confirm = await prompts({
-        type: "confirm",
-        name: "overwrite",
+        type: 'confirm',
+        name: 'overwrite',
         message: `Directory ${targetDirName} already exists. Overwrite?`,
-        initial: false,
+        initial: false
       });
 
       if (!confirm.overwrite) {
-        console.log(red("✖ Operation cancelled."));
+        console.log(red('✖ Operation cancelled.'));
         process.exit(0);
       }
     }
@@ -56,19 +66,29 @@ async function main() {
     console.log(`\nCopying workflows to ${bold(targetDirName)}...`);
     await fs.copy(sourceDir, targetDir);
 
-    console.log(
-      green(`\n✔ Successfully installed ${response.type} workflows!`)
-    );
+    // Special handling for Cursor and Claude Code: rename workflows to commands
+    if (response.type === 'cursor' || response.type === 'claude') {
+      const workflowsDir = path.join(targetDir, 'workflows');
+      const commandsDir = path.join(targetDir, 'commands');
+      
+      if (fs.existsSync(workflowsDir)) {
+        console.log(`Renaming workflows to commands for ${response.type}...`);
+        await fs.move(workflowsDir, commandsDir, { overwrite: true });
+      }
+    }
+    
+    console.log(green(`\n✔ Successfully installed ${response.type} workflows!`));
     console.log(`\nNext steps:`);
     console.log(`1. Open ${bold(targetDirName)} to explore the workflows.`);
     console.log(`2. Start using them in your project!\n`);
+    
   } catch (err) {
     console.error(red(`\n✖ Error copying files: ${err.message}`));
     process.exit(1);
   }
 }
 
-main().catch((err) => {
+main().catch(err => {
   console.error(red(err));
   process.exit(1);
 });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "yodogawa",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "description": "CLI to install Yodogawa Slash Commands workflows",
   "bin": {
     "yodogawa": "./bin/cli.js"