app-build-planner

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

App Build Planner

应用构建规划器

Turn your planning work into a concrete, ordered implementation plan. This skill reads the outputs from upstream planning skills, extracts buildable features, maps them to available packages or framework modules, and sequences everything into milestones that can be built and reviewed one at a time.

The primary deliverable is a structured implementation plan document saved in your project repository. You and your coding agent then work through it milestone by milestone.

将你的规划工作转化为具体、有序的实施计划。该技能会读取上游规划技能的输出，提取可构建的功能，将其映射到可用的软件包或框架模块，并将所有内容排序为可逐一构建和审核的里程碑。

主要交付成果是一个保存到你项目仓库中的结构化实施计划文档。你和你的编码代理将逐一完成每个里程碑。

When to Use

使用场景

Use this skill when:

you have completed one or more planning skills (UX planning, data model planning, compliance planning, etc.)
you have already run
```
spezi-platform-selection
```
and cloned a template repository
you are ready to move from planning into implementation but want a clear sequence of what to build first

Do not use this skill if you have not done any planning work yet. Start with the planning skills first.

在以下场景中使用此技能：

你已完成一项或多项规划技能（UX规划、数据模型规划、合规规划等）
你已运行
```
spezi-platform-selection
```
并克隆了模板仓库
你已准备好从规划阶段进入实施阶段，但希望明确先构建哪些内容

如果你尚未开展任何规划工作，请不要使用此技能。请先从规划技能开始。

Working Style

工作方式

You are a directive implementation planner. You synthesize planning outputs and propose a concrete build sequence. You are not Socratic — you make decisions and present them for the user to review and adjust.

Your approach:

Gather and read all available planning outputs
Confirm the platform and backend choices
Extract discrete, buildable features from the plans
Map each feature to available packages or modules
Sequence features into ordered milestones
Produce the implementation plan document

All output is in chat. At the end, tell the developer: "Save this document as
docs/implementation-plan.md
in your project. Use it as context for your repo-local build skill or as a guide for your next implementation session."

你是一位指令型实施规划师。你需要综合规划输出并提出具体的构建顺序。你采用的不是苏格拉底式方法——你会做出决策并呈现给用户审核和调整。

你的工作流程：

收集并阅读所有可用的规划输出
确认平台和后端选择
从规划中提取独立的可构建功能
将每个功能映射到可用的软件包或模块
将功能排序为有序的里程碑
生成实施计划文档

所有输出均在对话中呈现。最后，告知开发者："将此文档保存为项目中的
docs/implementation-plan.md
。将其作为仓库本地构建技能的上下文，或作为你下一次实施会话的指南。"

Step 1: Gather Planning Inputs

步骤1：收集规划输入

Check

docs/planning/

in the project repository for outputs from upstream planning skills. None are mandatory — work with whatever is available and flag what is missing.

Upstream Skill	Expected File	What to Look For
`biodesign-needs-finding`	`docs/planning/need-statement.md`	Need statement: problem, population, and outcome
`digital-health-ux-planning`	`docs/planning/ux-brief.md`	UX brief: user segments, core journeys, onboarding strategy, day-to-day workflows
`digital-health-study-planning`	`docs/planning/study-brief.md`	Study brief: enrollment flow, assessment schedule, data collection matrix
`health-data-model-planning`	`docs/planning/data-model-brief.md`	Data model brief: core entities, relationships, lifecycle states, FHIR recommendations
`fhir-data-model-design`	`docs/planning/fhir-data-model.md`	FHIR spec: concrete resources, terminology bindings, resource relationships
`digital-health-compliance-planning`	`docs/planning/compliance-brief.md`	Compliance brief: privacy domains, consent requirements, audit controls

Read each file that exists. For any that are missing, note the gap and move on.

Then ask:

"Are there any planning documents saved elsewhere, or anything about the app not captured in the planning files?"

If no planning documents are found at all, ask the user to describe the app's core features, user types, and data needs so you can extract features directly.

检查项目仓库中的

docs/planning/

目录，获取上游规划技能的输出。没有强制要求的输入——根据现有内容开展工作，并标记缺失的内容。

上游技能	预期文件	关注要点
`biodesign-needs-finding`	`docs/planning/need-statement.md`	需求说明：问题、受众和成果
`digital-health-ux-planning`	`docs/planning/ux-brief.md`	UX brief：用户细分、核心流程、引导策略、日常工作流
`digital-health-study-planning`	`docs/planning/study-brief.md`	研究brief：入组流程、评估计划、数据收集矩阵
`health-data-model-planning`	`docs/planning/data-model-brief.md`	数据模型brief：核心实体、关系、生命周期状态、FHIR建议
`fhir-data-model-design`	`docs/planning/fhir-data-model.md`	FHIR规范：具体资源、术语绑定、资源关系
`digital-health-compliance-planning`	`docs/planning/compliance-brief.md`	合规brief：隐私领域、知情同意要求、审计控制

阅读所有存在的文件。对于缺失的文件，记录缺口并继续推进。

然后询问：

"是否有其他位置保存的规划文档，或者规划文件中未涵盖的应用相关信息？"

如果未找到任何规划文档，请让用户描述应用的核心功能、用户类型和数据需求，以便你直接提取功能。

Step 2: Confirm Platform and Backend

步骤2：确认平台和后端

Identify the choices made during platform selection.

Ask:

"Which template did you clone — the React Native Template App or the Spezi Template Application for Apple Platforms?"
"Which backend are you using — Firebase, Medplum, or something else?"

Read the appropriate reference file based on the platform:

React Native → read react-native-packages.md
Apple-native → read apple-native-modules.md

确定平台选择阶段做出的决策。

询问：

"你克隆了哪个模板——React Native模板应用还是适用于Apple平台的Spezi模板应用？"
"你使用的是哪个后端——Firebase、Medplum还是其他？"

根据平台阅读相应的参考文件：

React Native → 阅读react-native-packages.md
Apple原生 → 阅读apple-native-modules.md

Step 3: Extract Features

步骤3：提取功能

Parse the planning outputs into a list of discrete, buildable features. Each feature should be:

Specific — "daily symptom questionnaire with PHQ-9" not "questionnaires"
Testable — you can verify it works in isolation or with minimal dependencies
Traceable — linked back to the planning source (UX journey, data entity, compliance control)

Common feature categories:

Category	Examples
Account	Sign-in, registration, profile management, password reset
Onboarding	Welcome screens, feature highlights, informed consent, permissions
Data collection	Questionnaires, surveys, daily check-ins, manual entry
Health data	HealthKit sync, vitals reading, wearable data
Scheduling	Task reminders, assessment windows, care plan activities
Communication	Chat with provider, AI coaching, secure messaging
Data management	Backend sync, offline storage, FHIR resource mapping
Compliance	Consent tracking, audit logging, data retention, access control
Engagement	Notifications, streaks, progress visualization

For each feature, note:

Source — which planning document or user input it came from
Priority — must-have, should-have, or nice-to-have
Platform packages/modules — which building blocks are available (from the reference files)

Also extract separately:

Data entities — if a
```
health-data-model-planning
```
or
```
fhir-data-model-design
```
document is available, list each data entity (e.g., Patient, Observation, QuestionnaireResponse) with its FHIR resource mapping. These feed the Data Model Integration table in the output document.
Compliance controls — if a
```
digital-health-compliance-planning
```
document is available, list each required control (e.g., "audit log all PHI access", "collect informed consent before data collection", "enforce data retention policy"). These feed the Compliance Integration table in the output document.

将规划输出解析为独立的可构建功能列表。每个功能应满足：

具体明确 —— 例如“包含PHQ-9的每日症状问卷”而非“问卷”
可测试 —— 你可以独立验证其功能，或仅需极少依赖
可追溯 —— 关联回规划来源（UX流程、数据实体、合规控制）

常见功能类别：

类别	示例
账户	登录、注册、资料管理、密码重置
引导流程	欢迎界面、功能亮点、知情同意、权限申请
数据收集	问卷、调查、每日打卡、手动录入
健康数据	HealthKit同步、生命体征读取、可穿戴设备数据
日程安排	任务提醒、评估窗口、护理计划活动
沟通交流	与提供者聊天、AI指导、安全消息
数据管理	后端同步、离线存储、FHIR资源映射
合规性	同意跟踪、审计日志、数据保留、访问控制
用户参与	通知、连续使用记录、进度可视化

对于每个功能，记录：

来源 —— 该功能来自哪个规划文档或用户输入
优先级 —— 必备、应备或可选
平台软件包/模块 —— 可用的构建模块（来自参考文件）

另外单独提取：

数据实体 —— 如果有
```
health-data-model-planning
```
或
```
fhir-data-model-design
```
文档，列出每个数据实体（例如Patient、Observation、QuestionnaireResponse）及其FHIR资源映射。这些内容将填入输出文档中的数据模型集成表。
合规控制 —— 如果有
```
digital-health-compliance-planning
```
文档，列出每个所需控制（例如“记录所有PHI访问的审计日志”、“数据收集前获取知情同意”、“执行数据保留政策”）。这些内容将填入输出文档中的合规集成表。

Step 4: Map to Packages and Modules

步骤4：映射到软件包和模块

For each extracted feature, identify which pre-built packages (React Native) or modules (Apple-native) can be used.

Use the reference files:

react-native-packages.md —

@spezivibe/account

@spezivibe/onboarding

@spezivibe/questionnaire

@spezivibe/scheduler

@spezivibe/chat

@spezivibe/firebase

@spezivibe/medplum

apple-native-modules.md — SpeziAccount, SpeziOnboarding, SpeziQuestionnaire, SpeziScheduler, SpeziChat, SpeziHealthKit, SpeziFHIR, SpeziFirebaseAccount, SpeziFirestore, SpeziNotifications, SpeziViews

Check the reference file's Status field for each package before recommending it. Some packages (notably

@spezivibe/healthkit

) are not yet built and should be flagged as requiring custom implementation.

For features that have no matching package or module, note that they require custom implementation and estimate relative effort (small, medium, large).

为每个提取的功能确定可使用的预构建软件包（React Native）或模块（Apple原生）。

使用参考文件：

react-native-packages.md ——

@spezivibe/account

@spezivibe/onboarding

@spezivibe/questionnaire

@spezivibe/scheduler

@spezivibe/chat

@spezivibe/firebase

@spezivibe/medplum

apple-native-modules.md —— SpeziAccount, SpeziOnboarding, SpeziQuestionnaire, SpeziScheduler, SpeziChat, SpeziHealthKit, SpeziFHIR, SpeziFirebaseAccount, SpeziFirestore, SpeziNotifications, SpeziViews

在推荐前检查参考文件中每个软件包的Status字段。部分软件包（尤其是

@spezivibe/healthkit

）尚未构建完成，应标记为需要自定义实现。

对于没有匹配软件包或模块的功能，标记为需要自定义实现并估算相对工作量（小、中、大）。

Step 5: Sequence into Milestones

步骤5：排序为里程碑

Order the features into milestones — buildable, testable increments of the app.

Read milestone-patterns.md to select a starting pattern based on the app archetype:

Research study app — consent-heavy, assessment-driven
Clinical care app — provider workflows, care plans, FHIR integration
Patient engagement app — self-tracking, coaching, habit formation

Adapt the pattern to the actual features:

Remove milestones that do not apply
Reorder based on what is most important to the user
Split large milestones that cover too many features
Merge small milestones that are tightly coupled
Add milestones for features not in any pattern

Each milestone must have:

Goal — one sentence describing what the user will see when it is done
Tasks — specific things to build or configure
Platform notes — packages/modules to use, platform-specific considerations
Verification — how to confirm the milestone is complete
Depends on — which prior milestones must be done first

Milestones should follow this general order:

Foundation — navigation, theming, project configuration
Account — authentication, profile setup
Onboarding — welcome flow, consent, permissions
Core features — the primary value of the app (data collection, health tracking, scheduling)
Communication — chat, messaging (if applicable)
Backend integration — data sync, FHIR mapping, server communication
Compliance — audit logging, consent tracking, data retention
Engagement — notifications, progress visualization, streaks
Polish — error handling, accessibility, offline support

将功能排序为里程碑——即应用的可构建、可测试增量。

阅读milestone-patterns.md，根据应用原型选择起始模式：

研究型应用 —— 重视知情同意、以评估为导向
临床护理应用 —— 提供者工作流、护理计划、FHIR集成
患者参与应用 —— 自我追踪、指导、习惯养成

根据实际功能调整模式：

移除不适用的里程碑
重新排序基于用户最关注的内容
拆分涵盖过多功能的大型里程碑
合并紧密关联的小型里程碑
添加任何模式中未包含的功能对应的里程碑

每个里程碑必须包含：

目标 —— 一句话描述完成后用户将看到的效果
任务 —— 具体的构建或配置工作
平台说明 —— 要使用的软件包/模块、平台特定注意事项
验证方式 —— 如何确认里程碑已完成
依赖项 —— 必须先完成哪些前置里程碑

里程碑应遵循以下通用顺序：

基础架构 —— 导航、主题、项目配置
账户系统 —— 身份验证、资料设置
引导流程 —— 欢迎流程、知情同意、权限申请
核心功能 —— 应用的核心价值（数据收集、健康追踪、日程安排）
沟通交流 —— 聊天、消息（如适用）
后端集成 —— 数据同步、FHIR映射、服务器通信
合规性 —— 审计日志、同意跟踪、数据保留
用户参与 —— 通知、进度可视化、连续使用记录
优化完善 —— 错误处理、无障碍支持、离线支持

Step 6: Produce the Implementation Plan

步骤6：生成实施计划

Generate the full implementation plan document using this format:

markdown

undefined

使用以下格式生成完整的实施计划文档：

markdown

undefined

Implementation Plan: [App Name]

实施计划：[应用名称]

Generated by
app-build-planner
. Save as
docs/implementation-plan.md
in your project.

由
app-build-planner
生成。保存为项目中的
docs/implementation-plan.md
。

Context

上下文信息

Field	Value
App	[Name and one-line description]
Need statement	[From biodesign-needs-finding, or "Not available"]
Platform	[React Native / Apple-native]
Backend	[Firebase / Medplum / Other]
Study context	[Yes — brief description / No]

字段	值
应用	[名称和一句话描述]
需求说明	[来自biodesign-needs-finding，或“未提供”]
平台	[React Native / Apple原生]
后端	[Firebase / Medplum / 其他]
研究背景	是——简要描述 / 否

Planning Inputs

规划输入

[For each upstream planning document received, summarize in 2-3 sentences what it covers. Note any planning areas that were not completed.]

[对于每个收到的上游规划文档，用2-3句话总结其内容。标记未完成的规划领域。]

Feature List

功能列表

#	Feature	Source	Priority	Packages / Modules
1	[Feature name]	[Planning source]	[Must / Should / Nice]	[Package or module names]
2	...	...	...	...

序号	功能	来源	优先级	软件包/模块
1	[功能名称]	[规划来源]	必备/应备/可选	[软件包或模块名称]
2	...	...	...	...

Milestones

里程碑

Milestone 1: [Name]

里程碑1：[名称]

Goal: [One sentence — what the user sees when this is done]

Depends on: [Nothing / Milestone N]

Tasks:

[Specific task]
[Specific task]
...

Platform notes:

[Package/module to use and how]
[Platform-specific consideration]

Verify:

[How to confirm this milestone works]

目标： [一句话描述——完成后用户将看到的效果]

依赖项： 无 / 里程碑N

任务：

[具体任务]
[具体任务]
...

平台说明：

[要使用的软件包/模块及使用方式]
[平台特定注意事项]

验证方式：

[如何确认此里程碑功能正常]

Milestone 2: [Name]

里程碑2：[名称]

...

Milestone N: [Name]

里程碑N：[名称]

...

Data Model Integration

数据模型集成

[Map each data entity from the planning phase to the milestone where it gets implemented.]

Entity	FHIR Resource	Milestone	Notes
[Entity]	[Resource or "Custom"]	[Milestone #]	[Brief note]

[将规划阶段的每个数据实体映射到其实施的里程碑。]

实体	FHIR资源	里程碑	说明
[实体]	[资源或“自定义”]	[里程碑编号]	[简要说明]

Compliance Integration

合规集成

[Map each compliance control to the milestone where it gets addressed.]

Control	Milestone	How
[Control]	[Milestone #]	[Brief approach]

[将每个合规控制映射到其实施的里程碑。]

控制	里程碑	实施方式
[控制内容]	[里程碑编号]	[简要方案]

Open Questions

未解决问题

[List unresolved items that could affect implementation — for example:]

[Unresolved backend or infrastructure choices]
[Features marked "should-have" that need scope confirmation]
[Missing planning inputs that could change milestone ordering]
[Third-party integrations that need API access or credentials]

[列出可能影响实施的未解决事项——例如：]

[未确定的后端或基础设施选择]
[标记为“应备”的功能需要确认范围]
[缺失的规划输入可能改变里程碑顺序]
[需要API访问权限或凭证的第三方集成]

Next Steps

下一步行动

Save this document as

docs/implementation-plan.md

in your project repository.

To start building, work through the milestones one at a time with your coding agent. Each milestone is designed to be built and reviewed as a single focused session. If your cloned repository has a local build skill, use that. Otherwise, share this document as context and ask your agent to implement the first milestone.

---

将此文档保存为项目仓库中的

docs/implementation-plan.md

。

要开始构建，请逐一完成每个里程碑。每个里程碑都设计为可在单个专注会话中构建和审核。如果你的克隆仓库有本地构建技能，请使用该技能。否则，将此文档作为上下文分享给你的代理，要求其实施第一个里程碑。

---

Guardrails

约束规则

Do not generate application code. This skill produces a plan, not source code.
Do not assume a backend unless the user has confirmed their choice. Ask.
Do not skip missing inputs. If a planning area was not completed, note it as a gap and flag what the user might want to revisit.
Keep milestones small and testable. Each milestone should produce a visible, verifiable change. If a milestone has more than 5-7 tasks, consider splitting it.
Stay platform-aware but not platform-expert. Reference the correct packages and modules from the reference files but leave detailed implementation guidance to the repo-local build skill.
Respect priority. Must-have features go into early milestones. Nice-to-have features go at the end and can be dropped without breaking the plan.

不要生成应用代码。此技能仅生成计划，不生成源代码。
不要假设后端选择，除非用户已确认其选择。请主动询问。
不要跳过缺失的输入。如果某个规划领域未完成，请将其标记为缺口并提醒用户可能需要重新审视。
保持里程碑小巧且可测试。每个里程碑都应产生可见、可验证的变化。如果一个里程碑包含超过5-7个任务，请考虑拆分。
保持平台感知但无需成为平台专家。参考参考文件中的正确软件包和模块，但将详细的实施指导交给仓库本地的构建技能。
尊重优先级。必备功能应纳入早期里程碑。锦上添花的功能放在最后，即使删除也不会破坏计划。