| name | project-kickoff-interrogation |
| description | Use when a user is starting a new project (0→1) or saying things like "我想做一个 X" / "I want to build" / "let's make a tool that". Conducts a 9-step interrogation grounded in the 钉钉 ONE post-mortem (《置身钉内》, 75k 字, 滕雅辛 2026) to lock down 发心/用户/场景/价值/竞争/双边博弈/MVP/倒排陷阱/止损线 BEFORE writing code or plans. Each question comes with intro + multiple-choice options (not blank-slate prompts), so the user picks rather than free-writes. Produces a frozen baseline.md the user can use to slap themselves later when the project drifts. |
| version | 1.0.0 |
| author | Hermes Agent (inspired by 滕雅辛《置身钉内》, 2026) |
| license | MIT |
| platforms | ["linux","macos","windows"] |
| metadata | {"hermes":{"tags":["product","kickoff","interrogation","post-mortem","planning","dingding-one","anti-vibe"],"related_skills":["writing-plans","plan","spike","ideation"]}} |
Project Kickoff Interrogation (立项拷问)
Overview
大部分项目不是死在执行，是死在「让我们开始做吧」那一刻——没有人逼着回答本来会杀死这个项目的问题。
这个 skill 是 ideation（发散）和 writing-plans（执行）之间缺失的中间层。它在项目最脆弱的瞬间（用户兴奋、答案还很软）逼一遍 9 个问题，把答案冻结成一份 baseline 文档，让以后的漂移可见、可问责。
9 个拷问 不是凭空设计的——每一条都对应滕雅辛《置身钉内》（钉钉 ONE 项目 75k 字复盘，2026 年 6 月）里的一个具体失败。完整映射见 references/one-case-study.md。
When to Use
Use when:
- 用户说"我想做一个 X" / "我有个 idea" / "I want to build" / "let's make"
- 项目位于 brainstorm 已完成 → 实施计划未开始 之间
- 用户很兴奋，回答听起来"都行"、"看情况"、"应该是"
- 团队即将投入人力/预算到一条新产品线
- 重新评估一个已经在漂移的项目
Don't use for:
- 纯技术 spike（→
spike）
- 完全没方向的发散（→
ideation）
- 方向已经锁定，要写实施计划（→
writing-plans / plan）
- 用户明说"side project 别 overthink"
强触发短语： "我有个想法" / "我想做" / "I want to build" / "let's build" / "we should make a tool that" / "如果有一个 X 就好了".
The Anti-Pattern This Skill Targets
「ONE 一开始就不是一个发心单纯的产品。它既想替用户减负，也想替钉钉换代；既想证明 AI 能进入工作流，也想证明钉钉还能站在下一代办公入口上。这里面有理想，也有指标；有用户价值，也有组织意志。」
—— 《置身钉内》第一卷
跳过这个 skill，你会复刻 ONE：300 人团队、首发 DAU 300 万、半年内被全网抵制、产品收缩。根因不是技术，是没人在 day 0 强迫创始人回答"这个产品不是给谁用的"。
How to Run This Interrogation
核心规则：
- 一次只问一个问题 — 不要 dump 所有 9 个。等用户答完一个再下一个。
- 每个问题先给 intro，再给 choices，再问 — 不要让用户从零开始写。
- 不接受 "and / both / 都要 / 看情况" — 选项是互斥的。如果用户含糊，追问"那个最重要？"。
- 第 2 题选 A（单边）时，跳过第 6 题 — 单边产品没有双边博弈。
- 第 7 / 8 题如果用户选 C 或 D，必须显式说："这是 ONE 同款 red flag，你确认知道这个风险后继续吗？" 得到 Y 才继续。
- 第 9 题必须落地具体数字、日期、人名 — "我们都会注意" = "没人会拉闸"。
- 9 题做完一定写 baseline.md — 不落档就白做。
拷问 1 — 发心 (Origin Intent)
对应 ONE 失败： 第一卷 — 同时挂 4 个发心 = "贪心是七罪之一"，后期所有决策被多目标撕扯。
Intro to give the user:
一个产品的「发心」是它最原始的出发点。原文给出 5 种典型。好产品通常只有一个主发心——其他可以是 side benefit，但不能并列。混发心的产品后期会被各种目标拉扯到崩。
Choices (pick exactly ONE primary):
- A. 解决某个尚未被解决的具体问题 — 最纯，最容易诞生有历史价值的产品
- B. 提升解决某个已解决问题的效率 — 常见且可行（要 10× 改善才有迁移动力）
- C. 服务好某个具体人群 — 社区/身份驱动（vertical SaaS、某行业工具）
- D. 推广某种理念 — 意识形态驱动（Linux、开源、去中心化）
- E. 销售某种资源 — 分发驱动（手里有 token / 算力 / 库存要消化）
Follow-up (mandatory):
- 列出次发心（每个标 ✓ side-benefit 或 ⚠️ distraction）
- 如果主发心选 E 且没有 A/B/C 作为次发心 → 显式提醒："销售资源 + 没有用户问题 = 分发游戏，不是产品。确认继续？"
拷问 2 — 用户定位
对应 ONE 失败： 第二卷 — "带着一盒薛定谔的用户出发了"，老板 vs 员工诉求拒绝下场判断。
Intro to give the user:
目标用户是谁是一半的问题。另一半是**「不是」谁**——而这一半更重要。ONE 拒绝回答"不是谁"，于是想服务所有人，结果谁也没服务好。
Choices (pick the SHAPE):
- A. 单边 (single-side): 付费 = 使用 = 受益，同一个人（消费应用、indie dev tools、开发者自己付钱给自己用的工具）
- B. 软双边 (aligned two-side): 不同人但利益一致（Slack: IT 买，员工用，都想协作顺）
- C. 硬双边 (opposing two-side): 不同人、利益对立（ONE: 老板买想管控，员工用想喘息）—— 死结警告
- D. 多边平台 (3+ sides): 双边市场、广告支撑（淘宝、抖音、Uber）
Follow-up (mandatory, 全部必须答)：
- 目标用户关键特征（一句话）：规模 / 行业 / 角色 / 习惯
- 明确不是谁：写下 3 类不要的用户。如 "不是个人开发者" / "不是非技术人员" / "不是 enterprise 合规客户"
- 如果选了 C：谁的诉求必须牺牲？ 写下原则（不是"具体看情况"）
拷问 3 — 场景定位
对应 ONE 失败： 第二卷三场景定位本来是 ONE 早期最优秀的部分（早晨排兵 / 开会后补课 / 下班前查漏，分钟级具体）。第三卷崩在卡片承载边界失控——审批/会议/文档/钉任务全部接入，从单场景智能助手变成"全模块消息聚合出口"，等于在原有钉钉消息之外新增一层信息流。
Intro to give the user:
"高频日常工具"是模糊词。要回答的是具体哪一秒钟，用户的什么动作或情绪，让他想到你。
Choices (frequency shape):
- A. 高频日常 (high-freq daily): 每天 N 次，竞争秒级注意力（IM、邮箱、浏览器）
- B. 事件触发 (event-triggered): 特定信号出现时才用（alert tool、incident response、客服 ticket）
- C. 周期任务 (periodic): 每周/月/季度一次（review、planning、billing）
- D. 项目周期 (project-based): 一段时间集中用，结束就放下（IDE、design tool）
Follow-up (mandatory):
- 用模板写出具体场景："用户在 ___ 之后/之前/期间，因为 ___ 痛苦/需要，想到我。"
- ✓ 好答案示例（ONE 早期）："用户在开完 2 小时长会、再次打开钉钉发现几十个未读群时，需要快速赶上进度，想到我。"
- ✗ 坏答案示例："AI 办公助手，提升日常效率。"
拷问 4 — 价值定位
对应 ONE 失败： 第三/四卷 — 晨间看板/复盘/发现页都没量化基准。"新鲜感一周后快速衰减"——本来就没人在为这个问题付钱/花时间，省下来也没意义。
Intro to give the user:
原文："用户原本愿意花费多少钱/时间/其他资源，来达成这种价值？" 没有这个 baseline，你的"价值"就是 PPT 词汇。
Choices for "用户现在怎么解决这个问题"：
- A. 手动忍着 — 那痛感真的够吗？
- B. 用工具 X（写出工具名 + 痛点）— 那就是和 X 竞争
- C. 雇人解决（写出成本）— 那你是替代人力
- D. 根本不解决 — ⚠️ 红旗：可能根本没痛
Follow-up (mandatory):
- 痛感量化： 用户每周花多少分钟 / 多少美元 / 多少情绪能量在这事上？给个数字。
- 改善倍数： 你能省下多少？
- 10× 改善 = painkiller，有迁移动力
- 1.2-2× 改善 = vitamin，"有也行没也行"，留存会崩
拷问 5 — 竞争定位
对应 ONE 失败： 第二卷竞争定位 + 第八卷长期思考。原文用 Stack Overflow 月度提问量被 ChatGPT 一年腰斩举例：过去的积累可能反过来成为被绕过的对象。ONE 自身的护城河（"钉钉掌握组织关系"）没用对——拿去做管控算法而不是做"事找人"，护城河浪费了。
Intro to give the user:
"差异化在哪？这个差异化是否可持续？" 第二问比第一问更重要。
Choices (你的护城河本质上是哪一种)：
- A. 数据 / context — 只有你有这数据（组织架构、历史日志、私有数据集）
- B. 渠道 / 分发 — 只有你能在那个入口触达用户（装机量、系统入口）
- C. 网络效应 — 用户越多产品越好（marketplace、social network）
- D. 切换成本 / lock-in — 数据/工作流锁定（CRM、ERP）
- E. 品味 / 手艺 — 难以复制的执行力（罕见，通常是自欺）
- F. 无明显护城河 — speed/timing play 🚨 时间窗口关闭就死
Follow-up (mandatory):
- 两年后还在吗？ 假设 LLM 进步 10×、竞品抄走 UI、用户习惯变了，你还剩什么？
- 如果两年后没了 → 你能做的是把短期窗口最大化（变现、被收购）还是放弃这个 idea？
拷问 6 — 双边博弈 (仅 #2 为 B/C/D 时执行)
对应 ONE 失败： 第四卷终极悖论 —— "To B 产品，付费的是老板，使用的是员工。老板要管控，员工要自由。两者需求 100% 互斥，没有折中解。"
Intro to give the user:
这是 #2 的展开。如果你的产品有多边用户，这里必须把"谁让步"写死。事到临头再决定 = ONE 同款。
Follow-up (mandatory):
- 列出每一边的核心诉求（每边一句话）
- 当两者直接冲突时（必然会冲突），写下优先原则（不是 case-by-case）
- 数据/能力暴露给一方时，另一方知道吗？ （ONE 同款问题：AI 帮员工梳理时也帮老板看到了员工所有漏洞）
- 付费方和决策方是同一人吗？ 否 → 这是 SaaS 双边死结，强烈建议读完
references/one-case-study.md 第四卷再继续
拷问 7 — MVP 边界
对应 ONE 失败： 第五卷 — "正常产品先做 10 分可用，验证后迭代到 80 分完美。ONE 直接一步到位：立项即对标终极形态。还没学会走路，直接强制冲刺百米决赛。"
Intro to give the user:
MVP 不是 "最小但完整"，是 "最小且能验证一个具体假设"。砍到只能验证 #4 的价值假设为止。
Choices (你计划的 MVP 范围)：
- A. 一个动作 (one action): 单一闭环 — "用户能完成 ___ 这一件事" — ✓ 健康
- B. 一个功能 (one feature): 一个核心功能 + 必要 plumbing — 可以，但要确认这一个功能能独立产生价值
- C. 三个核心功能 (3 features): ⚠️ 警告 — 是否真的每个都必要？砍到 A/B 试试
- D. 全场景全链路 (everything): 🚨 ONE 死亡剧本 — STOP，必须显式 ack 风险
Follow-up (mandatory):
- 如果 MVP 只能保留一个动作/界面/接口，是什么？
- 这个最小版本能不能独立验证 #4 的价值假设？不能 → 再砍。
🚨 If user picks C or D: Stop and ask: "这是 ONE 同款 'MVP 直接做终极形态' 的 red flag。原文记载这条死亡剧本。你确认知道这个风险后继续吗？" 必须得到明确 Y 再走下一题。
拷问 8 — 倒排陷阱 (Deadline Trap)
对应 ONE 失败： 第五卷 — "8 月 25 日是固定对外官宣日，日期不可改、规格不可降、战略不能输。所有排期、所有需求、所有设计、所有开发、所有测试，全部为发布会让路。"
Intro to give the user:
不需要建议，只需要诚实回答：是不是有一个外部固定 deadline 在催着这个产品？
Choices:
- A. 没有外部 deadline ✓ 健康
- B. 有 deadline 但可滑动 还行，注意不要让"将就的 deadline"逐步变成"硬 deadline"
- C. 有 hard deadline（发布会 / 合同 / 季度汇报 / 融资 demo） 🚨 ONE 同款
- D. 是 deadline 倒推出来的产品（先有 deadline 再凑产品 idea）🚨🚨 ONE 同款，几乎必败
Follow-up (mandatory if C/D):
- 这个 deadline 是真硬还是组织 perceived 硬？能不能 push 1-2 个 sprint？
- 如果 deadline 不动，MVP 范围（#7）能不能再砍？ 倒排时唯一可调整的是范围，不是质量。
🚨 If user picks C or D: Stop and ask: "这是 ONE 同款 'deadline 倒排一切' 的 red flag。你确认知道这个风险后继续吗？" 必须得到明确 Y 再走下一题。
拷问 9 — 止损线 (Stop-Loss Line)
对应 ONE 失败： 第五卷 — "内测出现隐患——压下；灰度出现用户抵触——无视；留存开始下跌——加码运营、加码推送、强行拉活；舆情开始爆发——公关压制、删帖控评。全程没有一次因为负面真实数据，修正顶层定位。" 第四卷数据："次日留存从 45% 暴跌至 18%；7 日留存跌破个位数；超 60% 用户打开三次以内永久关闭。"
Intro to give the user:
提前写下止损线，事后没有开脱空间。不写下 = 一定不会拉。
Follow-up (mandatory — 必须落到数字、日期、人名)：
- 主指标： 是什么？(DAU / 留存 / 转化率 / NPS / 用户数 / revenue / ...)
- 阈值（必须写具体数字+日期）： 上线 N 个月（N=2 / 3 / 6）后，如果 [指标] < [数值]，就 [stop / pivot / 缩编]。
- 次级触发： 出现 [质性信号 — 例如 "用户主动卸载 > 1000" / "差评率 > 30%" / "团队半数离职"] 时，立即触发复盘。
- 拉闸人： 写下具体人名/角色。
🚨 不接受："我们都会注意" / "团队一起拉" — 那就是没人会拉。必须有一个具体的负责人。
Output: baseline.md
9 题全部答完后，按 templates/baseline-template.md 的结构写一份 baseline 文档。
Save location (agent 自行判断当前环境)：
- Hermes 环境：
~/.hermes/projects/<project-slug>/baseline.md（目录不存在就创建）
- Claude Code 在 repo 内：
docs/baseline.md 或项目根目录
- 通用：在当前 workdir 下创建
<project-slug>-baseline.md
Format 强制要求：
- 文件顶部必须有「⚠️ 这是一份冻结基线 (Frozen Baseline)」声明
- 包含日期
- 包含本 skill 的版本（
project-kickoff-interrogation v1.0.0）便于追溯
写完之后向用户口头总结：
- baseline.md 已存到 [path]
- 高亮其中的 🚨 red flag 项（#7 C/D, #8 C/D 等）
- 提醒下一步：用
writing-plans 写第一阶段实施计划，只覆盖 #7 写下的 MVP 范围，不要把 9 题答案当 backlog
Common Pitfalls
-
让用户"and / both" 蒙混过关。 Choices 是互斥的。用户说 "A 和 B 都重要" → 必须追问"那个最重要？" 直到给一个。
-
跳过 #2 的"不是谁"。 "Everyone" / "所有人" 不是答案。强制要求 3 个明确的 "not for" 类别。
-
#6 在 #2 = A 时也乱问。 单边产品没有双边博弈，跳过 #6，不要硬问。
-
#7 / #8 用户选 C/D 时不停下确认风险。 这是 ONE 同款致命剧本。必须显式说 "这是 ONE red flag" 并得到明确 Y 再继续。
-
#9 没人名 / 没数字 / 没日期。 "我们都会注意" 是 ONE 同款"全程没有一次纠偏"的起点。
-
不存 baseline.md。 整套拷问做完不落档 = 白做。一定要写文件并报告路径。
-
照本宣科 ONE 案例。 ONE 是 to-B SaaS。如果用户做 to-C 消费产品 / 开发者工具 / 硬件，举例时要类比到对应领域，不要硬套钉钉场景。用户问"为什么"时再引用 references/one-case-study.md 对应卷。
-
一次 dump 全部 9 题。 用户会失去耐心或乱答。一次一题，等答完再下一题。
-
第 2 题 follow-up "不是谁" 接受 2 个就放过。 必须 3 个。ONE 失败的核心就是没有这一层。
Verification Checklist (for the agent running this skill)
Cross-Agent Note (Hermes + Claude Code)
This skill is designed to run on both Hermes and Claude Code. It deliberately avoids tool-specific calls in the question protocol. Both agents should:
- Read this SKILL.md
- Conduct the interrogation conversationally（一次一题，不要 dump）
- 引用
references/one-case-study.md when 用户问 "为什么要问这个？"
- Use
templates/baseline-template.md for output structure
- Write the output file using whatever file API the agent has
Placement for Claude Code: put this skill at .claude/skills/project-kickoff-interrogation/ for per-repo use, or ~/.claude/skills/ for user-global.
Placement for Hermes: already in ~/.hermes/skills/product-thinking/project-kickoff-interrogation/.
