project-kickoff-interrogation - SKILL.md Agent Skill

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)

9 个拷问全部走完（#6 仅在 #2 = A 时跳过）
不接受"and / both / 都要"答案 — 用户互斥选择了一个
#2 有明确的"不是谁"列表 (≥3 项)
#4 有量化的痛感 baseline + 改善倍数
#5 回答了"两年后还在吗"
#7 picked A 或 B（如果 C/D 必须显式得到 🚨 ack）
#8 picked A 或 B（如果 C/D 必须显式得到 🚨 ack）
#9 有具体数字 + 日期 + 人名
baseline.md 已落盘
baseline.md 顶部有 "冻结基线" 声明
完成后给用户报告：路径 + red flag 高亮 + 下一步建议

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/.