PM ハーネス設計 v1 — phuryn/pm-skills の統合（2026-09-08）
ユーザー指示（2026-09-08）「phuryn の pm-skills プラグインをインストールして、プロダクトマネジメント周りのハーネス設計を見直してほしい」への設計書。
対象は プロダクト管理の作業系（Notion の 5 DB と週次・月次の儀式・PRD・意思決定・戦略）で、開発側のハーネス（v2〜v4・beads・機械ゲート・敵対レビュー）は変えない。
正典の優先順位は従来どおり: AGENTS.md（機械が守る不変条件）> 本書 > Notion 🏠 の運用ルール（要点）。
0. 結論（先に）
- pm-skills（marketplace 全 9 プラグイン = 68 スキル・42 コマンド。README と一致）のうち 8 プラグインを導入（導入分の実測は 64 スキル・37 コマンド。差の 4 / 5 は未導入の pm-toolkit）し、常時有効は 4 つ（pm-execution / pm-product-discovery / pm-product-strategy / pm-marketing-growth・常時コスト約 5.6k トークン/セッション）。残り 4 つ（market-research / go-to-market / data-analytics / ai-shipping）は導入済みのまま 無効化し、フェーズが来たら有効にする。pm-toolkit（履歴書・NDA・プライバシーポリシー）は導入しない。
- 現行の儀式と Notion の器は変えず、各儀式の「下書きを作る工程」に主となる枠組みスキルを 1 つ差し込む（§3 の裁定表。前処理として連鎖させるスキルは表に明記した組だけ。例: 起票 = 要望の束ね → 優先順位法）。テンプレ（週次 6 節・PRD-lite）と RICE の運用規約はそのまま。
- 新たに入れる工程は 4 つ: プレモーテム（大きな出荷の前）・PRD のレッドチーム（prod-critical / 方式転換級）・成果文（Outcome）の併記（🗺 の月次見直し）・要望のトリアージ（ミニマム稼働のフィードバック即応枠）。
- 開発側の AI shipping（pm-ai-shipping）は 採用しない。verify ゲート・docker proof・ミューテーション・sol の敵対レビューの方が厳しく、重複する。
1. 現状（2026-09-08 実測）
1-1. 器と儀式
| 層 |
実体 |
儀式 |
| 人間・プロダクト |
Notion 🏠 Greco プロダクト管理: 💡 機能企画（RICE）/ 🗺 ロードマップ（四半期・律速）/ 📋 週次レポート / ⚖ 意思決定ログ / 📌 人間タスク、🧭 戦略（3 本柱・ベータターゲット）/ 📘 PRD v1 / 📣 ステークホルダー |
月曜「週次プラン」・金曜「週次締め」（C 方式・scripts/weekly-velocity.mjs）/ 月次ロードマップ見直し（8/23 初回）/ 判断は「整理案」に貯めて月曜に消化（D1〜D15） |
| AI・開発 |
beads（bd）・docs/superpowers/{specs,plans}・AGENTS.md |
claim → 実装ワーカー → 敵対レビュー → CI → develop / リリースは人間ゲート（担当モデルは AGENTS.md Routing 節が正典。2026-09-06 の切替（実装・レビューとも codex gpt-6-astra）が Routing 節に未反映で、同期は wl-jf3a） |
| 品質ループ |
eval-loop（文書系のみ・v3 §3） |
epic 分解・spec/ADR・週次/ロードマップ下書き・新規 docs |
1-2. 導入済みプラグインと PM への関与
| プラグイン |
役割 |
PM 作業への関与 |
| superpowers |
開発ワークフローの背骨（brainstorming / writing-plans / TDD / …） |
brainstorming が要件整理の入口。PM の枠組み（優先順位・戦略・リスク）は持たない |
| product-management@knowledge-work-plugins |
Cowork 向け PM プラグイン。~~connector 置換で 16 コネクタを束ねる |
Notion MCP のホスト（本セッションの notion-* ツールはここ経由）。スキル（roadmap-management / sprint-planning / stakeholder-update …）は汎用で、実際には使っていない |
| notion@claude-plugins-official |
Notion 公式（MCP + スキル） |
有効だが MCP は product-management 側が先に接続している |
| eval-loop |
文書のスコアループ |
週次・ロードマップ下書きの品質ループ（fork 版） |
| oh-my-beads |
beads 規律・hook |
起票品質（sharp-writing / bootstrap） |
PM の枠組み（RICE 以外の優先順位法・成果ロードマップ・OKR・プレモーテム・レッドチーム・North Star）は プラグインとして持っておらず、コーディネーターの暗黙知で回していた。
1-3. 8〜9 月の記録から見えたギャップ
| # |
観測（出典） |
問題 |
| G1 |
RICE が期限も実装済み度も表現できず順位が緊急度と逆になった → 「期限なし未着手の相対比較専用」の規約を後付け（8/23 見直し） |
優先順位の枠組みが 1 つしかなく、用途別の使い分けが無い |
| G2 |
🗺 の行は「運搬の一般化」「品質スイープ」などの出力で、成果や指標が書かれていない。📋 の数値は完了 bd・PR 数・サイクルタイム（=開発速度）のみ |
プロダクトの成果を測る指標（North Star・入力指標）が無い |
| G3 |
判断待ちが D1〜D15 まで積み上がり、各項目は「選択肢 + 影響」だけ |
判断基準（期限拘束・柱への寄与・可逆性・実装容量）が明示されず、比較が属人的 |
| G4 |
JWNET 接続テストにはリスク台帳（計画 §）があるが、PRD / 大きな出荷に共通のリスク工程が無い |
出荷前の「失敗を先に想像する」工程が標準化されていない |
| G5 |
ミニマム稼働のフィードバック即応枠は、要望を bd に直接起票する運用 |
要望の裏にある問題を束ねるトリアージ工程が無い |
| G6 |
🧭 の 3 本柱・ベータターゲットと 🗺 の四半期の間に、期ごとの目標（OKR）が無い |
四半期の「何を達成すれば勝ちか」が行の並びからしか読めない |
| G7 |
AI が書いたコードの説明責任は verify / proof / ミューテーション / sol レビュー / QA スイープで担保 |
ここは十分。pm-ai-shipping の「意図 vs 実装」は QA-6a の 5 点突合と同じ発想で、追加価値は薄い |
2. pm-skills の棚卸し
2-1. プラグイン単位（常時コストは claude plugin details の実測）
| プラグイン |
スキル / コマンド |
常時トークン |
本書の裁定 |
| pm-execution |
16 / 11（create-prd・prioritization-frameworks・outcome-roadmap・pre-mortem・strategy-red-team・sprint-plan・retro・release-notes・brainstorm-okrs・stakeholder-map・user-stories・job-stories・test-scenarios・summarize-meeting・wwas・dummy-dataset） |
~2,139 |
有効（中核） |
| pm-product-discovery |
13 / 5（analyze-feature-requests・prioritize-features・identify-assumptions-・prioritize-assumptions・brainstorm-・opportunity-solution-tree・interview-script・summarize-interview・metrics-dashboard） |
~1,527 |
有効（要望トリアージ・前提検証） |
| pm-product-strategy |
12 / 5（product-strategy・product-vision・value-proposition・lean-canvas・business-model・swot・pestle・porters・ansoff・pricing・monetization・startup-canvas） |
~1,392 |
有効（🧭 の年次更新・外部ベータ前） |
| pm-marketing-growth |
5 / 2（north-star-metric・value-prop-statements・positioning-ideas・product-name・marketing-ideas） |
~565 |
有効（North Star の定義に使う） |
| pm-market-research |
7 / 3（competitor-analysis・user-personas・market-segments・market-sizing・sentiment-analysis・customer-journey-map・user-segmentation） |
~760 |
無効（競合 JEMS の分析・外部ベータ前に有効化） |
| pm-go-to-market |
6 / 3（beachhead-segment・ideal-customer-profile・gtm-strategy・gtm-motions・growth-loops・competitive-battlecard） |
~755 |
無効（Y27Q1 の外部ベータ準備で有効化） |
| pm-data-analytics |
3 / 3（sql-queries・cohort-analysis・ab-test-analysis） |
~467 |
無効（本番 SQL は読み取り専用 preflight の運用があり、生成 SQL は使わない） |
| pm-ai-shipping |
2 / 5（intended-vs-implemented・shipping-artifacts・ship-check・security-audit-static・performance-audit-static・derive-tests・document-app） |
~775 |
無効（§1-3 G7） |
| pm-toolkit |
履歴書・NDA・プライバシーポリシー・文法 |
— |
導入しない |
いずれのプラグインも hook / agent / MCP サーバは持たない（.claude-plugin/plugin.json と各ディレクトリを実測）。スキルは英語で書かれており、出力は本プロジェクトの規約どおり日本語にする（スキルの雛形はそのまま、埋める内容と見出しは日本語）。
2-2. 既存スキルとの重なり
| pm-skills |
重なる既存 |
使い分け |
| brainstorm-ideas-* / brainstorm |
superpowers:brainstorming、knowledge-work product-brainstorming |
要件整理の入口は superpowers:brainstorming のまま。pm-skills の brainstorm は「新機能のアイデア出し」に限定 |
| create-prd / write-prd |
knowledge-work feature-spec、Notion の PRD-lite テンプレ |
PRD-lite の器は維持。節の抜け（成功指標・非スコープ・前提）を create-prd で点検 |
| prioritization-frameworks / prioritize-features |
knowledge-work roadmap-management（RICE・MoSCoW） |
pm-skills を採用（9 枠組みの使い分けがある） |
| sprint-plan / retro / release-notes |
knowledge-work sprint-planning、週次テンプレ 6 節 |
テンプレは不変。スキルは節の下書きの生成器 |
| stakeholder-map |
knowledge-work stakeholder-update、📣 ページ |
地図の更新は pm-skills、定期アップデート文は knowledge-work（コネクタ前提）を当面併用 |
| strategy-red-team / red-team-prd |
eval-loop の debate evaluator |
役割が違う。レッドチームは生成側で前提を攻撃して安価な検証法を出す。debate evaluator は採点側。prod-critical の spec はレッドチーム → eval-loop の順。棚卸しではレッドチームを eval-loop の evaluator として使う案も出た（順位づけ済みの反証可能な所見を出すため）。試行後に判断する |
| test-scenarios / user-stories |
S1 シナリオ（*.scenario.test.ts）の 9 ステップ形式 |
S1 の形式が正典。test-scenarios は PRD 段階の受入条件の洗い出しにだけ使う |
/brainstorm（pm-product-discovery） |
/brainstorm（knowledge-work product-management）とコマンド名が衝突 |
呼ぶときは /pm-product-discovery:brainstorm と修飾する |
metrics-dashboard / /setup-metrics |
knowledge-work metrics-review、scripts/weekly-velocity.mjs |
指標の定義（NSM・入力指標・カウンター指標・見直し頻度）は pm-skills、期間の実績 vs 目標の確認は weekly-velocity の実測 + knowledge-work metrics-review。pm-skills 側に「今期の実績を見る」スキルは無い |
summarize-meeting / /meeting-notes |
⚖ 意思決定ログ・📌 人間タスク |
出力（決定一覧 + 担当・期限つきアクション表）は 2 つの DB の行の形と一致するが、会議の議事録を Notion に置く運用が無いので当面使わない。台帳そのものを維持するスキルは pm-skills に無い（Notion の 2 DB が引き続き正典） |
3. 裁定表 — 儀式 × スキル × 器
| 儀式（トリガー語） |
差し込むスキル |
入力 → 出力 |
置き場 |
頻度 |
| 要望・アイデアの起票（「起票」） |
analyze-feature-requests（要望を問題に束ねる）→ prioritization-frameworks（Opportunity Score = 重要度 ×（1 − 満足度）で Impact を決める） |
現場の要望 / 会話 → 💡 の行（問題文・Reach/Impact/Confidence/Effort） |
💡 機能企画 |
随時。RICE は「期限なし未着手項目の相対比較専用」の規約を維持。期限のある項目は期限順、実装済みは RICE を再計算しない |
| ミニマム稼働のフィードバック即応枠（「トリアージ」） |
/triage-requests → 束ねた問題ごとに bd 起票（sharp-writing 準拠） |
事務・ドライバーの声 → 問題 × 頻度 × 影響の表 → bd / 💡 |
💡 → bd |
稼働開始後は週 1（週次締めの前） |
| PRD 起草（「PRD」） |
PRD-lite テンプレ + create-prd の節点検 → prod-critical / 方式転換級は /red-team-prd → eval-loop（debate evaluator） |
問題文 → PRD-lite（成功指標・非スコープ・前提・受入条件）+ レッドチーム表（前提 / 攻撃 / 最も安い検証） |
📘（Notion）+ docs/superpowers/specs（実装仕様） |
新機能ごと |
| 大きな出荷の前（「プレモーテム」） |
pre-mortem（Tigers / Paper Tigers / Elephants → Launch-Blocking / Fast-Follow / Track） |
計画 / PRD → リスク表 + 各 Launch-Blocking の対策・担当・期限 |
計画書の「リスク台帳」節と 📌（人間の対策） |
JWNET 接続テスト Day-1（G2 9/25 まで）・ミニマム稼働 第 2 段（請求）・外部ベータ |
| 月次ロードマップ見直し（「月次見直し」） |
outcome-roadmap（行ごとに「〜が〜できるようにし、〜が改善する」の成果文）+ 従来の実測ベロシティ照合 |
🗺 の行 → 成果文 + 指標 + スリップ判定 → 整理案（判断は貯める） |
🗺（成果文は §8 D16 の判断まではメモ欄）・整理案ページ |
月 1 |
| 四半期の目標（「四半期 OKR」） |
/plan-okrs（🧭 の 3 本柱を上位目標に、四半期の KR を 3 組） |
🧭 + 🗺 → 四半期 OKR 3 組 |
🧭 戦略ページに「四半期 OKR」節 |
四半期の始まり（次は Y26Q4 = 12 月） |
| 週次プラン（「週次プラン」） |
sprint-plan（容量・選択・リスク）を 6 節テンプレの ③ Sprint Backlog と ④ リスクの下書き生成器として使う |
🗺 のコミット候補 + bd ready → 6 節 |
📋 |
月曜 |
| 週次締め（「週次締め」） |
retro（KPT の下書き）+ release-notes（リリース行と release PR 本文の「概要」） |
実測ベロシティ + マージ PR → 締め 6 節 |
📋・release PR |
金曜 / リリースごと |
| 判断の整理（「判断整理」） |
prioritization-frameworks の Weighted Decision Matrix（基準 = 期限拘束 / 柱への寄与 / 可逆性 / 実装容量 / 依存） |
整理案 §6 の D 項目 → 基準 × 選択肢の点数表 + 推奨 |
整理案 §6 → 確定分だけ ⚖ |
判断待ちが 3 件以上溜まったとき |
| 戦略の更新（「戦略見直し」） |
product-strategy / value-prop-statements / north-star |
🧭 の 3 本柱・ベータターゲット → 価値提案文・North Star + 入力指標 |
🧭 |
年 1 + 外部ベータ前（Y27Q1） |
| 外部ベータ準備（Y27Q1〜） |
pm-go-to-market（beachhead-segment / ideal-customer-profile / plan-launch）・pm-market-research（competitor-analysis） |
🧭 のターゲット（古紙問屋 × 産廃兼業）→ ICP・ビーチヘッド・競合カード |
🧭 + 📣 |
有効化は Y27Q1 |
| 大きな賭けの前提検証（随時） |
identify-assumptions-new → prioritize-assumptions（最初の適用 = 契約書 OCR の Q4 繰り上げ判断 D8） |
企画 → 前提の一覧 → 危険な前提と最も安い検証 |
💡 の企画ページ |
新規の大型企画ごと |
採用しないもの（当面）: pm-ai-shipping 一式（§1-3 G7。棚卸しでは intended-vs-implemented（文書の意図と実装の乖離を file:line で示す）と /derive-tests（文書化した規則 → 既存テスト / 未検証の対応表）が本プロジェクト向きと評価されたが、前者は QA-6a の 5 点突合・sol の敵対レビュー、後者は AGENTS.md の各節が proof / ratchet を名指しで参照する構造で既に担保している。再評価のトリガーは次の全機能 QA か外部ベータ前の GA 準備で、そのとき claude plugin enable pm-ai-shipping@pm-skills で有効化して 1 回だけ /ship-check を流し、差分が出るか見る）、pm-data-analytics の SQL 生成（本番 SQL は「AI が読み取り専用クエリを提示 → 人間が SQL Editor で実行 → 結果を貼る」の運用を維持）、dummy-dataset/generate-data（dev シードは docs/test-data.sql 系が正典）、meeting-notes（会議は Notion に議事が無い運用）。
4. eval-loop 適用マップの更新（v3 §3 への差分）
| 成果物 |
generator（変更） |
evaluator（不変） |
発動 |
| スペック / ADR / PRD 起草 |
PRD-lite + create-prd 節点検 → prod-critical / 方式転換級は /red-team-prd を先に通す |
debate evaluator |
従来どおり乱用しない |
| 週次レポート / ロードマップ見直し下書き |
sprint-plan / retro / outcome-roadmap を節の生成器に使う |
既定 evaluator（意図忠実度・構造） |
fork 版 1 周 |
| プレモーテム（新設） |
pre-mortem |
なし（リスク表は人間が読む） |
大きな出荷の前 |
| 判断整理（新設） |
Weighted Decision Matrix |
なし |
判断待ち 3 件以上 |
コード・migration・proof には引き続き適用しない。
5. 配線（本 PR と同時に実施）
- プラグインの有効化状態: 常時有効 4（pm-execution / pm-product-discovery / pm-product-strategy / pm-marketing-growth）・無効 4（pm-market-research / pm-go-to-market / pm-data-analytics / pm-ai-shipping）。有効化は
claude plugin enable <name>@pm-skills（再起動で反映）。
CLAUDE.md（本リポジトリ・Claude 専用節）: PM routing を追記（§3 の儀式 → スキルの対応を 1 行ずつ・トリガー語）。AGENTS.md Routing: 「PM 作業（Notion の儀式）は Claude が pm-skills の枠組みで下書きし、人間が確定する」の 1 項目を追加。pm-skills は本環境では Claude Code にだけ導入している（upstream の README では Codex CLI にもスキルを導入できるが slash コマンドは動かない）。PM を Claude に集約するのは運用上の判断で、Codex / OpenCode のワーカーは PM 作業を受け持たない。- グローバル
~/.claude/CLAUDE.md（ユーザー設定）: プラグイン運用ガイドに「④ プロダクトマネジメント」節を追加（pm-skills の使い分け・knowledge-work PM plugin は Notion MCP のホストとして残す）。
- file memory
notion-workspace-structure: 本書へのポインタと「儀式 × スキル」の要約を追記。
- Notion 🏠 運用ルール（要点）: 「PM の下書きは pm-skills の枠組みで AI が作る（本書）」の 1 行を追加（無料ブロック上限 D13 の猶予内で 1 行のみ）。
6. 変えないもの（明示）
- Notion 5 DB のスキーマ（新プロパティは §8 の判断待ち）、週次テンプレ 6 節（計画 / 締め）、PRD-lite の器、RICE の運用規約（期限なし未着手の相対比較専用）。
- 人間タスク = 📌 / AI タスク = bd の境界、状態の二重更新禁止、相互リンクのみ。
- main マージの人間ゲート、
pnpm verify / docker proof / ミューテーション / sol レビューの機械ゲート（pm-ai-shipping で代替しない）。
- eval-loop の原則（fork 既定・2 周上限・文書系のみ）。
7. リスクと緩和
| リスク |
緩和 |
| 常時トークン +5.6k / セッション（AGENTS.md が大きいプロジェクトで文脈を圧迫） |
常時有効を 4 に絞る。使わないスキルが目立てばプラグイン単位で無効化 |
| スキルが英語前提で、出力が英語混じりになる |
出力は日本語・Notion の見出しは既存テンプレに合わせる。スキルの雛形語（Tigers 等）は括弧で併記 |
| knowledge-work PM plugin と pm-skills のスキルが同時に自動ロードされ、どちらが選ばれるか不定 |
本書 §2-2 の使い分けを CLAUDE.md に書く。将来は Notion MCP を公式プラグインへ移して knowledge-work PM plugin を無効化（§8 D18） |
| Notion 無料ブロック上限（D13・猶予 9/10 05:01 UTC） |
新規ページを作らず既存ページの更新で回す。プレモーテム表などは計画書（リポジトリ）側に置く |
| 枠組みが増えて儀式が重くなる |
各儀式に差し込む主スキルは 1 つ（§3。連鎖は表に明記した組だけで、表に無い組み合わせを足さない）。工程を足すのはプレモーテム・レッドチーム・成果文・トリアージの 4 つだけ |
8. 判断待ち（ユーザー）
| # |
判断 |
選択肢（推奨を先頭） |
| D16 |
🗺 に「成果」（Outcome 文）のテキストプロパティを新設するか |
(a) 新設し月次見直しで埋める / (b) メモ欄に併記 |
| D17 |
North Star 指標を定めるか（候補: 証跡つき完了率 / OCR 一発確定率 / 請求確定までのリードタイム — いずれも本番データで計測可能） |
(a) 10 月の月次見直しで north-star を使って 1 つ決める / (b) 外部ベータ前まで先送り |
| D18 |
Notion MCP のホストを公式 notion@claude-plugins-official へ移し、knowledge-work product-management plugin を無効化するか |
(a) 移す（接続テスト後の落ち着いた時期に認証を切替） / (b) 現状維持 |
| D19 |
無効化した 4 プラグインの有効化時期 |
(a) go-to-market / market-research は Y27Q1、data-analytics / ai-shipping は当面なし / (b) 個別判断 |
9. 試行計画（2 週間）
| 日 |
儀式 |
使うスキル |
期待する成果物 |
| 9/14（月） |
週次プラン Y26Q3 Sprint3 |
sprint-plan を ③④ の生成器に |
6 節テンプレのまま、リスク節が具体化されること |
| 9/18（金） |
週次締め Sprint2 |
retro |
KPT の下書きが実測ベロシティと結び付くこと |
| 9/25 まで |
JWNET 接続テスト Day-1 のプレモーテム（G2） |
pre-mortem |
計画 §リスク台帳との差分（Elephants）が 0 でないこと |
| 9 月末 |
月次見直し |
outcome-roadmap + D8 の前提検証（identify-assumptions-new） |
Q4 行の成果文と、契約書 OCR 繰り上げの根拠 |
| 随時 |
判断整理（D1〜D19） |
Weighted Decision Matrix |
月曜プランで消化できる比較表 |
試行後に本書を v1.1 として更新し、効かなかったスキルは §3 から外す。
追記（2026-09-15）: PM 台帳の最小移行
- 裁定（禹さん・2026-09-15・⚖ 記録済み）: 1 人体制のため PM 台帳を Notion から docs サイト（Cloudflare Access で社内限定）へ移す。最小範囲 = 📌 🗺 の 2 台帳。
- 器の対応: 📌 外部手続き・人間タスク →
docs/pm/human-tasks.md / 🗺 ロードマップ → docs/pm/roadmap.md。移行後は Notion 側の 📌 / 🗺 を凍結し二重更新しない。
- 残り（💡 機能企画・⚖ 意思決定ログ・📋 週次レポート）は接続テスト後に別 issue で判断するまで Notion が正典。
- RICE の運用規約と週次の数値（
scripts/weekly-velocity.mjs が正典）は変えない。RICE のスクリプト化は接続テスト後の残り移行と合わせて判断する。
- 本文（§0〜§9）は移行前の記録として変えない。以後の儀式の置き場は §3 の裁定表の「置き場」列をこの追記で読み替える（📌 🗺 →
docs/pm/）。