想把新 App 想法验证并做成无需重写的首版时…

适用于用户想构建新 App、写代码前验证想法、为 MVP 设计不会被迫重写的架构，或要求“帮我用正确方式构建 App”的场景。

适用场景

解决思路

1. 核心原则：快速验证同时保留选项：早期做昂贵且难逆转的决策，推迟所有便宜决策；把稀缺的早期精力花在会复利的三件事——最风险假设、依赖边界、领域语言；其他方面极力避免浪费。
2. Journey Map 编排：Phase 1 lean-startup 回答最风险假设是否为真及 MVP 是什么，创建 docs/PRODUCT.md + docs/EXPERIMENTS.md；Phase 2 design-sprint 回答核心流程应是什么，创建 docs/DESIGN.md 并扩展 docs/EXPERIMENTS.md — awaiting-evidence；Phase 3 clean-architecture 回答哪些边界能保留选项，创建 docs/ARCHITECTURE.md；Phase 4 domain-driven-design 回答代码意味着什么，扩展 docs/ARCHITECTURE.md；Phase 5 clean-code 回答每个函数是否可读且被测试，创建 docs/TESTING.md；Phase 6 pragmatic-programmer 回答哪些习惯保持健康，扩展 docs/TESTING.md + docs/TECH-DEBT.md；Phase 7 system-design 回答它真正需要多大，扩展 docs/ARCHITECTURE.md；Phase 8 ios-hig-design 回答在 iOS 上是否感觉原生，扩展 docs/DESIGN.md — 仅 iOS；Phase 9 37signals-way 回答发布什么、砍掉什么，扩展 docs/PRODUCT.md + docs/STRATEGY.md；Phase 10 software-design-philosophy 回答复杂度藏在哪里，扩展 docs/TECH-DEBT.md + docs/ARCHITECTURE.md。
3. Operating Rule 1 恢复优先：先读 docs/CREATE-APP-PLAN.md 和 Journey Map 中每个 artifact；如果 tracker 存在，用 3-5 行总结旅程状态并询问要进入哪个 phase；用户确认入口后本步完成；有 tracker 的旅程只恢复，绝不重启。
4. Operating Rule 2 仅首次运行做 Intake：没有 tracker 时先运行 Intake，然后创建 docs/CREATE-APP-PLAN.md，给每个 phase 标记 pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason；tracker 存在且用户确认 phase 计划后本步完成。
5. Operating Rule 3 进入 phase：宣布该 phase 做什么、强制什么决策、产出什么 artifact、大致工作量；提供 proceed / skip / defer；标记 GATE 的 phase 可 defer，不可 skip；用户选择 proceed 时标记 in-progress；用户选择后本步完成。
6. Operating Rule 4 技能调用与回退：加载该 phase 的 skill 并按 slug 使用；每个 phase 的 Invoke 行指定 skill；若不可用，提供 `npx skills add wondelai/skills/<slug> --global`；用户拒绝则按其 Brief 运行该 phase（最低可行方法），并说明当前处于哪种模式。
7. Operating Rule 5 阶段内决策：对每个「Decide with the user」问题都要提问，给出具体选项和你的建议；把选择记录到 tracker 的 Key Decisions；静默做出的决策算缺陷。
8. Operating Rule 6 阶段退出：写文件前先展示 artifact 草稿内容给用户签字；批准后写入或扩展 docs/ 文件，更新 tracker 的 status、Key Decisions、Next Actions；文件写出且该 phase 行显示 done 后完成。
9. Operating Rule 7 Artifact 纪律：写前先读；文件缺失才创建，否则扩展——增加或更新你的章节，保留其他人的章节；docs/ 下文件名用 UPPERCASE；每条建议落地为 checkbox 或带 owner 和 priority 的表格行；首次创建 docs/ 文件时参考 references/artifact-templates.md，用完整骨架（所有章节标题）创建，再填写本 phase 指定的章节。
10. Operating Rule 8 Agent 只准备和处理；只有人类能接触客户和测试用户：起草 sprint 脚本和访谈指南并给结果打分，然后以 awaiting-evidence 状态暂停，等用户带回笔记；仅在发布原生 iOS app 时执行 ios-hig-design phase，否则在 intake 时 skip。
11. Intake 问题 1：用一句话说明 app 想法，以及背后最风险的信念是什么？此项决定 Phase 1；如果 app 被雇佣完成的任务模糊，增加 jobs-to-be-done 可选 phase。
12. Intake 问题 2：底层想法是否已有行为证据验证，还是仍是直觉？未验证且高风险时 Phase 1 必做；若已有付费客户，可能走错旅程——应使用 improve-app 或 grow-app。
13. Intake 问题 3：阶段是什么——周末原型、融资后向发布构建，还是围绕它组建团队？原型侧重 Phases 1-3 和 10；组建团队可能增加 inspired-product。
14. Intake 问题 4：是否要发布原生 iOS 客户端？是则保留 Phase 8，否则跳过。
15. Intake 问题 5：是否有客户可谈，还是必须寻找客户？此项决定 Phases 1-2 的人类证据循环以及可选的 mom-test / continuous-discovery。
16. Intake 问题 6：预期前几个月负载是多少——每日活跃用户数和每日操作数？用于 Phase 7 容量计算并阻止过早扩展。
17. Intake 问题 7：单人构建还是团队，谁负责发布节奏？此项决定 Phase 9 shaping。
18. Phase-skip 启发式：核心流程已测试或很简单时跳过 Phase 2；不发布原生 iOS 时跳过 Phase 8；只有负载明显很小时才跳过 Phase 7，但仍要记录估算；周末原型把 Phases 3-6 作为一遍运行，但绝不跳过 Dependency Rule。
19. 创建 docs/CREATE-APP-PLAN.md：从模板创建，给每个 phase 标记状态，并标注 Phase 8 为 iOS-conditional；当 docs/CREATE-APP-PLAN.md 存在、每个 phase 都有状态且用户确认计划后完成。
20. Phase 1 目标：证明若为假会杀死 app 的信念——在写生产代码之前。
21. Phase 1 Brief（回退）：反向规划 Build-Measure-Learn：必须学到什么、如何知道、发现它所需的最小 build 是什么；按致命程度而非容易测试程度排列 leap-of-faith 假设；MVP 是学习载体，常常粗糙（Dropbox 用视频而非同步引擎验证）；攀爬验证阶梯——注册弱、付费押金强、活跃使用最强；瞄准行为级别 4-5，绝不用「你会用这个吗？」这类意见。
22. Phase 1 Invoke：用 `lean-startup` skill，输入想法；若 CUSTOMER.md 存在，输入 job statement；要求输出按风险排序的 leap-of-faith 假设、能证伪最风险假设的最小实验、预先承诺的行为成功阈值。
23. Phase 1 Decide with user：哪个假设若为假是致命的？实验类型选 smoke test（需求）、concierge（价值）还是 Wizard of Oz（自动化）？在运行前固定什么 go/pivot 阈值？只有用户能对真人运行它；然后暂停为 awaiting-evidence。
24. Phase 1 Artifact：创建 docs/PRODUCT.md 含 `## Vision` 和 `## MVP Definition`；创建 docs/EXPERIMENTS.md 含 `## Experiment Cards`（EXP-001 带 hypothesis、metric、decision rule）和 `## Experiment Backlog`；更新 tracker。
25. Phase 1 Done when：致命假设已命名，EXP-001 有预先承诺阈值，PRODUCT.md 写明 MVP 范围，且用户拿到要运行的实验。
26. Phase 2 目标：在投入工程时间前，用可测试 facade 确定核心流程应该是什么。
27. Phase 2 Brief（回退）：五天：周一 Map 问题、周二 Sketch、周三 Decide、周四 Prototype、周五 Test with five real users；输出是高保真 facade 加证据，不是代码；最风险时刻是陌生人最初十分钟——测试他们在无解释下是否理解并完成核心任务；5 个用户能暴露模式；需要的是模式而非显著性；绝不解释原型；观察他们卡在哪里。
28. Phase 2 Invoke：用 `design-sprint` skill，输入 PRODUCT.md 的 MVP scope；要求周一地图和 How Might We 重构、获胜概念 storyboard、五幕访谈脚本和记录网格（每位参与者 checkmark / cross / tilde）；暂停时把批准的脚本记录到 docs/EXPERIMENTS.md 的 sprint card 下，以便跨 session 保留。
29. Phase 2 Decide with user（返回时）：测试后的流程是原样可用、需要重塑，还是暴露需求问题并回到 Phase 1？哪些困惑变成修复项？
30. Phase 2 Artifact：创建 docs/DESIGN.md 含 `## Design Direction`；用 sprint test 及其 verdict 扩展 docs/EXPERIMENTS.md 的 `## Experiment Cards`；更新 tracker。
31. Phase 2 Done when：DESIGN.md 记录方向，sprint result 和 verdict 进入 EXPERIMENTS.md，且用户选择 proceed / reshape / loop。
32. Phase 3 目标：隔离业务规则，使数据库、框架和供应商保持为可替换细节。
33. Phase 3 Brief（回退）：源代码依赖朝内——框架指向 use cases 指向 entities；业务规则不得 import 框架或 ORM；use cases 定义接口（如 InvoiceRepository）；infrastructure 实现它们；controllers 把 HTTP request 翻译成普通 request object 并接收普通 response——没有框架类型跨边界；诊断：能否在无数据库、web server 或框架运行时测试业务规则？四个圆圈是典型而非神圣——只在波动点画边界。
34. Phase 3 Invoke：用 `clean-architecture` skill，输入 PRODUCT.md 中已验证的 MVP scope；要求 layer map、核心 use case 及其 request/response models、它依赖的 repository interfaces。
35. Phase 3 Decide with user：真实波动边界在哪里（数据库、第三方 API、交付机制）？小 app 用完整四层，还是合并 adapters 和 frameworks？
36. Phase 3 Artifact：创建 docs/ARCHITECTURE.md 含 `## System Context` 和 `## Layer Map & Dependency Rule`（layers、谁依赖谁、violations table）；更新 tracker。
37. Phase 3 Done when：ARCHITECTURE.md 命名 layers，Dependency Rule 方向明确，核心业务规则可在无 infrastructure 下测试。
38. Phase 4 目标：让代码说业务语言，使领域专家能读懂并指出错误。
39. Phase 4 Brief（回退）：模型即代码；构建 Ubiquitous Language——按领域概念而非技术角色命名（`InvoiceDraft.finalize()` 优于 `DataProcessor.process()`）；难以命名是设计信号；Bounded contexts：一个词在边界内只表示一个意思（billing 中的 `Customer` 不必等于 support 中的 `Customer`）；Aggregates：一个集群有一个 root 强制 invariants——保持小，其他 aggregate 用 ID 引用；避免贫血模型；把行为推入 entities 和 value objects。
40. Phase 4 Invoke：用 `domain-driven-design` skill，输入 ARCHITECTURE.md 的 layer map；要求 ubiquitous language、bounded contexts 和 context map、核心 aggregate 及其 root 强制的不变量。
41. Phase 4 Decide with user：核心 domain（竞争优势）是什么，哪些是 generic subdomains（auth、email、payments）应购买或使用开源？同一个词在哪些 contexts 中合法地表示不同意思？
42. Phase 4 Artifact：扩展 docs/ARCHITECTURE.md：增加 `## Bounded Contexts & Context Map` 和 `## Domain Glossary (Ubiquitous Language)`（term | meaning | code name）；更新 tracker。
43. Phase 4 Done when：glossary 命名核心概念，contexts 和 relationships 已映射，且 repository interface 按 Phase 3 位于 domain layer。
44. Phase 5 目标：随代码库增长，保持每个函数可读且被测试。
45. Phase 5 Brief（回退）：代码被读远多于被写；函数要小、只做一件事、位于单一抽象层级；命名揭示意图；不要 flag arguments（坏味道——函数做了两件事）；命令与查询分离；命名良好的提取函数胜过注释；测试是一等公民——脏测试比没有测试更糟；按 F.I.R.S.T.（Fast、Independent、Repeatable、Self-validating、Timely）编写，行为式命名如 shouldRejectNegativeTotal。
46. Phase 5 Invoke：用 `clean-code` skill，输入 Phases 3-4 的核心模块；要求按规则做 score-and-fix review，并为核心 use case 写干净单元测试（arrange-act-assert、描述性名称、builder helper）。
47. Phase 5 Decide with user：什么质量门槛挡住 commit——函数大小、命名清晰度、不吞异常？首批测试必须覆盖哪些 happy-path 和 failure cases？
48. Phase 5 Artifact：创建 docs/TESTING.md 含 `## Test Strategy`（pyramid、tooling、什么 green gates）和 `## Safety Net Map`（module | pinned behaviors | test files | gaps）；更新 tracker。
49. Phase 5 Done when：TESTING.md 写明策略，核心 use case 有通过的行为命名测试且不需要数据库，commit 质量门槛已记录。
50. Phase 6 目标：采用能让代码库多年易于修改的习惯。
51. Phase 6 Brief（回退）：发射 tracer bullet——一条穿过每层的薄真实切片（UI 到 use case 到数据库再返回），保留它，以在第二天暴露集成 bug；DRY 只适用于知识，不适用于偶然相似；正交性：改数据库不得触碰 UI；可逆性：把第三方 SDK 包在你自己的接口后面，使 Stripe 或模型供应商可替换而不碰业务逻辑；破窗：修复第一个 hack 或用 tracked ticket 把它封住——绝不留静默腐烂。
52. Phase 6 Invoke：用 `pragmatic-programmer` skill，输入 ARCHITECTURE.md 和核心 use case；要求最薄的端到端 tracer-bullet 设计，以及每个第三方依赖的 adapter interface。
53. Phase 6 Decide with user：tracer-bullet slice 是什么？破窗政策是否零容忍并带 tracked tickets？哪些依赖现在获得 adapter interfaces，哪些以后？
54. Phase 6 Artifact：扩展 docs/TESTING.md（`## CI Gates`）和 docs/TECH-DEBT.md（`## Debt Budget & Broken-Windows Policy` 和 `## Adopted Conventions`）；更新 tracker。
55. Phase 6 Done when：tracer bullet 端到端已指定，每个 provider 的 adapter interfaces 已命名，破窗政策已写下。
56. Phase 7 目标：诚实估算真实负载，并证明哪些东西你还不需要构建。
57. Phase 7 Brief（回退）：从需求开始，不从方案开始；QPS = daily active users x actions/day / 86,400，peak 为 average 的 2-5x；storage = records/day x record size x retention；几百用户时数学几乎总是说一个索引良好的数据库加一个 cache；按顺序扩展：先 vertical，再 read replicas，再 cache aside，最后 shard；只有估算或真实瓶颈证明合理时，才用 queue 吸收尖峰并把慢工作（如 photo OCR）从请求路径解耦。
58. Phase 7 Invoke：用 `system-design` skill，输入 intake 的负载数字；要求 back-of-the-envelope QPS 和 storage 估算，以及明确列出你还不需要的技术。
59. Phase 7 Decide with user：根据估算，你故意推迟哪些 scaling？哪个真实瓶颈（如果有）现在 justifies cache 或 queue？
60. Phase 7 Artifact：扩展 docs/ARCHITECTURE.md：增加 `## Data & Storage Decisions` 和 `## Decision Log`（date | decision | why | alternatives rejected），把每个「not yet」记录为 decision；更新 tracker。
61. Phase 7 Done when：容量估算已记录，推迟的 scaling 技术已明确列出，任何 cache 或 queue 都由数字证明合理。
62. Phase 8 目标（仅 iOS）：让 iPhone 客户端感觉原生——这是 iOS 用户信任的基础；仅在发布原生 iOS 客户端时运行（intake 决定），否则跳过。
63. Phase 8 Brief（回退）：三支柱——clarity、deference、depth；尊重 safe areas（Dynamic Island、home indicator）；每个 touch target 至少 44x44 pt；使用语义颜色（Color(.label)、Color(.systemBackground)）使 Dark Mode 自动生效；使用语义文本样式支持 Dynamic Type；原生导航——tab bars 用于主要目的地，NavigationStack 用于 drill-down，sheets 用于聚焦任务，绝不用 hamburger menu；accessibility 是一等公民：每个控件有 label，VoiceOver 能完成每个任务。
64. Phase 8 Invoke：用 `ios-hig-design` skill，输入 app 的关键 screens；要求对 safe areas、44pt targets、语义颜色和字体、原生导航、accessibility labels 做 HIG review。
65. Phase 8 Decide with user：首轮 review 覆盖哪些 screens？是否有故意的 platform deviations，是否有理由？
66. Phase 8 Artifact：扩展 docs/DESIGN.md：增加 `## Components`（component | decision | status）和 `## UX Audit Findings`（issue | heuristic | severity 0-4 | fix | status）；更新 tracker。
67. Phase 8 Done when：每个 in-scope screen 已 review，findings 带 severity 记录，accessibility gaps 已作为 fixes 捕获。
68. Phase 9 目标：在固定时间内发布聚焦的 v1，并抵抗 feature creep。
69. Phase 9 Brief（回退）：构建半个产品，而不是半吊子产品；在押注前 shape work：粗到保留设计自由，解决到移除大未知，用 appetite 限制（「这值两周」）而非估算；固定时间并砍 scope 来适应，绝不反过来；把 shaped pitches 押注到固定 cycles；circuit breaker 在 deadline 杀死任何未完成项；有主见的软件：每个提供的偏好都是拒绝的决策——选择合理默认值；对功能的默认回答是尊重地说「not now」。
70. Phase 9 Invoke：用 `37signals-way` skill，输入 PRODUCT.md 的 MVP scope；要求把下一个功能 shape 成 pitch（problem、appetite、breadboard、rabbit holes、no-gos）和 v1 cut list。
71. Phase 9 Decide with user：下一个功能的 appetite 是什么？哪些 v1 功能被砍，哪些用户可见偏好变成有主见的默认值？
72. Phase 9 Artifact：扩展 docs/PRODUCT.md（`## Outcome Roadmap`）和 docs/STRATEGY.md（`## No-List` — 我们明确不会做什么）；更新 tracker。
73. Phase 9 Done when：下一个功能有带 appetite 的 shaped pitch，v1 cut list 进入 STRATEGY.md 的 No-List，roadmap 反映 fixed-time / flexible-scope。
74. Phase 10 目标：在每个模块中压低复杂度——这是覆盖其他所有 phase 的镜头。
75. Phase 10 Brief（回退）：复杂度是结构中使系统难以理解和修改的任何东西；偏好 deep modules——简单接口背后有强大功能——而非 shallow modules；用 functionality 除以 interface complexity 评判模块，而非行数；这纠正 Clean Code 的「小」和 DDD 的许多概念滑向 classitis（成群的一方法 shallow classes）；战略高于战术：稳定投入 10-20% 额外设计，因为早期捷径会随着团队和代码库增长而精确复利。
76. Phase 10 Invoke：用 `software-design-philosophy` skill，输入 Phases 3-6 的模块；要求 deep-vs-shallow 评估，标出 shallow classes、pass-through methods、跨边界信息泄漏，以及哪些地方应合并。
77. Phase 10 Decide with user：哪些 shallow modules 应合并成 deeper ones？哪里 tactical shortcutting 正在积累债务，值得现在投入 strategic 10-20%？
78. Phase 10 Artifact：扩展 docs/TECH-DEBT.md（`## Smell Inventory`：smell | location | refactoring | status）和 docs/ARCHITECTURE.md（`## Decision Log`）；更新 tracker。
79. Phase 10 Done when：shallow modules 和 leaks 记录在 Smell Inventory，合并决策已记录，strategic-vs-tactical 立场已同意。
80. 可选 phases：jobs-to-be-done 在 app 被雇佣完成的任务模糊或有争议时加入，创建 docs/CUSTOMER.md。
81. 可选 phases：mom-test 在假设需要客户对话而非意见时加入，扩展 docs/CUSTOMER.md。
82. 可选 phases：lean-ux 在团队想要假设驱动 UX 而非重型规格时加入，扩展 docs/EXPERIMENTS.md。
83. 可选 phases：ux-heuristics 在第一个可用 build 需要可用性 pass 时加入，扩展 docs/DESIGN.md。
84. 可选 phases：hooked-ux 在产品依赖习惯性重复使用时加入，扩展 docs/PRODUCT.md。
85. 可选 phases：design-everyday-things 在核心流程让测试用户困惑时加入，扩展 docs/DESIGN.md。
86. 可选 phases：continuous-discovery 在发布后保持每周客户接触时加入，扩展 docs/CUSTOMER.md。
87. 可选 phases：inspired-product 在团队围绕产品形成并需要愿景和 outcome roadmaps 时加入，扩展 docs/PRODUCT.md。
88. 可选 phases 遵循相同 operating rules——像核心 phase 一样加载和使用每个列出的 skill；在 Add-when 条件首次成立处插入。
89. 常见错误：在验证想法前构建架构；修复：先跑 Phase 1——验证便宜，重写不便宜（`lean-startup`）。
90. 常见错误：把「MVP」当作写垃圾的许可证；修复：发布最小可学习物，greenlit 后再把真东西做好；最低不等于低质量（`lean-startup`）。
91. 常见错误：让框架支配架构；修复：把框架留在外环作为 plugins；没有 ORM 类型跨 use-case 边界（`clean-architecture`）。
92. 常见错误：贫血领域模型；修复：把行为推入 entities 和 value objects，而不是胖 service classes（`domain-driven-design`）。
93. 常见错误：Classitis——过度应用「小」；修复：用 depth（每单位接口的功能量）评判模块，而非行数（`software-design-philosophy`）。
94. 常见错误：过早扩展；修复：先估算；一个数据库加一个 cache 能带大多数 app 走很远——最后才 shard（`system-design`）。
95. 完成旅程 exit checklist：PRODUCT.md 陈述已验证的 MVP 和 vision；EXPERIMENTS.md 含一个已运行实验及记录 verdict。
96. 完成旅程 exit checklist：ARCHITECTURE.md 通过 Dependency Rule 测试，并命名 core domain、contexts 和 capacity estimate。
97. 完成旅程 exit checklist：TESTING.md 显示核心 use case 在无 infrastructure 下被测试，且 tracer bullet 端到端运行。
98. 完成旅程 exit checklist：如果继续发布，STRATEGY.md 的 No-List 和一个 shaped next feature 存在。
99. 关闭 tracker：每个 phase 为 done 或 skipped: reason，Key Decisions 已捕获，Next Actions 进入 artifacts（不留在 tracker）。
100. 前向路由：当 app 底下的想法被证明未验证，或实际是商业模型问题，继续用 `create-business` skill。
101. 前向路由：当 app 超出首个架构且结构本身成为难题，继续用 `design-code-architecture` skill。

适用边界 · 注意事项

• App 已存在：用 improve-app 或 grow-app，不要用 create-app。
• 商业想法尚未验证：先跑 create-business；仅营销站点用 create-website；只问架构用 design-code-architecture。
• 只想单独使用某个框架或技能：直接调用该技能，不要走完整 create-app 旅程。