yodogawa 1.0.0 → 1.0.2

package/.windsurf/scripts/setup-docs.sh

@@ -0,0 +1,92 @@
+#!/bin/bash
+
+# setup-docs.sh
+# プロジェクトのドキュメントディレクトリ構造を作成するスクリプト
+
+set -e
+
+DOCS_DIR="docs"
+
+echo "📂 ドキュメント構造のセットアップを開始します..."
+
+# 1. 現在の状態確認
+if [ -d "$DOCS_DIR" ]; then
+  echo "⚠️  '$DOCS_DIR' ディレクトリは既に存在します。"
+  read -p "既存の構造を保持したまま、不足しているディレクトリを追加しますか？ (y/N): " confirm
+  if [[ ! "$confirm" =~ ^[Yy]$ ]]; then
+    echo "❌ 中断しました。"
+    exit 0
+  fi
+fi
+
+# 2. ディレクトリ構造の作成
+echo "🔨 ディレクトリを作成中..."
+mkdir -p "$DOCS_DIR/project/01-requirements"
+mkdir -p "$DOCS_DIR/project/02-behavior"
+mkdir -p "$DOCS_DIR/project/03-domain"
+mkdir -p "$DOCS_DIR/project/04-design"
+mkdir -p "$DOCS_DIR/tasks"
+
+# 3. docs/README.md の作成
+README_FILE="$DOCS_DIR/README.md"
+if [ -f "$README_FILE" ]; then
+  echo "⚠️  '$README_FILE' は既に存在します。"
+  read -p "上書きしますか？ (y/N): " confirm_readme
+  if [[ ! "$confirm_readme" =~ ^[Yy]$ ]]; then
+    echo "ℹ️  READMEの作成をスキップしました。"
+  else
+    CREATE_README=true
+  fi
+else
+  CREATE_README=true
+fi
+
+if [ "$CREATE_README" = true ]; then
+  echo "📝 README.md を作成中..."
+  cat > "$README_FILE" <<EOF
+# プロジェクトドキュメント
+
+このディレクトリには、プロジェクト全体のドキュメントと個別タスクのドキュメントを管理します。
+
+## 構成
+
+### project/
+プロジェクト全体のドキュメント。要件定義、設計、アーキテクチャなど、プロジェクトスコープ全体に関わる情報を記載します。
+
+- **01-requirements/**: 要件定義（システム概要、機能要件、非機能要件、ユーザーストーリーなど）
+- **02-behavior/**: 振る舞い定義（シナリオ、ユースケース、ユーザージャーニーなど）
+- **03-domain/**: ドメインモデル（エンティティ、用語集など）
+- **04-design/**: 設計（アーキテクチャ、データモデル、API仕様など）
+
+### tasks/
+個別タスクのドキュメント。Issue やチケット単位で作成します。
+
+## 更新方針
+
+### プロジェクト全体のドキュメント (project/)
+- プロジェクトのスコープ全体に影響する情報を記載
+- チーム全体で共有すべき要件・設計・アーキテクチャを管理
+- 更新時は関係者にレビューを依頼
+
+### 個別タスクのドキュメント (tasks/)
+- 特定の Issue やチケットに紐づく情報を記載
+- タスク単位で作成・完了・アーカイブ
+- 完了後は参照資料として保持、または削除
+
+## ドキュメント作成ガイドライン
+
+- **具体的**: 抽象的な表現を避け、数値・期限・制約を明確に記載
+- **測定可能**: 成功基準やパフォーマンス目標を定量化
+- **最新**: 変更があれば速やかに更新し、古い情報を残さない
+- **簡潔**: 必要最低限の情報に絞り、詳細はコードやリンク先に委ねる
+EOF
+fi
+
+# 4. 完了報告
+echo ""
+echo "✅ ドキュメントディレクトリ構造のセットアップが完了しました！"
+echo ""
+find "$DOCS_DIR" -maxdepth 2 | sort
+echo ""
+echo "次のステップ:"
+echo "  - 必要に応じて 'git add $DOCS_DIR' を実行してください。"

package/.windsurf/workflows/a-001-SetupDocStructure.md

@@ -5,8 +5,6 @@ auto_execution_mode: 1
 
 # SetupDocStructure (a-001)
 
-
-
 ## 目的
 
 - プロジェクトルートに標準化されたドキュメントディレクトリ構造を作成する。
@@ -19,110 +17,29 @@ auto_execution_mode: 1
 
 ## 手順
 
-### 1. 現在の状態確認
+### 1. スクリプトの実行
 
-- プロジェクトルートで `docs/` ディレクトリの存在を確認する：
+- ドキュメント構造セットアップのために、スクリプト `.windsurf/scripts/setup-docs.sh` を実行してください。
   ```bash
-  ls -la docs/ 2>/dev/null || echo "docs/ ディレクトリは存在しません"
+  bash .windsurf/scripts/setup-docs.sh
   ```
-- 既に `docs/` が存在する場合は、ユーザーに確認する：
-  - 「既に `docs/` ディレクトリが存在します。既存の構造を保持したまま、不足しているディレクトリを追加しますか？」
-  - ユーザーが「はい」と回答した場合のみ続行する。
-
-### 2. ディレクトリ構造の作成
-
-- 以下のディレクトリ構造を作成する：
 
-```
-docs/
-├── project/
-│   ├── 01-requirements/    # 要件定義
-│   ├── 02-behavior/         # 振る舞い定義
-│   ├── 03-domain/           # ドメインモデル
-│   └── 04-design/           # 設計
-└── tasks/                   # 個別タスク
-```
+### 2. 結果の確認
 
-- `mkdir -p` コマンドで一括作成：
-  ```bash
-  mkdir -p docs/project/01-requirements docs/project/02-behavior docs/project/03-domain docs/project/04-design docs/tasks
-  ```
-
-- 作成結果を確認：
-  ```bash
-  find docs/ -type d | sort
+- スクリプトの実行結果を確認し、エラーがないことを確認してください。
+- 生成された構造：
   ```
-
-### 3. docs/README.md の作成
-
-- `docs/README.md` が既に存在する場合は、ユーザーに確認する：
-  - 「`docs/README.md` が既に存在します。上書きしますか、それとも既存のファイルを保持しますか？」
-
-- 以下の内容で `docs/README.md` を作成（または上書き）：
-
-```markdown
-# プロジェクトドキュメント
-
-このディレクトリには、プロジェクト全体のドキュメントと個別タスクのドキュメントを管理します。
-
-## 構成
-
-### project/
-プロジェクト全体のドキュメント。要件定義、設計、アーキテクチャなど、プロジェクトスコープ全体に関わる情報を記載します。
-
-- **01-requirements/**: 要件定義（システム概要、機能要件、非機能要件、ユーザーストーリーなど）
-- **02-behavior/**: 振る舞い定義（シナリオ、ユースケース、ユーザージャーニーなど）
-- **03-domain/**: ドメインモデル（エンティティ、用語集など）
-- **04-design/**: 設計（アーキテクチャ、データモデル、API仕様など）
-
-### tasks/
-個別タスクのドキュメント。Issue やチケット単位で作成します。
-
-## 更新方針
-
-### プロジェクト全体のドキュメント (project/)
-- プロジェクトのスコープ全体に影響する情報を記載
-- チーム全体で共有すべき要件・設計・アーキテクチャを管理
-- 更新時は関係者にレビューを依頼
-
-### 個別タスクのドキュメント (tasks/)
-- 特定の Issue やチケットに紐づく情報を記載
-- タスク単位で作成・完了・アーカイブ
-- 完了後は参照資料として保持、または削除
-
-## ドキュメント作成ガイドライン
-
-- **具体的**: 抽象的な表現を避け、数値・期限・制約を明確に記載
-- **測定可能**: 成功基準やパフォーマンス目標を定量化
-- **最新**: 変更があれば速やかに更新し、古い情報を残さない
-- **簡潔**: 必要最低限の情報に絞り、詳細はコードやリンク先に委ねる
-```
-
-### 4. 作成結果の確認
-
-- ディレクトリ構造とREADMEが正しく作成されたか確認：
-  ```bash
-  ls -R docs/
-  ```
-
-- ユーザーに作成結果を報告：
-  ```
-  ✅ ドキュメントディレクトリ構造を作成しました：
-
   docs/
-  ├── README.md (作成済み - ドキュメント構成の説明)
+  ├── README.md
   ├── project/
   │   ├── 01-requirements/
   │   ├── 02-behavior/
   │   ├── 03-domain/
   │   └── 04-design/
   └── tasks/
-
-  次のステップ:
-  - ドキュメントの作成を開始してください。
   ```
 
-### 5. Git への追加（オプション）
+### 3. Git への追加（オプション）
 
 - ユーザーに確認：「作成したディレクトリ構造を Git に追加しますか？」
 - 「はい」の場合、以下を実行：
@@ -131,6 +48,7 @@ docs/
   git status
   ```
 - Git status の結果を表示し、コミットメッセージの提案をする：
+
   ```
   推奨コミットメッセージ:
   ドキュメント構造の初期化
@@ -139,13 +57,11 @@ docs/
   - ドキュメント構成を説明する docs/README.md を追加
   ```
 
-### 6. 完了条件の確認
+### 4. 完了条件の確認
 
 - 以下の完了条件を満たしているか、チェックリストで確認してください：
-  - [ ] `docs/` ディレクトリが作成されている
-  - [ ] `docs/project/` 配下に `01-requirements/`, `02-behavior/`, `03-domain/`, `04-design/` ディレクトリが存在する
-  - [ ] `docs/tasks/` ディレクトリが存在する
-  - [ ] `docs/README.md` が作成されている
+  - [ ] スクリプトが正常に終了した
+  - [ ] `docs/` ディレクトリ構造が正しく作成されている
 
 ## 完了条件
 
@@ -162,4 +78,4 @@ docs/
 - ファイルシステムの権限エラーが発生した場合：
   - 「ディレクトリの作成に失敗しました。書き込み権限を確認してください。」とユーザーに通知する。
 - Git リポジトリでない場合に Git 追加を試みた場合：
-  - 「このディレクトリは Git リポジトリではありません。Git の初期化が必要な場合は `git init` を実行してください。」と案内する。
+  - 「このディレクトリは Git リポジトリではありません。Git の初期化が必要な場合は `git init` を実行してください。」と案内する。

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,35 @@ auto_execution_mode: 1
 - ディレクトリが存在しない場合：
   - ユーザーに通知：「`docs/project/requirements/` ディレクトリが見つかりません。先に `SetupDocStructure` (a-001) を実行してディレクトリ構造を作成してください。」
 
-### 2. システム概要の作成
+### 2. コードベースの自動分析と提案
+
+1. **コードベースの規模確認**:
+
+   - プロジェクトのルートにあるファイルやディレクトリを確認する。
+     ```bash
+     ls -F
+     ```
+   - **スキップ判断**:
+     - ファイルがほとんど存在しない（例: `.git` ディレクトリのみ、あるいは `README.md` だけなど）、または有意なソースコードが見当たらない場合は、このステップをスキップする。
+     - スキップする場合、ユーザーに「コードベースが空、または十分な情報がないため、自動分析をスキップします。」と通知し、次のステップへ進む。
+
+2. **詳細調査と分析（コードが存在する場合）**:
+   - `README.md`, `package.json`, および主要なソースコードを読み込む。
+     ```bash
+     cat package.json 2>/dev/null
+     cat README.md 2>/dev/null
+     find src app lib -maxdepth 2 2>/dev/null
+     ```
+   - 読み込んだ情報を基に、以下の内容を分析・推測し、ユーザーに提示する。
+     - **システム概要**: プロジェクトの目的、主要な技術スタック。
+     - **実装済み機能**: ファイル構造やコードから推測される機能。
+     - **ユーザーストーリー**: 想定されるユーザー像と利用シーン。
+   - この分析結果は、後続のステップ（システム概要の作成、機能一覧の作成など）の基礎情報として活用する。
+
+### 3. システム概要の作成
 
 1. **テンプレートの準備**:
+
    ```bash
    cp ".windsurf/templates/project/01-requirements/01-system-overview.md" "docs/project/requirements/01-system-overview.md"
    ```
@@ -41,24 +68,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 +109,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 +205,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 +242,7 @@ auto_execution_mode: 1
      - [ ] 各ファイルがテンプレートの基本構造を維持していて、主要なセクションやテーブルが適切に記載されている
      - [ ] プレースホルダーが適切な内容に置き換わっていいる
 
-### 9. Git への追加（オプション）
+### 10. Git への追加（オプション）
 
 - ユーザーに確認：「作成した要件定義ドキュメントを Git に追加しますか？」
 - 「はい」の場合、以下を実行：
@@ -206,6 +251,7 @@ auto_execution_mode: 1
   git status
   ```
 - Git status の結果を表示し、コミットメッセージの提案をする：
+
   ```
   推奨コミットメッセージ:
   docs: 要件定義ドキュメントの作成
@@ -226,4 +272,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.2",
   "description": "CLI to install Yodogawa Slash Commands workflows",
   "bin": {
     "yodogawa": "./bin/cli.js"