create-app

アプリを作成する

生のアプリのアイデアを、検証済みで、すっきりと設計された初版へと形にし、無理のないペースでリリースします。まだ実績のない規模に向けて作り込みすぎることも、プロトタイプを書いて後から全面的な作り直しが必要になることもありません。この取り組みは10のフェーズで構成され、あらゆる決定の前に質問を行い、各選択を docs/ に記録するため、セッションをまたいで中断・再開できます。初期フェーズでは、コードをまったく書かないこともよくあります。実験の結果、構築に進む判断が下されると、エンジニアリングの各フェーズで本番用のものを適切に作り上げます。

中心となる原則

選択肢を残しながら素早く検証します。後から覆すのにコストがかかる決定は早めに行い、簡単に変更できることは後回しにします。 初期の貴重な労力は、積み重ねて効果を生む少数の要素、つまり最もリスクの高い仮説、依存関係の境界、ドメインの用語に使い、それ以外の無駄は徹底的に避けます。

このスキルはフェーズの順序を組み立て、質問を行い、決定を記録します。各フェーズを構成するスキルが具体的な手法を担います。独自のフレームワークをその場で考案するのではなく、それらを呼び出してください。

取り組みの流れ

フェーズ	スキル	答える質問	成果物
1	lean-startup	最もリスクの高い仮説は正しいか、MVP は何か？	docs/PRODUCT.md + docs/EXPERIMENTS.md を作成
2	design-sprint	コアとなるフローはどうあるべきか？	docs/DESIGN.md を作成し、docs/EXPERIMENTS.md を拡張 — 証拠待ち
3	clean-architecture	選択肢を残すには、どのような境界が必要か？	docs/ARCHITECTURE.md を作成
4	domain-driven-design	コードは何を意味するか？	docs/ARCHITECTURE.md を拡張
5	clean-code	各関数は読みやすく、テストされているか？	docs/TESTING.md を作成
6	pragmatic-programmer	健全な状態を保つには、どのような習慣が必要か？	docs/TESTING.md + docs/TECH-DEBT.md を拡張
7	system-design	実際には、どれほどの規模が必要か？	docs/ARCHITECTURE.md を拡張
8	ios-hig-design	iOS でネイティブらしく感じられるか？	docs/DESIGN.md を拡張 — iOS のみ
9	37signals-way	何をリリースし、何を削るか？	docs/PRODUCT.md + docs/STRATEGY.md を拡張
10	software-design-philosophy	複雑さはどこに潜んでいるか？	docs/TECH-DEBT.md + docs/ARCHITECTURE.md を拡張

運用ルール

1. まず再開します。 何よりも先に、docs/CREATE-APP-PLAN.md とジャーニーマップ内のすべての成果物を読みます。トラッカーが存在する場合は、ジャーニーの状態を3〜5行で要約し、どのフェーズに入るかを尋ねます。ユーザーが開始地点を確認したら完了です。トラッカーがあるジャーニーは再開し、最初からやり直すことはありません。
2. 初回のみインテークを行います。 トラッカーがない場合は、以下のインテークを実施してから、各フェーズのステータスを pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason のいずれかにした docs/CREATE-APP-PLAN.md を作成します。トラッカーが作成され、ユーザーがフェーズ計画を確認したら完了です。
3. フェーズへの移行。 そのフェーズで行うこと、必ず決定する事項、作成する成果物、おおよその所要時間を説明します。続行／スキップ／延期を提示します。GATE と記されたフェーズは延期できますが、スキップはできません。続行する場合は、フェーズを in-progress にします。ユーザーが選択したら完了です。
4. スキルの呼び出しと代替手段。 フェーズのスキルを読み込み、使用します。各フェーズの Invoke 行にはスキルのスラッグが記載されています。そのスキルを使ってフェーズを実施します。利用できない場合は、npx skills add wondelai/skills/<slug> --global を提示します。ユーザーが断った場合は、Brief に基づく最小限の方法でフェーズを実施します。どの方法で進めるかを明示します。
5. フェーズ内の決定。 「ユーザーと決定する」の下にあるすべての質問を、具体的な選択肢と推奨案とともに尋ねます。選択内容をトラッカーの Key Decisions に記録します。黙って決定を下すことは不備です。
6. フェーズの終了。 書き込む前に、成果物のドラフト内容を提示し、承認を得ます。承認後、docs/ ファイルを作成または更新し、トラッカー（ステータス、Key Decisions、Next Actions）を更新します。ファイルが書き込まれ、フェーズの行が done になったら完了です。
7. 成果物の管理。 書き込む前に読み込みます。ファイルがない場合のみ作成し、存在する場合は追記します。自分のセクションを追加または更新し、他の人の内容は保持します。ファイル名は docs/ 内で大文字にします。すべての推奨事項は、担当者と優先度を含むチェックボックスまたは表の行にします。docs/ ファイルを初めて作成するときは、references/artifact-templates.md を参照してください。完全なひな形（すべてのセクション見出しを含む）から作成し、その後、フェーズで指定されたセクションを埋めます。
8. エージェントが準備と処理を行い、顧客やテストユーザーと話すのは人間だけです。 スプリントの台本やインタビューガイドを作成し、結果を評価した後、ユーザーがメモを持ち帰るまでステータスを awaiting-evidence にして待機します。ios-hig-design フェーズはネイティブ iOS アプリをリリースする場合にのみ適用し、それ以外の場合はインテーク時にスキップします。

受付時の質問

トラッカーを作成する前に、以下を確認します。

1. アプリのアイデアを一文で表すと何ですか？ また、その背後にある最もリスクの高い仮説は何ですか？（Phase 1 のゲートです。アプリがどのような仕事を担うのかが曖昧な場合は、任意の jobs-to-be-done フェーズを追加します。）
2. 根底にあるアイデアは、すでに行動に基づく証拠で検証されていますか？ それとも、まだ仮説の段階ですか？（未検証でリスクが高い場合、Phase 1 は必須です。すでに有料顧客がいる場合は、適切なジャーニーではない可能性があります。その場合は improve-app または grow-app を選びます。）
3. 現在の段階はどれですか？ 週末のプロトタイプ、ローンチに向けて資金を得て開発中、またはチームが結成されつつある段階ですか？（プロトタイプの場合は Phase 1〜3 と 10 が中心です。チームが結成されつつある場合は inspired-product を追加することがあります。）
4. ネイティブ iOS クライアントをリリースしますか？（はいの場合は Phase 8 を維持し、いいえの場合はスキップします。）
5. 話を聞ける顧客はいますか？ それとも、顧客を見つける必要がありますか？（Phase 1〜2 の人を対象とするエビデンスループと、任意の mom-test / continuous-discovery の実施可否を左右します。）
6. 最初の数か月に見込む負荷はどの程度ですか？ 1 日あたりのアクティブユーザー数とアクション数を教えてください。（Phase 7 のキャパシティ計算に使い、早すぎるスケーリングを防ぎます。）
7. 1 人で開発しますか、それともチームで開発しますか？ リリースのペースは誰が担当しますか？（Phase 9 のシェイピングの実施可否を左右します。）

フェーズをスキップする際の目安：コアフローをすでにテスト済み、または自明な場合は Phase 2 をスキップします。ネイティブ iOS をリリースしない場合は Phase 8 をスキップします。負荷が明らかに小さい場合に限り Phase 7 をスキップできますが、見積もりは記録します。週末のプロトタイプでは Phase 3〜6 をまとめて一度に実施しますが、Dependency Rule は必ず守ります。

次に、テンプレートから docs/CREATE-APP-PLAN.md を作成し、すべてのフェーズにステータスを設定して、Phase 8 に iOS 条件付きと明記します。docs/CREATE-APP-PLAN.md が存在し、すべてのフェーズにステータスが設定され、ユーザーが計画を確認したら完了です。

フェーズ

Phase 1 — 最もリスクの高い仮説を検証する（lean-startup）

目的： それが誤りならアプリを頓挫させる仮説を、本番コードを書く前に検証します。

概要（フォールバック）： Build-Measure-Learn を逆算して計画します。何を学ぶ必要があり、どうすれば分かり、それを確かめるための最小限の構築は何かを考えます。大胆な信念に基づく仮説は、テストの簡単さではなく、致命的かどうかで順位付けします。MVP は学習のための手段であり、しばしば粗削りです（Dropbox は同期エンジンではなく動画で検証しました）。検証の段階を上げていきます。登録は弱い証拠、前払いのデポジットは強い証拠、実際の利用は最も強い証拠です。行動レベル 4〜5 を目指し、「使いたいと思いますか？」という意見に頼ることは避けます。

実行： アイデアと、CUSTOMER.md が存在する場合はジョブの記述を添えて、lean-startup スキルを使用します。順位付けした大胆な信念に基づく仮説、最もリスクの高い仮説を反証する単一の最小実験、そして事前に確定する行動ベースの成功基準を求めます。

ユーザーと決定すること： 誤りなら致命的となる仮説はどれですか？ 実験の種類はどれにしますか？（需要を調べるスモークテスト、価値を調べるコンシェルジュ、または自動化を調べる Wizard of Oz）実施前に固定する継続／方向転換の基準は何ですか？ 実際の人を対象に実験を行うのはユーザーだけです。その後、awaiting-evidence の状態で一時停止します。

成果物： ## Vision と ## MVP Definition を含む docs/PRODUCT.md を作成します。仮説、指標、判断ルールを含む EXP-001 と、## Experiment Backlog を含む ## Experiment Cards を docs/EXPERIMENTS.md に作成します。トラッカーを更新します。

完了条件： 致命的となる仮説が明示され、EXP-001 に事前確定した基準があり、PRODUCT.md に MVP の範囲が記載され、ユーザーが実施する実験を把握していること。

フェーズ 2 — コア体験のリスクを低減する（デザインスプリント）

目的： エンジニアリングの時間を投入する前に、テスト済みのファサードを使って、コアフローのあるべき姿を固めます。

概要（フォールバック）： 5 日間で実施します。月曜日に問題を整理し、火曜日にスケッチし、水曜日に決定し、木曜日にプロトタイプを作成し、金曜日に実際のユーザー 5 人でテストします。成果物は高忠実度のファサードとエビデンスであり、コードではありません。最もリスクの高い瞬間は、初対面の人が最初の 10 分間に体験する部分です。説明なしで内容を理解し、コアタスクを完了できるかをテストします。5 人のユーザーでパターンを見つけます。必要なのは有意性ではなく、パターンです。プロトタイプについて説明してはいけません。どこでつまずくかを観察してください。

実行： design-sprint スキルを、PRODUCT.md の MVP スコープとともに使用します。月曜日のマップと「どうすれば〜できるか」という問いへの言い換え、採用するコンセプトのストーリーボード、5 幕構成のインタビュースクリプト、およびメモ用グリッド（参加者ごとにチェックマーク／バツ／チルダ）を作成するよう依頼してください。中断時には、承認済みのスクリプトを docs/EXPERIMENTS.md のスプリントカードに記録し、セッションの中断後も残るようにしてください。

ユーザーと一緒に決定（再開時）： テスト済みのフローはそのまま機能するのか、形を変える必要があるのか、それとも需要の問題が明らかになりフェーズ 1 に戻るのかを決めます。どの混乱を修正につなげますか？

成果物： ## Design Direction を含む docs/DESIGN.md を作成します。スプリントテストとその判定を ## Experiment Cards に追加し、docs/EXPERIMENTS.md を拡張します。トラッカーを更新します。

完了条件： DESIGN.md に方針が記録され、スプリントの結果と判定が EXPERIMENTS.md に記録され、ユーザーが「進める／形を変える／戻る」を選択していること。

フェーズ 3 — 境界を定義する（クリーンアーキテクチャ）

目的： データベース、フレームワーク、プロバイダーを交換可能な詳細として扱えるよう、ビジネスルールを分離します。

概要（フォールバック）： ソースコードの依存関係は内側を向きます。フレームワークからユースケースへ、ユースケースからエンティティへと向かいます。ビジネスルールからフレームワークや ORM をインポートしてはいけません。ユースケースがインターフェース（例：InvoiceRepository）を定義し、インフラストラクチャがそれを実装します。コントローラーは HTTP リクエストを単純なリクエストオブジェクトに変換し、単純なレスポンスを受け取ります。フレームワークの型が境界を越えてはいけません。診断として、データベース、Web サーバー、フレームワークを稼働させずにビジネスルールをテストできるかを確認してください。4 つの円は一般的な構成ですが、絶対ではありません。変化しやすい箇所だけに境界を設けてください。

実行： clean-architecture スキルを、PRODUCT.md の検証済み MVP スコープとともに使用します。レイヤーマップ、リクエスト／レスポンスモデルを含むコアユースケース、および依存先となるリポジトリインターフェースを作成するよう依頼してください。

ユーザーと一緒に決定： 実際に変化しやすい境界（データベース、サードパーティ API、提供手段）はどこですか？4 つのレイヤーをすべて設けますか。それとも小規模なアプリではアダプターとフレームワークをまとめますか？

成果物： ## System Context と ## Layer Map & Dependency Rule（レイヤー、依存関係、違反の一覧表）を含む docs/ARCHITECTURE.md を作成します。トラッカーを更新します。

完了条件： ARCHITECTURE.md にレイヤーが記載され、依存関係ルールの方向が明確で、インフラストラクチャなしでコアビジネスルールをテストできること。

フェーズ 4 — ドメインをモデル化する（domain-driven-design）

目的： ドメインエキスパートがコードを読んで、問題点を見つけられるような、ビジネスを語るコードにします。

概要（代替案）： モデルとはコードです。ユビキタス言語を作り、技術上の役割ではなくドメインの概念に基づいて名前を付けます（DataProcessor.process() よりも InvoiceDraft.finalize() のほうが適切です）。名前を付けにくい場合は、設計上の問題を示すサインです。境界づけられたコンテキストでは、境界の内側で言葉の意味はひとつです（請求における「Customer」は、サポートにおける「Customer」と同じである必要はありません）。集約とは、不変条件を守るルートをひとつ持つまとまりです。小さく保ち、他の集約は ID で参照します。貧血モデルを避け、エンティティと値オブジェクトに振る舞いを持たせます。

実行： domain-driven-design スキルを ARCHITECTURE.md のレイヤーマップとともに使用します。ユビキタス言語、境界づけられたコンテキストとコンテキストマップ、そしてルートが守る不変条件を備えた中核の集約を明らかにします。

ユーザーと決めること： コアドメイン（競争上の優位性）と、購入するかオープンソースを利用する汎用サブドメイン（認証、メール、決済）の境界はどこですか？ 同じ言葉がコンテキストごとに異なる意味を持つのは、どのような場合ですか？

成果物： docs/ARCHITECTURE.md に ## Bounded Contexts & Context Map と ## Domain Glossary (Ubiquitous Language)（用語 | 意味 | コード上の名前）を追加します。トラッカーを更新します。

完了条件： 用語集にコア概念が記載され、コンテキストとその関係がマッピングされ、リポジトリインターフェースがフェーズ 3 に従ってドメインレイヤーに配置されています。

フェーズ 5 — 読みやすいコードを書く（clean-code）

目的： コードベースの成長に伴い、すべての関数を読みやすく、テスト済みの状態に保ちます。

概要（代替案）： コードは書かれるよりも読まれる機会のほうがはるかに多いものです。ひとつの抽象化レベルでひとつのことだけを行う小さな関数、意図が伝わる名前、フラグ引数の排除（関数がふたつのことをしているという問題のサインです）、コマンドとクエリの分離を徹底します。コメントを書くより、名前を付けた関数に処理を切り出すほうが効果的です。テストは一級の存在です。テストが汚れているくらいなら、ないほうがましです。F.I.R.S.T.（高速、独立、反復可能、自己検証可能、タイムリー）に従い、shouldRejectNegativeTotal のように振る舞いを表す名前を付けます。

実行： フェーズ 3〜4 の中核モジュールを対象に、clean-code スキルを使用します。ルールに基づく採点と修正のレビュー、および中核ユースケース向けのクリーンな単体テスト（準備・実行・検証、説明的な名前、ビルダーヘルパー）を依頼します。

ユーザーと決めること： コミットを許可する品質基準は何ですか？（関数のサイズ、名前の明確さ、例外の握りつぶし禁止など。）最初のテストで、正常系と失敗ケースのどれを必ずカバーしますか？

成果物： docs/TESTING.md を作成し、## Test Strategy（テストピラミッド、ツール、グリーン判定の条件）と ## Safety Net Map（モジュール | 固定する振る舞い | テストファイル | 不足点）を記載します。トラッカーを更新します。

完了条件： TESTING.md にテスト戦略が記載され、中核ユースケースにデータベースを必要としない、振る舞いを表す名前のテストがあり、コミットの品質基準が記録されています。

フェーズ 6 — メタ規律を取り入れる（pragmatic-programmer）

目的： 長年にわたってコードベースを変更しやすく保つ習慣を身につけます。

概要（フォールバック）： トレーサーバレットを放ちます。すべてのレイヤー（UI からユースケース、データベース、そして戻るまで）を通る、薄くても実際に動くスライスを 1 つ作って維持し、2 日目に統合バグを見つけられるようにします。DRY が適用されるのは知識に対してのみであり、偶然の類似性には適用されません。直交性：データベースの変更で UI に手を加える必要があってはなりません。可逆性：サードパーティ SDK を独自のインターフェースの背後に置き、ビジネスロジックに手を加えずに Stripe やモデルプロバイダーを切り替えられるようにします。壊れた窓：最初のハックは修正するか、追跡対象のチケットを登録してふさぎます。静かに腐敗していく状態を決して放置しません。

呼び出し： pragmatic-programmer スキルを ARCHITECTURE.md と中核となるユースケースとともに使用します。エンドツーエンドで最も薄いトレーサーバレット設計と、サードパーティ依存関係ごとのアダプターインターフェースを依頼します。

ユーザーと決めること： トレーサーバレットのスライスは何ですか？ 壊れた窓のポリシーは、追跡対象のチケットを登録することを含め、ゼロトレランスにしますか？ どの依存関係に今アダプターインターフェースを設け、どれを後回しにしますか？

成果物： docs/TESTING.md に ## CI Gates を追加し、docs/TECH-DEBT.md に ## Debt Budget & Broken-Windows Policy と ## Adopted Conventions を追加します。トラッカーを更新します。

完了条件： トレーサーバレットがエンドツーエンドで仕様化され、各プロバイダーのアダプターインターフェースが命名され、壊れた窓のポリシーが文書化されていること。

フェーズ 7 — 正直に規模を見積もる（system-design）

目的： 実際の負荷を見積もり、まだ構築する必要のないものを明らかにします。

概要（フォールバック）： 解決策ではなく要件から始めます。QPS = 1 日のアクティブユーザー数 x 1 日あたりのアクション数 / 86,400。ピーク時は平均の 2〜5 倍です。ストレージ = 1 日あたりのレコード数 x レコードサイズ x 保持期間。数百人程度のユーザーであれば、十分にインデックスを設定したデータベース 1 つとキャッシュでほぼ必ず対応できます。拡張は、まず垂直スケーリング、次に読み取りレプリカ、続いてキャッシュアサイド、シャーディングは最後の順に行います。ピークを吸収し、遅い処理（写真の OCR など）をリクエスト処理経路から切り離すためにキューを導入するのは、見積もりまたは実際のボトルネックによって必要性が裏付けられた場合に限ります。

呼び出し： system-design スキルを、インテークで得た負荷の数値とともに使用します。概算の QPS とストレージの見積もり、およびまだ必要のない手法の明示的な一覧を依頼します。

ユーザーと決めること： 見積もりを踏まえ、どのスケーリングを意図的に先送りにしますか？ キャッシュやキューを今導入する正当な理由となる実際のボトルネックはありますか？

成果物： docs/ARCHITECTURE.md に ## Data & Storage Decisions と ## Decision Log（日付 | 決定 | 理由 | 却下した代替案）を追加し、「まだ導入しない」という判断をそれぞれ記録します。トラッカーを更新します。

完了条件： キャパシティの見積もりが記録され、先送りにするスケーリング手法が明示的に列挙され、キャッシュやキューを導入する場合はその必要性が数値で裏付けられていること。

フェーズ 8 — ネイティブな使い心地にする（ios-hig-design）— iOS のみ

目的： iPhone クライアントをネイティブな使い心地にします。これは iOS ユーザーの信頼の基盤です。ネイティブ iOS クライアントをリリースする場合（インテーク時に決定）のみ実施し、それ以外はスキップします。

概要（フォールバック）： 3 つの柱は、明瞭さ、敬意、奥行きです。セーフエリア（Dynamic Island、ホームインジケーター）を尊重し、すべてのタッチターゲットを少なくとも 44x44 pt にします。セマンティックカラー（Color(.label)、Color(.systemBackground)）を使って、ダークモードに自動対応します。Dynamic Type にはセマンティックなテキストスタイルを使います。ネイティブなナビゲーションとして、主要な画面にはタブバー、階層を掘り下げる画面には NavigationStack、目的を絞ったタスクにはシートを使い、ハンバーガーメニューは使いません。アクセシビリティを最優先にし、すべてのコントロールにラベルを付け、VoiceOver ですべてのタスクを完了できるようにします。

呼び出し： アプリの主要画面を対象に ios-hig-design スキルを使います。セーフエリア、44pt のタッチターゲット、セマンティックカラーとテキスト、ネイティブなナビゲーション、アクセシビリティラベルについて、HIG レビューを依頼します。

ユーザーと決めること： 最初のレビューでは、どの画面を対象にしますか？ 意図的にプラットフォームの慣例から外れる箇所はありますか？ また、その理由は妥当ですか？

成果物： docs/DESIGN.md を拡張し、## Components（component | decision | status）と ## UX Audit Findings（issue | heuristic | severity 0-4 | fix | status）を追加します。トラッカーを更新します。

完了条件： 対象画面をすべてレビューし、指摘事項を深刻度とともに記録し、アクセシビリティの不足を修正項目として記録します。

フェーズ 9 — 一定のペースでリリースする（37signals-way）

目的： 機能の肥大化を防ぎながら、範囲を絞った v1 を期限内にリリースします。

概要（フォールバック）： 中途半端な製品ではなく、製品の半分を作ります。取り組みに賭ける前に形を整えます。設計の自由を保てる程度に粗く、大きな不確実性を取り除ける程度に解決し、「これは 2 週間をかける価値がある」という意欲の範囲に収めます。これは見積もりではありません。期限を決め、範囲を合わせて削り、逆にしてはいけません。形を整えた提案を、期間が固定されたサイクルに投入します。期限までに終わらなかったものは、サーキットブレーカーで打ち切ります。ソフトウェアには明確な方針を持たせます。提示される選択肢はすべて、決断を先送りしているということです。妥当なデフォルトを選び、機能への基本回答は、敬意を込めた「今は対応しない」とします。

呼び出し： PRODUCT.md の MVP の範囲をもとに 37signals-way スキルを使います。次の機能を、提案（問題、意欲、ブレッドボード、深掘りが必要な箇所、対象外）と v1 の削減リストにまとめるよう依頼します。

ユーザーと決めること： 次の機能にかける意欲はどの程度ですか？ v1 から削る機能と、ユーザー向けの選択肢のうち、明確なデフォルトにするものはどれですか？

成果物： docs/PRODUCT.md（## Outcome Roadmap）と docs/STRATEGY.md（## No-List — 明確に実施しないこと）を拡張します。トラッカーを更新します。

完了条件： 次の機能について、意欲を明記した提案がまとまり、v1 の削減リストが STRATEGY.md の No-List に記載され、ロードマップに期限固定・範囲柔軟の方針が反映されています。

フェーズ 10 — 複雑さを敵とみなす（software-design-philosophy）

目的： すべてのモジュールで複雑さを抑えます。他のすべてのフェーズを見渡す視点です。

概要（代替案）： 複雑さとは、システムの理解や変更を難しくする構造上のあらゆる要素です。浅いモジュールより、シンプルなインターフェースの背後に強力な機能を備えた深いモジュールを優先します。モジュールは行数ではなく、機能をインターフェースの複雑さで割った値で評価します。これは、Clean Code の「小さく」と DDD の多くの概念が、クラス偏重（1 メソッドだけを持つ浅いクラスが大量に生まれること）に陥るのを防ぎます。戦術より戦略を重視します。設計に継続的に 10〜20％多く投資してください。チームとコードベースの成長に伴い、初期の近道はまさにその分だけ積み重なるためです。

実施方法： software-design-philosophy スキルを、フェーズ 3〜6 のモジュールに対して使用します。浅いクラス、処理をそのまま通すだけのメソッド、境界を越えて漏えいする情報を指摘し、統合すべき箇所を示す、深さと浅さの評価を依頼します。

ユーザーと決めること： どの浅いモジュールを、より深いモジュールに統合しますか？ 戦術的な近道による負債のうち、今すぐ戦略的に 10〜20％を投資する価値があるのはどれですか？

成果物： docs/TECH-DEBT.md に ## Smell Inventory（問題 | 場所 | リファクタリング | 状態）を追加し、docs/ARCHITECTURE.md の ## Decision Log を拡張します。トラッカーを更新します。

完了条件： 浅いモジュールと情報漏えいが Smell Inventory に記録され、統合に関する決定が記録され、戦略と戦術のどちらを重視するかについて合意できていること。

任意のフェーズ

スキル	追加するタイミング	成果物
jobs-to-be-done	アプリが解決する課題が曖昧、または意見が分かれている場合	docs/CUSTOMER.md を作成
mom-test	意見ではなく、顧客との対話で仮説を確かめる必要がある場合	docs/CUSTOMER.md を拡張
lean-ux	重い仕様書ではなく、仮説主導の UX をチームが求めている場合	docs/EXPERIMENTS.md を拡張
ux-heuristics	最初の実用可能なビルドにユーザビリティ評価が必要な場合	docs/DESIGN.md を拡張
hooked-ux	習慣的な反復利用が製品の成否を左右する場合	docs/PRODUCT.md を拡張
design-everyday-things	テストユーザーが主要なフローで迷う場合	docs/DESIGN.md を拡張
continuous-discovery	リリース後も毎週顧客との接点を保つ場合	docs/CUSTOMER.md を拡張
inspired-product	製品を中心にチームが結成され、ビジョンと成果ロードマップが必要な場合	docs/PRODUCT.md を拡張

任意のフェーズにも同じ運用ルールを適用します。各スキルを、コアフェーズとまったく同じ方法で読み込み、使用します。「追加するタイミング」の条件が初めて満たされた時点で、そのフェーズを挿入してください。

よくある間違い

間違い	対策
アイデアを検証する前にアーキテクチャを構築する	まずフェーズ 1 を実施します。検証は安価ですが、書き直しはそうではありません（lean-startup）。
「MVP」を粗雑なものを作る口実にする	学びを得られる最小のものをリリースし、承認されたら本物をきちんと作ります。最小であることは低品質でよいという意味ではありません（lean-startup）。
フレームワークにアーキテクチャを決めさせる	フレームワークはプラグインとして外側の層に置きます。ユースケースの境界を越えて ORM の型を持ち込んではいけません（clean-architecture）。
貧血ドメインモデル	振る舞いを大きなサービスクラスではなく、エンティティや値オブジェクトに持たせます（domain-driven-design）。
クラス偏重 — 「小さく」を過剰に適用する	行数ではなく、モジュールの深さ（インターフェースあたりの機能）で評価します（software-design-philosophy）。
時期尚早なスケーリング	見積もりを行います。ほとんどのアプリは、データベース 1 つとキャッシュで十分に処理できます。シャーディングは最後に行います（system-design）。

ジャーニーを完了する

終了チェックリスト：

• PRODUCT.md に検証済みの MVP とビジョンが記載され、EXPERIMENTS.md に実験の実施内容と記録済みの判定が記載されている。
• ARCHITECTURE.md が依存関係ルールのテストに合格し、コアドメイン、コンテキスト、容量の見積もりを明示している。
• TESTING.md に、インフラを使わずにテストしたコアユースケースと、エンドツーエンドで動作するトレーサーバレットが示されている。
• 開発を続ける場合に備え、STRATEGY.md に No-List と、具体化された次の機能が用意されている。

トラッカーを締めくくります。すべてのフェーズを done または skipped: reason とし、重要な決定事項を記録して、次のアクションを成果物に引き継ぎます（トラッカーに残したままにしないでください）。次のルーティング先：

• アプリの根底にあるアイデアが未検証だと判明した場合、または実際にはビジネスモデルの問題である場合は、create-business スキルに進みます。
• アプリが最初のアーキテクチャを超えて成長し、構造そのものが難題になった場合は、design-code-architecture スキルに進みます。