spec-runner 1.1.17 → 1.1.18

package/spec-runner/templates/.github/skills/existing-project-to-docs/SKILL.md

@@ -34,18 +34,25 @@ Phase 5: architecture contract 化
 
 ## Phase 3: 概要設計の draft 化
 
-1. UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を draft する
-2. `docs/02_概要設計/システム全体俯瞰.md` を作る
+1. `docs/02_概要設計/システム全体俯瞰.md` を作る
+2. `style: ddd` の場合: UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を draft する
 3. 必要なら ADR 候補も洗い出す（配置先は `90_ADR/全体/` / `ドメイン/` / `UC/` / `DB/`）
 4. ユーザーに確認・承認を得る
 
 ## Phase 4: 詳細設計の draft 化
 
+`style: ddd` の場合:
+
 1. ドメインごとにビジネスルール・集約を整理し `docs/03_詳細設計/01_ドメイン/{ドメイン名}.md` を draft する
 2. UC ごとに `docs/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を draft する
 3. DB・外部サービスの仕様が必要なら `docs/03_詳細設計/03_DB・外部サービス/` を作る
-4. 各ファイルの `maps_to` に対応コードとテストを入れる
-5. ユーザーに確認・承認を得る
+
+`style: layered` の場合:
+
+1. UC ごとに `docs/03_詳細設計/01_ユースケース/UC-{日本語名}.md` を draft する
+2. DB・外部サービスの仕様が必要なら `docs/03_詳細設計/02_DB・外部サービス/` を作る
+
+各ファイルの `maps_to` に対応コードとテストを入れる。ユーザーに確認・承認を得る。
 
 ## Phase 5: architecture contract 化
 
@@ -55,6 +62,6 @@ Phase 5: architecture contract 化
 
 ## 原則
 
-- 既存コードを正として観測し、推測は明示する
-- docs は最初から完璧を目指さず、draft として起こす
+- 既存コードを正として観測する。推測する場合は明示する
+- docs は最初から完璧を目指さず draft として起こす
 - `maps_to` と `depends_on` を使って後続変更に耐える形へ整える

package/spec-runner/templates/.github/skills/harness-engineering/SKILL.md

@@ -1,12 +1,11 @@
 ---
 name: harness-engineering
-description: AI 開発運用の skills・rules・agents・テンプレートを改善・保守するためのメタスキル。別の作業を進めた結果、繰り返し発生する手戻り、ルール不足、責務の曖昧さ、テンプレートの重複が見つかったときに使用する。通常の機能実装やアプリコードの TDD には使わない。
+description: skills・rules・agents・テンプレートを改善・保守するメタスキル。手戻り・ルール不足・責務の曖昧さ・テンプレート重複が繰り返し発生したときに使う。通常の機能実装や TDD には使わない。
 ---
 
 # harness-engineering
 
-skills・rules・agents・テンプレートを改善するためのメタスキル。
-**主目的の作業を先に進め、再利用価値のある改善が必要なときだけ使う。**
+skills・rules・agents・テンプレートを改善するためのメタスキル。主目的の作業を先に進め、再利用価値のある改善が必要なときだけ使う。
 
 ## 使うタイミング
 
@@ -24,8 +23,7 @@ skills・rules・agents・テンプレートを改善するためのメタスキ
 - アプリケーションコードに対する TDD
 - 単なる言い回しの微調整で済む変更
 
-**TDD はこのスキルの対象ではない。**
-TDD は `test-driven-development` スキルに従い、対象プロダクトのコード品質を上げるために行う。
+TDD はこのスキルの対象ではない。TDD は `test-driven-development` スキルに従い、対象プロダクトのコード品質を上げるために行う。
 
 ## 全体フロー
 
@@ -68,7 +66,7 @@ Phase 4: 影響範囲の反映確認
 
 ## Phase 3: skill / rule / agent / template の修正
 
-ファイルを作成・修正する前に **`.github/instructions/harness-formats.instructions.md`** を読み、フォーマットを確認する。
+ファイルを作成・修正する前に `.github/instructions/harness-formats.instructions.md` を読み、フォーマットを確認する。
 
 1. 対象ファイルを特定する
 2. 意図が変わらない最小差分で修正する
@@ -93,13 +91,13 @@ Phase 4: 影響範囲の反映確認
 - Claude / Copilot の対応ファイルに反映漏れがないか
 - 今回限りのノイズをルール化していないか
 - skill 名・起動条件・使いどころを変更した場合、`CLAUDE.md` の記述と一致しているか
-- `CLAUDE.md` が肥大化していないか（20行超えたら `instructions/` や `skills/` へ移動を検討する）
+- `CLAUDE.md` が肥大化していないか（20 行超えたら `instructions/` や `skills/` へ移動を検討する）
 - docs 構造・命名規則・node_id 体系に影響する変更の場合、`design-docs.instructions.md` と整合しているか
 
 ## 原則
 
-- **ハーネス改善は常時実行しない。必要なときだけ行う**
-- **主目的の作業を優先する**
-- **最小変更で改善する**
-- **新しい skill の追加は慎重に行う**
-- **TDD の責務を skill 改善と混同しない**
+- ハーネス改善は常時実行しない。必要なときだけ行う
+- 主目的の作業を優先する
+- 最小変更で改善する
+- 新しい skill の追加は慎重に行う
+- TDD の責務を skill 改善と混同しない

package/spec-runner/templates/.github/skills/simple-seed/SKILL.md

@@ -5,10 +5,8 @@ description: レイヤードアーキテクチャ / CRUD 中心のプロジェ
 
 # simple-seed
 
-**レイヤードアーキテクチャ / CRUD 中心のプロジェクト向け**の docs 正本開発フロー参照実装（種）。
-`architecture.yaml` の `style: layered` のときに使う。DDD が必要なプロジェクトは `docs-driven-seed` を使う。
-
-**このスキルをそのまま使い続けない。`architecture-skill-development` で自プロジェクト専用スキルに育てることを前提とする。**
+> レイヤードアーキテクチャ / CRUD 中心のプロジェクト向けの docs 正本開発フロー（種）。`architecture.yaml` の `style: layered` で使う。DDD が必要なプロジェクトは `docs-driven-seed` を使う。
+> このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てる。
 
 ## 全体フロー
 
@@ -33,7 +31,7 @@ Phase 5: TDD → 実装
 
 ## Phase 2: 概要設計
 
-テンプレート: `../docs-driven-seed/templates/02_概要設計/`（ユースケース一覧・システム全体俯瞰のみ）
+テンプレート: `templates/02_概要設計/`
 
 1. 要件定義からユースケースを洗い出す（Query / Command を意識）
 2. テンプレートをコピーして `docs/02_概要設計/ユースケース一覧.md` を作る
@@ -55,7 +53,7 @@ docs/02_概要設計/
 ## Phase 3: ADR（必要時のみ）
 
 1. 設計判断が必要な場合だけ ADR を作る
-2. **提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する**
+2. 提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する
 3. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
 
 | 対象 | 配置先 |
@@ -68,7 +66,7 @@ docs/02_概要設計/
 
 ## Phase 4: 詳細設計
 
-**UC → DB・外部サービス の順に設計する。**
+UC → DB・外部サービス の順に設計する。
 
 ### 4-1. ユースケース
 
@@ -100,6 +98,5 @@ docs/03_詳細設計/02_DB・外部サービス/
 
 ## 原則
 
-- **このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てることを前提とする**
-- **ドメイン層は持たない。ビジネスロジックは UC / サービス層で表現する**
-- **`maps_to` は必ず設定する。パス推定に頼らない**
+- ドメイン層は持たない。ビジネスロジックは UC / サービス層で表現する
+- `maps_to` は必ず設定する。パス推定に頼らない

package/spec-runner/templates/.github/skills/simple-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//343/202/267/343/202/271/343/203/206/343/203/240/345/205/250/344/275/223/344/277/257/347/236/260.md

@@ -0,0 +1,33 @@
+---
+spec_runner:
+  node_id: overview.system_context
+  kind: overview_design
+  depends_on:
+    - overview.use_case_list
+  maps_to:
+    - src/
+---
+
+# システム全体俯瞰
+
+## コンポーネント全体図
+
+```mermaid
+graph LR
+  User([ユーザー])
+  subgraph システム
+    {フロントエンド}
+    {バックエンド}
+  end
+  Ext([{外部サービス}])
+
+  User --> {フロントエンド}
+  {フロントエンド} --> {バックエンド}
+  {バックエンド} --> Ext
+```
+
+## 外部インターフェース
+
+| 外部システム | 方向 | プロトコル | 概要 |
+|------------|------|----------|------|
+| {外部システム名} | 受信 / 送信 | {HTTP / gRPC など} | {概要} |

package/spec-runner/templates/.github/skills/simple-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//343/203/246/343/203/274/343/202/271/343/202/261/343/203/274/343/202/271/344/270/200/350/246/247.md

@@ -0,0 +1,15 @@
+---
+spec_runner:
+  node_id: overview.use_case_list
+  kind: overview_design
+  depends_on:
+    - requirement.要件定義
+  maps_to:
+    - docs/03_詳細設計/01_ユースケース/
+---
+
+# ユースケース一覧
+
+| UC ID | UC名 | 種別 | 概要 |
+|-------|------|------|------|
+| UC-{番号} | {UC名} | Command / Query | {概要} |

package/spec-runner/templates/.github/skills/test-driven-development/SKILL.md

@@ -9,13 +9,13 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 テストを先に書く。失敗するのを確認する。通る最小のコードを書く。
 
-**中核原則:** テストが失敗するのを見ていないなら、そのテストが正しいものを検証しているか分からない。
+テストが失敗するのを見ていないなら、そのテストが正しいものを検証しているか分からない。
 
 ## いつ使うか
 
-**常に:** 新機能・バグ修正・リファクタリング・振る舞い変更
+常に使う: 新機能・バグ修正・リファクタリング・振る舞い変更
 
-**例外（ユーザーに確認する）:** 使い捨てプロトタイプ・生成コード・設定ファイル
+例外（ユーザーに確認する）: 使い捨てプロトタイプ・生成コード・設定ファイル
 
 ## 鉄の掟
 
@@ -28,7 +28,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 ## テスト戦略：テストピラミッド
 
-実装前にどのテスト種別を書くかを決める。迷ったら**単体テストから始める**。
+実装前にどのテスト種別を書くかを決める。迷ったら単体テストから始める。
 
 ```
         /\
@@ -55,7 +55,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 ### 結合テスト（Integration）
 
-**対象:** 複数モジュールの連携、DB・キャッシュ・外部APIとの境界
+**対象:** 複数モジュールの連携、DB・キャッシュ・外部 API との境界
 
 **書くとき:**
 - DB へのクエリ・永続化
@@ -91,7 +91,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 | バグ修正 | 最小レベルで再現テスト | — |
 
 **バグ修正の場合:** バグを再現できる最も低いレベルのテストを書く。
-単体で再現できるなら単体、DBが絡むなら結合。E2E で初めて再現するバグは、単体・結合に落とし込めないか検討する。
+単体で再現できるなら単体、DB が絡むなら結合。E2E で初めて再現するバグは、単体・結合に落とし込めないか検討する。
 
 ## テスト実行コマンド
 
@@ -145,7 +145,7 @@ test("ある入力に対して期待する出力を返す", () => {
 
 ### Verify RED - 失敗するのを確認する
 
-**必須。絶対に省略しない。**
+> 必須。絶対に省略しない。
 
 `@test-runner` エージェントに委任して実行する。
 
@@ -164,7 +164,7 @@ test("ある入力に対して期待する出力を返す", () => {
 
 ### Verify GREEN - 通るのを確認する
 
-**必須。**
+> 必須。
 
 `@test-runner` エージェントに委任して実行する。
 
@@ -178,8 +178,8 @@ test("ある入力に対して期待する出力を返す", () => {
 
 ### REFACTOR - 整理する
 
-Greenの後にのみ: 重複削除・命名改善・ヘルパ抽出。
-テストは常にGreenを維持する。新しい挙動は追加しない。
+Green の後にのみ: 重複削除・命名改善・ヘルパ抽出。
+テストは常に Green を維持する。新しい挙動は追加しない。
 
 ### 繰り返す
 
@@ -189,12 +189,12 @@ Greenの後にのみ: 重複削除・命名改善・ヘルパ抽出。
 
 - **最小**: 1つの振る舞いだけ。「and」が入るなら分割する
 - **明確**: テスト名が挙動を説明する
-- **意図が見える**: 望ましいAPIの使い方が伝わる
+- **意図が見える**: 望ましい API の使い方が伝わる
 
 ## テストのコメント
 
 テストコメントの規約は同梱のコーディング規約ファイルの「テストコメント規約」に従う。
-GREEN / REFACTORフェーズで書く実装コードにもビジネスロジックの意図をコメントする。
+GREEN / REFACTOR フェーズで書く実装コードにもビジネスロジックの意図をコメントする。
 
 ## テスト構成
 
@@ -256,18 +256,19 @@ tests/
 |------|------|
 | 「簡単すぎてテスト不要」 | 簡単でも壊れる。テストは30秒 |
 | 「あとでテストする」 | すぐ通るテストは何も証明しない |
-| 「今回だけTDDを飛ばす」 | 合理化である。止めること |
-| テスト前にコードを書いた | コードを削除し、TDDで最初からやり直す |
+| 「今回だけ TDD を飛ばす」 | 合理化である。止めること |
+| テスト前にコードを書いた | コードを削除し、TDD で最初からやり直す |
 | テストが最初から通る | 既存挙動をテストしている。テストを修正する |
 | なぜ失敗したか説明できない | テストが正しいか再検討する |
 | 全部 E2E で書いた | ピラミッドが逆転している。単体・結合に落とし込む |
 | 全部モックだらけ | 結合が強すぎる。または結合テストを書くべき |
 
-**どれか1つでも当てはまるなら: コードを削除し、TDDで最初からやり直す。**
+どれか 1 つでも当てはまるなら: コードを削除し、TDD で最初からやり直す。
 
 ## 完了時のレビュー
 
-実装完了後、以下のエージェントでレビューする:
+実装完了後、以下のエージェントを**同時に**起動してレビューする:
+- `@design-reviewer` — 設計書⇔実装の整合性チェック
 - `@code-reviewer` — コーディング規約への適合チェック
 
 ## 検証チェックリスト
@@ -285,13 +286,13 @@ tests/
 - [ ] モック方針がテスト種別に合っている
 - [ ] エッジケースとエラーをカバーした
 
-すべてにチェックできないならTDDを飛ばしている。やり直すこと。
+すべてにチェックできないなら TDD を飛ばしている。やり直すこと。
 
 ## 詰まったとき
 
 | 問題 | 解決 |
 |------|------|
-| どうテストすべきか分からない | 望むAPIを書き、まずアサーションを書く。ユーザーに相談する |
+| どうテストすべきか分からない | 望む API を書き、まずアサーションを書く。ユーザーに相談する |
 | どのテスト種別か迷う | 単体から始める。単体で書けないなら結合を検討する |
 | テストが複雑すぎる | 設計が複雑すぎる。インターフェースを簡素化する |
 | 何でもモック必須 | 結合が強すぎる。依存性注入を使う。または結合テストで書く |
@@ -302,7 +303,7 @@ tests/
 
 ```
 本番コード → 先にテストが存在し、失敗している
-それ以外 → TDDではない
+それ以外 → TDD ではない
 ```
 
 ユーザーの許可なしに例外はない。