spec-story-starter

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された施策なら「なぜこの施策か」の根拠も拾う。