spec-runner 1.0.6 → 1.0.8

package/templates/claude/CLAUDE.md

@@ -1,141 +0,0 @@
-# 開発ルール（Claude Code 向け）
-
-このプロジェクトは **.spec-runner/scripts/spec-runner.sh** によるフェーズゲートで運用している。  
-本ファイルは AI 向けの指示であり、**.spec-runner/scripts/spec-runner.sh** はフェーズが通過していないと実行を拒否するため、設計をスキップできない。
-
----
-
-## 最優先ルール
-
-**何かを実装する前に必ず実行せよ：**
-
-`./.spec-runner/scripts/spec-runner.sh status`（チャットでは `/sr-状態`）で現在のフェーズを確認する。
-
-`phase` が `implement` でない場合、実装コードを生成してはならない。
-代わりに「現在のフェーズを確認してください」と伝えてユーザーに委ねよ。
-
----
-
-## TDD（テスト駆動）ルール（デフォルトで有効）
-
-**実装フェーズに進むまでに、テストを必ず含める。**
-
-1. **テスト設計** … `docs/04_テスト設計/<UC名>.md` を書く
-2. **テストを先に書く（Red）** … 実装より前にテストコードを書き、失敗することを確認する
-3. **テストコードをコミット** … `./.spec-runner/scripts/spec-runner.sh set-gate test_code_committed` でゲート通過
-4. **実装で Green** … `implement` フェーズでテストを通す実装を書く
-
-ドキュメントだけでなく**テストコードも必須**。テストを書かずに実装に進むことはできない。ゲートが `TEST_DIR` 配下の未コミットを検出し、コミットするまで `implement` に進めない。
-
-- **テストのパス**は `.spec-runner/config.sh` の `TEST_DIR` で動的に指定（例: `tests`, `spec`, `__tests__`）。ここに置いたテストが未コミットだと implement ゲートでブロックされる。
-- TDD をオプションにしたい場合: `export TDD_ENABLED="false"` にすると、実装前にテストコードを書かなくても `implement` に進める。
-
----
-
-## スラッシュコマンド（チャット用）
-
-### .claude/commands/（Claude Code カスタムスラッシュコマンド）
-
-`.claude/commands/` に Markdown を置くと、チャット欄で `/sr-憲章` や `/sr-状態` などのスラッシュコマンドとして呼び出せる。各ファイルは「spec-runner.sh を実行せよ」という指示になっており、**ハード強制**に繋がる。コマンド一覧は **README の「スラッシュコマンド」** を参照。各 .md 内の `$ARGUMENTS` には、ユーザーがスラッシュの後に続けて入力した文字列が入る。
-
-### 自然言語・短いスラッシュでの依頼
-
-ユーザーが `/init`・`/status`・`/design-high` などの短いスラッシュ、または「init して」「顧客登録で design-high まで進めて」などの自然言語で依頼した場合も、**必ず** 対応する `./.spec-runner/scripts/spec-runner.sh` をターミナルで実行すること（上記の `/sr-*` と同じ動作）。
-
----
-
-## フェーズ別の行動規則
-
-### require（要件定義）フェーズ
-- `docs/01_要件/<UC名>.md` を編集する
-- 実装・設計・テーブル定義は書かない
-- 完了後: `./.spec-runner/scripts/spec-runner.sh review-pass docs/01_要件/<UC名>.md`
-
-### design-high（概要設計）フェーズ
-- `docs/02_概要設計/<UC名>.md` を編集する
-- ユースケース記述とドメインモデル候補の洗い出しのみ
-- **具体的なメソッド定義・テーブルカラムは書かない**
-- 新しい概念が出たら先に `docs/03_用語集.md` に追加する
-- 完了後: `./.spec-runner/scripts/spec-runner.sh review-pass docs/02_概要設計/<UC名>.md`
-
-### design-detail（詳細設計）フェーズ
-この順序で作業する：
-
-1. **domain** → `docs/03_詳細設計/<UC名>/ドメイン.md`
-   - エンティティ・値オブジェクト・ドメインイベント・集約・リポジトリIF
-   - 振る舞い（メソッド）の定義
-   - ← レビュー通過後に次へ
-
-2. **usecase** → `docs/03_詳細設計/<UC名>/ユースケース.md`
-   - ドメインモデルを使う設計（ドメインモデルを参照して書く）
-   - Command/Query の入出力・シーケンス図
-   - ← レビュー通過後に次へ
-
-3. **table** → `docs/03_詳細設計/<UC名>/テーブル.md`
-   - ドメインモデル ≠ テーブル（用途で分けてOK）
-   - ER図（Mermaid）
-   - ← レビュー通過後に次へ
-
-4. **infra** → `docs/03_詳細設計/<UC名>/インフラ.md`
-   - APIエンドポイント定義
-   - リポジトリ実装方針
-   - フロントエンドコンポーネント構成
-   - ← レビュー通過後に次へ
-
-### test-design（テスト設計）フェーズ
-- `docs/04_テスト設計/<UC名>.md` を編集する
-- **TDD: テストコードを実装より先に書く（Red 状態で OK）**
-- テストコードをコミットしてから次へ: `./.spec-runner/scripts/spec-runner.sh set-gate test_code_committed`
-- 完了後: `./.spec-runner/scripts/spec-runner.sh review-pass docs/04_テスト設計/<UC名>.md`
-
-### implement（実装）フェーズ
-- **TDD: テストを Green にする実装を書く**
-- 設計と乖離した場合は先にドキュメントを更新する
-- コードとドキュメントを同一コミットに含める
-- 実装完了後: git push → PR。次のユースケースは `./.spec-runner/scripts/spec-runner.sh init <名前>` で開始
-
----
-
-## ドキュメント同時更新ルール
-
-| 変更内容 | 必ず同時更新するもの |
-|---------|-------------------|
-| `Domain/` 配下のクラス変更 | `docs/03_詳細設計/<UC名>/ドメイン.md` |
-| `UseCase/` 配下のクラス変更 | `docs/03_詳細設計/<UC名>/ユースケース.md` |
-| `Infrastructure/Api/` の変更 | `docs/03_詳細設計/<UC名>/インフラ.md` |
-| DBマイグレーション | `docs/03_詳細設計/<UC名>/テーブル.md` |
-| 新しいエンティティ/値オブジェクト | `docs/03_用語集.md` |
-| アーキテクチャ判断 | `docs/99_設計判断記録/<番号>-<タイトル>.md` |
-
----
-
-## ユビキタス言語ルール
-
-- 設計ドキュメント → `docs/03_用語集.md` の **日本語** 列を使う
-- コード（クラス名・メソッド名・変数名）→ **英語** 列を使う
-- PHPDoc/JSDoc → 日本語のユビキタス言語を `@description` に併記する
-- 新しい概念が登場 → **まず `docs/03_用語集.md` に追加してから**設計・実装に入る
-
----
-
-## DDDレイヤー依存ルール（違反禁止）
-
-```
-Infrastructure → UseCase → Domain
-```
-
-- `Domain/` のコードは `UseCase/` や `Infrastructure/` を import してはならない
-- `UseCase/` のコードは `Infrastructure/` の具体実装を import してはならない
-- Eloquentモデルは `Infrastructure/Persistence/` のみで使用する
-
----
-
-## Gitコミットメッセージ
-
-```
-<type>(<scope>): <日本語の説明>
-
-type: feat, fix, docs, refactor, test, chore
-scope: domain, usecase, infra, frontend, design, adr, test
-```
-

package/templates/copilot/.github/copilot-instructions.md

@@ -1,25 +0,0 @@
-# spec-runner（GitHub Copilot 用指示）
-
-このプロジェクトは **.spec-runner/scripts/spec-runner.sh** によるフェーズゲートで運用している。実装前に必ずフェーズを確認すること。
-
-## 最優先
-
-- 実装コードを書く前に **必ず** `./.spec-runner/scripts/spec-runner.sh status` を実行する。
-- `phase` が `implement` でないときは実装コードを生成しない。ユーザーに「現在のフェーズを確認してください」と伝える。
-- ユーザーが「init して」「status 確認して」「design-high で進めて」などと言ったら、対応する `./.spec-runner/scripts/spec-runner.sh` をターミナルで実行する。
-- スラッシュコマンド `/sr-初期化` などは `.github/prompts/*.prompt.md` に定義済み（コマンド名は日本語）。`tools: [shell]` でシェル実行される。
-
-## TDD（テスト駆動）— デフォルトで有効
-
-- 実装前に **テスト設計ドキュメント** と **テストコード** を必ず書く。テストを先に書いて Red → 実装で Green。
-- `.spec-runner/config.sh` の `TDD_ENABLED=false` で無効化すると、テストなしでも implement に進める（オプション）。
-
-## フェーズとコマンド
-
-- require → design-high → design-detail (domain → usecase → table → infra) → test-design → implement
-- 各フェーズ完了時: `./.spec-runner/scripts/spec-runner.sh review-pass <該当ファイル>`
-- ゲート: `./.spec-runner/scripts/spec-runner.sh set-gate glossary_checked` など
-- 実装完了後: git push → PR。次のユースケースは `init <名前>` で開始
-- 修正: `./.spec-runner/scripts/spec-runner.sh fix "内容"` / `./.spec-runner/scripts/spec-runner.sh hotfix "内容"`
-
-詳細はプロジェクトの README を参照。

package/templates/copilot/.github/prompts/sr-/343/202/262/343/203/274/343/203/210/350/250/255/345/256/232.prompt.md

@@ -1,14 +0,0 @@
----
-agent: 'agent'
-description: 'spec-runner: ゲート通過を記録'
-argument-hint: 'ゲート名（例: 用語集確認済み、テストコードコミット済み）'
-tools: ['shell']
----
-
-以下を**必ずシェルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh set-gate ${input:gate:ゲート名}
-```
-
-ゲート名は日本語（用語集確認済み、テストコードコミット済み など）または英語キーで指定できます。引数が空の場合は、ユーザーに「ゲート名を指定してください。例: 用語集確認済み、テストコードコミット済み」と伝えてください。

package/templates/copilot/.github/prompts/sr-/343/203/206/343/202/271/343/203/210/350/250/255/350/250/210.prompt.md

@@ -1,13 +0,0 @@
----
-agent: 'agent'
-description: 'spec-runner: テスト設計フェーズへ移行'
-tools: ['shell']
----
-
-以下を**必ずシェルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh test-design
-```
-
-実行結果をユーザーに伝えてください。

package/templates/copilot/.github/prompts/sr-/343/203/254/343/203/223/343/203/245/343/203/274.prompt.md

@@ -1,14 +0,0 @@
----
-agent: 'agent'
-description: 'spec-runner: レビュー通過を記録'
-argument-hint: 'ファイルパス（例: docs/01_要件/顧客登録.md）'
-tools: ['shell']
----
-
-以下を**必ずシェルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh review-pass ${input:path:レビュー通過させるファイルパス}
-```
-
-引数が空の場合は、ユーザーに「ファイルパスを指定してください」と伝えてください。

package/templates/copilot/.github/prompts/sr-/344/273/225/346/247/230.prompt.md

@@ -1,13 +0,0 @@
----
-agent: 'agent'
-description: 'spec-runner: プロジェクト仕様を編集。何を作るか・なぜか・スコープを docs/02_仕様.md に書く'
-tools: []
----
-
-**チャットで使うプロンプト**。プロジェクト仕様を編集します。
-
-1. `docs/02_仕様.md` の内容を読み、必要なら開く。
-2. ユーザーと一緒に「このプロジェクトで作るもの」「作る理由」「スコープ（含む/含まない）」「想定ユーザー」を書き足す・修正する。
-3. 曖昧な点があれば質問して解消する。
-
-init の前に書いておくと、最初のユースケースを決めやすくなる。

package/templates/copilot/.github/prompts/sr-/344/277/256/346/255/243.prompt.md

@@ -1,14 +0,0 @@
----
-agent: 'agent'
-description: 'spec-runner: 通常修正（設計変更を伴う）'
-argument-hint: '修正内容'
-tools: ['shell']
----
-
-以下を**必ずシェルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh fix "${input:content:修正内容}"
-```
-
-引数が空の場合は、ユーザーに「修正内容を指定してください」と伝えてください。

package/templates/copilot/.github/prompts/sr-/345/210/235/346/234/237/345/214/226.prompt.md

@@ -1,15 +0,0 @@
----
-agent: 'agent'
-description: 'spec-runner: ユースケースを初期化（未設定なら詳細設定の対話から）。チャットで /sr-初期化 ユースケース名 集約名 と入力して使う'
-argument-hint: 'ユースケース名 集約名（例: 顧客登録 顧客管理）。空なら設定対話のみ'
-tools: ['shell']
----
-
-**チャットで /sr-初期化 と入力して使う**。以下を**必ずシェルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh init ${input:args:ユースケース名 集約名（スペース区切り。集約名は省略可）}
-```
-
-- **引数あり**: 未設定なら詳細設定の対話 → ユースケース作成。
-- **引数が空**: 設定対話のみ。ユースケースを作らない場合はこのまま実行でよい。ユースケースを作る場合は引数で名前を指定するよう伝えてください。

package/templates/copilot/.github/prompts/sr-/345/256/237/350/243/205.prompt.md

@@ -1,13 +0,0 @@
----
-agent: 'agent'
-description: 'spec-runner: 実装フェーズへ移行'
-tools: ['shell']
----
-
-以下を**必ずシェルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh implement
-```
-
-実行結果をユーザーに伝えてください。

package/templates/copilot/.github/prompts/sr-/346/206/262/347/253/240.prompt.md

@@ -1,13 +0,0 @@
----
-agent: 'agent'
-description: 'spec-runner: プロジェクト憲章を編集。不変原則・品質ルールを docs/01_憲章.md に書く'
-tools: []
----
-
-**チャットで使うプロンプト**。プロジェクト憲章を編集します。
-
-1. `docs/01_憲章.md` の内容を読み、必要なら開く。
-2. ユーザーと一緒に「このプロジェクトで守る開発ルール」「品質基準」「フォルダ・成果物の原則」を書き足す・修正する。
-3. 憲章は技術やツールに依存しない抽象的なルールに留める。
-
-init の前に書いておくと、その後のユースケース開発で参照できる。

package/templates/copilot/.github/prompts/sr-/346/246/202/350/246/201/350/250/255/350/250/210.prompt.md

@@ -1,13 +0,0 @@
----
-agent: 'agent'
-description: 'spec-runner: 概要設計フェーズへ移行'
-tools: ['shell']
----
-
-以下を**必ずシェルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh design-high
-```
-
-実行結果をユーザーに伝えてください。

package/templates/copilot/.github/prompts/sr-/347/212/266/346/205/213.prompt.md

@@ -1,13 +0,0 @@
----
-agent: 'agent'
-description: 'spec-runner: 現在のフェーズを表示'
-tools: ['shell']
----
-
-以下を**必ずシェルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh status
-```
-
-実行結果をユーザーにそのまま伝えてください。

package/templates/copilot/.github/prompts/sr-/347/267/212/346/200/245/344/277/256/346/255/243.prompt.md

@@ -1,14 +0,0 @@
----
-agent: 'agent'
-description: 'spec-runner: 緊急修正（負債として記録）'
-argument-hint: '修正内容'
-tools: ['shell']
----
-
-以下を**必ずシェルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh hotfix "${input:content:修正内容}"
-```
-
-引数が空の場合は、ユーザーに「修正内容を指定してください」と伝えてください。

package/templates/copilot/.github/prompts/sr-/350/250/255/345/256/232.prompt.md

@@ -1,13 +0,0 @@
----
-agent: 'agent'
-description: 'spec-runner: 詳細設定の対話のみ（パス・TDD等）。ユースケースは作らない'
-tools: ['shell']
----
-
-以下を**必ずシェルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh init
-```
-
-引数なしのため、対話でパス・TDD 等を聞かれたあと終了します。ユースケースを作成する場合は /sr-初期化 でユースケース名・集約名を指定してください。

package/templates/copilot/.github/prompts/sr-/350/251/263/347/264/260/350/250/255/350/250/210.prompt.md

@@ -1,14 +0,0 @@
----
-agent: 'agent'
-description: 'spec-runner: 詳細設計サブフェーズ（domain / usecase / table / infra）'
-argument-hint: 'domain | usecase | table | infra'
-tools: ['shell']
----
-
-以下を**必ずシェルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh design-detail ${input:sub:サブフェーズ（domain, usecase, table, infra）}
-```
-
-引数が無効な場合は、ユーザーに「domain, usecase, table, infra のいずれかを指定してください」と伝えてください。

package/templates/cursor/.cursor/commands/sr-/343/202/262/343/203/274/343/203/210/350/250/255/345/256/232.md

@@ -1,11 +0,0 @@
-# /sr-ゲート設定
-
-**チャットで使うコマンド**。ユーザーが `/sr-ゲート設定` の後に続けて入力したゲート名で、以下を**ターミナルで実行**してください（例: `/sr-ゲート設定 用語集確認済み`）。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh set-gate <ユーザーが入力したゲート名>
-```
-
-ゲート名は**日本語**でも**英語キー**でも指定できます。引数が空の場合は、ユーザーに次のように伝えてください。
-
-「ゲート名を指定してください。例: 用語集確認済み、テストコードコミット済み、概要設計レビュー済み」

package/templates/cursor/.cursor/commands/sr-/343/203/206/343/202/271/343/203/210/350/250/255/350/250/210.md

@@ -1,9 +0,0 @@
-# /sr-テスト設計
-
-以下を**必ずターミナルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh test-design
-```
-
-実行結果をユーザーに伝えてください。

package/templates/cursor/.cursor/commands/sr-/343/203/254/343/203/223/343/203/245/343/203/274.md

@@ -1,9 +0,0 @@
-# /sr-レビュー
-
-**チャットで使うコマンド**。ユーザーが `/sr-レビュー` の後に続けて入力したファイルパスで、以下を**ターミナルで実行**してください（例: `/sr-レビュー docs/01_要件/顧客登録.md`）。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh review-pass <ユーザーが入力したファイルパス>
-```
-
-引数が空の場合は、ユーザーに「レビュー通過させるファイルパスを指定してください」と伝えてください。

package/templates/cursor/.cursor/commands/sr-/344/273/225/346/247/230.md

@@ -1,9 +0,0 @@
-# /sr-仕様
-
-**チャットで使うコマンド**。プロジェクト仕様（何を作るか・なぜか・スコープ）を編集します。
-
-1. `docs/02_仕様.md` を開くか、内容を確認する。
-2. ユーザーと一緒に「このプロジェクトで作るもの」「作る理由」「スコープ（含む/含まない）」「想定ユーザー」を書き足す・修正する。
-3. 曖昧な点があれば clarify のように質問して解消する。
-
-init の前に書いておくと、最初のユースケースを決めやすくなる。

package/templates/cursor/.cursor/commands/sr-/344/277/256/346/255/243.md

@@ -1,9 +0,0 @@
-# /sr-修正
-
-以下を**必ずターミナルで実行**してください。ユーザーが続けて入力した修正内容を渡します（例: `/sr-修正 顧客名を必須に変更`）。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh fix "<ユーザーが入力した内容>"
-```
-
-引数が空の場合は、ユーザーに「修正内容を指定してください」と伝えてください。

package/templates/cursor/.cursor/commands/sr-/345/210/235/346/234/237/345/214/226.md

@@ -1,35 +0,0 @@
-# /sr-初期化
-
-**チャットで使うコマンド**。ユーザーが `/sr-初期化` の後に続けて入力した文字列を引数として扱います（例: `/sr-初期化 Todoアプリ` → ユースケース名「Todoアプリ」）。
-
-## 重要: 対話は「チャット上で AI が埋める」形式で行う
-
-- **ターミナルで read や npx --configure の入力待ちにしないこと。** 未設定時は、**AI が** プロジェクト構成を確認し、必要ならチャットでユーザーに聞きながら設定を決め、**AI が** `.spec-runner/config.sh` を編集・生成してから init を実行する。
-
-## 手順
-
-1. **設定済みか確認**  
-   `.spec-runner/config.sh` が存在し、かつ `CONFIGURED="true"` かどうかを確認する。
-
-2. **未設定の場合（config.sh がない、または CONFIGURED が true でない）**
-   - プロジェクトの `package.json` や既存の `src/` などを確認し、Domain/UseCase/テストのパスなどを推測する。
-   - 必要ならチャットでユーザーに聞く（例: 「Domain のパスは `src/domain` でよさそうですが、変更しますか？」）。
-   - 決まったら **AI が** `.spec-runner/config.sh` を編集または作成する。必ず `export CONFIGURED="true"` を設定し、以下の変数も設定する（既存の config.sh がある場合は必要な部分だけ上書きする）。
-   - その後、ターミナルで `./.spec-runner/scripts/spec-runner.sh init <引数>` を実行する。このときはすでに CONFIGURED が true なので、ターミナルでの対話は発生しない。
-
-3. **設定済みの場合**  
-   そのまま `./.spec-runner/scripts/spec-runner.sh init <ユーザーが入力した引数>` を実行する。
-
-4. **引数がない場合**  
-   ユーザーに「ユースケース名（と任意で集約名）を指定してください」と伝えるか、設定だけしたい場合は `/sr-設定` を案内する。
-
-## config.sh に必要な変数（AI が書くときの目安）
-
-- `CONFIGURED="true"` （必須）
-- `DOMAIN_PATH`, `USECASE_PATH`, `INFRA_PATH`（例: `src/domain`, `src/useCase`, `src/infrastructure`）
-- `TEST_DIR`（例: `tests`）, `SOURCE_EXTENSIONS`（例: `ts tsx js jsx`）, `TEST_EXTENSIONS`（例: `test.ts spec.ts`）
-- `TDD_ENABLED`, `SPEC_RUNNER_DDD_ENABLED`（`"true"` / `"false"`）
-- `BUILD_CMD`, `TEST_CMD`, `LINT_CMD`（例: `npm run build`, `npm test`, `npm run lint`）
-- その他、既存の `.spec-runner/config.sh` にあれば同じ形式で揃える（`SPEC_RUNNER_FRAMEWORK`, `SPEC_RUNNER_TOOLS`, `SPEC_RUNNER_LANGUAGE`, `CI_PLATFORM` など）。
-
-非対話で実行したいときは、上書き確認もスキップするため `SR_YES=1 ./.spec-runner/scripts/spec-runner.sh init <引数>` のように実行してよい。

package/templates/cursor/.cursor/commands/sr-/345/256/237/350/243/205.md

@@ -1,9 +0,0 @@
-# /sr-実装
-
-以下を**必ずターミナルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh implement
-```
-
-実行結果をユーザーに伝えてください。

package/templates/cursor/.cursor/commands/sr-/346/206/262/347/253/240.md

@@ -1,9 +0,0 @@
-# /sr-憲章
-
-**チャットで使うコマンド**。プロジェクト憲章（不変原則・品質ルール）を編集します。
-
-1. `docs/01_憲章.md` を開くか、内容を確認する。
-2. ユーザーと一緒に「このプロジェクトで守る開発ルール」「品質基準」「フォルダ・成果物の原則」を書き足す・修正する。
-3. 憲章は技術やツールに依存しない抽象的なルールに留める（API や具体的なバージョンは書かない）。
-
-init の前に書いておくと、その後のユースケース開発で参照できる。

package/templates/cursor/.cursor/commands/sr-/346/246/202/350/246/201/350/250/255/350/250/210.md

@@ -1,9 +0,0 @@
-# /sr-概要設計
-
-**チャットで使うコマンド**。以下を**ターミナルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh design-high
-```
-
-実行結果をユーザーに伝えてください。

package/templates/cursor/.cursor/commands/sr-/347/212/266/346/205/213.md

@@ -1,9 +0,0 @@
-# /sr-状態
-
-以下を**必ずターミナルで実行**してください。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh status
-```
-
-実行結果をユーザーにそのまま伝えてください。

package/templates/cursor/.cursor/commands/sr-/347/267/212/346/200/245/344/277/256/346/255/243.md

@@ -1,9 +0,0 @@
-# /sr-緊急修正
-
-以下を**必ずターミナルで実行**してください。ユーザーが続けて入力した緊急修正の内容を渡します（例: `/sr-緊急修正 ログイン落ちの修正`）。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh hotfix "<ユーザーが入力した内容>"
-```
-
-引数が空の場合は、ユーザーに「修正内容を指定してください」と伝えてください。

package/templates/cursor/.cursor/commands/sr-/350/250/255/345/256/232.md

@@ -1,20 +0,0 @@
-# /sr-設定
-
-詳細設定（パス・TDD・DDD 等）を**チャット上で AI が埋める**形で行います。ユースケースは作成しません。
-
-## 重要: 対話はターミナルではなくチャットで行う
-
-- **ターミナルで `init` を実行して入力待ちにしないこと。** AI がプロジェクトを確認し、必要ならチャットでユーザーに聞きながら設定を決め、**AI が** `.spec-runner/config.sh` を編集・生成する。
-
-## 手順
-
-1. `.spec-runner/config.sh` の有無を確認する。ない場合は `npx spec-runner` で一度セットアップされている必要がある（config.sh が存在する前提）。
-2. プロジェクト構成（`package.json`、既存の `src/` やテストディレクトリなど）を確認し、以下を決める（不明ならチャットでユーザーに聞く）:
-   - Domain / UseCase / Infrastructure のパス
-   - テストディレクトリ、ソース・テストの拡張子
-   - TDD を必須にするか、DDD を使うか
-   - CI プラットフォーム、ドキュメント言語 など
-3. **AI が** `.spec-runner/config.sh` を編集または作成する。必ず `export CONFIGURED="true"` を設定し、`sr-初期化` のコマンド説明にある変数（DOMAIN_PATH, USECASE_PATH, TEST_DIR, TDD_ENABLED など）を適切に設定する。
-4. 完了したら「設定を config.sh に反映しました。ユースケースを開始する場合は `/sr-初期化 ユースケース名 集約名` を使ってください」と伝える。
-
-**ターミナルで `./.spec-runner/scripts/spec-runner.sh init` を実行して対話に頼る必要はない。**

package/templates/cursor/.cursor/commands/sr-/350/251/263/347/264/260/350/250/255/350/250/210.md

@@ -1,9 +0,0 @@
-# /sr-詳細設計
-
-以下を**必ずターミナルで実行**してください。ユーザーが続けて入力したサブフェーズ（domain / usecase / table / infra）を渡します（例: `/sr-詳細設計 domain`）。
-
-```bash
-./.spec-runner/scripts/spec-runner.sh design-detail <ユーザーが入力したサブフェーズ>
-```
-
-引数が空、または domain / usecase / table / infra 以外の場合は、ユーザーに「サブフェーズを指定してください: domain, usecase, table, infra」と伝えてください。

package/templates/cursor/.cursorrules

@@ -1,26 +0,0 @@
-# spec-runner（Cursor 用ルール）
-
-このプロジェクトは **scripts/spec-runner.sh** によるフェーズゲートで運用している。実装前に必ずフェーズを確認すること。
-
-## 最優先
-
-- 実装コードを書く前に **必ず** `./scripts/spec-runner.sh status` を実行する。
-- `phase` が `implement` でないときは実装コードを生成しない。ユーザーに「現在のフェーズを確認してください」と伝える。
-- ユーザーが「init して」「status 確認して」「design-high で進めて」などと言ったら、対応する `./scripts/spec-runner.sh` をターミナルで実行する。
-- スラッシュコマンド `/sr-init` などは `.cursor/commands/` に定義済み。チャットで `/sr-status` のように呼び出せる（Agent 経由でシェル実行）。
-- **初期化・設定**: `/sr-初期化` や `/sr-設定` では、未設定時も**ターミナルの入力待ちにしない**。AI がプロジェクトを確認し、チャットで聞くか推測して `.spec-runner/config.sh` を編集・生成してから init を実行する（対話は「AI がどんどん埋めていく」形式）。
-
-## TDD（テスト駆動）— デフォルトで有効
-
-- 実装前に **テスト設計ドキュメント** と **テストコード** を必ず書く。テストを先に書いて Red → 実装で Green。
-- `.spec-runner/config.sh` の `TDD_ENABLED=false` で無効化すると、テストなしでも implement に進める（オプション）。
-
-## フェーズとコマンド
-
-- require → design-high → design-detail (domain → usecase → table → infra) → test-design → implement
-- 各フェーズ完了時: `./scripts/spec-runner.sh review-pass <該当ファイル>`
-- ゲート: `./scripts/spec-runner.sh set-gate glossary_checked` など
-- 実装完了後: git push → PR。次のユースケースは `./scripts/spec-runner.sh init <名前>` で開始
-- 修正: `./scripts/spec-runner.sh fix "内容"` / `./scripts/spec-runner.sh hotfix "内容"`
-
-詳細はプロジェクトの CLAUDE.md または README を参照。