pm-mode-dev-skill

你当产品经理，Claude 当技术合伙人。

友情链接：本项目在 LINUX DO 社区分享与交流，欢迎前往讨论、提建议。

一个 Claude Code 个人 skill，面向不太懂代码、但想把项目正经做出来的人。说一句「我要做一个 XX」，它会：用白话选择题访谈你 → 自己定技术方案 → 生成六份分工明确的项目文档 → 搭好自动质量检查 → 然后退场。此后你在项目里的日常只有三句话：「继续」「连着做完 M1」「通过 / 不行，因为……」。

为什么做这个

我之前的方案是三个 Claude 窗口组成的流水线（规划/执行/质检三个角色，靠 GitHub 传话、/loop 每 4 分钟轮询一次贴缓存）。出发点不错，但实际用起来仪式繁琐、token 烧得快，大量轮询是空转。

后来两件事让我推倒重来：

1. Claude Code 订阅版的提示缓存 TTL 变成 1 小时，"勤轮询省钱"的前提消失了；
2. 读了 Anthropic 和 OpenAI 的官方工程实践文章，两家的结论指向同一个方向——模型越强，套在它身上的流程就该越薄。Anthropic 明确写过：他们的长任务 harness 每个组件都编码一条"模型不行"的假设，模型升级一代就该拆掉一件；线性开发任务拆成多 agent 是浪费。OpenAI 那篇 5 个月 100 万行代码、0 行手写的文章，口号是 "Humans steer. Agents execute."——人管方向，agent 干活。

所以这个 skill 的思路是反过来的：不给模型加流程，而是给项目装底盘。

和 Superpowers 这类流程框架有什么不同

Superpowers 等框架把工程流程（头脑风暴→计划→强制 TDD）注入每一次对话，让 agent 按步骤走。它们面向工程师，社区对它们最常见的反馈是：流程太重、模型被拖慢，简单任务也要走全套。

本 skill 的取向不同：

防屎山不靠流程仪式，靠不会说谎的机械手段：一条命令的质量门（格式化+lint+类型检查+测试，不全绿不许提交）、防造假抽查（故意改坏代码验证测试警报真的会响）、技术债记账、架构决策留痕、验收标准冻结。这些全部写在生成的项目文档里，由任何一个新会话自动执行。

安装

git clone https://github.com/Starigen-x/pm-mode-dev-skill.git ~/.claude/skills/new-project

需要 Claude Code（CLI 或桌面 app 均可；Claude Desktop 聊天应用不支持 skills）。新开一个会话即生效。

更新：cd ~/.claude/skills/new-project && git pull

使用

在任何目录下对 Claude 说「我要做一个 XX」，或输入 /new-project。它会：

1. 产品访谈：白话选择题，只问产品问题，不考你技术
2. 技术选型：自己定（保守主流、最少活动部件），只向你汇报影响
3. 生成文档六件套：PRD、功能台账（你的仪表盘）、架构与决策记录、协作手册、技术债台账、白话更新日志，外加项目 CLAUDE.md 和一个独立质检子代理
4. 搭工程底座：git、一条命令的质量门、一键启动
5. 开工汇报后进入日常循环：每个功能做完都按固定模板汇报，必含一条「你怎么验证」——非程序员一步能照做的操作

设计依据

每条规矩防什么事故、出处在哪，全部记录在 references/playbook.md。主要来源：

• Anthropic《Effective harnesses for long-running agents》及其续作《Harness design for long-running apps》
• Anthropic Claude Code 官方最佳实践、内部团队用法
• OpenAI《Harness engineering》、Codex 最佳实践与 AGENTS.md 规范
• 前身项目（三角色流水线）一天七个 PR 实战中沉淀的教训对照表

交流与反馈

本项目在 LINUX DO 社区分享，欢迎在那里交流使用体验、提改进建议；也欢迎直接开 Issue。

这套东西的设计哲学是流程只减不加——如果你觉得哪条规矩多余、拖慢了你，那正是我下一个要拆的规矩，非常欢迎这类反馈。

License

MIT