inbound-plan-work

インバウンド計画の作成

選択した成長戦略、インバウンドブランチ、またはインバウンドキャンペーンの親課題から、子課題を一度に1階層ずつ計画します。

計画によって作成されるのは、未割り当てのbacklog構造です。作業を開始できる状態にはなりません。

参照資料

まず、以下をお読みください。

• references/CONTEXT.md
• references/docs/growth-operator/workflow.md
• references/docs/growth-operator/control-plane.md
• references/docs/growth-operator/afk-readiness.md
• references/docs/paperclip-operator/cli-contract.md
• references/docs/paperclip-operator/integration-matrix.md

プロセス

1. 対象となる成長戦略、インバウンドブランチ、またはインバウンドキャンペーンの親課題を特定します。

2. 課題、計画書、親子関係、プロジェクト、リンクされた目標、ブロッカー、コメントを確認します。

3. 計画する階層の深さを確認します。

4. 子課題を1階層分提案します。

5. 提案する各子課題を、以下のいずれか1つだけに分類します。

   • ready-looking
   • planning parent
   • needs-human
   • blocked
   • needs-info

   すべての提案する子課題に、分類が1つだけ付いている状態が完了条件です。

6. 不明確な子課題が3件以上ある場合は、課題を作成する前に一旦停止し、論点を絞って確認します。

7. 各課題の正確なタイトル、本文、ステータス、親課題、プロジェクト、ブロッカー、担当者を記載します。

8. 承認を求めます。

9. 承認後、依存関係の順に課題を作成し、各レコードを確認します。

Wiki のソース資料

親課題、計画書、コメント、またはオペレーターのプロンプトで Paperclip wiki の URL、wiki ページのパス、または取得済みの wiki ソースが参照されている場合は、インバウンドの子課題を提案する前にpaperclip-wiki-fetchを使用します。取得したソースのタイトル、パス、更新日時、ハッシュ、証拠となる抜粋のうち、オーディエンス、切り口、ストーリー、主張、または検証に関わるものを、提案する課題の本文またはSource material/proofに含めます。

認証情報、会社のスコープ、wiki ID、スペーススラッグ、またはページパスが不足していて wiki 参照を取得できない場合は、計画を一旦停止し、不足している情報を尋ねます。アクセスできない wiki 資料に依存する子課題は作成しないでください。

オペレーターからインバウンド計画の成果を wiki に公開、同期、または反映するよう明示的に依頼された場合は、まず提案する課題の内訳を完成させ、その後、承認を得てから wiki の変更にpaperclip-wiki-manageを使用します。

クリエイターのソーススペース

特定のクリエイター向けのコンテンツ投稿を計画する際、生のソース資料や整理済みのソース資料は、そのクリエイター専用のクリエイター wiki スペース（paperclip-source-captureで取得。例：spaceSlug: creator-jane）に保存されている場合があります。投稿課題を提案する際は、以下の手順で参照します。

• オペレーターは、クリエイターのspaceSlugを指定してpaperclip-wiki-fetchでスペースを直接読み込み（ページ／ソースの一覧を取得し、関連するwiki/...ページを読み込みます）、根拠となる切り口、ストーリー、証拠をSource material/proofに含めます。
• 作業を実行する下書き作成エージェント向けに、課題本文で会社のwiki-askスキルを参照し、クリエイターのspaceSlugを明記します。これにより、エージェントは下書き作成時に引用元の詳細情報や語り口を取得できます。
• 計画時にソース資料を匿名化しないでください。公開投稿の前に、下書き／公開の段階でクライアント名、運送会社名、個人を特定できる詳細を削除する必要があることをStop conditionsに記載します。

計画パターン

例：

• 年間インバウンド戦略 → 四半期戦略の親課題。
• 四半期インバウンド戦略 → 月次戦略の親課題。
• 月次インバウンド戦略 → チャネルキャンペーンの親課題。
• LinkedIn キャンペーン → ソース調査、切り口の提案、投稿の下書き、レビュー修正、シグナルの収集。
• ニュースレターキャンペーン → ソース調査、アウトライン、下書き、編集、配信準備、シグナルの収集。

広範な子課題は、実行準備が整った課題ではなく、計画用の親課題として作成します。

提案する内訳の形式

## Proposed Inbound Child Issues

### 1. <title>

- Type: ready-looking | planning parent | needs-human | blocked | needs-info
- Priority:
- Status to write: backlog
- Parent:
- Project:
- Linked goals:
- Blocked by:
- Assignee: null
- Readiness level: I0 strategy | I1 source-research | I2 asset-draft | I3 publishing-prep | I4 signal-capture
- Channel:
- Author/persona:
- Audience/ICP:
- Wedge or story:
- Source material/proof:
- Body:
- Acceptance criteria:
- Validation:
- Stop conditions:

作成ルール

• 計画したイシューは backlog として作成し、担当者を割り当てないでください。
• イシューを todo に移動しないでください。
• エージェントを割り当てないでください。
• 作業をチェックアウトしないでください。
• ハートビートを手動で実行しないでください。
• 外部アカウントへの投稿、予約、公開、変更を行わないでください。
• parentId／ネイティブの親リンクを使用し、作成後に検証してください。
• 具体的な依存関係には、利用可能な場合、第一級の blockedByIssueIds を使用してください。
• オペレーターが劣化モードを明示的に承認しない限り、計画ドキュメントやブロッカーリンクをコメントで置き換えないでください。

変更ルール

オペレーターが提案した内訳を承認するまで、子イシューを作成しないでください。