pm

/pm — ポートフォリオ全体のプロジェクト管理

方法論を重視したプロジェクト管理です。カンバン＋アイゼンハワー・マトリクス＋非同期。事業ごとに1つのボードを用意します。アダプターを介して、特定のツールに依存しません。

メンタルモデル

事業ごとに、5つの列からなる独自のカンバンを用意します。

Backlog  →  Ready  →  In Progress  →  Review/Blocked  →  Done/Archived

• バックログ：重要になる可能性のあるものすべて — まだ着手を決めていない
• 準備完了：優先順位付けと定義が済み、着手できる状態
• 進行中：現在、積極的に作業している
• レビュー／ブロック中：他の人の対応、レビュー、外部依存関係を待っている
• 完了／アーカイブ：リリース済み、または中止

アイゼンハワー・マトリクスはボードに重ねて使います — バックログから準備完了に移す際のトリアージ（どの項目を選ぶか）と、次に着手する準備完了項目の選択に使います（どの項目を取り上げるか）。

                Urgent          Not Urgent
Important       Q1: Do          Q2: Schedule    ← Q2 is the high-leverage zone
Not Important   Q3: Delegate    Q4: Delete

非同期を第一に：ステータスのスナップショットは、録画する必要のないLoomのように読めるべきです。会議を開かなくても作業が見えるようにします。

ステップ 1 — モードと対象を判定する

呼び出しを解析します。

呼び出し	モード	対象
/pm setup [business]	setup	指定された事業
/pm triage [business]	triage	指定された事業（または確認）
/pm next [business]	next	指定された事業
/pm next	next	すべてのボードを対象（ポートフォリオ横断）
/pm status [business]	status	指定された事業（または確認）
/pm unblock [business]	unblock	指定された事業（または確認）
/pm weekly	weekly	すべてのボード（金曜日の状況確認）
/pm weekly [business]	weekly	指定された事業

ステップ 2 — ボード設定と個人用オーバーレイを読み込む

${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/pm/boards.md を読み込みます（個人用 — 実際の事業一覧と、事業ごとのツールマッピングが記載されています）。ローカルファイルがまだ存在しない場合は、リポジトリ内の references/boards.md を使います — これはテンプレートです。

${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/pm/team.local.md があれば、こちらも読み込みます — ユーザーがパートナー、進行中のクライアント、よく使うブロッカーの表現を記載するファイルです。一般的な表現ではなく、「のレビュー待ち」のように、具体的なステータスを出力するために使います。

フィールド	例
business	<slug>
tool	notion / github / plane / linear / obsidian / manual
board_id または URL	ツール固有
列の上書き設定	このボードがデフォルトの5列を使わない場合のみ

事業にまだマッピングが設定されていない場合は、自動的にsetupへ進みます — 使用するツールを確認し、マッピングを保存して、リクエストされたモードに戻ります。

ステップ 3 — アダプターを読み込む

ツールに対応する references/adapters.md のセクションを読み込みます。各アダプターのセクションでは、次の方法を説明しています。

• 列ごとにカード／課題／ページを一覧表示する
• 1つのカードの全内容を読む
• カードを作成する
• カードを別の列へ移動する
• コメント／メモを追加する

アダプターの使用方法：

• Notion → $NOTION_API_KEY（すでにzshenvに設定済み）。Status セレクトプロパティを持つデータベース。
• GitHub Projects → gh CLI（すでに認証済み）。gh project item-list、gh project item-edit。
• Plane → Plane API（$PLANE_API_KEY とワークスペースのslugが必要）。
• Linear → Linear MCPまたはAPIキー。
• Obsidian → Vault内のローカルなカンバン用Markdownファイル。直接読み書きします。
• Manual → 現在のボードの状態を貼り付けるようユーザーに依頼します。ローカルのMarkdownファイルへの書き戻しも提案します。

ステップ 4 — モードを実行する

setup

• 事業で使用しているツールを確認する
• 列の設定を案内する（デフォルトは5列。カスタム設定も提案する）
• マッピングを ${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/pm/boards.md に保存する（リポジトリ内の references/boards.md には保存しない — これはテンプレート専用です）。まだ存在しない場合は親ディレクトリを作成する。
• 任意で、その事業についてユーザーが考えていることを会話で確認し、初期カードをボードに追加する

triage

• Backlog 列を取得する
• アイゼンハワー（Q1/Q2/Q3/Q4）を適用する — ユーザーにマトリックスビューを表示する
• 移動を提案する:
  • Q1（緊急 + 重要）→ 今すぐ Ready または In Progress に移動
  • Q2（重要、緊急でない）→ Ready に移動し、いつ着手するかをスケジュール
  • Q3（緊急、重要でない）→ 委任する（誰に？）、担当者がいなければ Ready に移動
  • Q4（どちらでもない）→ アーカイブ
• アダプター経由で移動を適用する（またはユーザーが手動で適用するテキストを出力する）

next

• 単一ボード: Ready を取得し、次に In Progress を取得します。WIP を超えている場合は、先に何を完了すべきかを明示します。WIP に空きがある場合は、アイゼンハワー優先度に基づいて Ready の最上位項目を提案します。
• ポートフォリオ横断（ビジネス指定なしの /pm next）: すべてのボードから Ready を取得し、アイゼンハワーで順位付けし、すべてのビジネスを横断して上位 1〜3 件を提案します。Q1、次に Q2 を優先します。

status

非同期で共有可能なスナップショットを生成します:

# [Business] — Status as of YYYY-MM-DD

**Shipped this week:** N cards
- <card title>
- <card title>

**In progress:** N cards
- <card title> — <who/what>

**Review/Blocked:** N cards
- <card title> — blocked on <reason>

**Up next:** top 2–3 from Ready
- <card title>
- <card title>

**Open question:** <one thing that would unblock progress if answered>

出力は Slack、Notion、メール、パートナーへの DM にそのまま貼り付けられます。

unblock

• Review/Blocked にあるすべてを読む
• 各カードについて: ブロッカーを明示し、アクションを提案する（X に催促、Y にエスカレーション、スコープ縮小、中止、ブロッカーが解消済みなら In Progress に戻す）
• 移動の短いリストを出力する

weekly

金曜日のパルス + プランニング:

1. 各ボードについて: 今週出荷したもの、進行中、ブロック中
2. ポートフォリオ横断: 勢いがあるのはどこか？ 停滞しているのはどこか？
3. 来週の計画: 月曜日に Ready から In Progress へ引き上げる Q2 項目を 3〜5 件
4. 統合スナップショットを出力する — Notion の週次ログ、パートナー向けアップデート、個人ジャーナルに貼り付け可能

WIP 制限

列ごとのデフォルト WIP（ビジネスごとにローカルの boards.md で上書き可能）:

列	デフォルト WIP
In Progress	3
Review/Blocked	（制限なし — ただし 5 を超えたらフラグを立てる）

next モードで WIP を超えている場合、それ以上引き上げないでください — 先に何かを完了するか、Review/Blocked へ移動することを提案してください。

非同期ファーストのライティングルール

status / weekly の出力を生成する際:

• 見出しから始める — 今週出荷したもの、またはリスクのあるもの
• 具体的に書く — 「Y で進捗があった」ではなく「X を出荷した」
• 主語のない動詞を書かない — 読者が前提知識なしで読めるように書く
• ブロッカーはブロッカーを名指しする — 「ブロック中」ではなく「デザイナーのレビュー待ち」
• 未解決の問いは明示する — ステータスごとに 1 行、勢いを回復するために必要なことを尋ねる太字の行

組み合わせ可能なもの

• decide — プロジェクトが本当の意思決定に直面したとき、/decide にルーティングする
• deep-research — カードが実行可能になる前に調査が必要なとき
• business-brainstorm — Backlog のアイデアがトリアージ前に検証に値するとき
• jab-hook — ステータス / 出荷済み項目が BIP 投稿の素材になるとき
• メモリ（project_*.md） — ビジネスごとのポートフォリオコンテキスト用

品質に関する注意

• WIP を制限する。 マルチタスクは、何も出荷できない最も確実な方法です。In Progress は 3 に制限してください（本当に必要な場合は、ビジネスごとにローカルの boards.md で上書きできます）。上限に達したら、それ以上引き上げないでください — 何かを完了するか、Review/Blocked へ移動することを提案してください。
• すべてのステータス出力で見出しから始める — 今週出荷したもの、またはリスクのあるもの。「X で進捗があった」ではありません — それはノイズです。
• 具体的に書く。 「ブランディングで進捗があった」よりも「主要なロゴバリアントを出荷した」のほうが優れています。具体性は実際の動きを示し、曖昧さは何も示しません。
• 主語のない動詞を書かない。 読者が前提知識なしで読めるようにステータスを書いてください — 3 週間後でも、前回の更新を見逃したパートナーに転送されても読めるように。
• ブロッカーはブロッカーを名指しする。 「ブロック中」ではなく「ホームページ草案に対するデザイナーのレビュー待ち」。名前のないブロッカーは緊急性を生みません。
• 未解決の問いは明示する — ステータスごとに 1 行、勢いを回復するために必要なことを尋ねる太字の行。非同期の勢いは、未解決の問いをどれだけうまく表面化できるかにかかっています。
• 設計上ツール非依存。 pm はカンバン + アイゼンハワーで話し、アダプター（Notion / GitHub / Plane / Linear / Obsidian / 手動）がそれを変換します。新しいツールの追加 = アダプターファイル 1 つであり、書き直しではありません。