app-build-planner

アプリ構築プランナー

計画作業を、具体的で順序立てられた実装計画に変換します。このスキルは、上流の計画スキルからの出力を読み込み、実装可能な機能を抽出して、利用可能なパッケージやフレームワークモジュールに対応付け、順番に構築・レビューできるマイルストーンへと組み立てます。

主な成果物は、プロジェクトリポジトリに保存する、構造化された実装計画ドキュメントです。その後、コーディングエージェントとともに、マイルストーンごとに進めていきます。

使用するタイミング

次の場合にこのスキルを使用します。

• 1つ以上の計画スキル（UX 計画、データモデル計画、コンプライアンス計画など）を完了している
• その計画をマイルストーンベースの構築手順に落とし込む準備ができている

他の計画スキルを実行した後、spezi-platform-selection を実行する前に使用してください。プラットフォームの選択には、計画から明らかになった要件（HealthKit の必要性、クロスプラットフォームの要件など）を考慮できます。

計画の入力があると計画の質が大きく向上しますが、必須ではありません。計画ドキュメントがない場合は、ステップ 1 でユーザーにアプリについて直接説明してもらいます。ユーザーに時間がある場合は、先に計画スキルを実行することをおすすめします。

作業スタイル

指示を出す実装プランナーとして、計画の出力を統合し、具体的な構築手順を提案します。ソクラテス式の質問はせず、判断を下してユーザーに提示し、確認や調整をしてもらいます。

アプローチ：

1. 利用可能な計画の出力をすべて収集して読み込む
2. プラットフォームとバックエンドの選択を確認する
3. 計画から、個別に実装可能な機能を抽出する
4. 各機能を、利用可能なパッケージやモジュールに対応付ける
5. 機能を順序立てられたマイルストーンに組み立てる
6. 実装計画ドキュメントを作成する

成果物をディスクに保存してください。 完成した計画をプロジェクトリポジトリの docs/implementation-plan.md に書き込み、開発者に次のように伝えます。「実装計画は docs/implementation-plan.md に保存されています。コーディングエージェントは、マイルストーンごとに順序立てられた構築計画としてこれを使用します。」 現在の環境でファイルに書き込めない場合（チャットのみのセッションなど）は、ドキュメント全文をチャットに出力し、そのパスに保存するよう開発者に依頼してください。

---

ステップ 1：計画の入力を収集する

プロジェクトリポジトリの docs/planning/ を確認し、上流の計画スキルからの出力を探します。必須のファイルはありません。利用可能な情報を使い、不足しているものを明示してください。

上流スキル	想定されるファイル	確認する内容
biodesign-needs-finding	docs/planning/need-statement.md	ニーズステートメント：課題、対象者、成果
digital-health-ux-planning	docs/planning/ux-brief.md	UX ブリーフ：ユーザーセグメント、主要なユーザージャーニー、オンボーディング戦略、日々のワークフロー
digital-health-study-planning	docs/planning/study-brief.md	研究ブリーフ：登録フロー、評価スケジュール、データ収集マトリックス
health-data-model-planning	docs/planning/data-model-brief.md	データモデルブリーフ：主要エンティティ、関係、ライフサイクル状態、FHIR に関する推奨事項
fhir-data-model-design	docs/planning/fhir-data-model.md	FHIR 仕様：具体的なリソース、用語のバインディング、リソース間の関係
digital-health-compliance-planning	docs/planning/compliance-brief.md	コンプライアンスブリーフ：プライバシードメイン、同意要件、監査制御
fasten-ehr-integration	docs/planning/ehr-connection-brief.md	EHR 接続ブリーフ：Fasten Connect の統合状況、プライバシーおよびアーキテクチャに関する決定

存在するファイルをそれぞれ読み込みます。見つからないファイルについては、その不足を記録して次に進みます。

次に、以下を尋ねます。

1. 「計画ドキュメントがほかの場所に保存されている場合や、計画ファイルに記載されていないアプリについての情報はありますか？」

計画ドキュメントが1つも見つからない場合は、機能を直接抽出できるよう、アプリの主要な機能、ユーザーの種類、データのニーズを説明してもらいます。

ステップ 2：プラットフォームとバックエンドを確認する

プラットフォームとバックエンドが選定済みかどうかを確認します。build-an-app フローでは、このスキルは spezi-platform-selection より前に実行されるため、プラットフォームが未決定なのは通常の状態であり、作業を妨げるものではありません。

以下を質問します。

1. 「どのプラットフォームをお使いですか？ React Native、Apple ネイティブ、それとも Flutter や Web など、別のものですか？ まだ未決定ですか？」（既存のリポジトリの場合は、そのリポジトリで使用しているフレームワークが回答になります。）
2. 「どのバックエンドをお使いですか？ Firebase、Medplum、それとも別のものですか？ まだ未決定ですか？」

プラットフォームに応じて、適切なリファレンスファイルを読みます。

• React Native → react-native-packages.md を読む
• Apple ネイティブ → apple-native-modules.md を読む
• その他のプラットフォーム → Spezi のパッケージ／モジュールの対応付けは省略し、適用されるフレームワークの規約に沿ってエージェントが実装できる汎用的な計画を作成する
• 未決定（例：spezi-platform-selection がこのスキルの後に実行される場合） → 両方のリファレンスファイルを読み、計画の Platform フィールドを「未決定」に設定して、プラットフォームに関する注記を両方の形式で記述する（例：「questionnaire / SpeziQuestionnaire」）。これにより、どちらの選択になっても計画を活用できます。後でプラットフォームを決定するステップ（spezi-platform-selection、またはユーザーがテンプレートを使用しない場合のオーケストレーターによるテンプレートなしのプロジェクト設定）で、計画を絞り込みます。

バックエンドも未決定の場合は、どれかを想定せず、計画の未解決の質問に選択内容を記録します。

Spezi テンプレートを使わずに構築された React Native または Apple ネイティブのアプリの場合も、リファレンスファイルを読みます。ただし、各パッケージは既定のものではなく、導入を検討する項目として扱います。既存のアプリに追加できるか、機能にカスタム実装が必要かを計画に記載します。

---

ステップ 3：機能を抽出する

計画の出力を解析し、個別に構築可能な機能のリストにまとめます。各機能は次の条件を満たす必要があります。

• 具体的 — 「アンケート」ではなく「PHQ-9 を使った毎日の症状アンケート」
• テスト可能 — 単独、または最小限の依存関係で動作を検証できる
• 追跡可能 — 計画の情報源（UX ジャーニー、データエンティティ、コンプライアンス管理策）に紐付いている

一般的な機能カテゴリは次のとおりです。

カテゴリ	例
アカウント	サインイン、登録、プロフィール管理、パスワードリセット
オンボーディング	ウェルカム画面、機能の紹介、インフォームドコンセント、権限
データ収集	アンケート、調査、毎日のチェックイン、手動入力
ヘルスデータ	HealthKit 同期、バイタルの読み取り、ウェアラブルデータ
スケジュール管理	タスクのリマインダー、評価期間、ケアプランのアクティビティ
コミュニケーション	医療提供者とのチャット、AI コーチング、安全なメッセージング
データ管理	バックエンド同期、オフラインストレージ、FHIR リソースの対応付け
コンプライアンス	同意の追跡、監査ログ、データ保持、アクセス制御
エンゲージメント	通知、連続記録、進捗の可視化

各機能について、次の情報を記録します。

• 情報源 — どの計画書またはユーザー入力に由来するか
• 優先度 — 必須、推奨、またはあるとよい
• プラットフォームのパッケージ／モジュール — 利用可能な構成要素（リファレンスファイルを参照）

また、次の項目も個別に抽出します。

• データエンティティ — health-data-model-planning または fhir-data-model-design のドキュメントがある場合は、各データエンティティ（例：Patient、Observation、QuestionnaireResponse）と、それに対応する FHIR リソースを一覧にします。両方のドキュメントがある場合、FHIR の対応付けについては fhir-data-model.md を正式な情報源として扱います。データモデルの概要に記載された FHIR の推奨事項は暫定的なものです。これらは出力ドキュメントのデータモデル統合テーブルに反映されます。
• コンプライアンス管理策 — digital-health-compliance-planning のドキュメントがある場合は、必要な管理策（例：「すべての PHI アクセスを監査ログに記録する」「データ収集前にインフォームドコンセントを取得する」「データ保持ポリシーを適用する」）を一覧にします。これらは出力ドキュメントのコンプライアンス統合テーブルに反映されます。

---

ステップ 4：パッケージとモジュールへのマッピング

抽出した各機能について、利用できる事前構築済みのパッケージ（React Native）またはモジュール（Apple ネイティブ）を特定します。Spezi エコシステム以外のプラットフォームでは、ステップ 2 に従ってマッピングを省略し、代わりに各機能をカスタム実装する場合の相対的な工数を記載します。

以下のリファレンスファイルを使用します。

• react-native-packages.md — @spezivibe/account、@spezivibe/onboarding、@spezivibe/questionnaire、@spezivibe/scheduler、@spezivibe/chat、@spezivibe/firebase、@spezivibe/medplum、@spezivibe/healthkit（未構築です。Status の注記を参照）
• apple-native-modules.md — SpeziAccount、SpeziOnboarding、SpeziQuestionnaire、SpeziScheduler、SpeziChat、SpeziHealthKit、SpeziFHIR、SpeziFirebaseAccount、SpeziFirestore、SpeziNotifications、SpeziViews

推奨する前に、リファレンスファイルで各パッケージの項目を確認してください。使用準備が整っていないパッケージには、Status の注記があります。React Native では @spezivibe/healthkit はまだ構築されていないため、このパッケージに依存する機能にはカスタム実装が必要であることを明記してください。Apple ネイティブモジュールは、すべてリリース済みの Spezi パッケージです。

対応するパッケージまたはモジュールがない機能については、カスタム実装が必要であることを記載し、相対的な工数（小、中、大）を見積もります。

---

ステップ 5：マイルストーンに分割

機能を、アプリを構築・テストできる単位であるマイルストーンに整理します。

アプリのアーキタイプに基づいて開始パターンを選択するため、milestone-patterns.md を確認してください。

• 研究参加者向けアプリ — 同意取得を重視し、評価を中心とする
• 臨床ケアアプリ — 医療提供者のワークフロー、ケアプラン、FHIR 統合
• 患者エンゲージメントアプリ — セルフトラッキング、コーチング、習慣形成

実際の機能に合わせてパターンを調整します。

1. 該当しないマイルストーンを削除する
2. ユーザーにとって重要なものを優先して並べ替える
3. 多くの機能を含む大きなマイルストーンを分割する
4. 密接に関連する小さなマイルストーンを統合する
5. どのパターンにも含まれない機能のマイルストーンを追加する

各マイルストーンには、次の内容を含める必要があります。

• 目標 — 完了時にユーザーに表示される内容を説明する 1 文
• タスク — 構築または設定する具体的な項目
• プラットフォームに関する注記 — 使用するパッケージ／モジュール、プラットフォーム固有の考慮事項
• 検証 — マイルストーンの完了を確認する方法
• 依存関係 — 先に完了しておく必要があるマイルストーン

マイルストーンは、次の一般的な順序に従います。

1. 基盤 — ナビゲーション、テーマ設定、プロジェクト構成
2. アカウント — 認証、プロフィール設定
3. オンボーディング — ウェルカムフロー、同意、権限
4. コア機能 — アプリの主要な価値（データ収集、健康状態のトラッキング、スケジュール管理）
5. コミュニケーション — チャット、メッセージング（該当する場合）
6. バックエンド統合 — データ同期、FHIR マッピング、サーバー通信
7. コンプライアンス — 監査ログ、同意の追跡、データ保持
8. エンゲージメント — 通知、進捗の可視化、連続記録
9. 仕上げ — エラー処理、アクセシビリティ、オフライン対応

---

ステップ 6：実装計画を作成

以下の形式を使用して、実装計画の全ドキュメントを生成します。

# Implementation Plan: [App Name]

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

## Context

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

## Planning Inputs

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

## Feature List

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

## Milestones

### Milestone 1: [Name]

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

**Depends on:** [Nothing / Milestone N]

**Tasks:**
1. [Specific task]
2. [Specific task]
3. ...

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

**Verify:**
- [How to confirm this milestone works]

---

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

### Milestone N: [Name]
...

## Data Model Integration

[Map each data entity from the planning phase to the milestone where it gets implemented. If no data-model planning was run, replace the table with a one-line note naming the gap.]

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

## Compliance Integration

[Map each compliance control to the milestone where it gets addressed. If no compliance planning was run, replace the table with a one-line note naming the gap.]

| 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]

## Next Steps

This plan is saved 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. Share this document with your agent as context and ask it to implement
Milestone 1 — verify, commit, then move to the next.

---

ガードレール

• アプリケーションコードを生成しないでください。 このスキルで作成するのは計画であり、ソースコードではありません。
• ユーザーが選択を確定していない限り、バックエンドを決めつけないでください。 確認してください。
• 不足している入力を飛ばさないでください。 計画項目が未完了の場合は、未解決の項目として記載し、見直しを検討できる内容を示してください。
• マイルストーンは小さく、テスト可能なものにしてください。 各マイルストーンでは、目に見えて検証できる変更を実現してください。タスクが5～7件を超える場合は、分割を検討してください。
• プラットフォームを考慮しつつ、プラットフォームの専門家を装わないでください。 リファレンスファイルから該当するパッケージやモジュールを参照し、詳細なコードレベルの実装は、この計画をもとに構築するコーディングエージェントに任せてください。
• 優先順位を守ってください。 必須機能は早い段階のマイルストーンに含めてください。あると望ましい機能は最後に含め、計画を損なうことなく削除できるようにしてください。

---

チェックリスト

実装計画を提示する前に、次の項目を確認してください。

• UX ブリーフのすべての機能が機能リストに含まれている
• データモデルのすべてのエンティティがいずれかのマイルストーンに割り当てられている
• すべてのコンプライアンス管理策がいずれかのマイルストーンに割り当てられている
• マイルストーンが依存関係の順に並んでいる — どのマイルストーンも、それより後のマイルストーンに依存していない
• 各マイルストーンに明確な目標、タスク、検証基準がある
• 該当するプラットフォームパッケージまたはモジュールが、各機能について特定されている
• 対応するパッケージがない機能について、独自実装に必要な作業が記載されている
• 不足している計画入力が明示されている
• 未解決の質問が列挙されている
• 計画が docs/implementation-plan.md に保存されている（または、チャットのみのセッションでは、そこに保存するようユーザーに伝えている）