feature-teardown
Skill0 starsChanged 3 months agoMITView on GitHub
功能级竞品拆解:这个功能别人家怎么做的、用户路径几步、他们为什么做、 我们现在是不是其实已经有了只是用户找不到、有没有别的解法。 触发词:竞品怎么做的、别人家怎么做的、有竞品吗、这个功能谁做过、拆一下竞品、 我们是不是已经有了、feature-teardown。 轻量前置动作,不出完整竞品简报;不查开源代码实现(那个用本套件的 prior-art)。
In this repository5 other files it gives its agents.
- pm-flowSkill
- prd-writingSkill
- prior-artSkill
- requirement-evalSkill
- tracking-planSkill
The file
Files
Feature Teardown
一个功能想法或一句用户抱怨进来,五步之内给出结论:抄谁 / 我们已经有了改入口就行 / 换个解法 / 真得做。
边界
管:单个功能级别的对比。别人怎么做、为什么做、我们有没有、还能怎么做。
不管:
- 完整竞品简报(公司定位、pricing、win/loss、battle cards、market trend)→ 装有 product-management 插件时用其 competitive-brief,否则不在本 skill 范围
- 这个需求值不值得做的 KANO/RICE 结论 → requirement-eval(本套件内)
- 方向还没定、要发散多个方向 → 推荐上游 addyosmani/agent-skills 的 idea-refine
- 开源库/能抄的代码 → prior-art(本套件内)
当前产品从上下文解析,不预设
第 4 步要盘点"我们现有能力","我们"指哪个产品每次都要确认:用户当场说的、项目文档、 项目根配置、对话上文。没有默认产品,也不要沿用其它会话或其它任务里出现过的产品。 缺就问一句,不猜。
如果这轮压根没有"我们"(纯个人新项目,还没有存量产品),第 4 步跳过并说明跳过了。
五步
1. 谁做过
分三层,别只看直接竞品:
- 直接 —— 同类产品的同一功能
- 间接 —— 用完全不同的形态解决同一个问题
- 替代 —— 不用软件怎么解决:Excel、手工流程、雇个人、或者干脆啥也不做
"啥也不做"是最容易漏的一个选项,也经常是真实答案。
2. 用户路径几步
不要停在"他们有这个功能"。写出从触发到拿到结果的完整步骤:
- 入口在哪(用户怎么发现的)
- 中间几步、每步要用户做什么决定
- 什么时候能看到结果、失败了怎么办
步数和入口位置本身就是结论。 同一个功能藏在三级菜单里和挂在首屏,是两个产品决策。
3. 为什么做(反推,不是事实)
从可查的东西倒推动机:改版记录 / 发布说明 / 帮助中心措辞 / 应用商店更新日志 / 社区和评论区吐槽 / 招聘 JD。
回答两个问题:他们在服务哪类人、解决这类人的什么问题。
这一步的产出全部标成推断,不能当事实用。 写「推测:…,依据:…」, 依据拿不出来就写「动机不明」,不要编一个合理的故事。
4. 自查:我们是不是已经有了 ⟵ 早退出闸门
先把需求升维:这个功能在第一性原理上解决的是什么问题("要收藏功能" → "高频内容会被历史清理冲掉")。 拿这个问题、而不是功能名,去核当前产品——同一个问题常常已经被另一个形态的功能解决了,按功能名查永远查不到。
核对必须有证据来源,按优先级:
- 产品知识库:按 PRODUCT-CONTEXT 协议登记过知识库的, 先去知识库里查现有能力和历史方案,再下结论
- 拿升维后的问题反问用户:"现在用户遇到这个问题时是怎么解决的?有没有部分解决它的功能?"
- 两者都没有 → 明确写「现状能力未核实」,不许凭空回答下面三问
有了证据再对着第 2 步的用户路径逐步核:
- 这条路径我们能不能走通?
- 能走通的话,是能力问题还是发现路径问题——用户不知道有、找不到、还是用了但不认为解决了?
- 不能走通的话,缺的是哪一步?
结论是「已经有了,是入口/认知问题」就到此为止,不要往下走第 5 步、不要交给 requirement-eval、更不要写 PRD。 直接给改入口/改文案/加引导的建议,这轮就结束了。
这一步是整个 skill 最值钱的地方。跳过它的代价是白做一个功能。
5. 别的解法
只有第 4 步没早退时才做。不做这个功能,同一个问题还能怎么解决—— 改现有功能、换交互形态、改默认值、加引导、或者判定这个问题不值得解。
输出
只写最终态。不写调研过程,不列否掉的候选,除非否掉的理由本身是结论。
## 结论
<一句话,四选一:抄 X 的做法 / 我们已经有了,改的是入口 / 换 Y 解法 / 真得做,做 Z>
## 别人怎么做的
| 产品 | 类型(直接/间接/替代) | 用户路径 | 入口位置 | 访问日期 |
|---|---|---|---|---|
## 动机推断
- <产品>:推测服务 <人群> 的 <问题>;依据:<可查来源>
## 我们现在的状态
- 路径能否走通:
- 缺的是能力还是发现路径:
- 证据:
## 建议
<具体到做什么,不是"建议进一步调研">反模式
- 只写"竞品 A 有这个功能",不写路径几步、入口在哪
- 动机推断没标成推断,写得像事实
- 跳过第 4 步直接说"该做" —— 这是这个 skill 存在的唯一理由
- 漏掉"替代方案"层,尤其是"啥也不做"
- 结论写成"各有优劣,供参考",不给推荐
- 表里没有访问日期 —— 产品一改版整张表就过期了
- 越界去做 pricing、市场规模、win/loss
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

