engagement-workflow

/digital-marketing-pro:engagement-workflow — 12部構成のエンゲージメントオーケストレーター

スクリプトの場所。 ホストが ${CLAUDE_PLUGIN_ROOT} を設定していない場合、スクリプトはこのプラグインの scripts/ フォルダー（skills/ と同じ場所）にあります。Python 3.10 以降で実行してください。python を使用し、見つからない場合（macOS、多くの Linux システム）は python3 を使用します。

このスキルは、12部構成の逐次的な方法論を用いて、マーケティングエンゲージメント全体をオーケストレーションします。ブランドとのエンゲージメントはすべて、同じ12部を順番に進み、各段階で標準ファイル一式を生成します。

コンテキスト効率

負荷の高いスキルです。参照ファイルは、Read する前に Grep し、一致した範囲だけを offset と limit で指定して Read してください。ファイルを開く前に、ブランドのワークスペース（~/.claude-marketing/brands/{slug}/、または環境変数が設定されている場合は $CLAUDE_PLUGIN_DATA/digital-marketing-pro/brands/{slug}/）を一覧表示してください。セッションの途中で再度呼び出された場合は、すでにコンテキストにあるファイルをスキップしてください。

出力を作成する前に、以下の参照資料を読んでください。

• engagement-flow-methodology.md — 12部構成の全体フロー
• two-views-model.md — v1 / v2 アーキテクチャ
• stone-vs-opinion.md — 確信度のタグ付け
• decision-matrix-rerun.md — 再実行する内容とタイミング
• update-back-rule.md — バージョン管理プロトコル
• living-instruction-file-spec.md — LIF スキーマ

動作モード

このスキルは /digital-marketing-pro:engagement コマンドファミリー経由で呼び出されます。このコマンドは薄いルーターです。エンゲージメントのライフサイクル、チェックポイントプロトコル、各部の成果物作成契約に関する 唯一の信頼できる情報源は、このスキルです。各サブコマンドは特定のライフサイクルアクションに対応します。このスキルは、以下を通じて永続化を行う engagement-state.py を呼び出します。

python "${CLAUDE_PLUGIN_ROOT}/scripts/engagement-state.py" <subcommand> ...

_engagement.json を手動で編集しないでください。必ず engagement-state.py を使用してください。

チェックポイントと再開（唯一の信頼できる情報源）

長時間のエンゲージメント実行はすべて再開できます。チェックポイントプロトコルは、実行を初期化 → 各部の完了時に保存 → 最終処理 → 可視出力フォルダーに公開です。これにより、実行が中断された場合（コンテキストの枯渇、ユーザーによるキャンセル、マシンのスリープ）に、Part 1からやり直すのではなく、次のチェックポイント未保存の部から再開できます。

1. start では、ブランドの事前条件を満たした後、チェックポイント実行を開始し、エンゲージメントの状態に関連付けます。

python "${CLAUDE_PLUGIN_ROOT}/scripts/checkpoint-manager.py" init \
    --brand "{brand_slug}" --workflow engagement --topic "{engagement_id}"

# Record the returned run_id into _engagement.json so resume can find it:
python "${CLAUDE_PLUGIN_ROOT}/scripts/engagement-state.py" set-checkpoint-run \
    --brand "{brand_slug}" --id "{engagement_id}" --run-id "{run_id}"

set-checkpoint-run は run_id を _engagement.json に保存し、再開時の関連付けを確立します（以前は run_id が永続化されていませんでした）。

2. 各部が完了して品質ゲートを通過した後、オーケストレーターはその部の出力を保存します。

python "${CLAUDE_PLUGIN_ROOT}/scripts/checkpoint-manager.py" save \
    --brand "{brand}" --run-id "{run_id}" \
    --step {part_number} --content-file "{path_to_that_part_deliverable}" --extension md

その部の実際の成果物パスを渡してください（例：Part 3ではFour Core Documentsのパス、Part 8ではGrowth Planのパスを保存します）。別の部の代替としてプレースホルダーを使うことは絶対に避けてください。

3. Part 5（Client Validation）とPart 8（Growth Plan）の成果物を保存する前に、完全な品質ゲートを実行します。

# BLOCKING gate — Part 5 and Part 8 deliverables cannot be checkpointed until this passes
/digital-marketing-pro:check "{path_to_deliverable}" --full --brand {brand}

/digital-marketing-pro:check --full が BLOCKED を返した場合は、その部をチェックポイントに保存する前に、CRITICAL の問題を修正してください。

4. 最終部の完了後、すべての成果物をユーザーから見えるフォルダーに公開し、最終処理を行います。

python "${CLAUDE_PLUGIN_ROOT}/scripts/output-publisher.py" publish-run \
    --brand "{brand}" --run-id "{run_id}"

python "${CLAUDE_PLUGIN_ROOT}/scripts/checkpoint-manager.py" finalize \
    --brand "{brand}" --run-id "{run_id}" --status completed

続いて、/digital-marketing-pro:output-folder {brand} を使って、ユーザーに可視出力フォルダーを案内してください。

中断された実行を再開するには、/digital-marketing-pro:resume を使用してください。保存済みの各部を再読み込みし、次のチェックポイント未保存の部から続行します。

状態の検証と再実行の上限

• 完了としてマークする前に、パートの出力をマニフェストと照合して検証します：

  python "${CLAUDE_PLUGIN_ROOT}/scripts/engagement-state.py" validate-part \
      --brand "{brand}" --id "{id}" --part {N}
  

  ディスク上の実際のファイルと PART_DEFINITIONS マニフェストを差分比較し、不足している成果物にフラグを付けます。file-tree 内および next の前に使用します。

• 部分的に初期化されたエンゲージメントディレクトリを修復します（空でないディレクトリでクラッシュする代わりに）：

  python "${CLAUDE_PLUGIN_ROOT}/scripts/engagement-state.py" init --repair \
      --brand "{brand}" --id "{id}"
  

  --repair を指定すると、部分的な状態のみを含むディレクトリに、標準のディレクトリツリーと状態ファイルを作成します。

• v2 の再実行上限： 明示的なユーザーの承認がない場合、パートごとに許可される v2 の再実行ラウンドは最大 2 回です。ラウンド数は _engagement.json に保存されます。パートが 2 ラウンドを超える場合は停止し、ユーザーに追加の再実行を明示的に承認するよう求めます（承認は状態に記録されます）。これにより、再実行が無制限に繰り返されるのを防ぎます。

サブコマンド

/digital-marketing-pro:engagement start <brand-slug> <engagement-id>

目的： 新しいエンゲージメントを初期化します。

手順：

1. ブランドプロフィールが ~/.claude-marketing/brands/{brand-slug}/profile.json に存在することを確認します。存在しない場合は、まず /digital-marketing-pro:brand-setup を実行するようユーザーに指示します。
2. python "${CLAUDE_PLUGIN_ROOT}/scripts/engagement-state.py" init --brand {brand-slug} --id {engagement-id} を実行します。
3. ディレクトリツリーが作成されたことを確認し、次に必要な作業（パート 1 のインテーク）を報告します。
4. 質問を一度に 1 バッチずつ行い、パート 1 の事実と意見のインテークをユーザーと進めます。

パート 1 のインテーク質問（次の順に尋ねます）：

事実 — クライアントが確実に把握していること：

1. 会社の基本情報：設立年、従業員数、本社所在地、事業展開地域
2. ビジネスモデル：収益源、料金プラン、主要な製品／サービスのカテゴリー
3. 現在のマーケティング：現在利用中のチャネル、月間マーケティング費用、現在測定可能な KPI
4. 技術スタック：CRM、メールサービスプロバイダー、分析環境、広告アカウント
5. 顧客基盤の規模：顧客数、最大の記名顧客、判明している場合は平均注文額

各事実について、次の情報を記録します：

• 事実そのもの
• 出典（ユーザーがどのように把握しているか／どの文書で確認したか）

それぞれ次のコマンドで保存します：

python "${CLAUDE_PLUGIN_ROOT}/scripts/engagement-state.py" add-stone-fact --brand {slug} --id {id} --fact-json '{"category":"...","fact":"...","source":"..."}'

意見 — クライアントが考えていること：

1. ブランドポジショニング：クライアントは市場における自社の立ち位置をどのように説明していますか？
2. 顧客基盤：クライアントは顧客をどのような人々と考えていますか？なぜ購入するのでしょうか？
3. 競合他社：クライアントは主な競合他社を誰だと考えていますか？
4. 成長機会：最大の機会はどこにあると考えていますか？
5. うまくいっていること：クライアントは、どのマーケティング活動がうまくいっていると考えていますか？
6. うまくいっていないこと：クライアントは、何がうまくいっていないと考えていますか？

各意見について、次の情報を記録します：

• 仮説
• その根拠としてクライアントが示す証拠（直感、逸話、部分的なデータなど）
• 調査上の問い — 偏りのない調査で検証または反証する必要があること

それぞれ次のコマンドで保存します：

python "${CLAUDE_PLUGIN_ROOT}/scripts/engagement-state.py" add-opinion --brand {slug} --id {id} --hypothesis-json '{"category":"...","hypothesis":"...","client_evidence":"...","research_question":"..."}'

パート 1 の完了時： mark-part-completed --part 1 でパート 1 を完了としてマークし、ユーザーにパート 2（外部調査）へ進むよう案内します。

/digital-marketing-pro:engagement next [brand] [id]

目的： 次のパートに進みます。

手順：

1. engagement-state.py status でエンゲージメントの状態を読み取ります
2. 現在のパートと、まだ完了していない次のパートを特定します
3. 現在のパートが実際に完了していることをユーザーに確認します（自動では進めず、質問します）
4. 確認後、現在のパートを完了としてマークし、current_part ポインターを進めます
5. 新しいパートで必要となる作業について、ユーザーに簡潔に説明します

/digital-marketing-pro:engagement status [brand] [id]

目的： エンゲージメントの状態を表示します。

手順：

1. engagement-state.py status を実行して、状態全体を取得します
2. Living Project Instruction File のヘッダーを読み取ります
3. 人が読みやすい形式で概要をまとめます：
   • エンゲージメント：ブランド＋ID＋開始日
   • 現在のパート：パート名＋経過日数
   • 完了済みのパート：一覧
   • 保留中のパート：一覧
   • 未解決の再実行判断：件数
   • LIF の最終更新日：日付
4. 解決が必要な未処理項目がエンゲージメントにある場合は、その一覧を表示します

/digital-marketing-pro:engagement file-tree [brand] [id]

目的： エンゲージメントディレクトリのファイルツリーを表示します。

手順：

1. engagement-state.py file-tree を実行します
2. インデント付きのツリー形式に整えます
3. 正規の構成に沿って不足しているファイルを強調表示します。engagement-state.py validate-part --part {N} を使用して、完了済みの各パートの実際のファイルと PART_DEFINITIONS マニフェストを比較します（たとえば、パート3が完了済みとされているのに 3.1-business-and-sbu-analysis.md がない場合、目視で確認する代わりに validate-part が不足を確実に検出します）。

/digital-marketing-pro:engagement validate [brand] [id]

目的： パート5のクライアント検証フローを実行します。

前提条件： パート2、3、4が完了している必要があります。

手順：

1. 前提条件（パート2、3、4が完了していること）を確認します
2. client-validation-document スキルを呼び出します。これにより、v1の各調査結果について ACCEPT／REJECT／EDIT／DEFER の選択肢を提示する、構成済みのドキュメントがパート5の成果物として作成されます
3. パート5の成果物をクライアントに送る前に、完全な品質ゲートを実行します： /digital-marketing-pro:check "{part5_path}" --full --brand {brand}。BLOCKED が返された場合は、まず CRITICAL の問題を修正します（このゲートは、パート5とパート8の成果物に必須です）。
4. ユーザーが確認して決定を提示した後、その内容を Decision Matrix のカテゴリに従ってトリガーリストに変換します
5. engagement-state.py decision-matrix --triggers "{comma-separated}" を実行して、v2 の再実行計画を算出します
6. 再実行計画をユーザーに提示します
7. パート5を完了済みとしてマークします。ユーザーが再実行計画を承認したら、パート6に進みます

/digital-marketing-pro:engagement re-run-decision [brand] [id]

目的： Decision Matrix を適用して、v2 の再実行を算出します。

手順：

1. パート5のクライアント検証ドキュメントを読みます
2. 拒否または編集された調査結果を Decision Matrix のトリガーに分類します
3. トリガーと算出された再実行項目を表示します
4. 各再実行のコスト（概算トークン数）を見積もります
5. ユーザーの承認を待ちます。ユーザーは承認、変更（一部をスキップまたは追加）、拒否のいずれかを選べます
6. engagement-state.py record-rerun-execution を使用して、実行した計画を記録します

/digital-marketing-pro:engagement update-back [brand] [id] --doc <doc-id> --reason <reason>

目的： Update-Back Rule を適用して、パート7以降にソースドキュメントのバージョンを更新します。

前提条件： ユーザーが修正版ドキュメントの内容をすでに作成している必要があります。

手順：

1. ドキュメントの現在のバージョンを読みます
2. ユーザーに修正内容を確認します（Update-Back Rule に基づく検証ステップ）
3. engagement-state.py bump-version --doc {id} --reason "{reason}" を使用してバージョンを更新します
4. v(prev) → v(new) の変更を記したヘッダーを付けて、新しいバージョンのファイルを保存します
5. lif-log-change を使用して Living Project Instruction File を更新します。変更内容が living-instruction-file.md に追記され、ヘッダーの日付が更新されるため、LIF に修正内容がすぐに反映されます
6. レビューが必要になる可能性のある下流ドキュメントを特定し、エンゲージメントのレビューキューに追加します

/digital-marketing-pro:engagement lif-show [brand] [id]

目的： Living Project Instruction File を表示します。

手順： engagement-state.py lif-show を実行し、Markdown の出力を読みやすく整えます。

/digital-marketing-pro:engagement list-engagements [brand]

目的： すべてのエンゲージメントを一覧表示します（ブランドでの絞り込みも可能です）。

手順： engagement-state.py list-engagements --brand {slug} を実行し、表形式に整えます。

制作のショートカット

コマンドファミリーには、パートを制作するスキル（以下の パートごとの制作ターゲット に記載）に直接振り分ける、本番用のショートカットが4つ用意されています。これらはコマンドの構成と1対1で対応しています。

• /digital-marketing-pro:engagement four-core <brand> <id> [--doc 3.X] [--view v2] [--combined] — パート3。four-core-documents スキルを呼び出します
• /digital-marketing-pro:engagement growth-plan <brand> <id> — パート8。growth-plan スキルを呼び出します
• /digital-marketing-pro:engagement yearly-planner <brand> <id> — パート8の関連項目。yearly-planner スキルを呼び出します
• /digital-marketing-pro:engagement loop <brand> <id> — パート12。continuous-improvement-loop スキルを呼び出します

パートごとの制作ターゲット

各パートは、実在するエージェントとスキルによって制作されます。このオーケストレーターは以下のターゲットに振り分けます。external-research／preparation-documents／channel-strategy-fanout／execution-artefacts／ai-creative-instructions というラッパースキルは存在せず、これらが存在したこともありません。ここに記載された正確なターゲットを使用してください。

パート	実際のターゲット
1	（このスキル — ここで直接インテークを実施）
2	エージェント market-intelligence ＋ competitive-intel、スキル audience-intelligence（スキルとして呼び出す）、リファレンス compliance-rules.md（コンテキストとして読み込む）
3	スキル four-core-documents（3.1、3.2、3.3、3.4を制作）
4	コマンド competitor-analysis ＋ スキル audience-intelligence ＋ エージェント market-intelligence
5	スキル client-validation-document
6	再実行では、four-core-documents スキルを --view v2 で呼び出します
7	スキル content-engine ＋ campaign-orchestrator ＋ analytics-insights
8	スキル growth-plan ＋ yearly-planner
9	チャネル別スキル — paid-advertising、aeo-geo、social-strategy、seo-plan、email-sequence（各チャネルファミリーにつき1つ）
10	スキル content-engine（実行／出力モード）
11	スキル content-engine ＋ ad-creative ＋ video-script（クリエイティブブリーフ）。アセットのレンダリングは、独自のクリエイティブツール（デザインチーム、AI 画像／動画ツール、または接続済みのデザインプラットフォーム）で行い、その後、完成したアセットに c2pa-metadata で署名します
12	スキル continuous-improvement-loop

並列ディスパッチ

エンゲージメントのいくつかのパートには、独立したサブタスクが含まれており、逐次ではなく、1つのメッセージ内で複数の Task ツール呼び出しを使って並列にディスパッチする必要があります。独立したサブタスクを同時にディスパッチすると、順番に実行するより大幅に速くなります。実際の所要時間は、エンゲージメントの深さ、モデル、レート制限によって異なります。同時に実行するサブエージェントは、少数（およそ3～8）に抑えてください。それ以上では API のレート制限によって待ち行列が発生し、効果が薄れます。3未満では、並列化できる作業がありません。

**コストに関する注意：**トークンの総使用量は概ね同じです（同じ作業を行うため）が、並列の各サブエージェントがコンテキストを再読み込みするため、ターンごとの入力コストはやや増える傾向があります。

並列ディスパッチの効果があるパート：

パート	並列化可能な作業	ディスパッチ方法
パート2 — 外部調査	市場規模、競合環境、顧客の動向、規制環境は互いに依存しません	market-intelligence エージェントと competitive-intel エージェントを、並列の Task 呼び出しとしてディスパッチします。audience-intelligence はスキルとして呼び出し、compliance-rules.md（参照ファイル）はサブエージェントではなくコンテキストとして読み込みます
パート4 — 競合・顧客・市場	4つのドキュメント（4.1、4.2、4.3、4.4）は独立しており、パート2のみを参照します	それぞれに対応する4つのサブエージェントを、1つのメッセージ内でディスパッチします
パート9 — チャネル戦略のファンアウト	最大17のチャネルドキュメントが7つのファミリーに分かれています。ファミリー1（検索・キャンペーン）と6（Web・測定）が完了すれば、ファミリー2（有料プラットフォーム）、3（オーガニック・インフルエンサー）、4（マーケットプレイス・CRM）、5（コンテンツ・ATL・BTL・PR）は独立して作業できます	順序：F1 →（F2 ∥ F3 ∥ F4 ∥ F5を並列実行）→ F6 → F7。中央のバッチでは、1つのメッセージ内で Task を4つ並列に呼び出します。
パート10 — 実行アセット	チャネルごとの広告コピー、投稿コピー、見出し、CTAは互いに独立しています	チャネルごとにサブエージェントを1つずつ、並列にディスパッチします
パート11 — AI クリエイティブ指示	ビジュアルアセットのブリーフは、アセットごとに独立しています	アセットごとに並列にディスパッチします

順次実行を維持しなければならないパート（ハードなデータ依存関係があります）：

• パート1 → パート2（インテーク情報が調査範囲に反映されます）
• パート3 → パート4（4つのコアドキュメントが競合・顧客・市場分析の基礎になります）
• パート5 → パート6（クライアント検証によって、どのドキュメントを v2 で再実行するかが決まります）
• パート7 → パート8（準備ドキュメントが成長計画の基礎になります）
• パート8 → パート9（成長計画に基づいてチャネルへファンアウトします）

横断的なルール：

1. 複数の並列エージェントに、同じファイルを同時に書き込ませてはいけません。出力ファイルごとに作業を分けてください。
2. 各並列サブエージェントには、共有コンテキストを読み込めるよう、エンゲージメントのスラッグと LIF パスを渡します。ただし、書き込み先はそれぞれの番号付きパート別サブディレクトリ（01-… 12-…）のみにしてください。
3. **サブエージェントがエンゲージメントの状態を変更することはありません。**サブエージェントは lif-log-change、mark-part-completed、bump-version、その他の engagement-state.py 書き込み処理を呼び出してはならず、_engagement.json や living-instruction-file.md に触れてもいけません。これらはロックされていない読み取り・変更・書き込みファイルであり、複数の書き込みが並行すると更新が失われます。各サブエージェントは、パート別ファイルのみを出力として返します。並列バッチの完了後は、オーケストレーターだけが状態を変更します。バッチごとに lif-log-change を1回実行し、必要に応じて mark-part-completed / bump-version を実行してから、次のステップに進む前に LIF を再読み込みします。
4. 並列バッチが途中で失敗しても、失敗したサブエージェントの出力は自動的にロールバックされません。失敗したサブエージェントのみを再ディスパッチしてください。成功したサブエージェントの出力は有効なままです。

12パートのフロー以外の多次元コマンド（例：/digital-marketing-pro:competitor-analysis、/digital-marketing-pro:seo-audit、/digital-marketing-pro:content-engine）にも、同じパターンが適用されます。独立した各次元を、1つのメッセージ内で複数の Task 呼び出しを使って並列にディスパッチしてください。

1つの会話でエンゲージメントを進める

大規模コンテキストモデルは、インテーク、外部調査、4つのコアドキュメント（61ステップ）、競合・顧客・市場分析、クライアント検証、選択的な v2 再実行、準備ドキュメント、成長計画＋年間プランナー、チャネルへの展開、実行成果物、クリエイティブブリーフ、継続的改善ループなど、エンゲージメントの大部分を1回の作業セッション内で扱えます（エンゲージメント全体では、通常50～60件の正規ドキュメントが作成されます）。

チェックポイント＋永続化のパターンは、常にデフォルトです。 すべてが1つの会話に収まる場合でも、次の点に注意してください。

• engagement-state.py と checkpoint-manager.py は引き続き信頼できる唯一の記録元です。監査証跡、会話をまたいだ再開、複数ユーザー・複数日にわたる継続性は、すべて永続化された状態に依存します。
• 「すべてコンテキスト内にある」という前提で、LIF の更新や状態の書き込みを省略しないでください。中断が発生すれば、メモリ上の作業は失われます。また、エンゲージメントを引き継ぐチームメイトが読むのは永続化された状態であり、あなたの会話ではありません。
• 1つの会話で進める利点は、すでにコンテキスト内にあるファイルをセッション中に読み直す回数が減ることだけです。永続化、チェックポイントの作成、LIF の更新が不要になるわけではありません。

品質管理

1. _engagement.json を手動で編集しないでください。 必ず engagement-state.py を使用してください。
2. v1 を削除しないでください。 v2 を作成した場合も、両方を残してください。
3. ソースドキュメントが変更されたら、必ず LIF を更新してください。 lif-log-change を使用してください。これは living-instruction-file.md の変更履歴セクションに変更を追記し、ヘッダーの日付を更新するため、LIF が古くならないようにできます。
4. すべての事実に出典を必ず明記してください。 確定事実には検証ソースを、意見に基づく仮説にはクライアントの根拠を引用してください。
5. パートを自動で先に進めないでください。 パートの完了はユーザーが明示的に確認します。
6. 独立した作業は必ず並列化してください。 パートに独立したサブタスクが2つ以上ある場合（上記の並列ディスパッチを参照）、複数の Task 呼び出しを1つのメッセージでディスパッチしてください。独立した作業を順番にディスパッチすると、実時間と API の呼び出し回数を無駄にします。
7. ユーザーの承認なしに v2 の再実行を自動で実施しないでください。 計画を提示し、承認を得てから実行してください。ユーザーが明示的に上書きしない限り、状態に記録された各パートの v2 再実行は最大2ラウンドまでです。

例

例：新しいエンゲージメントを開始する

User: I want to start a new engagement for Acme Corp this quarter.

Skill response:
1. Verify Acme has a brand profile (slug: acme-corp). Found.
2. Initialise engagement: engagement-state.py init --brand acme-corp --id 2026-q2
3. Engagement directory created at ~/.claude-marketing/brands/acme-corp/engagements/2026-q2/
4. Walk Part 1 intake. Begin with Stone questions:
   "Let's start with what we know for certain. What year was Acme founded? Where is it headquartered? How many employees today?"
5. (User answers; each fact captured via add-stone-fact)
6. Move to Opinion questions:
   "Now let's capture what you believe but haven't formally validated. How would you describe Acme's positioning in the market today?"
7. (User answers; each hypothesis captured via add-opinion)
8. Mark Part 1 completed. Advise: "Part 1 is complete. The unbiased External Research (Part 2) is next — recommend running it now or scheduling it for the next session."

例：エンゲージメント途中の状況を確認する

User: Where are we on the Beta Industries engagement?

Skill response:
- Reads engagement-state.py status --brand beta-industries --id 2026-h1
- Shows:
  Engagement: beta-industries / 2026-h1
  Started: 2026-04-01 (32 days in)
  Current part: Part 9 — Channel Strategy Fan-out (in progress)
  Completed parts: 1, 2, 3, 4, 5, 6, 7, 8
  Pending parts: 9 (in progress), 10, 11, 12
  Open re-run decisions: 1 (Part 6 v2 re-runs in progress)
  Open items requiring resolution: 2 (LinkedIn Ads CPL forecast pending; Q3 budget envelope pending)
  LIF last updated: 2 days ago
  Next required action: complete remaining Part 9 channel docs (5 of 9 complete)

例：意思決定マトリックスを適用する

User: We just finished Part 5 client validation. The client rejected our positioning recommendation and added two new competitors. What re-runs do we need?

Skill response:
1. Categorise the changes:
   - Two new competitors → trigger "competitors_changed"
   - Positioning rejected → trigger "positioning_changed"
2. Run engagement-state.py decision-matrix --triggers "competitors_changed,positioning_changed"
3. Output the triggered re-runs:
   Triggered re-runs: 3.1, 3.2, 3.3, 3.4, 4.1, 4.2
   (competitors_changed triggers all four Core Docs + 4.1 + 4.2; positioning_changed adds 3.3 which is already in scope)
4. Estimate token cost: ~85K tokens for the full re-run set
5. Ask: "Approve all? Modify? Skip any?"
6. On user approval, mark Part 6 started and invoke four-core-documents skill with view=v2 for each triggered doc

例：進行中の Update-Back 修正

User: We've been live for two months. Q1 channel data shows our actual CAC for Segment X is INR 4,800 — but Core Doc 3.1 v2.0 had it estimated at INR 3,000. Need to update.

Skill response:
1. Validate the correction: 60+ days of data, statistically meaningful sample. ✓
2. Read current 3.1 v2.0
3. Bump version: engagement-state.py bump-version --doc 3.1 --reason "Segment X CAC corrected from INR 3,000 to INR 4,800 based on Q1 channel data"
4. Save 3.1 v2.1 with header note: "v2.0 → v2.1 changes: Section 4 (Unit Economics) — Segment X CAC corrected. LTV:CAC drops from 4.0 to 2.5; below 3.0 health threshold."
5. lif-log-change --section "Recent Corrections" --summary "Segment X CAC corrected to INR 4,800. Channel mix for Segment X under review."
6. Identify downstream review needed: Core Doc 3.4 (DMFlow) channel allocation for Segment X may need revision
7. Add to engagement review queue

関連スキル

• four-core-documents — パート3の成果物を作成します
• client-validation-document — パート5の成果物を作成します
• growth-plan + yearly-planner — パート8の成果物を作成します
• continuous-improvement-loop — パート12を担当します

関連リファレンス

• engagement-flow-methodology.md
• four-core-documents-spec.md
• decision-matrix-rerun.md
• update-back-rule.md
• living-instruction-file-spec.md
• stone-vs-opinion.md
• two-views-model.md