--- name: spec-planner description: >- 要求・要件・MTG決定（Google Meet / Gemini メモ含む）を取り込んで設計成果物（requirements / design / data-model / requirements-mapping / usecases / open-issues）を新規作成または incremental に改訂し、必要に応じて Notion DB に親ページ + 子ページ構成で同期する。単発 subagent 逐次フロー（architect / modeler / requirements-analyst / critic / scribe を 1 体ごとに呼び出し、critic blocker ゼロまで needs-revise ループ）で設計判断の質を担保し、ステークホルダー向け要求仕様 requirements.md の生成・MTG議事の取り込み・過去比較表現クレンジング・Notion同期までを一気通貫で担当する。Notion 同期が不要なら `notion: skip` でローカル運用に倒せる。設計を起こす / MTG決定を設計に反映する / Notion に上げる、いずれのユースケースでも本スキル単独で対応可能。 argument-hint: >- <普通の日本語で「何を・どの MTG ノートを使って・どの資料を参考に」を書けばよい。明示キー (slug:/meetings:/base:/notion:) も後方互換で受け付ける> disable-model-invocation: true allowed-tools: Read, Write, Edit, Glob, Grep, Bash, Agent, AskUserQuestion, WebFetch --- # spec-planner: 要求 / MTG 議事から設計を起こし、incremental に育てて Notion へ同期するスキル あなたはこのスキルのファシリテーター（**オーケストレーター**）として動く。 入力された MTG 議事録（ローカルファイル or Google Docs URL）と既存の要求・要件文書、自然文の指示を取り込み、**単発 subagent 逐次フロー**（architect / modeler / requirements-analyst / critic / scribe を 1 体ごとに `Agent` tool で呼び出し、critic blocker ゼロまで needs-revise ループ）を回したうえで、最終成果物を指定された Notion DB に親ページ + 子ページ構成で同期する。 **Agent-Team は使わない**。`TeamCreate` / `SendMessage` / `TeamDelete` は呼ばない。subagent 呼び出し契約（10 件必須項目 / model 振り分け / 戻り値最小化 / critic 専用契約 / 全文 Read 禁止）は [docs/subagent-contract.md](./docs/subagent-contract.md) に集約してある。本 SKILL では再掲しない。 ## このスキルが Opus 4.7 で動く前提 Opus 4.7 の挙動（subagent を控えめに spawn / tool より推論優先 / effort 厳格 / 字義通り解釈）に整合させた方針: - **単発 subagent 逐次フロー**は変えない。MTG 取り込みと Notion 同期もメイン（あなた）が直接やる - **指示は字義通り**: 「ついでに同期して」「適切に取り込んで」等の曖昧語をメインの内部判断でも使わない。各フェーズで何を / どのファイルに / どの形式で書くかを毎回明示する - **思考深度の steer**: MTG 議事の取り込みは「Respond directly. 既知形式の正規化」、設計判断は既存スキルと同じく architect / 最終 critic だけ「Think carefully step-by-step」 - **コンテキスト前出し**: subagent に「議事録を直接 Read して判断して」と委ねない。本スキルは MTG 議事を `meeting-decisions.md` に正規化し、analyst の入力として渡す。Gemini トランスクリプトをそのまま subagent に投げない - **メインのナレーション抑制**: フェーズ間の "now I will..." 系の前置きを書かない。各フェーズ完了時に `task-state.md` を 1 回 Edit + 1 行報告だけ ## 入力 `$ARGUMENTS` には**普通の日本語で書かれた指示文**が入る。スラグ・MTG ノート・既存資料・Notion 同期スキップ等の指定は、**メイン（あなた）が自然文から抽出する**。明示キー（`slug:` / `meetings:` / `base:` / `notion:`）も後方互換として認識するが、推奨はしない（ユーザーは普通に話せばよい）。 ### 自然文の起動例 ユーザーはたとえば以下のように書く。キーは付けなくてよい: ``` order-cancel について、5/10 の Gemini ノートと ./docs/req.md を参考に、返金フロー切替を反映してほしい。 ``` ``` 新規で「在庫予約」の設計を起こしたい。先週月曜の Weekly Standup と昨日の打合せメモを取り込んで。Notion 同期はしないで、ローカルだけでいい。 ``` ``` 新規機能「在庫予約」の設計を起こしたい。倉庫オペレーターが事前に在庫枠を確保できるようにする想定。 ``` メインはこれらから「slug 候補 / MTG ソース / base ソース / Notion 同期可否 / 純粋な指示文」を抽出する。抽出方法はフェーズ 0-0 で詳述。 ### 抽出される 5 つの要素 | 要素 | 抽出元の典型パターン | 省略時の挙動 | |------|--------------------|--------------| | **slug** | 「order-cancel について」「在庫予約の改訂」「先週作った X の」等。既存 `./spec-planner-output/` ディレクトリ名との一致を優先 | 自動検出（既存 1 件 → 採用 / 無ければ新規・指示文から推測 / 複数 → 1 回質問） | | **meetings** | 「5/10 の MTG」「先週月曜の Weekly Standup」「Gemini ノート」「打合せメモ」+ ローカルパス + URL | 自然文の指示だけが要求源になる（plan 相当） | | **base** | 「./docs/req.md を参考に」「既存の要件書を見て」「base に X を置いてある」+ ローカルパス | 既存資料の引継ぎなしで起こす | | **notion 同期可否** | 「Notion に上げないで」「同期しないで」「ローカルだけ」「sync skip」 | Notion 同期まで実行（指定なし = 同期する） | | **純粋な指示文** | 上記以外のすべての文 | これが実質必須。極端に薄い / 「設計して」だけの場合は中断 | ### 設計判断の優先順位 **MTG 決定 > base 文書 > 純粋な指示文**（より新しく具体的な合意を上位とする）。これはフェーズ 1 の subagent prompt にも転記される。 --- ## フェーズ 0: 事前チェックと準備 ### 0-0. 自然文からの引数抽出 メイン（あなた）は `$ARGUMENTS` 全体を 1 度だけ解析し、以下を抽出する。subagent には渡さず、メインの内部状態として `task-state.md` の `## Notes` に **`extracted: ...`** 1 行で記録する。 #### 抽出ルール（決定的・ヒューリスティック） 優先順位は上から順に評価し、明示キーがあれば自然文抽出より優先する: 1. **明示キーの先取り**: `slug:` / `meetings:` / `base:` / `notion:` が `$ARGUMENTS` に書かれていれば、そのキー部分を切り出して採用し、残りを「純粋な指示文」とみなす（後方互換ルート） 2. **明示キーが無い場合の自然文抽出**: - **ローカルパス検出**: `(?:\./|/|~/)[^\s,]+\.(md|txt|json|pdf|docx|html)` または既知拡張子で終わる絶対 / 相対パスを正規表現で抽出。文脈語（「参考」「ベース」「base」「既存」「資料」「要件」「設計書」が近接）と組み合わせて **base 候補**。「議事」「メモ」「MTG」「ミーティング」「打合せ」が近接していれば **meetings 候補** - **URL 検出**: `https?://[^\s,]+` を抽出。`docs.google.com/document/d/` を含むものは **meetings 候補**（Google Docs ルート）。それ以外は文脈で base / meetings を判定。判別困難なら meetings 寄り - **MTG 自然文クエリ検出**: 文中から「<日付表現>」+「MTG / ミーティング / 打合せ / Gemini ノート / 議事 / Weekly Standup / Sync / Review 等」のパターンを抽出。日付表現は `YYYY-MM-DD` / `M/D` / `M月D日` / 曜日 / 「昨日」「先週」「今月頭」等の相対表現を網羅。同種のパターンが複数あればすべて **meetings 候補** - **slug 候補抽出**: `./spec-planner-output/` 配下のディレクトリ名を全件取得し、`$ARGUMENTS` 内の語と完全一致 / kebab-case 部分一致を試みる。一致があれば **slug 候補** として採用。新規なら「<キーワード>の設計」「新規で <名前>」等のパターンから kebab-case の slug を推測（例: 「在庫予約の設計を起こしたい」→ `inventory-reservation`） - **Notion 同期スキップ検出**: 「Notion に上げない」「同期しない」「同期不要」「ローカルだけ」「ローカル完結」「sync skip」「同期は後で」等のパターンを文字列マッチ。1 つでもヒットすれば **notion: skip** として扱う 3. **残りの純粋な指示文**: 上記で抽出された区間を `$ARGUMENTS` から除去した残文字列。これが「純粋な指示文」となる。空または極端に短い場合（10 文字未満かつ意図不明）は、`meetings` も `base` も無ければ中断してユーザーに具体の意図を問う #### 抽出結果の通知 抽出が完了したら、ユーザーに **1 メッセージで以下を 1 ブロックで提示**してから次のフェーズに進む（AskUserQuestion は使わず、確認待ちもしない。後で違っていたら指摘してもらう前提）: ``` 解釈: - slug: <抽出結果 or auto> - meetings: <抽出件数とそれぞれの形式の要約> - base: <抽出件数 or なし> - notion: - 指示文: <80文字以内に切り詰め> （違っていれば指摘してください） ``` #### 曖昧時のフォールバック 以下のケースでは抽出結果をユーザーに**確認 1 回**だけ取りに行く（後続フェーズの `AskUserQuestion` とまとめて 1 回にすること）: - **slug が既存 2 件以上に一致**: どれか / 新規かを `AskUserQuestion` で選択（フェーズ 0-1 の質問とマージ） - **抽出した meetings の自然文クエリが Google Drive 検索でゼロ件**: 中断（既述） - **`base` と `meetings` の判別が文脈からつかないパス / URL がある**: 抽出結果通知に「 は base か meetings か判別できなかった」と書いて続行（明示キーで再指定を促す）。ただし、メインの判定は meetings 寄りに倒す（MTG が要求源として最優先のため） #### 明示キー併用の互換性 ユーザーが `slug: order-cancel` 等の明示キーを混在させた場合、明示キーが**常に優先**される。例: - `slug: order-cancel 5/10 の MTG ノートを取り込んで返金フローを反映` → slug=order-cancel（明示）、meetings=「5/10 の MTG ノート」（自然文抽出）、純粋な指示文=「返金フローを反映」 ### 0-1. 対象スラグの特定 0-0 の抽出結果を起点に確定する: 1. **0-0 で slug が抽出された場合**: その値を採用。該当ディレクトリが無ければ「新規」とみなす 2. **0-0 で抽出されなかった場合**: `./spec-planner-output/` 配下のディレクトリを列挙: - 0 件: 新規モード（指示文から短いスラグを推測し採用。生成不能なら `untitled-`） - 1 件: 自動採用して使用スラグを 1 行通知 - 2 件以上: 各スラグの `design.md` 冒頭 3 行と最終更新日時を一覧で提示し、ユーザーに `AskUserQuestion` で 1 回だけ指定を求める（0-5 の Notion 設定確認と同じ呼び出しにまとめられるならまとめる） `` = `/spec-planner-output//` を絶対パス化して以降で使う。 ### 0-2. モード判定 `` の存在で判定する: - **存在しない / 空** → **新規モード**（[docs/new-mode-flow.md](./docs/new-mode-flow.md)） - **存在し `design.md` が埋まっている** → **改訂モード**（[docs/revise-mode-flow.md](./docs/revise-mode-flow.md)、Revision 番号 +1） `task-state.md` の `Current Phase` を `sync-mode-detected: ` に更新（ファイル未生成なら 0-3 で初期化）。 ### 0-3. 作業ディレクトリの初期化（新規モード時のみ） `~/.claude/skills/spec-planner/templates/` から以下を `` にコピー: ``` cp ~/.claude/skills/spec-planner/templates/requirements.md /requirements.md cp ~/.claude/skills/spec-planner/templates/design.md /design.md cp ~/.claude/skills/spec-planner/templates/data-model.md /data-model.md cp ~/.claude/skills/spec-planner/templates/requirements-mapping.md /requirements-mapping.md cp ~/.claude/skills/spec-planner/templates/usecases.md /usecases.md cp ~/.claude/skills/spec-planner/templates/open-issues.md /open-issues.md cp ~/.claude/skills/spec-planner/templates/minutes.md /minutes.md cp ~/.claude/skills/spec-planner/templates/revision-history.md /revision-history.md cp ~/.claude/skills/spec-planner/templates/critic-findings.md /critic-findings.md cp ~/.claude/skills/spec-planner/templates/task-state.md /task-state.md cp ~/.claude/skills/spec-planner/templates/meeting-decisions.md /meeting-decisions.md cp ~/.claude/skills/spec-planner/templates/notion-sync-state.md /notion-sync-state.md ``` - `requirements.md`: ステークホルダー（顧客・PdM・ビジネスサイド）が業務言語で読む要求仕様書。`requirements-mapping.md`（開発者向け要求→設計対応表）とは別ファイルで責務分離する ### 0-4. 改訂モード時の欠損補完 改訂モードで `` に `requirements.md` / `meeting-decisions.md` / `notion-sync-state.md` / `critic-findings.md` / `task-state.md` が無ければ、テンプレートからその不足分だけコピーする。既存ファイルは触らない。`requirements.md` が欠落していた場合は、最初の改訂で analyst に**既存 `requirements-mapping.md` / `design.md` 冒頭 / `meeting-decisions.md` からステークホルダー視点で再構成して初版を起こす**よう依頼する（旧 `spec-planner-output` の遺産対応）。 ### 0-5. Notion 出力先の解決 `$ARGUMENTS` に `notion: skip` が含まれる場合は**このステップ全体をスキップ**し、`task-state.md` の `## Notes` に `notion-sync: skipped (user-opted-out)` を記録する。フェーズ 2 はスキップされる。 それ以外は `/notion-config.json` の有無で分岐: - **存在する**: 中身（`database_id`, `parent_page_id`, `title`）を採用し、ユーザー確認は不要 - **存在しない**: 初回のみ `AskUserQuestion` で**まとめて 1 回**確認する。質問項目: - `Notion 出力先 DB の URL or ID` (Q1) - `親ページの扱い` (Q2): `新規作成（タイトル=スラグから生成）` / `新規作成（タイトルを別途指定）` / `既存ページに紐づけ（URL or ID を指定）` - Q2 の選択に応じてタイトル文字列 or 既存ページ ID を続けて聞く（同じ `AskUserQuestion` 呼び出しに含める） 取得した値で `/notion-config.json` を Write: ```json { "database_id": "", "parent_page_id": "<親ページ ID or null（DB 直下に新規作成）>", "title": "<親ページタイトル>", "child_pages": {} } ``` `child_pages` は Notion 同期完了後に `{ "design": "", "data-model": "", ... }` で埋まる。 `AskUserQuestion` の呼び出しは**フェーズ全体を通じてここ 1 回のみ**を目標とする。それ以外の点は推測 or 字義通り解釈で進める。 ### 0-6. 改訂モード時の Ad-hoc Instructions 移送 改訂モードでは、`meeting-decisions.md` の `## Ad-hoc Instructions` セクションを今回の指示で**完全に置換**する。前回までの指示は累積させない: 1. 既存の `## Ad-hoc Instructions` 本文を取り出し、`revision-history.md` の前回 Revision セクション内に `### 当時の Ad-hoc Instructions` 見出しで Move（元の `meeting-decisions.md` からは削除） 2. `meeting-decisions.md` の `## Ad-hoc Instructions` を空にしてから 0-7 で今回分を書き込む これは原則「仕様はいつ誰が読んでも前提知識なしで分かる」を守るため。subagent が古い指示を「現在の意図」と誤読する余地を断つ。 ### 0-7. 入力資料の収集と正規化 0-0 で抽出された `meetings` 候補と `base` 候補を順に処理する（明示キー指定があればそれを優先採用済み）。 #### meetings の取り込み 各エントリを以下の判定順で形式分類し、`meeting-decisions.md` の `## Sources` セクションに 1 行ずつ追記する。 **形式分類**（先頭一致で判定。曖昧時は自然文クエリ扱い）: 1. `./` `/` で始まる、または既知拡張子（`.md` / `.txt` / `.json` / `.pdf` 等）で終わる → **ローカルパス** 2. `https://docs.google.com/document/d//...` パターン → **Google Docs URL** 3. `http(s)://` で始まるその他 URL → **汎用 URL** 4. 上記に該当しない → **自然文クエリ** **取り込み方法**: | 形式 | 取り込み方法 | キャッシュ先 | |---|---|---| | ローカルパス | `Read`（offset/limit で必要箇所のみ） | 元ファイルをそのまま参照 | | Google Docs URL | `mcp__*__read_file_content` で `fileId` 指定取得 | `/.cache/gdoc-.md` に Write | | 汎用 URL | `WebFetch` でテキスト抽出 | `/.cache/web-.md` に Write | | 自然文クエリ | 後述の「自然文クエリ → ファイル特定フロー」 | 解決後は Google Docs URL と同等に扱う | Google Docs の場合の `fileId` 抽出は `/document/d/([A-Za-z0-9_-]+)` で URL から取り出す。`mcp__*__read_file_content` が利用不可（権限拒否等）なら、ユーザーに「Google Drive MCP 未接続。手元でダウンロードしたファイルパスを `meetings:` に渡し直してほしい」と伝えて中断する。推測で進めない。 ##### 自然文クエリ → ファイル特定フロー 1. **日付の正規化**: クエリ内の相対日付表現（昨日 / 一昨日 / 今朝 / 先週月曜 / 先月末 / 今月頭 / N日前 等）を、`context` の現在日付を基準に絶対日付（`YYYY-MM-DD`）へ変換する。具体日付（`5/10` / `2026-05-10` / `5月10日` 等）はそのまま `YYYY-MM-DD` へ正規化 2. **検索クエリ構築**: クエリ本文から「日付」「MTG タイトル候補」「キーワード」を分離し、Google Drive の `mcp__*__search_files` 用クエリを組み立てる。検索対象は **Gemini が生成したメモ**を優先（ファイル名に MTG タイトル + 日時を含むパターン、または mime 種別が Google Docs かつ最終更新が指定日近傍） 3. **検索実行**: `search_files` を呼び出して候補一覧を取得（最大 10 件）。各候補について `get_file_metadata` で最終更新日時・所有者・サイズを取得して候補メタを揃える 4. **候補絞り込み**: - 候補 1 件 → **自動採用**。1 行で「<タイトル>（<最終更新日時>, ）を採用」とユーザーに通知して続行（後で違っていれば指摘してもらう前提） - 候補 2〜4 件 → `AskUserQuestion` で 1 回だけ選ばせる（選択肢に各候補の `<タイトル> / <最終更新> / <冒頭抜粋 1 行>` を表示）。Notion 設定確認と同じ `AskUserQuestion` 呼び出しにまとめられるなら同時実行 - 候補 5 件以上 → クエリ過広と判断し、「クエリを絞り込んでほしい（日付やキーワードの追加）」と 1 行通知して中断。推測で大量取り込みしない - 候補ゼロ → 「該当 MTG ノートが見つからない。クエリを変更するか、URL / ローカルパスで指定し直してほしい」と 1 行通知して中断 5. **採用後の取り込み**: 採用された候補の `fileId` を抽出して Google Docs URL 形式に正規化し、以降は通常の Google Docs URL ルートと同じ取り込みを行う。`meeting-decisions.md` の `## Sources` 行には**元の自然文クエリと採用された fileId / タイトルの両方**を記録する（再現性のため） ##### タイムライン集約 複数の Gemini メモが渡された場合、`meeting-decisions.md` の `## Decisions Timeline` セクションに**MTG 日時の昇順**で決定事項を集約する（取り込み元日時はファイル名 / Doc メタデータから推定。不明なら「日時不明」とラベル）。後から開かれた MTG が前の MTG の決定を覆している場合は、**新しい決定を優先**して採用し、`## Overridden Decisions` セクションに古い決定と上書き経緯を残す。 #### base の取り込み `base:` のローカルパスは Read だけ（コピーしない）。`meeting-decisions.md` の `## Base Documents` セクションにパスと冒頭 3 行を引用記録する。subagent には「base パスは offset/limit で参照可、ただし base が古い場合は MTG 決定を優先する」と prompt に明記する。 #### 取り込みの完了条件 `meeting-decisions.md` に以下のすべてが書かれていること: - `## Sources`: 取り込み元の一覧（path / URL / 取り込み方法） - `## Decisions Timeline`: MTG ごとに `### <タイトル>` 見出しで決定事項を箇条書き - `## Overridden Decisions`: 上書き発生時のみ。無ければ「該当なし」 - `## Base Documents`: base パスがあれば一覧、無ければ「該当なし」 - `## Ad-hoc Instructions`: `$ARGUMENTS` の自然文指示本文（slug/meetings/base キーを除いた残り）を全文転記 メイン（あなた）はここまでを直接 Edit で行う。subagent には任せない（取り込みは推論より字義通りの転写が中心。Opus 4.7 が本体で処理した方が判断のブレが少ない）。 --- ## フェーズ 1: 設計フローの実行 本スキルは単発 subagent 逐次フローを内部で回す。設計フローの詳細は分割して docs/ 配下に置く: - **共通 subagent 呼び出し契約**（10 件必須項目 / model 振り分け / critic 専用契約 / sync 固有追加項目 / Opus 4.7 前提）: [docs/subagent-contract.md](./docs/subagent-contract.md) - **新規モード逐次フロー**: [docs/new-mode-flow.md](./docs/new-mode-flow.md) - **改訂モード逐次フロー**: [docs/revise-mode-flow.md](./docs/revise-mode-flow.md) メイン（あなた）は 0-2 で判定したモードに応じて該当の docs を完全に実行する。両 docs の手順は subagent-contract.md を前提とする。 ### 1-1. モード分岐 - **新規モード**（`` 新規 / `design.md` が初期テンプレのまま）→ [docs/new-mode-flow.md](./docs/new-mode-flow.md) のステップ 1〜8 を順に実行 - **改訂モード**（`` 存在 / `design.md` が埋まっている）→ Revision 番号を `revision-history.md` 末尾 +1 で確定し、[docs/revise-mode-flow.md](./docs/revise-mode-flow.md) のステップ 1〜6 を順に実行 ### 1-2. 過去比較表現クレンジング手順（両モード共通・scribe 必須タスク） 両モードの scribe ステップから参照される共通手順。設計書本文に過去議論や Revision 比較の痕跡が残らないことを保証する: 1. **Grep 検出**: `` 直下の `requirements.md` / `design.md` / `data-model.md` / `requirements-mapping.md` / `usecases.md` / `open-issues.md` を対象に、以下のパターンを正規表現で網羅的に検出する: ``` (以前は|もともと|当初は|変更前|変更後|旧仕様|新仕様|旧モデル|新モデル|旧設計|新設計|以前のバージョン|過去の判断|過去には|これまでは) (Revision[ ]?R[0-9]+|Rev[0-9]+|v[0-9]+ では|前回の改訂|前回 Revision) (改訂前|改訂後|変更により|から変更|に変更した|に切り替えた|から切り替え) ``` 2. **検出ヒットの精査**: 各ヒット箇所を 1 件ずつ Read し、文脈を確認: - **採用判断と却下案の対比**（例: 「A案を採用、B案は X のため却下」）→ これは過去比較ではない。保持 - **過去 Revision との比較や経緯の言及**（例: 「以前は A だったが今は B」「Revision R1 で C を採用したが R2 で D に変更」）→ 設計書本文から削除し、`revision-history.md` の該当 Revision に移送 - **判断が難しい場合**: 「読者が過去議論を知らないとこの段落の意味が変わるか」で判定。Yes なら過去比較として除去対象 3. **除去と移送**: 該当箇所を Edit で削除し、削除した内容を `revision-history.md` の `## Revision R{N}` セクション末尾に `### 設計書から除去した過去比較記述` 見出しで追記（改訂モードのみ。新規モードでは単に削除して終わる） 4. **再 Grep**: 同じパターンで再検出してゼロを確認。残っていれば 2-3 を繰り返す（最大 3 ループ） 5. **`task-state.md` への記録**: `## Notes` セクションに「過去比較クレンジング: 検出 N 件 / 除去 M 件 / 採用判断として保持 K 件」を 1 行追記 ### 1-3. 設計フロー完了条件 選択したモードの scribe ステップ完了をもって設計フロー完了とする。`task-state.md` の `Current Phase` を `sync-ready` に更新する。 --- ## フェーズ 2: Notion 同期 `notion: skip` が指定された場合、または 0-5 でスキップ判定された場合はこのフェーズ全体をスキップしてフェーズ 3 に進む。 それ以外の場合、設計フロー完了後に `` 内の成果物 md 群を Notion DB に親ページ + 子ページ構成で upsert する。 ### 2-1. 同期対象ファイル 子ページは以下の**読者導線優先順**で親ページ配下に並べる（ステークホルダーが上から順に読めば概要 → 詳細に降りられる構造にする）: | 並び順 | ローカルファイル | Notion 子ページタイトル | 主な読者 | 同期内容 | |--------|------------------|------------------------|----------|----------| | 1 | `requirements.md` | `requirements` | ステークホルダー（業務言語） | 全文 | | 2 | `usecases.md` | `usecases` | ステークホルダー + 開発者 | 全文 | | 3 | `design.md` | `design` | 開発者・レビュアー | 全文 | | 4 | `data-model.md` | `data-model` | 開発者 | 全文（Mermaid はコードブロックのまま） | | 5 | `requirements-mapping.md` | `requirements-mapping` | 開発者（要求↔設計対応表） | 全文 | | 6 | `open-issues.md` | `open-issues` | 関係者全員 | 全文 | | 7 | `revision-history.md` | `revision-history` | 関係者全員 | 全文（改訂モード時のみ。新規モードでは初期空ファイルなので作成不要） | | 8 | `minutes.md` | `minutes` | 関係者全員 | 全文 | **同期しない**: - `meeting-decisions.md`: MTG 議事のタイムラインは「読者が前提知識なしで読める仕様」という原則に反するため、Notion には上げない。ローカルの設計フロー内部運用ファイルとして `` 内に閉じる - `task-state.md` / `critic-findings.md` / `notion-config.json` / `notion-sync-state.md` / `.cache/` 配下: ローカル運用専用 ### 2-2. 同期手順 1. `notion-config.json` を Read。`child_pages` マップを参照 2. 親ページの確保: - `parent_page_id` が JSON にあればそれを採用 - 無ければ `database_id` 配下に新規ページを作成（プロパティ: タイトル = `title`、その他のプロパティは触らない）。作成された page_id を `notion-config.json` の `parent_page_id` に Write 3. 各子ページについて以下を**逐次**で実行（並列禁止 — Notion API レート制限と冪等性のため）: - `child_pages[]` に page_id があれば、その page を**全コンテンツ削除 → 再生成**で更新（block 単位の差分更新は今回は採用しない。実装と冪等性のシンプルさを優先） - 無ければ親ページ配下に新規子ページを作成し、page_id を `child_pages` に Write - md → Notion blocks 変換は notion MCP の標準サポート範囲で行う（見出し / 段落 / 箇条書き / コードブロック / 引用 / 表 / Mermaid をコードブロック扱い） 4. 同期 1 件ごとに `notion-sync-state.md` の `## Last Sync` テーブルに ` | | | ` を追記（既存行は置換） 5. 全件完了後、`notion-config.json` の `child_pages` を最終状態で Write ### 2-3. Notion MCP 不使用時のフォールバック Notion MCP が利用不可（接続エラー / 権限拒否）の場合は、推測でリトライせず即座に中断し、ユーザーに以下を 1 行で報告: - 「Notion MCP に接続できない。設計成果物はローカル `` に確定済み。Notion 同期は後ほど `spec-planner` を再実行すれば再開可能（設計フローはスキップされ、フェーズ 2 から再開される）」 スキル再実行時、`task-state.md` の `Current Phase` が `sync-ready` なら設計フローをスキップしてフェーズ 2 から再開する。 ### 2-4. 同期失敗時のロールバック方針 途中失敗時はロールバックしない（Notion 側の部分更新は許容）。失敗した子ページキーを `notion-sync-state.md` の `## Failures` に追記し、ユーザーに残件を報告。次回再実行時に未同期 / 失敗キーから再開する。 --- ## フェーズ 3: 報告 フェーズ 2 完了後、ユーザーに 1 メッセージで報告: - 作業ディレクトリの絶対パス - モード（新規 / 改訂 R{N}）と needs-revise ループ回数 - 取り込んだ MTG ソース件数（ローカル / Google Docs それぞれの内訳）。`meetings:` 未指定なら省略 - 上書きされた過去決定の件数（あれば 3 件以内で要点） - Notion 同期結果: - 実行時は同期した子ページ件数と親ページ URL（`https://www.notion.so//` 形式で生成、`-` を除いた page_id） - `notion: skip` 時は `Notion 同期はスキップ（ローカル までで完結）` の 1 行 - **ステークホルダー向け `requirements.md` のサマリ**: 1〜2 文で「何を作るか・誰のために・主要な提供価値」を要約 - 特に注目すべき設計判断 3 件以内 - 未解消 open-issues 件数 --- ## 運営上の厳守事項 - **subagent 呼び出し契約は [docs/subagent-contract.md](./docs/subagent-contract.md) に集約**。本スキル固有の追加（MTG 議事優先 / 根拠タグ / 過去比較禁止）も同ファイル内に内包済み - **戻り値最小化**: 各 subagent の戻り値は `wrote: / summary: / findings_count:` 形式で最大 200 tokens - **ファイル全文 Read 禁止**: メインも subagent も、必要なセクションだけ offset/limit で Read。Grep は cross-file 整合検証用途 - **Agent-Team を使わない**: `TeamCreate` / `SendMessage` / `TeamDelete` を呼ばない - **状態はファイルに**: `task-state.md` / `critic-findings.md` / `notion-sync-state.md` に書く。メインのコンテキストに累積させない - **AskUserQuestion は最小限**: 0-1 のスラグ曖昧時、0-5 の Notion 設定未保存時、0-7 の自然文クエリで候補 2〜4 件の選択時。これらは可能なら**まとめて 1 回**の `AskUserQuestion`（複数 question を 1 呼び出しに格納）で済ませる。候補 1 件は自動採用 / 候補ゼロまたは 5 件以上は中断（推測で進めない） - **0-0 の抽出結果通知は確認待ちにしない**: 抽出結果は 1 メッセージで提示するが、`AskUserQuestion` を使わず後続フェーズに即進む。誤抽出はユーザーが後で指摘する前提（フリクション最小化のため） - **MTG 取り込みはメインがやる**: subagent に Google Docs URL や Gemini トランスクリプトを直接渡さない。`meeting-decisions.md` に正規化したものだけを subagent の入力にする - **設計判断の優先順位**: MTG 決定 > base 文書 > 既存 design.md（改訂モード時）。矛盾は critic の回帰観点で必ず検出させる - **Notion 同期は逐次**: 並列発火しない。レート制限と冪等性のため - **同期しないファイル**: `task-state.md` / `critic-findings.md` / `notion-config.json` / `notion-sync-state.md` / `.cache/` は Notion に上げない（ローカル運用専用） - **改訂マーカー禁止**: 既存契約と同じく `v2` / `rev2` / `（改訂）` 等のマーカーを成果物本文に残さない - **過去比較表現禁止（成果物本文）**: `requirements.md` / `design.md` / `data-model.md` / `requirements-mapping.md` / `usecases.md` / `open-issues.md` の本文に「以前は」「もともと」「変更前」「Revision R{N} では」等の過去比較表現を残さない。scribe ステップの「過去比較表現クレンジング手順」で Grep 検出 → 除去 → `revision-history.md` 移送を必須実行する。仕様は新規読者が前提知識なしで読める『最新の確定版』として書く（原則「いつ誰が読み始めても分かる仕様」のため） - **`requirements.md` は業務言語で書く**: ステークホルダー（顧客・PdM・ビジネスサイド）が読む唯一の文書。技術用語・API 名・テーブル名・実装詳細は混入禁止。scribe ステップで技術固有名詞の Grep 検出を必須実行する - **Ad-hoc Instructions の累積禁止**: 改訂モードで `meeting-decisions.md` の `## Ad-hoc Instructions` セクションは今回分で完全に置換する。前回分は `revision-history.md` の前回 Revision に移送して `meeting-decisions.md` からは削除する - **minutes.md は新規モードのみ書く**: 改訂モードでは `revision-history.md` に集約し、`minutes.md` は不可侵（Write/Edit 禁止） - **`meeting-decisions.md` は Notion 同期しない**: MTG 議事タイムラインは「前提知識なしで読める仕様」原則に反する。ローカル運用ファイルとして `` 内に閉じる - **字義通り解釈の徹底**: prompt に「同様に」「適切に」「自動的に」「必要に応じて」を書かない。Opus 4.7 は曖昧語を補完しない - **$ARGUMENTS が薄い場合**: 即座に止めて、何を取り込み何を反映したいのかを問う。推測で進めない ## 参照 - 単発 subagent 呼び出し契約（10 件必須項目 / model 振り分け / critic 専用契約 / sync 固有追加 / Opus 4.7 前提）: [docs/subagent-contract.md](./docs/subagent-contract.md) - 新規モード逐次フロー（ステップ 1〜8）: [docs/new-mode-flow.md](./docs/new-mode-flow.md) - 改訂モード逐次フロー（ステップ 1〜6）: [docs/revise-mode-flow.md](./docs/revise-mode-flow.md) - subagent 定義: `~/.claude/agents/spec-planner-*.md`（architect / modeler / requirements-analyst / critic / scribe / japan-ehr-specialist / japan-receipt-computer-specialist） - テンプレート: `~/.claude/skills/spec-planner/templates/`