spec-planner

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 行で記録する。

抽出ルール（決定的・ヒューリスティック）

優先順位は上から順に評価し、明示キーがあれば自然文抽出より優先する:

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: <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 の抽出結果を起点に確定する:

1. 0-0 で slug が抽出された場合: その値を採用。該当ディレクトリが無ければ「新規」とみなす
2. 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> の存在で判定する:

• 存在しない / 空 → 新規モード（docs/new-mode-flow.md）
• 存在し design.md が埋まっている → 改訂モード（docs/revise-mode-flow.md、Revision 番号 +1）

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 セクションを今回の指示で完全に置換する。前回までの指示は累積させない:

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/<fileId>/... パターン → Google Docs URL
3. http(s):// で始まるその他 URL → 汎用 URL
4. 上記に該当しない → 自然文クエリ

取り込み方法:

形式	取り込み方法	キャッシュ先
ローカルパス	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: に渡し直してほしい」と伝えて中断する。推測で進めない。

自然文クエリ → ファイル特定フロー

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 ごとに ### <YYYY-MM-DD> <タイトル> 見出しで決定事項を箇条書き
• ## 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/new-mode-flow.md
• 改訂モード逐次フロー: docs/revise-mode-flow.md

メイン（あなた）は 0-2 で判定したモードに応じて該当の docs を完全に実行する。両 docs の手順は subagent-contract.md を前提とする。

1-1. モード分岐

• 新規モード（<WORKDIR> 新規 / design.md が初期テンプレのまま）→ docs/new-mode-flow.md のステップ 1〜8 を順に実行
• 改訂モード（<WORKDIR> 存在 / design.md が埋まっている）→ Revision 番号を revision-history.md 末尾 +1 で確定し、docs/revise-mode-flow.md のステップ 1〜6 を順に実行

1-2. 過去比較表現クレンジング手順（両モード共通・scribe 必須タスク）

両モードの scribe ステップから参照される共通手順。設計書本文に過去議論や Revision 比較の痕跡が残らないことを保証する:

1. 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)
   (改訂前|改訂後|変更により|から変更|に変更した|に切り替えた|から切り替え)
   

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 に進む。

それ以外の場合、設計フロー完了後に <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. 同期手順

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[<key>] に page_id があれば、その page を全コンテンツ削除 → 再生成で更新（block 単位の差分更新は今回は採用しない。実装と冪等性のシンプルさを優先）
   • 無ければ親ページ配下に新規子ページを作成し、page_id を child_pages に Write
   • md → Notion blocks 変換は notion MCP の標準サポート範囲で行う（見出し / 段落 / 箇条書き / コードブロック / 引用 / 表 / Mermaid をコードブロック扱い）
4. 同期 1 件ごとに notion-sync-state.md の ## Last Sync テーブルに <key> | <page_id> | <YYYY-MM-DD HH:MM:SS> | <md size> を追記（既存行は置換）
5. 全件完了後、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/