growth-record-strategy

增长策略记录

将获批的增长策略记录到 Paperclip。除非操作员批准了更大范围的精确方案，否则仅创建或更新下一个缺失层级。

参考资料

请先阅读以下内容：

• 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

流程

1. 确认存在已获批的《增长澄清摘要》或同等的、经操作员批准的策略。
   • 如果操作员明确要求停止澄清并记录策略，请先根据已明确的答案编写一份简洁的《增长澄清摘要》。
   • 如果操作员批准了该摘要，或已在当前对话中批准了等效方向，则将其视为已获批的等效策略。
2. 检查当前的 Paperclip 目标、项目、候选父级议题、计划文档和相关评论。
3. 判断缺失或需要修订的层级：
   • 长期获客公司目标
   • 入站或出站团队目标
   • 专业领域、垂直行业、渠道或运营方式团队目标
   • 长期渠道或运营方式项目
   • 年度策略父级议题
   • 季度策略父级议题
   • 月度策略父级议题
   • 入站分支父级议题
   • 出站分支父级议题
   • 营销活动或实验父级议题
   • 现有父级议题上的计划文档
4. 起草拟议变更的准确内容。
5. 在修改 Paperclip 前征求批准。
   • 仅当操作员批准了确切的组合方案时，较大范围的提案才可包含多个层级。
6. 仅应用已获批的变更。
   • 按依赖顺序创建记录，并在写入依赖项之前逐一验证。
7. 回读已创建或更新的记录，并报告标识符。
8. 对于记录策略过程中创建的策略父级议题，确认其仍为规划记录：
   • status 为 backlog
   • assigneeAgentId 和 assigneeUserId 均为 null
   • 除非另行获批，否则推迟子分支规划
   • 执行 record-strategy 时，不得将任何议题移至 todo

Wiki 源材料

如果获批的增长澄清摘要或操作员提示中引用了 Paperclip wiki URL、wiki 页面路径或已捕获的 wiki 源材料，请在起草策略、分支、营销活动或实验计划文档之前使用 paperclip-wiki-fetch。如果可用，请在 Shared Proof And Source Material 中记录获取页面的标题、路径、更新时间和哈希值，然后将 Markdown 正文作为已获批的输入。

如果缺少 wiki 凭据、公司范围、wiki id、空间 slug 或页面路径，且无法从 Paperclip 上下文中推断，请停止并询问缺失的信息，而不是根据尚未获取的 wiki 引用起草内容。

如果操作员明确要求将最终增长策略文档发布或同步到 wiki，请先完成 Paperclip 规划链提案，然后使用 paperclip-wiki-manage 执行 wiki 修改。默认情况下，不得以 wiki 替代计划文档作为事实来源。

实体指导

使用目标表示稳定的获客方向。每次拟议的目标变更都必须指定 title、level、status；如果是子目标，还必须指定 parentId；只有由真实 Agent 拥有的目标才指定 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 用于持久的入站、出站、专业领域、垂直行业、渠道、验证或推广方式成果。
• 仅在将所有权分配给特定 Paperclip Agent 时使用 agent；并设置 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 基础地址和公司信息，使用 paperclipai auth whoami --json 验证身份验证，且绝不打印 bearer token。如果无法写入原生字段，请停止并询问操作人员，而不是悄悄降低策略文档的要求。

在直接写入 REST 之前：

• 运行 paperclipai context show --json。
• 运行 paperclipai auth whoami --json。
• 尽可能通过安全的 GET 请求确认路由。
• 绝不打印 bearer token。
• 一次只写入一个依赖项。
• 继续操作前，读取并核对原生字段。

变更规则

在创建或更新 Paperclip 之前，始终展示拟议内容的确切版本：目标（包括 level、status、parentId 和 ownerAgentId），以及项目、议题、计划正文、评论和状态变更。