growth-record-strategy

Growth Record Strategy

承認済みの成長戦略を Paperclip に記録します。オペレーターがより大きな具体的提案を承認しない限り、次に不足しているレイヤーのみを作成または更新してください。

References

まず、以下を読みます。

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

Process

1. 承認済みの Growth Clarification Summary、またはそれに相当するオペレーター承認済みの戦略があることを確認します。
   • オペレーターが明示的に確認プロセスを中止し、戦略の記録を依頼した場合は、解決済みの回答から簡潔な Growth Clarification Summary をまず作成します。
   • オペレーターがその要約を承認した場合、またはスレッド内ですでに同等の方針を承認している場合は、承認済みの同等戦略として扱います。
2. 現在の Paperclip の目標、プロジェクト、候補となる親課題、計画文書、関連コメントを調べます。
3. 不足している、または改訂対象となっているレイヤーを判断します。
   • 長期的な獲得に関する会社目標
   • インバウンドまたはアウトバウンドのチーム目標
   • 専門性、業種、チャネル、または施策に関するチーム目標
   • 長期的なチャネルまたは施策のプロジェクト
   • 年間戦略の親課題
   • 四半期戦略の親課題
   • 月次戦略の親課題
   • インバウンドの分岐親課題
   • アウトバウンドの分岐親課題
   • キャンペーンまたは実験の親課題
   • 既存の親課題に関する計画文書
4. 変更内容の具体的な提案を作成します。
5. Paperclip を変更する前に承認を求めます。
   • オペレーターが具体的な一括提案を承認した場合に限り、より大きな提案に複数のレイヤーを含めることができます。
6. 承認された変更のみを適用します。
   • レコードは依存関係の順に作成し、依存する書き込みの前にそれぞれを確認します。
7. 作成または更新したレコードを読み戻し、識別子を報告します。
8. 記録時に作成した戦略の親課題について、計画用レコードの状態が保たれていることを確認します。
   • status は backlog
   • assigneeAgentId と assigneeUserId は null
   • 別途承認されない限り、子分岐の計画は保留する
   • record-strategy 中に課題を todo に移動しない

Wiki Source Material

承認済みの成長に関する確認要約またはオペレーターのプロンプトが Paperclip の wiki URL、wiki ページパス、または取得済みの wiki ソースを参照している場合、戦略、分岐、キャンペーン、または実験の計画文書を作成する前に paperclip-wiki-fetch を使用します。取得できた場合は、取得したページのタイトル、パス、更新時刻、ハッシュを Shared Proof And Source Material に記録し、Markdown の本文を承認済みの入力として使用します。

wiki の認証情報、会社のスコープ、wiki ID、スペースのスラッグ、またはページパスが不足しており、Paperclip のコンテキストから推測できない場合は、取得していない wiki 参照から計画を作成せず、不足している情報を尋ねます。

オペレーターが作成した成長戦略の成果物を wiki に公開または同期するよう明示的に依頼した場合は、まず Paperclip の計画チェーンの提案を完了し、その後 paperclip-wiki-manage を使用して wiki を変更します。デフォルトの信頼できる情報源として、計画文書を wiki に置き換えないでください。

エンティティの指針

目標は、安定した獲得方針を示すために使用します。目標の変更を提案する場合は、必ず title、level、status、子目標の場合は parentId を指定してください。ownerAgentId は、実際にエージェントが所有する目標に限り指定します。

[company] Build repeatable acquisition
|-- [team] Build inbound trust engine through <person>'s personal brand
|   `-- [team] Establish <person>'s <domain> expertise brand
`-- [team] Build outbound engine for operator walkthroughs and validation
    `-- [team] Build repeatable <vertical/persona> outreach motion

目標のデフォルトの割り当て：

• company は、たとえば Build repeatable acquisition のような、全社の獲得における最終目標に使用します。
• team は、継続的なインバウンド、アウトバウンド、専門性、業種、チャネル、検証、または施策の成果に使用します。
• agent は、特定の Paperclip エージェントに所有権を割り当てる場合に限り使用し、ownerAgentId を設定します。
• task は原則として使用しません。キャンペーン、月ごとの取り組み、リードリスト、シーケンス、コンテンツスプリント、実行可能な作業には、親課題または子課題を優先してください。

継続的なチャネルや施策には、プロジェクトを使用します。

• Inbound: Ihor LinkedIn
• Inbound: Ihor Newsletter
• Outbound: Operator walkthroughs
• Outbound: Partnerships and warm intros

戦略期間、分岐、キャンペーン、実験には、親課題と計画ドキュメントを使用します。

Growth 2026
`-- Growth strategy Q3 2026
    `-- June inbound logistics strategy
        `-- LinkedIn campaign: logistics workflow pain

Outbound growth 2026
`-- Outbound strategy Q3 2026
    `-- June construction walkthrough strategy
        `-- Campaign: estimate-to-invoice walkthroughs

毎月の取り組み、短期キャンペーン、メッセージシーケンス、リードリスト、コンテンツスプリント、学習成果物ごとに新しい目標を作成しないでください。

戦略計画ドキュメント

推奨する計画の構成：

## Outcome

## Goal Structure

## Projects

## Time Horizon

## Market / Vertical

## ICP / Buyer / Persona

## Wedge Or Painful Workflow

## Inbound Role

## Outbound Role

## Shared Proof And Source Material

## Artifact Ask

## Offer / CTA

## Scope

## Non-Goals

## Success Signals

## Constraints

## Risks

## Validation

## Stop Conditions

## Branch Planning Notes

既存の戦略計画を改訂する場合は、承認後に既存の計画ドキュメントを更新し、変更理由を要約したコメントを追加してください。新しい課題を作成するのは、明確に区別できる戦略上の対象、分岐、キャンペーン、実験、または実行可能な作業項目に限ります。

操作面のルール

integration-matrix.md の CLI 優先の段階的な方法を使用してください。ネイティブフィールドに対応し、その内容を検証できる場合は CLI を使用し、CLI では不十分な場合は専用の MCP ツールを使用します。専用ツールがない場合は paperclipApiRequest を使用し、CLI と MCP の両方が利用できないか動作しない場合に限り、REST を直接使用してください。

最初の MCP API リクエストまたは REST による直接の変更を行う前に、paperclipai context show --json から API のベース URL と会社を取得し、paperclipai auth whoami --json で認証を確認してください。ベアラートークンは決して出力しないでください。ネイティブフィールドに書き込めない場合は、戦略成果物の内容を暗黙に損なうのではなく、作業を中止してオペレーターに確認してください。

REST に直接書き込む前に：

• paperclipai context show --json を実行します。
• paperclipai auth whoami --json を実行します。
• 可能であれば、安全な GET でルートを確認します。
• ベアラートークンは決して出力しないでください。
• 依存関係は一つずつ書き込みます。
• 続行する前に、ネイティブフィールドの値を読み戻して確認します。

変更のルール

Paperclip を作成または更新する前に、level、status、parentId、ownerAgentId を含む、提案する目標の正確な内容に加えて、プロジェクト、課題、計画本文、コメント、ステータスの変更を必ず提示してください。