GeekX App Forge

把“我好像想做个东西”锻造成值得做、范围清楚、体验克制、可直接开发的产品交付包。

核心不是更快写 Spec，而是先证明：为什么要做、真正要解决什么、最小产品是什么、什么绝对不做。

硬门槛

1. 先查再问。 能从上下文、文件、仓库、官方文档或公开资料确认的事实，不问用户。
2. 先怀疑需求。 “能做”不等于“该做”；AI Coding 降低开发成本，不等于降低维护和产品复杂度。
3. 至少 10 轮有效澄清。 REQUIRED SUB-SKILL: 使用 geekx-grilling，一次一问。每轮必须改变目标、范围、用户、成功标准、风险或路线；禁止凑数。
4. 推荐不等于确认。 用户没有明确选择，就不能关闭分支。
5. 先自用，再商业化。 先验证自己的高频真实痛点，再检查是否存在可复制人群、付费理由和差异化。
6. 先删再加。 每个功能都问：这是用户真正要的吗？删掉会不会更好？现在不做会怎样？
7. 确认前不写 Spec。 需求、非目标和主要风险未关闭时，不进入设计资产。
8. 交付必须可开发。 已经调研过的静态数据、文案、分类、图标规范、App identity 不得甩给 Coding Agent 重新研究。

阶段门

Gate 0 — 还原真正动机

先确认：

• 为什么现在产生这个想法；
• 当前真实场景和频率；
• 不做 App 时用户如何解决；
• 用户说要 A，底层是不是其实要 B；
• 这是持续问题、一次性问题，还是“因为现在容易开发所以想做”。

随后进入至少 10 轮 geekx-grilling。读取 references/grilling-and-reality-check.md。

Gate 1 — Reality Check

对已经形成的主张做反方审查：

• 伪需求风险；
• 使用频率是否足够；
• 是否已有更轻的替代方案；
• 技术可行性与平台限制；
• 最大复杂度税；
• 最可能失败的假设；
• 最低成本验证；
• 什么证据会让我们停止。

证据不足时只能标记“待验证”，不能装成事实。

Gate 2 — Evidence Chain

对会改变决策的事实做调研。优先级：

1. 官方/一手资料；
2. 原始仓库、API、平台政策；
3. 真实用户/社区反馈；
4. 竞品与商业信号；
5. 二手分析仅作补充。

读取 references/evidence-and-commercialization.md。输出证据、反证、未知项和结论权限。

Gate 3 — Product Shape

把想法压成：

• 目标用户；
• 核心任务；
• 高频触发场景；
• 一句话价值；
• P0；
• 明确非目标；
• 成功标准；
• 最小验证；
• P0.5/P1 只作为延期项。

如果 P0 仍像一个平台，继续删。

Gate 4 — Commercialization Lens

先保证自用价值成立，再回答：

• 哪类人和我有同样痛点；
• 为什么他们会持续使用；
• 为什么现有方案不够；
• 什么能力可形成差异；
• 谁可能付钱、为什么；
• 商业化会不会反过来污染 P0。

商业化不是强行加账号、订阅、云服务；只是保留未来路径。

Gate 5 — Design Freeze

若为 Apple 平台，读取 references/apple-native-product-design.md。 默认：Apple HIG、系统组件、SF 字体、semantic colors、内容优先、低认知负担。禁止把“高级感”翻译成渐变、玻璃、阴影、卡片墙。

用户明确确认目标、P0、非目标、体验方向后，才进入正式设计。

Gate 6 — Spec → Plan

REQUIRED SUB-SKILL: 使用 superpowers:brainstorming 写 Product + Design Engineering Spec；复用已确认决定，不重新发散需求。

用户批准 Spec 后： REQUIRED SUB-SKILL: 使用 superpowers:writing-plans 写 Implementation Plan。

Spec 和 Plan 必须保持同一套名称、范围、数据结构、文案和验收标准；发现冲突先修文档，不让实现 Agent 猜。

Gate 7 — Static Data & App Identity

在交付前补齐 Coding Agent 不应该重新研究的内容：

• App 名称、英文名、Repo、Bundle ID、平台和最低版本；
• Tab/导航名称；
• 用户可见固定文案；
• 首批 seed；
• 枚举/分类/manifest；
• 已研究的数据集与来源映射；
• 本地通知固定文案；
• 导出格式；
• Icon 概念、禁止项、Light/Dark/Tinted 规则；
• 设计 tokens/系统语义；
• 任何可直接 import 的 JSON/CSV/Markdown。

读取 references/developer-handoff.md。

Gate 8 — Developer Handoff ZIP

最终交付至少包含：

AGENTS.md
README.md
docs/
  product/
  research/
  plans/
  handoff/
Resources/
  Seeds/

根据项目实际删掉不需要的目录；不要为了模板完整制造空文件。

交付前审查：

• Coding Agent 是否还需要重新做产品研究？
• 是否还有 TBD / TODO / “自行决定”？
• 静态数据能否直接导入？
• App 名称/Icon/文案是否明确？
• P0 与延期项是否分开？
• 是否出现未经确认的新功能？
• 是否有过度设计？
• ZIP 解压后是否能直接开始 Task 1？

STOP 条件

出现任一情况，停止进入开发计划：

• 真实痛点证据不足；
• 低频一次性需求，轻量替代已足够；
• 核心技术假设未验证；
• 用户仍未确认关键范围；
• P0 主要由“以后可能需要”组成；
• 商业化假设依赖虚构用户；
• 维护成本明显高于可获得价值。

此时输出 不做 / 先验证 / 缩小 / 转向，而不是为了产出 ZIP 强行继续。

最终原则

先证明值得做，再决定做什么；先把产品变简单，再把交付变完整。

如果一个功能不能明显帮助核心任务，删掉。 如果一份文档不能减少实现歧义，删掉。 如果 Coding Agent 还需要重新研究已经研究过的东西，交付还没完成。