spec-story-starter

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収束型翻案