| 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 に集約してある。本 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 行で記録する。
抽出ルール（決定的・ヒューリスティック）
優先順位は上から順に評価し、明示キーがあれば自然文抽出より優先する:
-
明示キーの先取り: slug: / meetings: / base: / notion: が $ARGUMENTS に書かれていれば、そのキー部分を切り出して採用し、残りを「純粋な指示文」とみなす（後方互換ルート）
-
明示キーが無い場合の自然文抽出:
-
ローカルパス検出: (?:\./|/|~/)[^\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 として扱う
-
残りの純粋な指示文: 上記で抽出された区間を $ARGUMENTS から除去した残文字列。これが「純粋な指示文」となる。空または極端に短い場合（10 文字未満かつ意図不明）は、meetings も base も無ければ中断してユーザーに具体の意図を問う
抽出結果の通知
抽出が完了したら、ユーザーに 1 メッセージで以下を 1 ブロックで提示してから次のフェーズに進む（AskUserQuestion は使わず、確認待ちもしない。後で違っていたら指摘してもらう前提）:
解釈:
- slug: <抽出結果 or auto>
- meetings: <抽出件数とそれぞれの形式の要約>
- base: <抽出件数 or なし>
- notion: <skip or sync>
- 指示文: <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 の抽出結果を起点に確定する:
- 0-0 で slug が抽出された場合: その値を採用。該当ディレクトリが無ければ「新規」とみなす
- 0-0 で抽出されなかった場合:
./spec-planner-output/ 配下のディレクトリを列挙:
- 0 件: 新規モード（指示文から短いスラグを推測し採用。生成不能なら
untitled-<YYYYMMDD>）
- 1 件: 自動採用して使用スラグを 1 行通知
- 2 件以上: 各スラグの
design.md 冒頭 3 行と最終更新日時を一覧で提示し、ユーザーに AskUserQuestion で 1 回だけ指定を求める（0-5 の Notion 設定確認と同じ呼び出しにまとめられるならまとめる）
<WORKDIR> = <cwd>/spec-planner-output/<slug>/ を絶対パス化して以降で使う。
0-2. モード判定
<WORKDIR> の存在で判定する:
task-state.md の Current Phase を sync-mode-detected: <new|revise-R{N}> に更新（ファイル未生成なら 0-3 で初期化）。
0-3. 作業ディレクトリの初期化（新規モード時のみ）
~/.claude/skills/spec-planner/templates/ から以下を <WORKDIR> にコピー:
cp ~/.claude/skills/spec-planner/templates/requirements.md <WORKDIR>/requirements.md
cp ~/.claude/skills/spec-planner/templates/design.md <WORKDIR>/design.md
cp ~/.claude/skills/spec-planner/templates/data-model.md <WORKDIR>/data-model.md
cp ~/.claude/skills/spec-planner/templates/requirements-mapping.md <WORKDIR>/requirements-mapping.md
cp ~/.claude/skills/spec-planner/templates/usecases.md <WORKDIR>/usecases.md
cp ~/.claude/skills/spec-planner/templates/open-issues.md <WORKDIR>/open-issues.md
cp ~/.claude/skills/spec-planner/templates/minutes.md <WORKDIR>/minutes.md
cp ~/.claude/skills/spec-planner/templates/revision-history.md <WORKDIR>/revision-history.md
cp ~/.claude/skills/spec-planner/templates/critic-findings.md <WORKDIR>/critic-findings.md
cp ~/.claude/skills/spec-planner/templates/task-state.md <WORKDIR>/task-state.md
cp ~/.claude/skills/spec-planner/templates/meeting-decisions.md <WORKDIR>/meeting-decisions.md
cp ~/.claude/skills/spec-planner/templates/notion-sync-state.md <WORKDIR>/notion-sync-state.md
requirements.md: ステークホルダー（顧客・PdM・ビジネスサイド）が業務言語で読む要求仕様書。requirements-mapping.md（開発者向け要求→設計対応表）とは別ファイルで責務分離する
0-4. 改訂モード時の欠損補完
改訂モードで <WORKDIR> に 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 はスキップされる。
それ以外は <WORKDIR>/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 呼び出しに含める）
取得した値で <WORKDIR>/notion-config.json を Write:
{
"database_id": "<UUID or DBページ ID>",
"parent_page_id": "<親ページ ID or null（DB 直下に新規作成）>",
"title": "<親ページタイトル>",
"child_pages": {}
}
child_pages は Notion 同期完了後に { "design": "<page_id>", "data-model": "<page_id>", ... } で埋まる。
AskUserQuestion の呼び出しはフェーズ全体を通じてここ 1 回のみを目標とする。それ以外の点は推測 or 字義通り解釈で進める。
0-6. 改訂モード時の Ad-hoc Instructions 移送
改訂モードでは、meeting-decisions.md の ## Ad-hoc Instructions セクションを今回の指示で完全に置換する。前回までの指示は累積させない:
- 既存の
## Ad-hoc Instructions 本文を取り出し、revision-history.md の前回 Revision セクション内に ### 当時の Ad-hoc Instructions 見出しで Move（元の meeting-decisions.md からは削除）
meeting-decisions.md の ## Ad-hoc Instructions を空にしてから 0-7 で今回分を書き込む
これは原則「仕様はいつ誰が読んでも前提知識なしで分かる」を守るため。subagent が古い指示を「現在の意図」と誤読する余地を断つ。
0-7. 入力資料の収集と正規化
0-0 で抽出された meetings 候補と base 候補を順に処理する（明示キー指定があればそれを優先採用済み）。
meetings の取り込み
各エントリを以下の判定順で形式分類し、meeting-decisions.md の ## Sources セクションに 1 行ずつ追記する。
形式分類（先頭一致で判定。曖昧時は自然文クエリ扱い）:
./ / で始まる、または既知拡張子（.md / .txt / .json / .pdf 等）で終わる → ローカルパスhttps://docs.google.com/document/d/<fileId>/... パターン → Google Docs URLhttp(s):// で始まるその他 URL → 汎用 URL- 上記に該当しない → 自然文クエリ
取り込み方法:
| 形式 | 取り込み方法 | キャッシュ先 |
|---|
| ローカルパス | Read（offset/limit で必要箇所のみ） | 元ファイルをそのまま参照 |
| Google Docs URL | mcp__*__read_file_content で fileId 指定取得 | <WORKDIR>/.cache/gdoc-<fileId-short>.md に Write |
| 汎用 URL | WebFetch でテキスト抽出 | <WORKDIR>/.cache/web-<hash>.md に Write |
| 自然文クエリ | 後述の「自然文クエリ → ファイル特定フロー」 | 解決後は Google Docs URL と同等に扱う |
Google Docs の場合の fileId 抽出は /document/d/([A-Za-z0-9_-]+) で URL から取り出す。mcp__*__read_file_content が利用不可（権限拒否等）なら、ユーザーに「Google Drive MCP 未接続。手元でダウンロードしたファイルパスを meetings: に渡し直してほしい」と伝えて中断する。推測で進めない。
自然文クエリ → ファイル特定フロー
- 日付の正規化: クエリ内の相対日付表現（昨日 / 一昨日 / 今朝 / 先週月曜 / 先月末 / 今月頭 / N日前 等）を、
context の現在日付を基準に絶対日付（YYYY-MM-DD）へ変換する。具体日付（5/10 / 2026-05-10 / 5月10日 等）はそのまま YYYY-MM-DD へ正規化
- 検索クエリ構築: クエリ本文から「日付」「MTG タイトル候補」「キーワード」を分離し、Google Drive の
mcp__*__search_files 用クエリを組み立てる。検索対象は Gemini が生成したメモを優先（ファイル名に MTG タイトル + 日時を含むパターン、または mime 種別が Google Docs かつ最終更新が指定日近傍）
- 検索実行:
search_files を呼び出して候補一覧を取得（最大 10 件）。各候補について get_file_metadata で最終更新日時・所有者・サイズを取得して候補メタを揃える
- 候補絞り込み:
- 候補 1 件 → 自動採用。1 行で「<タイトル>（<最終更新日時>, ）を採用」とユーザーに通知して続行（後で違っていれば指摘してもらう前提）
- 候補 2〜4 件 →
AskUserQuestion で 1 回だけ選ばせる（選択肢に各候補の <タイトル> / <最終更新> / <冒頭抜粋 1 行> を表示）。Notion 設定確認と同じ AskUserQuestion 呼び出しにまとめられるなら同時実行
- 候補 5 件以上 → クエリ過広と判断し、「クエリを絞り込んでほしい（日付やキーワードの追加）」と 1 行通知して中断。推測で大量取り込みしない
- 候補ゼロ → 「該当 MTG ノートが見つからない。クエリを変更するか、URL / ローカルパスで指定し直してほしい」と 1 行通知して中断
- 採用後の取り込み: 採用された候補の
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 ごとに ### <YYYY-MM-DD> <タイトル> 見出しで決定事項を箇条書き## Overridden Decisions: 上書き発生時のみ。無ければ「該当なし」## Base Documents: base パスがあれば一覧、無ければ「該当なし」## Ad-hoc Instructions: $ARGUMENTS の自然文指示本文（slug/meetings/base キーを除いた残り）を全文転記
メイン（あなた）はここまでを直接 Edit で行う。subagent には任せない（取り込みは推論より字義通りの転写が中心。Opus 4.7 が本体で処理した方が判断のブレが少ない）。
フェーズ 1: 設計フローの実行
本スキルは単発 subagent 逐次フローを内部で回す。設計フローの詳細は分割して docs/ 配下に置く:
メイン（あなた）は 0-2 で判定したモードに応じて該当の docs を完全に実行する。両 docs の手順は subagent-contract.md を前提とする。
1-1. モード分岐
1-2. 過去比較表現クレンジング手順（両モード共通・scribe 必須タスク）
両モードの scribe ステップから参照される共通手順。設計書本文に過去議論や Revision 比較の痕跡が残らないことを保証する:
- Grep 検出:
<WORKDIR> 直下の 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)
(改訂前|改訂後|変更により|から変更|に変更した|に切り替えた|から切り替え)
- 検出ヒットの精査: 各ヒット箇所を 1 件ずつ Read し、文脈を確認:
- 採用判断と却下案の対比（例: 「A案を採用、B案は X のため却下」）→ これは過去比較ではない。保持
- 過去 Revision との比較や経緯の言及（例: 「以前は A だったが今は B」「Revision R1 で C を採用したが R2 で D に変更」）→ 設計書本文から削除し、
revision-history.md の該当 Revision に移送
- 判断が難しい場合: 「読者が過去議論を知らないとこの段落の意味が変わるか」で判定。Yes なら過去比較として除去対象
- 除去と移送: 該当箇所を Edit で削除し、削除した内容を
revision-history.md の ## Revision R{N} セクション末尾に ### 設計書から除去した過去比較記述 見出しで追記（改訂モードのみ。新規モードでは単に削除して終わる）
- 再 Grep: 同じパターンで再検出してゼロを確認。残っていれば 2-3 を繰り返す（最大 3 ループ）
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 に進む。
それ以外の場合、設計フロー完了後に <WORKDIR> 内の成果物 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 には上げない。ローカルの設計フロー内部運用ファイルとして <WORKDIR> 内に閉じるtask-state.md / critic-findings.md / notion-config.json / notion-sync-state.md / .cache/ 配下: ローカル運用専用
2-2. 同期手順
notion-config.json を Read。child_pages マップを参照- 親ページの確保:
parent_page_id が JSON にあればそれを採用- 無ければ
database_id 配下に新規ページを作成（プロパティ: タイトル = title、その他のプロパティは触らない）。作成された page_id を notion-config.json の parent_page_id に Write
- 各子ページについて以下を逐次で実行（並列禁止 — Notion API レート制限と冪等性のため）:
child_pages[<key>] に page_id があれば、その page を全コンテンツ削除 → 再生成で更新（block 単位の差分更新は今回は採用しない。実装と冪等性のシンプルさを優先）- 無ければ親ページ配下に新規子ページを作成し、page_id を
child_pages に Write
- md → Notion blocks 変換は notion MCP の標準サポート範囲で行う（見出し / 段落 / 箇条書き / コードブロック / 引用 / 表 / Mermaid をコードブロック扱い）
- 同期 1 件ごとに
notion-sync-state.md の ## Last Sync テーブルに <key> | <page_id> | <YYYY-MM-DD HH:MM:SS> | <md size> を追記（既存行は置換）
- 全件完了後、
notion-config.json の child_pages を最終状態で Write
2-3. Notion MCP 不使用時のフォールバック
Notion MCP が利用不可（接続エラー / 権限拒否）の場合は、推測でリトライせず即座に中断し、ユーザーに以下を 1 行で報告:
- 「Notion MCP に接続できない。設計成果物はローカル
<WORKDIR> に確定済み。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/<workspace>/<page_id> 形式で生成、- を除いた page_id）
notion: skip 時は Notion 同期はスキップ（ローカル <WORKDIR> までで完結） の 1 行
- ステークホルダー向け
requirements.md のサマリ: 1〜2 文で「何を作るか・誰のために・主要な提供価値」を要約
- 特に注目すべき設計判断 3 件以内
- 未解消 open-issues 件数
運営上の厳守事項
- subagent 呼び出し契約は 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 議事タイムラインは「前提知識なしで読める仕様」原則に反する。ローカル運用ファイルとして <WORKDIR> 内に閉じる- 字義通り解釈の徹底: prompt に「同様に」「適切に」「自動的に」「必要に応じて」を書かない。Opus 4.7 は曖昧語を補完しない
- $ARGUMENTS が薄い場合: 即座に止めて、何を取り込み何を反映したいのかを問う。推測で進めない
参照
- 単発 subagent 呼び出し契約（10 件必須項目 / model 振り分け / critic 専用契約 / sync 固有追加 / Opus 4.7 前提）: docs/subagent-contract.md
- 新規モード逐次フロー（ステップ 1〜8）: docs/new-mode-flow.md
- 改訂モード逐次フロー（ステップ 1〜6）: 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/
