app-planner

App Planner

你将产出一份设计计划——一份采用与 exec-plans 相同格式的动态文档，按照 Apple Design DNA 模式，将应用领域映射到各个功能组。每个功能组都对应一个里程碑，可在一次 ios-taste 会话中完成构建。

输出为 Markdown 文件，保存到 docs/design-plans/（或项目存放计划文档的位置）。它将指导跨多个会话的整个构建流程。

你将产出什么

一份包含以下部分的设计计划文档：

1. 目的 / 总体愿景（重新设计要实现什么）
2. 用户与使用时刻（用户画像 + 按频率排序的交互）
3. 进度（动态复选框，每次会话后更新）
4. 设计里程碑（每个屏幕对应一个，并映射到模式）
5. 刻意排除的内容（不在范围内的内容）
6. 决策日志（执行过程中更新）
7. 意外情况与发现（执行过程中更新）

你不会产出什么

• SwiftUI 代码或数据模型
• 布局、线框图或模型图
• 颜色、字体或间距选择
• 导航架构图
• 一次性构建整个应用

构建将在之后进行。每次只处理一个里程碑。使用 ios-taste。

模式优先的方法

阅读 ios-taste 技能目录中的 references/apple-design-dna.md （~/.claude/skills/ios-taste/references/apple-design-dna.md）。其中包含从 6 个 Apple 应用中提取的 22 种模式。这些就是你的构建模块。

模式	来源	最适合
时间网格	Calendar	日程安排、预约、日计划
海报详情	Contacts	人物 / 实体档案、身份视图
渐变上的玻璃效果	Contacts	高级详情视图、记录展示
仪表盘卡片	Fitness	一目了然的指标、每日摘要
模块化卡片网格	Weather	多指标展示、状态仪表盘
层级缩放	Calendar	按时间尺度或详情层级浏览
触感状态转换	Calendar	模式切换、拖动交互、吸附点
指标详情模板	Health	带图表和说明的数据下钻
语义化领域颜色	Health	需要视觉编码的多类别系统
密集网格	Photos	图像 / 缩略图集合
标注层	Photos Markup	在图像上绘图 / 标记 / 注释
签名采集	Photos Markup	同意、签字确认、手写输入
卡片与行布局规则	Fitness/Contacts	仪表盘（卡片）与详情（行）
行内数据增强	Contacts/Fitness	嵌入行中的预览
空状态骨架	Fitness	在数据出现前展示结构

输出格式

将设计计划保存为 Markdown 文件。严格按照以下结构编写：

# [App Name] Design Plan — [Focus]

This DesignPlan is a living document. Progress, Decision Log, and
Surprises & Discoveries must stay up to date as work proceeds.

## Purpose / Big Picture

[1-3 sentences: what the user can do AFTER this plan is executed.
Outcome-focused, not feature-list.]

## User & Moments

- **[Persona 1]**: [who, when, device context]
- **[Persona 2]**: [who, when, device context]

| Frequency | Moment | What they do |
|-----------|--------|-------------|
| 50x/day | [moment name] | [one line] |
| 10x/day | [moment name] | [one line] |
| 5x/day | [moment name] | [one line] |
| 1x/day | [moment name] | [one line] |
| 1x/week | [moment name] | [one line] |

## Progress

- [ ] Milestone 1: [screen name]
- [ ] Milestone 2: [screen name]
- [ ] Milestone 3: [screen name]
...

## Design Milestones

### Milestone 1: [Screen Name]

**User goal**: "[What the user is trying to do — in their words]"
**Pattern**: [Apple Design DNA pattern name] (from [source app])
**Priority**: Must-have
**Frequency**: [how often this screen is used]
**Existing TCA domain**: [which reducer/feature this touches]

**Features**:
- [Feature] — [why the user needs it]
- [Feature] — [why the user needs it]
- [Feature] — [why the user needs it]

**Acceptance criteria**:
1. [Observable proof — what the screen shows/does]
2. [User test — "show to [persona], they say X"]
3. [Technical — builds, tests pass, no raw design tokens]

**ios-taste prompt** (use this to start the build session):
> "[Exact prompt to give ios-taste to build this screen, including
> user context, emotional intent, and which pattern to reference]"

---

### Milestone 2: [Screen Name]
...

## Deliberate Omissions

- [Feature] — [why it's excluded]
- [Feature] — [why it's excluded]

## Decision Log

_Updated during execution._

## Surprises & Discoveries

_Updated during execution._

规则

1. 按用户目标分组，而不是按技术类别分组。“一眼查看当天安排”，而不是“日历模块”。

2. 每个里程碑 = 一个屏幕 = 一种模式 = 一次 ios-taste 会话。 如果一个里程碑需要两种模式，就将其拆分为两个里程碑。

3. **构建顺序按使用频率排列。**每天使用 50 次的屏幕是里程碑 1。

4. **最多 8 个里程碑。**超过 8 个说明范围过大。请合并或延后。

5. **每项功能都要说明“为什么”。**不要只写“患者搜索”，而要写“患者搜索——因为她正在打电话，需要单手找到来电者的病历”。

6. **包含 ios-taste 提示词。**每个里程碑都要附带一条预先编写的提示词，用于启动构建会话。构建者无需琢磨该问什么，提示词已准备好，可直接粘贴。

7. **引用现有代码。**如果项目已有 reducer、模型或领域模块，请在每个里程碑中指出，让构建者知道要处理哪些内容。

8. **验收标准必须可测试。**不要写“看起来不错”，而要写“接待员能在 2 秒内识别下一位患者”。