grow-app

アプリを成長させる

アプリに登録した後、静かに離れていくユーザーがいます。コホートは縮小し、デイリーアクティブユーザー数は横ばいで、アクティベーションファネルはいつも同じ場所で漏れているのに、明らかな問題は何も見当たりません。このジャーニーはバケツの穴を塞ぎ、8つのインタラクティブなフェーズを通じて、初めてのユーザーをアクティベーション済みのユーザー、習慣的に使うユーザー、そして手放せないユーザーへと変えていきます。エージェントは意思決定の前に毎回質問し、結果を docs/ に記録するため、作業を最初からやり直すのではなく、セッションをまたいで再開できます。ここでの成長は、広告予算を増やすことではなく、エンジニアリングとデザインの課題です。

基本原則

獲得に注力する前に、穴の空いたバケツを修繕します。成長への投資より、習慣、アクティベーション、リテンションが先です。 このスキルは8つのフェーズを順番に進め、意思決定に関するすべての質問を行い、選択内容を docs/ に記録します。各スキルが手法を担うため、フレームワークを即興で作るのではなく、それらを呼び出してください。

ジャーニーマップ

フェーズ	スキル	答える質問	成果物
1	hooked-ux	費用をかけなくても、ユーザーが戻ってくるのはなぜですか？	docs/PRODUCT.md を拡張
2	improve-retention	新規ユーザーがループにたどり着けないのはなぜですか？	docs/PRODUCT.md を拡張
3	continuous-discovery	自社のユーザーが実際に必要としているものは何ですか？	docs/PRODUCT.md + docs/CUSTOMER.md を拡張
4	lean-ux	構築する価値があるのは、どの仮説ですか？	docs/EXPERIMENTS.md を拡張
5	inspired-product	チームは適切なものを構築していますか？	docs/PRODUCT.md を拡張
6	lean-analytics	真実を示す単一の数値はどれですか？	docs/METRICS.md を作成 — Rule 8 の基準を設定
7	microinteractions	実際に触れたとき、いきいきと感じられますか？	docs/DESIGN.md を拡張
8	drive-motivation	エンゲージメントは続きますか、それとも損なわれますか？	docs/PRODUCT.md を拡張

フェーズ1～2でループとファネルの穴を塞ぎ、3～5でエビデンスに基づいて方向を定めます。6は計器盤、7～8は仕上げと倫理面の安全策です。lean-analytics のベースライン（フェーズ6）は早めに確認し、フェーズ1～2の修正が反映される前から、すべての変更を変更前の数値と照らして評価できるようにして、その後も更新を続けてください。習慣の形成には時間がかかります。フェーズ1の成功は単一のコホートではなく、「5%ルール」（ユーザーの5%以上が促されなくても戻ってくると、習慣が形成されたとみなす）に照らして評価してください。

運用ルール

1. まず再開します。 何よりも先に、docs/GROW-APP-PLAN.md とジャーニーマップ内のすべての成果物を読みます。トラッカーがある場合は、ジャーニーの状況を3〜5行で要約し、どのフェーズに進むか尋ねます。ユーザーが開始地点を確認したら完了です。トラッカーがあるジャーニーは再開し、やり直しません。
2. 初回実行時のみインテークを行います。 トラッカーがない場合は、以下のインテークを実施してから、すべてのフェーズのステータスを pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason のいずれかにした docs/GROW-APP-PLAN.md を作成します。トラッカーが存在し、ユーザーがフェーズ計画を確認したら完了です。
3. フェーズへの移行。 フェーズで行うこと、必要となる決定事項、作成する成果物、おおよその作業量を伝えます。続行／スキップ／延期を提案します。GATE と記されたフェーズは延期できますが、スキップはできません。続行が選ばれたら、フェーズを in-progress にします。ユーザーが選択したら完了です。
4. スキルの呼び出しと代替手段。 フェーズのスキルを読み込み、使用します。各フェーズの Invoke 行にはスキルのスラッグが記載されています。そのスキルを使ってフェーズを実施してください。利用できない場合は、npx skills add wondelai/skills/<slug> --global を提案します。ユーザーが断った場合は、Brief に沿った最小限の実施方法でフェーズを進めます。どのモードで進めているかを明示します。
5. フェーズ内の決定。 「Decide with the user」にある質問をすべて、具体的な選択肢と推奨案を添えて尋ねます。選択内容はトラッカーの Key Decisions に記録します。決定を黙って行うのは不備です。
6. フェーズの終了。 成果物の草案を提示し、書き込む前に承認を得ます。承認後、docs/ ファイルを作成または追記し、トラッカーを更新します（ステータス、Key Decisions、Next Actions）。ファイルへの書き込みが完了し、フェーズの行が done になったら完了です。
7. 成果物の管理。 書き込み前に読み込みます。ファイルがない場合のみ作成し、それ以外は追記して自分のセクションを追加または更新し、他の人の内容は保持します。docs/ 内のファイル名は大文字で記述します。推奨事項はすべて、担当者と優先度を添えたチェックボックスまたは表の行にします。初めて docs/ ファイルを作成する際は、references/artifact-templates.md を参照してください。すべてのセクション見出しを含む完全なひな形から作成し、そのうえでフェーズに指定されたセクションを記入します。
8. 獲得より定着を優先します。 獲得を目的とするフェーズ（任意の cold-start-problem、contagious、crossing-the-chasm、および有料グロース施策）は、インテークで定めた基準をアクティベーションと定着が下回っている間はロックしたままにします。コホート曲線がその基準を超えた場合にのみロックを解除します。すべての習慣ループと報酬は Manipulation Matrix に照らして検証します。作り手自身が使いたいと思い、ユーザーに実質的な改善をもたらすと誠実に信じられるものだけを作ります。人為的に不安や損失回避をあおる戦術が必要な場合は、実際の価値に基づく戦術に置き換えます。

初回確認

初回起動時のみ実行します（トラッカーがない場合）。以下を確認します。

1. アプリは何をするもので、定着したユーザーが繰り返す中核的なアクションは何ですか？（Hook ループと OMTM を定義します）
2. 現在のリテンション数値はどのくらいですか？ — 1日目／7日目／30日目、または4週目のコホートで教えてください。（Rule 8 の獲得基準を設定し、lean-analytics に反映します）
3. アクティベーションファネルのどこで離脱が起きていますか？ 初回利用時のフローはどのようなものですか？（improve-retention の実施可否を判断します）
4. 個人／小規模チームですか、それともプロダクト担当者、デザイナー、エンジニアから成る正式なプロダクトチームですか？（continuous-discovery と inspired-product の適用範囲を調整します）
5. アプリはネットワーク型／マーケットプレイス型のプロダクトですか？ また、エンゲージメントの高いユーザーが収益化に至っていない状況ですか？（必要に応じて cold-start-problem／monetizing-innovation を検討します）
6. 現在、どのような分析機能や計測機能がありますか？（lean-analytics とすべての実験の実施可否を判断します）
7. リテンションの問題は、エンゲージメント不足ではなく UX やパフォーマンスに起因していますか？（はいの場合、まず improve-app に進みます）

ヒューリスティックを適用しないケース：チームの足並みを揃える必要のない個人創業者の場合は Phase 5 をスキップします。ループとアクティベーションが基準を満たすまでは Phase 7 を延期します。まだユーザーにアクセスできない場合は、Phase 3 の実施頻度を落とします。次に references/artifact-templates.md からトラッカーを作成し、すべてのフェーズのステータスを記入して、計画を確認します。

docs/GROW-APP-PLAN.md が存在し、すべてのフェーズのステータスが記入され、ユーザーが計画を確認したら完了です。

フェーズ

Phase 1 — ユーザーが戻ってくる習慣ループを設計する（hooked-ux）

目的： 有料通知ではなく、内的なきっかけでユーザーが戻ってくるほど強力な Hook ループを作り、再訪の原動力を構築します。

概要（代替案）： Hook Model は Trigger → Action → Variable Reward → Investment の順に進みます。外的なきっかけ（プッシュ通知、メール）を、内的なきっかけ（退屈、FOMO、不安などの感情）へと移行します。アクションは極めて簡単にします。報酬は tribe／hunt／self の各タイプで変化をつけます。切り替えコストを高め、次のきっかけを生み出すため、Investment は報酬の 後に 配置します。1つのフェーズが弱いループは、半分機能するのではなく、停滞します。

実行： 中核的なループと、現在デイリーアクティブユーザーがどのように戻ってきているかをもとに、hooked-ux スキルを使用します。以下を依頼します。(a) 4つのフェーズすべてについてループを図示し、それぞれを0～10で評価して、最も弱いフェーズを特定する。(b) すでに保有しているデータを活用した誠実な可変報酬のコンセプトを設計し、それぞれを Manipulation Matrix に照らして確認する。

ユーザーと決めること：

• ユーザーを呼び戻す内的なきっかけ（感情）を1つ選び、確認します。
• 最も弱く、今すぐ最も効果の高い修正を行うフェーズを1つ選びます。ループがすでに形成されている場合（促されずに戻るユーザーが5％以上）は、修正を延期します。
• 強化する報酬タイプ（tribe（ソーシャル）、hunt（リソース）、self（習熟））を選び、Manipulation Matrix の基準を満たさないコンセプトは却下します。

成果物： docs/PRODUCT.md の ## Hook Model を拡張します（trigger → action → variable reward → investment。最も弱いフェーズも明記）。トラッカーを更新します。

完了条件： PRODUCT.md に内的なきっかけと4つすべてのフェーズが記載され、最も弱いフェーズとその修正が記録されていること。新規ユーザーが初回セッション中に Hook サイクルを1周できるよう、オンボーディングが再設計されていること。ユーザーが実装する修正を選んでいること。

フェーズ 2 — 最初のアクションをほぼ負担なく実行できるようにして、利用開始を改善する（improve-retention）

目的： 最初の価値あるアクションをほぼ負担なく実行できるようにし、新規ユーザーが利用のループに入れるようにします。

概要（フォールバック）： B=MAP — 行動は、Motivation（動機）、Ability（能力）、Prompt（きっかけ）がそろったときにのみ起こります。動機は当てにならないため、能力を高めます。シンプルさは、時間、お金、身体的労力、精神的労力、社会的逸脱、非日常性の6つのリソースのうち、最も不足しているものによって上限が決まります。目標を、30秒以内に価値を届ける Starter Step に絞り、既存の習慣に結び付けて、達成をすぐに称えます。

実行： 実際の利用開始フローを段階ごとに確認し、1日目／7日目／30日目の離脱率を調べながら、improve-retention スキルを使います。6つの Ability-Chain 要因すべてを評価する B=MAP 摩擦監査、不足しているリソースの特定、Starter Step の再設計、イベントベースのきっかけのルールを求めます。

ユーザーと決めること：

• 最初のアクションで最も不足している Ability リソースは何か。明白な要因ではなく、まずそのつながりを改善します。
• Starter Step（最小限の価値あるアクション）と、それを達成した際に称えるタイミング。
• どの時間ベースのきっかけをイベントベースに切り替えるか。「今このタイミングなら歓迎されるか？」に当てはまらないものは削除します。

成果物： docs/PRODUCT.md の ## Activation & Retention Plan を拡張します（摩擦／タイミング | 改善策 | 担当者 | ステータス）。トラッカーを更新します。

完了条件： 最も不足しているリソースが特定され、Starter Step、達成を称える方法、きっかけの変更がそれぞれ担当者付きの行として記録され、1日目／7日目／30日目の離脱が、考えられる B=MAP の失敗要因に対応付けられ、ユーザーが改善策の一覧を承認していること。

フェーズ 3 — 継続的なディスカバリーを実施し、推測をやめる（continuous-discovery）

目的： 一般的なベストプラクティスに頼るのではなく、自社のユーザーについての確かな証拠を毎週集めます。

概要（フォールバック）： 週に少なくとも1回、顧客と接点を持つことを目指します。Opportunity Solution Tree を作成します。最上位に成果を置き、その下に顧客の機会（顧客自身の言葉で表したニーズや課題）、さらに候補となるソリューションや実験を並べます。成果からソリューションへ飛躍してはいけません。インタビューでは、「最後に……したときのことを教えてください」のように、体験を語ってもらい、内容を1ページのスナップショットに記録します。リスクが最も高い「信じて賭ける」前提を、まず低コストで検証します。

実行： リテンションの成果と、把握している離脱パターンを使って continuous-discovery スキルを実行します。Opportunity Solution Tree、離脱したユーザーが現在どのように目標達成を試みているかを示す現状の体験マップ、毎週のストーリーベースのインタビュー用スナップショットテンプレート、次に予定している機能の前提マップを求めます。

ユーザーと決めること：

• ツリー最上位に置く成果を1つ。
• 最初に取り組む機会を2つか3つ。
• チームが実際に継続できる週次の実施頻度と参加者の募集方法。今すぐ設定するか、実施内容を縮小します。
• 次の機能に関する「信じて賭ける」前提のうち、最もリスクが高いもの（望ましさ、実現可能性、実行可能性、使いやすさ）と、それを検証する最も低コストな方法。

成果物： docs/PRODUCT.md の ## Opportunity Solution Tree Notes、## Outcome Roadmap（成果／課題 | 対応するジョブ | 優先度 | ステータス）、## Discovery Cadence を拡張します。docs/CUSTOMER.md の ## Interview Evidence（日付 | 対象者 | 事実 | コミットメント）を拡張します。トラッカーを更新します。

完了条件： ツリーの成果と優先度の高い機会が記録され、実施頻度が予定に組み込まれ、最初のインタビュースナップショットテンプレートが用意され、最もリスクの高い前提を検証する低コストなテストが設計されていること。

フェーズ 4 — 議論を低コストの実験に置き換える（lean-ux）

目的： 機会を、会議ではなくユーザーの行動によって結論が出る、反証可能な仮説に変えます。

概要（代替案）： 成果を重視し、アウトプットではなく行動の変化を価値とします。仮説を「[ペルソナ] が [機能] で [アクション] を達成すれば、[成果] が実現すると考えます」という形式で記述し、テストの前に指標としきい値を確定します。リスクに応じた忠実度を選びます（5 人のユーザーを使った紙のプロトタイプで、ユーザビリティ上の問題のおよそ 85％を発見できます）。A/B テストは、実証済みのコンセプトを調整するときに限って実施します。仮説が否定されたら、先送りせずバックログから削除します。

実行： 現在もっとも議論になっているデザイン上の論点、または有望なディスカバリーの機会を対象に、lean-ux スキルを使います。標準形式の仮説を 3 つ、最有力の仮説を検証できる最低限の忠実度の実験、そして事前に確定する指標、しきい値、期間を提示するよう依頼します。

ユーザーとともに決めること：

• 最初に検証する仮説。
• 実験の忠実度 — 実際の問いに答えられる最低限の忠実度。
• 合格／不合格の基準と、不合格の場合にバックログから削除するもの。

成果物： docs/EXPERIMENTS.md の ## Experiment Cards（仮説、種類、主要指標＋しきい値、ガードレール、判断ルール）と ## Experiment Backlog（アイデア | ICE | ステータス）を拡充します。トラッカーを更新します。

完了条件： 少なくとも 1 つの実験カードに事前確定したしきい値と判断ルールがあり、バックログの優先順位が整理され、ユーザーが最初のテストを選んでいること。

フェーズ 5 — 権限を持つチームで、作るべきものを作る（inspired-product）

目的： チームを機能を量産する組織から、成果に責任を持つ組織へと移行させます。提供する機能ではなく、解決する問題に取り組みます。

概要（代替案）： 権限を持つチームにはバックログではなく解決すべき問題が与えられ、成果に責任を負います。デュアルトラックでは、ディスカバリー（価値、ユーザビリティ、実現可能性、事業性に取り組み、何を作る価値があるかを見極める）をデリバリーと並行して継続的に進めます。リリースする機能 1 つにつき、10〜20 回のディスカバリー反復が必要になると想定します。チームが自律的に判断できるよう、プロダクトビジョンと成果ベースのロードマップを提供します。

実行： 上位 3 件のバックログ要望と現在のロードマップを対象に、inspired-product スキルを使います。それぞれについて機会評価（目的、対象ユーザー、問題、成功指標、代替案）を行い、1 段落のビジョンと、四半期分の成果ベースのロードマップ項目を作成するよう依頼します。

ユーザーとともに決めること：

• どのバックログ要望にもっとも強い根拠があるか、そしてスプリントに入る前にどれを取り下げるか。
• 1 段落のプロダクトビジョン。
• ロードマップを、日付付きの機能ではなく、問題＋主要な成果に再構成するかどうか。

成果物： docs/PRODUCT.md の ## Vision と ## Outcome Roadmap（成果／問題 | 対応するジョブ | 優先度 | ステータス）を拡充します。トラッカーを更新します。

完了条件： ビジョンの段落があり、3 件すべての要望について作る／取り下げる判断が済み、ロードマップの各項目が機能ではなく成果になっていること。

フェーズ 6 — 本当に重要な 1 つの数値を測る（lean-analytics）

目的： チーム全体の意識を「最重要指標」に向け、衰退を覆い隠す見栄えだけの指標を明らかにします。

概要（フォールバック）： 良い指標とは、比較可能で、比率／率（累計ではない）であり、行動を変えるものです。重要な指標はビジネスモデルによって異なり、取り組む順序はステージによって決まります（共感 → 定着 → バイラル → 収益 → 拡大）。定着率が低い場合は定着ステージにあるため、最重要指標は定着率です。後のステージから先に取り組むのは、典型的な間違いです。目標、日付、未達時の対応を定めて一線を引き、最重要指標に対照指標を組み合わせ、コホート別にデータを分析します。

実行： 現在のダッシュボード／指標とビジネスモデルを使い、lean-analytics スキルを呼び出します。見栄えだけの指標にフラグを立て、定着ステージの最重要指標と対照指標を選び、1 画面のダッシュボード（最重要指標を大きく表示し、補助指標は最大 6 つ）と、コホート別の定着率ビューを設計するよう依頼します。

ユーザーと決めること：

• 最重要指標とその対照指標。
• 一線を引く基準 — 目標、日付、未達時に事前に決めておく対応。
• 現在の指標のうち、見栄えだけの指標として廃止するもの。

成果物： ## Stage & One Metric That Matters、## KPI Definitions、## Baselines & Targets、## Funnel、## Cohort Notes を含む docs/METRICS.md を作成します。トラッカーを更新します。

完了条件： METRICS.md に最重要指標と対照指標が記載され、一線を引く基準と日付が記録され、コホート別のベースラインが列挙され、見栄えだけの指標が廃止済みとして示され、1 画面のダッシュボードが仕様化され、Rule 8 の獲得ゲートに向けた定着率の基準が設定されていること。

フェーズ 7 — 生き生きとした印象を生むマイクロモーメントを磨く（microinteractions）

目的： ユーザーが毎日触れる瞬間に、我慢して使うアプリと、愛されるアプリとの隔たりを埋めます。

概要（フォールバック）： すべてのマイクロインタラクションは、トリガー → ルール → フィードバック → ループとモードで構成されます。フィードバックは即時（直接操作の場合は 100 ms 未満）で、操作に見合ったものにします。別のトーストを表示するよりも、ユーザーが触れた要素をアニメーションさせます。空、読み込み中、一部表示、エラー、無効、ダブルタップなど、すべての状態を洗い出します。削除テストに合格する特徴的な瞬間に 1 つか 2 つ投資し、長いループを使って熟練ユーザー向けのヒントを段階的に終了します。

実行： 最もよく使われる 5 つのインタラクションを対象に、microinteractions スキルを呼び出します。それぞれについてトリガー／ルール／フィードバック／ループの監査、100 ms 未満のフィードバックと不足しているエッジケース状態の確認、そして実際のコードで実装する特徴的な瞬間を 1 つ提案するよう依頼します。

ユーザーと決めること：

• 監査する 5 つのインタラクション。
• 特徴的な瞬間にするもの（削除テストを適用）。
• どのエッジケース状態から優先して実装するか。

成果物： docs/DESIGN.md の ## Microinteraction Inventory を拡張します（インタラクション | トリガー／ルール／フィードバック／ループ | 修正 | ステータス）。トラッカーを更新します。

完了条件： 5 つのインタラクションが、不足している状態と修正内容とともに一覧に記載され、特徴的な瞬間が選ばれ、それぞれの修正にステータスが付いていること。

フェーズ 8 — 内発的動機づけでエンゲージメントを維持する（drive-motivation）

目的： 搾取ではなく、自律性・熟達・目的意識に基づくエンゲージメントで、ループが悪循環に陥るのを防ぎます。

概要（フォールバック）： 認知的な努力が必要なタスクでは、「もし〜したら」という報酬が内発的動機づけを損ないます。エンゲージメントを長続きさせるのは、自律性（何を、いつ、どのように、誰と行うかを選べること）、熟達（目に見える進歩と、フローに合わせて調整された課題）、目的意識（なぜそれが重要なのか）です。自律性を損なう要因には、強制的なチュートリアル、スキップできない手順、必須の通知があります。報酬は意義のある節目のために取っておき、「もし〜したら」という取引よりも、「〜したので」という形の承認を優先します。

実行： アプリのゲーミフィケーション、連続記録、ポイント、通知のパターンを対象に、drive-motivation スキルを使用します。AMP 監査を 0〜10 で評価し、自律性を損なう箇所をすべて特定し、連続記録が損失回避に転じた時点を明らかにしたうえで、真の熟達と目的意識を軸に進行設計を見直すよう依頼します。

ユーザーと一緒に決めること：

• どの自律性を損なう要因（強制・スキップ不可の手順）を取り除くか。
• どの「もし〜したら」という報酬を「〜したので」という形の承認に変えるか。
• 連続記録やポイントの仕組みが損失回避を利用しており、変更が必要かどうか。

成果物： docs/PRODUCT.md の ## Activation & Retention Plan に AMP 監査の行（違反／所見 | 修正 | 担当者 | ステータス）を追加します。トラッカーを更新します。

完了条件： AMP スコアと自律性を損なう箇所がすべて記録され、報酬や連続記録の修正案に担当者が割り当てられ、ループがルール 8 の Manipulation Matrix に合格していること。

オプションのフェーズ

スキル	追加する条件	成果物
cold-start-problem	アプリがネットワーク型またはマーケットプレイス型の製品である場合	docs/PRODUCT.md を拡張
monetizing-innovation	エンゲージメントの高いユーザーが収益につながらない場合	docs/OFFER.md を拡張
contagious	ユーザーがアプリを気に入っているのに、話題にしない場合	docs/MARKETING.md を拡張
crossing-the-chasm	アーリーアダプターの境界で成長が停滞している場合	docs/STRATEGY.md を拡張
jobs-to-be-done	利用パターンから、アプリが別のジョブのために利用されていると分かる場合	docs/CUSTOMER.md を拡張

オプションのフェーズにも同じ運用ルールが適用されます。各フェーズを支えるものとして記載されたスキルを読み込み、使用し、追加条件が初めて満たされた時点で挿入します。獲得を重視するフェーズである cold-start-problem、contagious、crossing-the-chasm は、リテンションが基準を満たすまでルール 8 によってロックされたままにします。

よくある間違い

間違い	修正
リテンションを改善する前に成長を購入する	獲得に費用をかける前に Stickiness ゲート（コホート曲線が横ばいになること）を通過します。獲得フェーズはルール 8 に従ってロックしたままにします。
外部トリガーにいつまでも頼る	hooked-ux を使って内部トリガーへ移行します。通知は足場として扱い、支えとなる壁にはしません。
Ability-Chain の誤った要素を最適化する	improve-retention で 6 つの要素すべてを評価し、最も分かりやすいものではなく、最も不足しているリソースを改善します。
成果からすぐ解決策に飛びつく	まず continuous-discovery で Opportunity Solution Tree を構築します。明白に見える機能が、5 つの候補の中で最悪の場合もよくあります。
成果ではなくアウトプットを測る	リリースごとに計測を導入します。lean-ux と inspired-product では、成功とはリリースしたストーリーではなく、ユーザーの行動の変化です。
あらゆるものにポイントを付けてゲーミフィケーションする	報酬は意義のある節目のために取っておき、drive-motivation の AMP 監査を実施します。「もし〜したら」という報酬は、最も熱心なユーザーのモチベーションを損ないます。

ジャーニーを完了する

• PRODUCT.md に、最も弱いフェーズを改善したフックループ、アクティベーションのスターターステップ、更新され続けるオポチュニティソリューションツリー、AMP に準拠したエンゲージメント設計が記載されています。
• METRICS.md に、スティッキネス段階の OMTM と、限界線（目標、日付、未達時の対応）を伴うカウンターメトリックが記載されています。
• 少なくとも 1 つの lean-ux 実験が結論に至り、判定が記録されています。また、無効と判断されたアイデアはバックログから削除されています。
• インテーク時に設定したリテンションの基準を満たすか、残るギャップを定量化してから、獲得フェーズを実施します。

トラッカーを完了します。すべてのフェーズを done または skipped にし、次のアクションを PRODUCT.md、METRICS.md、EXPERIMENTS.md に反映します。その後、次のスキルに進みます。

• エンゲージメントの仕組みでは、UX の不備やパフォーマンスの問題によって足かせとなっているプロダクトを改善できない場合は、improve-app スキルに進みます。
• アプリの定着が進み、収益、チャネル、運用など、アプリを取り巻くビジネスも成長させる必要がある場合は、grow-business スキルに進みます。