| name | spec-story-starter |
| description | 議論・議事録・選定された施策を起点に、対象リポジトリの実構造にgroundした「エンジニア向け Story（User Story + Acceptance Criteria）と Spec（技術仕様）」をSubagentで収束生成する。target_repoで対象コードベースを、backlog_db_urlで起票先バックログを選べる汎用スキル。抽象的な打ち手を実装可能な仕様へ絞り込む収束フェーズの実行に使う。 |
spec-story-starter — Feature Story & Spec Starter（汎用・Subagent収束型）
議論／議事録／選定済み施策を起点に、対象リポジトリの実構造にgroundした Story + Spec を生成し、指定バックログに起票（またはローカル出力）する。特定ツール連携の専用版スキル（v1.1）を、任意リポジトリ・任意バックログに向けられる汎用スキルへ翻案したもの。
収束の中核: 抽象的な施策（「補充リマインドをやる」）を、複数Subagentで「既存コードのどこに何を実装するか」まで絞り込む。発散（広げる）の対に位置する収束（実装可能な1形に落とす）フェーズを担う。
When to Use
- 発散・選定フェーズで決まった施策を、エンジニアに渡せる仕様に落としたいとき
- Chat/議事録の機能議論を、Story（受け入れ基準付き）とSpec（技術仕様）に一気に構造化したいとき
- 既存の簡素なStoryを、対象リポジトリの実装文脈で詳細化したいとき
入力インターフェース
| 入力 | 必須 | 説明 |
|---|
source | ✅ | 起点。選定ドキュメント／議事録ページ／Chat議論／既存Story。パス・URL・直近会話のいずれか |
feature_label | ✅ | 機能名（例: 補充リマインド配信） |
target_repo | ⭕ | 仕様をgroundする対象リポジトリのパス。指定するとそのコード構造を読んで実装箇所を特定。未指定＝カレントリポ or repo探索スキップ（構造非依存の一般Specになる） |
backlog_db_url | ⭕ | 起票先バックログDB（Notion DB URL / ローカルbacklogパス）。指定時はそこにStory行を起票。未指定＝ローカル <出力先>/Story.md に出力 |
spec_output | ⭕ | Spec出力先（ローカルファイルパス / Specs DB URL）。未指定＝<出力先>/Spec.md |
detail_level | ⭕ | lean / standard(既定) / deep。Story/Spec同一粒度 |
出力先が未指定の場合は Flow/[YYYYMM]/[YYYY-MM-DD]/[feature_label]/ を既定とする。
処理フロー（Subagent収束）
source ──▶ P1 要旨抽出
│
▼
P2 repo探索(Subagent①) ── target_repoの構造・接続点・既存パターンを地図化
│ (target_repo未指定ならスキップ)
▼
P3 Story骨子 + Spec章立て 提案 ──▶ P4 Mob CP(停止・承認)
│ OK
▼
P5 並列収束: Story起草(Subagent②) ∥ Spec起草(Subagent③) ← ともにP2の地図をground情報として受領
│
▼
P6 整合レビュー(Subagent④ / maker≠checker) ── Story⇔Spec整合・repo実現可能性
│
▼
P7 出力/起票(backlog_db_url or ローカル) ─▶ P8 Verification ─▶ P9 完了報告
Phase 1: 要旨抽出
source から抽出: 課題(Why) / 背景 / 成功条件(Acceptance想定) を3〜5行に要約。selectされた施策なら「なぜこの施策か」の根拠も拾う。
Phase 2: repo探索（Subagent①・target_repo指定時）
target_repo を Agent tool（Subagent, tools: Read/Glob/Grep）で探索させ、以下を含む grounding map を返させる:
- feature が触るレイヤ/ファイル（entities / repositories / services / components / infra 等）
- 追加すべき箇所（新規ファイル vs 既存拡張）と、その根拠となる既存パターン
- 依存する外部クライアント（例: LINE/メール/決済クライアント）
- 命名・構造の既存規約（新Specがそれに従うため）
プロンプト骨子: 「このリポジトリで機能『[feature_label]』を実装するなら、どのファイルに何を足すか。既存の構造・命名規約に沿って、touch pointsをファイルパス付きで列挙。要旨: [P1]」
target_repo未指定時はP2をスキップし、構造非依存の一般Specとして続行（その旨をP4で明示）。
Phase 3: Story骨子 + Spec章立て 提案
- Story骨子:
As a / I want / So that + Acceptance Criteria 3〜5個
- Spec章立て: 概要 / 対象ユーザーストーリー / 画面 or API / データモデル / インタラクション / バリデーション・エラーケース / 実装箇所（P2の grounding mapを反映：どのファイルに何を足すか） / ガードレール
Phase 4: Mob Checkpoint — 骨子承認（停止）
🚨 必ず停止し応答を待つ。骨子（Story + Spec章立て + 実装箇所サマリ）を提示し、🙋承認待ちブロック（OK / 修正 / 差し戻し）を出す。target_repo未指定ならその旨も明示。
Phase 5: 並列収束（Subagent② ∥ ③）
承認後、2つのSubagentを並列で走らせる（Agent tool・同時2発）:
- Subagent② Story起草: User Story + Acceptance Criteria（チェックボックス形式）+ 背景/期待効果。detail_levelに従う
- Subagent③ Spec起草: P3章立てを本文化。P2の grounding mapを必ず入力に含め、「実装箇所」章は実ファイルパスで書く。detail_levelに従う
両Subagentに同じ grounding map と骨子を渡し、記述粒度・用語を揃えるよう指示する（収束＝1つの整合した仕様へ）。
Phase 6: 整合レビュー（Subagent④ / maker≠checker）
起草した Story と Spec のみを、作成文脈を渡さない独立Subagentに検証させる:
- Story⇔Spec の整合（AC と Spec の対応、粒度の一致）
- target_repo に対する実現可能性（存在しないファイル/構造を前提にしていないか）
- 欠落（バリデーション・エラーケース・非機能）
- 出力: P0-P3 フラットリスト or 「No findings」
P0/P1は修正してP5成果物に反映（必要ならP5の該当Subagentを再実行）。
Phase 7: 出力・起票
backlog_db_url 指定あり:
- Notion DB URL → notion-cli / nsync で Story行を起票（Feature=feature_label / Status=Backlog / Priority / 本文=Story）。Spec は
spec_output（Specs DB or ローカル）へ。両者を相互リンク
- ローカルbacklogパス → その backlog.yaml / ディレクトリに Story を追記・作成
backlog_db_url 指定なし: <出力先>/Story.md と <出力先>/Spec.md を作成し、相互に相対リンク
いずれも Story本文の冒頭に対応Spec参照、Spec冒頭に対応Story参照を置く。
Phase 8: Verification
Story/Spec が存在・双方向リンク成立・（target_repo指定時）実装箇所が実在ファイルを指すこと・AC が検証可能な粒度か、を確認しチェックリスト出力。
Phase 9: 完了報告（Next Action Protocol）
成果物パス（Story/Spec）＋起票先＋レビュー結果を報告。Next Action: A=Story段階分け（Tier化）/ B=デザイン下書き / C=別Feature起票。
Subagent役割まとめ（収束の見せ場）
| # | Subagent | 入力 | 出力 | tools |
|---|
| ① | repo探索 | target_repo, 要旨 | grounding map（touch points） | Read/Glob/Grep |
| ② | Story起草 | 骨子, grounding map | Story本文 | Read/Write |
| ③ | Spec起草 | 章立て, grounding map | Spec本文 | Read/Write |
| ④ | 整合レビュー | Story+Spec（文脈なし） | P0-P3 findings | Read/Glob/Grep |
②③を並列 → ④で収束、という流れが「複数の視点を1つの実装可能な仕様に絞り込む」収束フェーズの体現になる。
ガードレール
- Mob CP（P4）は必ず停止。承認なしにP5へ進まない
- Spec の「実装箇所」は target_repo に実在するパスのみを指す（探索結果に無い構造を捏造しない）
- レビュー（P6）は作成文脈を渡さない独立Subagentで行う（maker≠checker）
.env・秘密情報を生成/参照しない。target_repo に書き込まない（読むだけ）- backlog_db_url へ起票する前に、同名Story重複を確認（存在時はsuffix提案）
使用例
/spec-story-starter
source: @T004_施策選定_意思決定.md
feature_label: 補充リマインド配信
target_repo: examples/kotonoha/store
backlog_db_url: （未指定=ローカルStory.md/Spec.md出力）
detail_level: standard
/spec-story-starter
source: @議事録_XXX
feature_label: 条件分岐ノード
target_repo: <your-repo>/path/to/product-repo
backlog_db_url: https://notion.so/.../ProductBacklog-DB
作成日: 2026-07-08 ｜ 由来: 特定ツール連携の専用版スキル（v1.1）の汎用・ローカル・Subagent収束型翻案
