pm

/pm — 跨业务组合的项目管理

以方法论为先的项目管理。看板 + 艾森豪威尔矩阵 + 异步协作。每项业务一个看板。通过适配器实现工具无关。

心智模型

每项业务都有自己的看板，包含 5 列：

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

• Backlog：所有可能重要的事项——尚未承诺处理
• Ready：已完成分流、定义清晰，可以开始处理
• In Progress：正在积极推进
• Review/Blocked：正在等待他人、评审或外部依赖
• Done/Archived：已交付或已取消

艾森豪威尔矩阵位于看板之上——用于将 Backlog 分流到 Ready（哪些事项入选），以及从 Ready 中选出下一项（先处理哪项 Ready 事项）。

                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 中与该工具相关的部分。每个适配器部分都说明如何：

• 按列列出卡片 / issue / 页面
• 读取单张卡片的完整内容
• 创建卡片
• 在列之间移动卡片
• 添加评论 / 备注

适配器使用：

• 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 key。
• Obsidian → vault 中的本地 kanban 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、电子邮件或合作伙伴私信中。

unblock

• 阅读 Review/Blocked 中的所有内容
• 对每张卡片：指出阻碍因素，并建议采取行动（提醒 X、升级给 Y、缩小范围、取消；如果阻碍已消除，则移回 In Progress）
• 输出简短的操作列表

weekly

周五进展简报 + 规划：

1. 对每个看板，列出本周已交付、进行中和受阻的事项
2. 跨业务组合：哪些方面进展顺利？哪些方面偏离了计划？
3. 规划下周：从 Ready 中挑选 3–5 项 Q2 任务，于周一移至 In Progress
4. 输出汇总快照，可粘贴到 Notion 周报、合作伙伴更新或个人日志中

WIP 限制

各列的默认 WIP（可在各业务对应的本地 boards.md 中覆盖）：

列	默认 WIP
In Progress	3
Review/Blocked	（不限——但超过 5 项时需标记）

在 next 模式下，如果超出 WIP 限制，不要再拉取任务——建议先完成某项任务，或先将某项移至 Review/Blocked。

异步优先写作规则

生成状态或周报时：

• 开头先写重点——本周交付了什么，或什么事项存在风险
• 具体明确——写“已交付 X”，而不是“Y 有进展”
• 动词必须有主语——确保读者无需了解上下文也能看懂
• 明确写出阻碍因素——写“等待设计师审核”，而不是“受阻”
• 明确列出待解决问题——每条状态用一行加粗文字提出需要解决什么问题才能推动进展

可组合使用

• decide——项目需要做出实际决策时，转到 /decide
• deep-research——卡片需要先研究才能采取行动时
• business-brainstorm——Backlog 中的想法在分类前值得深入验证时
• jab-hook——状态或已交付项目可以作为 BIP 帖子的素材时
• 记忆（project_*.md）——用于了解各业务的业务组合背景

质量说明

• 限制 WIP。 多任务处理是最可靠的“什么都交付不了”的方式。将 In Progress 限制在 3 项（如确有需要，可在各业务对应的本地 boards.md 中覆盖）。达到上限后，不要再拉取任务——建议先完成某项任务，或将某项移至 Review/Blocked。
• 每次输出状态时都要开头先写重点——本周交付了什么，或什么事项存在风险。不要写“X 有进展”——这毫无信息量。
• 具体明确。“已交付主徽标变体”胜过“品牌建设有进展”。具体表明确有进展；含糊则无法体现进展。
• 动词必须有主语。 撰写状态时，要确保读者无需了解上下文也能看懂——即使是 3 周后阅读，或转发给错过上次更新的合作伙伴，也能看懂。
• 明确写出阻碍因素。 写“正在等待设计师审核首页草稿”，而不是“受阻”。不明确的阻碍不会带来紧迫感。
• 明确列出待解决问题——每条状态用一行加粗文字提出需要解决什么问题才能推动进展。异步协作的推进成效，取决于待解决问题是否清晰可见。
• 设计上不依赖特定工具。 pm 使用 Kanban + 艾森豪威尔矩阵；适配器（Notion / GitHub / Plane / Linear / Obsidian / 手动操作）负责转换。添加新工具只需新增一个适配器文件，无需重写。