Back to Details

initiative-brief

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Initiative Brief

倡议简报

Turn a rough roadmap idea into a sharp initiative brief, then create the initiative in One Horizon.
将粗略的路线图想法转化为清晰的倡议简报，之后在One Horizon中创建对应倡议。

Core rule

核心规则

  • Understand the problem before proposing solutions.
  • Produce a design doc, not code.
  • Write the brief in markdown. Use tables and Mermaid diagrams when they make the design clearer.
  • Stay focused on what the initiative should do from a product perspective, not how a developer should implement it.
  • Default to feature-level scoping unless the user clearly describes a broader product or company initiative.
  • Treat business goals as supporting context, not the backbone of the brief.
  • 提出解决方案前先充分理解问题。
  • 产出设计文档，而非代码。
  • 使用markdown撰写简报，当表格和Mermaid图能提升设计清晰度时可以使用。
  • 聚焦于从产品视角明确倡议要实现的目标，而非指导开发人员如何实现。
  • 默认按功能级别界定范围，除非用户明确说明是更宽泛的产品或公司级倡议。
  • 业务目标仅作为辅助背景，不作为简报的核心框架。

Use when

适用场景

  • The user is shaping roadmap-first planned work.
  • The initiative is still fuzzy and needs better background, user story, scope, non-goals, risk, or rollout clarity.
  • The user needs a brief others can review, align on, and execute from.
  • 用户正在制定以路线图为优先的规划工作。
  • 倡议还比较模糊，需要完善背景、用户故事、范围、非目标、风险或上线细节。
  • 用户需要一份可供其他人评审、对齐和执行的简报。

Do not use when

不适用场景

  • The user already has a complete initiative brief and just wants the record created.
  • The request is really a bug, ongoing work, or a small personal task.
  • The user wants an initiative status update rather than a new brief.
  • 用户已经有完整的倡议简报，仅需要创建记录。
  • 需求本质是漏洞修复、进行中的工作或小型个人任务。
  • 用户想要获取倡议状态更新，而非撰写新的简报。

Relationship to other skills

与其他技能的关联

  • Use 
    initiative-brief
    to diagnose, shape, and draft new roadmap work.
  • Use 
    create-task
    only when the initiative is already clear enough to create directly.
  • Use 
    task-management
    for operational task lookup, assignment, tagging, or direct creation outside this drafting flow.
  • Use 
    initiative-summary
    for reporting on existing initiatives, not writing new ones.
  • 使用
    initiative-brief
    来调研、梳理和草拟新的路线图工作。
  • 仅当倡议已经足够明确，可以直接创建时才使用
    create-task
    。
  • 运营类任务的查询、分配、打标签或在本草拟流程外直接创建任务的场景，使用
    task-management
    。
  • initiative-summary
    用于汇报现有倡议的情况，不用于撰写新倡议。

Initiative metadata rules

倡议元数据规则

  • Pull taxonomy before creation when product, customer, company, release, goal, or component signals are present.
  • Apply taxonomy labels when they are clearly present in the discussion and improve routing or reporting.
  • Prefer product labels first when the initiative obviously belongs to a product or product area.
  • Also apply other relevant taxonomy such as goals, releases, components, and company/customer labels when the workspace supports them and the match is clear.
  • Use 
    list-taxonomy
    only after the core scope is stable enough to know what should be tagged.
  • Attach labels only for exact or high-confidence matches.
  • If multiple labels are plausible for the same concept, ask a disambiguation question instead of guessing.
  • If this initiative clearly belongs under an existing roadmap effort, set 
    parentInitiativeId
    .
  • Do not guess taxonomy or parentage from weak signals. Resolve them first.
  • Keep owner and parent linkage in structured initiative metadata. Do not add 
    Owner:
    or 
    Related initiative:
    lines to the markdown brief unless the user explicitly wants them in the document.
  • If related initiatives, bugs, or other work items are mentioned in the brief or surfaced during discovery, reference them as URLs or markdown links, not plain text labels.
  • 当存在产品、客户、公司、发布、目标或组件相关信号时，创建前先拉取分类体系。
  • 当讨论中明确出现分类标签，且能提升流转或汇报效率时，添加对应分类标签。
  • 当倡议明确属于某款产品或产品领域时，优先添加产品标签。
  • 当工作区支持且匹配度明确时，也可以添加其他相关分类标签，比如目标、发布、组件、公司/客户标签。
  • 仅当核心范围足够稳定，明确需要打什么标签时，再使用
    list-taxonomy
    。
  • 仅为完全匹配或高置信度匹配的内容添加标签。
  • 如果同一个概念存在多个可能的标签，要提出歧义问题确认，不要猜测。
  • 如果该倡议明确属于现有路线图工作的子项，设置
    parentInitiativeId
    。
  • 不要通过弱信号猜测分类或所属父项，先确认清楚。
  • 负责人和父项关联信息保留在结构化的倡议元数据中，不要在markdown简报里添加「负责人:」或「相关倡议:」这类内容，除非用户明确要求放在文档里。
  • 如果简报中或调研过程中提到了相关倡议、漏洞或其他工作项，用URL或markdown链接引用，不要用纯文本标签。

Conversation rules

对话规则

  • Ask one question at a time and stop after each question.
  • Reuse what the user already said. Skip answered questions.
  • If the user says "just do it", shows impatience, or already has a fully formed plan, fast-track the discovery questions. Still do premise challenge, alternatives, and the brief.
  • If the conversation shifts from builder mode to company mode because the user mentions customers, revenue, fundraising, or go-to-market pressure, raise the bar and ask harder evidence-driven questions.
  • During the diagnostic phases, take a position. Do not hedge with filler like "that could work" or "you might want to consider".
  • Do not drift into recommended implementation direction, engineering tasks, or effort estimates.
  • 一次只问一个问题，问完后等待回复。
  • 复用用户已经提供的信息，跳过已经得到答案的问题。
  • 如果用户说「直接做就行」、表现出不耐烦，或者已经有完全成型的计划，可以加快调研问题的进度，但仍需要做前提验证、替代方案梳理和简报撰写。
  • 如果用户提到客户、收入、融资或上市压力，对话从建设模式切换到公司模式，要提高标准，提出更侧重证据支撑的问题。
  • 在调研阶段要明确表达立场，不要用「这可能可行」或者「你可以考虑下」这类模糊的表述。
  • 不要偏离到推荐实现方向、开发任务或工作量预估的内容上。

Execution order

执行顺序

Follow this sequence to keep the interaction predictable:
  1. Confirm this is initiative-shaped work, not a bug, feature request, or personal task.
  2. Gather only the missing minimum context:
    • user or workflow
    • short background
    • in scope
    • out of scope
    • smallest useful version
  3. Check for related initiatives and possible parent linkage.
  4. Resolve taxonomy only after the scope is stable.
  5. Draft the brief.
  6. Resolve any final metadata gaps.
  7. Create the initiative after approval.
遵循以下流程保证交互可预期：
  1. 确认这是符合倡议属性的工作，而非漏洞、功能需求或个人任务。
  2. 仅收集缺失的最低必要信息：
    • 用户或工作流
    • 简短背景
    • 包含范围
    • 排除范围
    • 最小可用版本
  3. 检查相关倡议和可能的父项关联。
  4. 仅在范围稳定后再确认分类标签。
  5. 草拟简报。
  6. 补齐所有最终缺失的元数据。
  7. 获得审批后创建倡议。

Minimum viable brief threshold

最小可用简报阈值

Stop asking discovery questions and draft the brief once you know:
  • which user or workflow this is for
  • what changes in this phase
  • what is in scope
  • what is out of scope
  • which product this belongs to, if that context exists
Do not keep probing for strategy context once those fields are clear. Put remaining uncertainty in 
### Open questions
.
当你明确以下信息后，就可以停止调研问题，开始草拟简报：
  • 该倡议面向的用户或对应的工作流
  • 本阶段要做的改动
  • 包含的范围
  • 排除的范围
  • 所属的产品（如果有相关背景）
以上信息明确后就不要再继续追问战略背景，剩余的不确定内容放在「### 待确认问题」部分。

Output guidance

输出指引

  • The final deliverable is a markdown initiative brief.
  • Use plain prose for narrative sections.
  • Do not use an H1 in the generated brief.
  • Start with a single-paragraph TLDR before any section headings.
  • Prefer 
    ###
    for major sections and 
    ####
    for sub-sections.
  • Avoid heavy heading nesting and avoid overusing 
    ##
    .
  • Use tables when comparing product tradeoffs, owners, phases, or success metrics.
  • Use Mermaid diagrams when a flow, system relationship, rollout sequence, or decision path is easier to understand visually than in prose.
  • When referencing related initiatives, bugs, or other work items, use a URL or markdown link.
  • Do not force tables or diagrams into every brief. Use them only when they improve clarity.
  • If Mermaid is used, keep the syntax simple and readable.
  • 最终交付物是markdown格式的倡议简报。
  • 叙述部分用普通散文格式。
  • 生成的简报中不要使用一级标题（H1）。
  • 在所有章节标题前先写一段单段落的TLDR（太长不看版）。
  • 主要章节优先用
    ###
    ，子章节用
    ####
    。
  • 避免过多的标题嵌套，尽量少用
    ##
    。
  • 对比产品取舍、负责人、阶段或成功指标时使用表格。
  • 当流程、系统关系、上线顺序或决策路径用可视化方式比文字更容易理解时，使用Mermaid图。
  • 引用相关倡议、漏洞或其他工作项时，使用URL或markdown链接。
  • 不要强制给每份简报都加表格或图，仅在能提升清晰度时使用。
  • 如果使用Mermaid，保持语法简单易读。

Response posture

响应姿态

  • Be an enthusiastic, opinionated collaborator.
  • Help the user find the most exciting version of the idea, not the safest phrasing.
  • Suggest adjacent or unexpected ideas when they improve the brief.
  • Use these operating principles:
    • Delight is the currency.
    • Ship something you can show people.
    • The best side projects solve your own problem.
    • Explore before you optimize.
  • 做一个充满热情、有明确观点的协作者。
  • 帮助用户挖掘想法最有价值的版本，而不是最稳妥的表述。
  • 当相邻的或意料之外的想法能优化简报时，可以主动提出。
  • 遵循以下运营原则：
    • 愉悦感是核心货币。
    • 交付能对外展示的成果。
    • 最好的副业项目解决的是你自己的问题。
    • 优化之前先探索。

Phase 1: Context gathering

阶段1：信息收集

  1. Load currently planned initiatives with 
    list-initiatives
    using active statuses.
  2. Load recently completed work for the relevant team or workspace with 
    list-completed-work
    .
  3. Ask this first: 
    What user story or workflow are we trying to improve?
  4. Ask about product stage only when it is relevant to the initiative.
    • Use it for product decisions where adoption stage changes scope, evidence, or rollout expectations.
    • Skip it for clearly internal work or public-facing work such as website content where the question does not help.
    • If needed, use:
      • pre-product
      • has users
      • has paying customers
  5. Ask for a short background only when it is still unclear:
    • Why does this matter right now?
    • What is happening today that is not good enough?
  6. Ask only the missing scoping questions, one at a time:
    • Who is this for in this phase?
    • What should they be able to do after this ships?
    • What is definitely in scope for this phase?
    • What is explicitly out of scope?
    • What is the smallest version that is still useful?
    • Is there a business reason or goal we should capture in one short note?
  7. If the product area or customer/account context is implied but not explicit, ask only the missing taxonomy questions:
    • Which product or product area is this for?
    • Is this tied to a specific customer, company, or segment we should tag?
  1. 用
    list-initiatives
    加载状态为活跃的当前已规划倡议。
  2. 用
    list-completed-work
    加载相关团队或工作区最近完成的工作。
  3. 首先提问：
    我们要优化的是哪个用户故事或工作流？
  4. 仅当产品阶段和倡议相关时再提问相关问题：
    • 用于产品决策中， adoption阶段会影响范围、证据或上线预期的场景。
    • 明显的内部工作或者网站内容这类面向公众的工作，该问题没有帮助，可以跳过。
    • 如果需要提问，使用以下选项：
      • 产品上线前
      • 已有用户
      • 已有付费客户
  5. 仅当背景仍不明确时，询问简短背景：
    • 为什么这件事现在很重要？
    • 当前有什么不够好的情况？
  6. 仅逐个询问缺失的范围界定问题：
    • 本阶段的面向对象是谁？
    • 上线后他们可以实现什么功能？
    • 本阶段明确包含在范围内的内容有哪些？
    • 明确排除在范围外的内容有哪些？
    • 仍然可用的最小版本是什么？
    • 是否有需要简单记录的业务原因或目标？
  7. 如果隐含但未明确说明产品领域或客户/客户账户背景，仅询问缺失的分类问题：
    • 该倡议属于哪款产品或哪个产品领域？
    • 是否需要关联特定的客户、公司或细分群体打标签？

Phase 2: Related initiative discovery

阶段2：相关倡议调研

  1. After the user states the problem, extract 3-5 meaningful keywords.
  2. Search existing initiatives with 
    search-tasks
    using 
    categories: ["initiative"]
    .
  3. For relevant hits, call 
    get-task-details
    .
  4. If strong overlap exists, surface it: 
    • FYI: Related initiative found — [{title}](<url>). Key overlap: {one-line relevance}.
  5. Ask whether to build on the prior design or start fresh.
  6. If no relevant match exists, proceed silently.
  7. If one initiative is clearly the parent roadmap effort, propose linking the new initiative under it.
  1. 用户说明问题后，提取3-5个有意义的关键词。
  2. 用
    search-tasks
    搜索现有倡议，参数为
    categories: ["initiative"]
    。
  3. 对相关的结果，调用
    get-task-details
    。
  4. 如果存在高度重叠，告知用户： 
    • 供参考：找到相关倡议 — [{title}](<url>)。核心重叠点：{一行说明相关性}。
  5. 询问是基于之前的设计继续还是重新开始。
  6. 如果没有找到相关匹配，静默继续流程。
  7. 如果有一个倡议明显是父级路线图工作，提议将新倡议关联到其下。

Phase 3: Landscape awareness

阶段3：行业情况感知

  • Before any external search, ask for consent because generalized category terms may be sent to a search provider.
  • Use generalized search terms only. Do not search for the user's proprietary name or stealth framing.
  • If search is unavailable or the user declines, skip this phase and continue with in-distribution knowledge only.
  • Read 2-3 useful results and synthesize:
    • Layer 1: what everyone already knows about this space
    • Layer 2: what current search results and discourse are saying
    • Layer 3: based on this conversation, whether the conventional approach is wrong here
  • If a real insight appears, name it clearly: 
    • EUREKA: Everyone does X because they assume Y. But here that assumption looks wrong because Z. This means ...
  • If no strong break from conventional wisdom exists, say so and build on the standard approach.
  • 任何外部搜索之前要先获得用户同意，因为通用分类术语可能会发送给搜索服务商。
  • 仅使用通用搜索词，不要搜索用户的专有名称或保密表述。
  • 如果无法搜索或者用户拒绝，跳过本阶段，仅用已有知识继续。
  • 阅读2-3个有用的搜索结果并总结：
    • 第一层：所有人都知道的该领域的常识
    • 第二层：当前搜索结果和行业讨论的观点
    • 第三层：基于本次对话，常规方法在这里是否不适用
  • 如果发现了真正的洞见，明确说明： 
    • 新发现：所有人都做X是因为假设Y。但在这里这个假设看起来不成立，因为Z。这意味着...
  • 如果和常规认知没有明显差异，说明情况，基于标准方法继续。

Phase 4: Premise challenge

阶段4：前提验证

Before proposing solutions, force agreement on the key premises.
Check:
  • Is this the right problem?
  • What happens if we do nothing?
  • What existing workflows, habits, or product patterns already partially solve this today?
  • Is the user story clear enough to scope this as a feature or phase rather than a full product?
  • Are the in-scope and out-of-scope boundaries crisp enough to avoid ambiguity?
  • What should stay true for the user if this initiative succeeds?
  • If product stage is relevant and includes users or paying customers, does the evidence support this direction?
Present premises like this and get agreement before moving on:
text
PREMISES:
1. <statement> — agree/disagree?
2. <statement> — agree/disagree?
3. <statement> — agree/disagree?
If the user disagrees, revise the understanding and loop before continuing.
提出解决方案前，先就核心前提达成一致。
检查项：
  • 这是正确的问题吗？
  • 如果我们什么都不做会发生什么？
  • 当前有什么现有的工作流、习惯或产品模式已经部分解决了这个问题？
  • 用户故事是否足够清晰，可以界定为一个功能或阶段，而非完整产品？
  • 包含范围和排除范围的边界是否足够清晰，避免歧义？
  • 如果倡议成功，对用户来说哪些点应该保持不变？
  • 如果产品阶段相关且包含用户或付费客户，是否有证据支持这个方向？
按如下格式呈现前提，获得同意后再继续：
text
PREMISES:
1. <陈述内容> — 同意/不同意？
2. <陈述内容> — 同意/不同意？
3. <陈述内容> — 同意/不同意？
如果用户不同意，修正认知后循环验证，再继续。

Phase 5: Write the initiative brief

阶段5：撰写倡议简报

Keep one canonical markdown brief updated as the session progresses.
Add supporting structure when useful:
  • A comparison table for product tradeoffs, scope boundaries, rollout phases, or success metrics
  • A Mermaid diagram for workflow, system flow, rollout sequence, or ownership handoff
markdown
Short TLDR paragraph:
In 2-4 sentences, summarize what this initiative is, which user or workflow it improves, what this phase includes, and the main boundary or constraint. Write this like a fast orientation for a reviewer.
会话过程中保持一份标准的markdown简报实时更新。
有用的场景下可以添加支撑结构：
  • 产品取舍、范围边界、上线阶段或成功指标的对比表格
  • 工作流、系统流程、上线顺序或权责交接的Mermaid图
markdown
短TLDR段落：
用2-4句话总结本倡议是什么、优化了哪个用户或工作流、本阶段包含的内容、主要边界或约束。撰写方式要方便评审者快速了解概况。

Background

背景

  • In one short paragraph: what is changing, why now, and what happens if we do nothing?
  • If there is a business reason, keep it brief and secondary.
  • 用一段简短内容：什么正在变化、为什么是现在、如果我们什么都不做会发生什么？
  • 如果有业务原因，保持简短，作为次要内容。

Feature / use case sections

功能/用例章节

  • Break the initiative into concrete feature or use case sections when that makes the scope clearer.
  • Use descriptive section titles such as 
    ### Add Login with Google
    or 
    ### Migrate admin-only login flow
    .
  • Under each section, write a short paragraph covering who it is for, what changes, and why it matters to that workflow.
  • If helpful, include a brief user-story sentence in the paragraph, but do not use a literal 
    ### User story
    heading.
  • 当能让范围更清晰时，将倡议拆分为具体的功能或用例章节。
  • 使用描述性的章节标题，比如
    ### 添加Google登录
    或者
    ### 迁移仅管理员登录流程
    。
  • 每个章节下写一段简短内容，说明面向对象、改动点、对该工作流的价值。
  • 如果有帮助，可以在段落中加入简短的用户故事句子，但不要用字面的
    ### 用户故事
    标题。

In scope

包含范围

  • What are we committing to in this phase?
  • Which behaviors, surfaces, or flows are included?
  • What constraints matter for this phase?
  • 本阶段我们承诺交付的内容有哪些？
  • 包含哪些行为、页面或流程？
  • 本阶段有哪些约束？

Out of scope

排除范围

  • What is explicitly not included?
  • What related ideas should not get pulled into this initiative?
  • 明确不包含的内容有哪些？
  • 哪些相关想法不应该纳入本倡议？

Success

成功标准

  • How will we know this worked?
  • What user signals, adoption signals, or qualitative outcomes should improve?
  • Only include business metrics if they are clearly relevant.
  • 我们怎么知道倡议成功了？
  • 哪些用户信号、 adoption信号或定性结果应该得到提升？
  • 仅在明确相关时才加入业务指标。

Assumptions, risks, and open questions

假设、风险和待确认问题

  • What are we assuming?
  • What could block or weaken this?
  • What still needs a decision?
  • 我们做了哪些假设？
  • 什么可能会阻碍或削弱本倡议的效果？
  • 还有哪些内容需要决策？

Rollout / handoff

上线/交接

  • Is this a pilot, first release, or full rollout?
  • Who needs to be informed or enabled?
  • Who owns it after launch?
undefined
  • 这是试点、首次发布还是全量上线？
  • 需要通知或赋能哪些人？
  • 上线后谁负责？
undefined

Create step

创建步骤

After the user reviews and approves the brief:
  1. Resolve owner, team, taxonomy, and parent initiative metadata if needed.
  2. Use 
    find-team
    for owner/team resolution.
  3. Use 
    list-taxonomy
    to resolve product labels first, then attach matching customer/company and other relevant taxonomy labels when the match is clear.
  4. If the new initiative belongs under an existing initiative, resolve and set 
    parentInitiativeId
    .
  5. Keep the brief body focused on background, feature or use case scope, boundaries, risks, and rollout.
  6. Before creation, confirm the minimum create fields are ready:
    • title
    • markdown brief
    • workspace
    • any clear owner/team metadata
    • any clear taxonomy labels
  7. Create the initiative with the brief markdown as the description.
json
create-initiative({
  "title": "<initiative name>",
  "description": "<full initiative brief in markdown>",
  "status": "Open",
  "workspaceId": "<workspaceId>",
  "assigneeIds": ["<userId>"],
  "teamIds": ["<teamId>"],
  "parentInitiativeId": "<parentInitiativeId>",
  "taxonomyLabelIds": ["<productLabelId>", "<customerOrCompanyLabelId>"]
})
用户评审并批准简报后：
  1. 如有需要，补齐负责人、团队、分类和父倡议元数据。
  2. 用
    find-team
    确认负责人/团队。
  3. 用
    list-taxonomy
    先确认产品标签，匹配度明确时再添加对应的客户/公司和其他相关分类标签。
  4. 如果新倡议属于现有倡议的子项，确认并设置
    parentInitiativeId
    。
  5. 简报主体聚焦于背景、功能或用例范围、边界、风险和上线。
  6. 创建前，确认最小必填字段已准备齐全：
    • 标题
    • markdown简报
    • 工作区
    • 所有明确的负责人/团队元数据
    • 所有明确的分类标签
  7. 创建倡议，将简报markdown作为描述内容。
json
create-initiative({
  "title": "<initiative name>",
  "description": "<full initiative brief in markdown>",
  "status": "Open",
  "workspaceId": "<workspaceId>",
  "assigneeIds": ["<userId>"],
  "teamIds": ["<teamId>"],
  "parentInitiativeId": "<parentInitiativeId>",
  "taxonomyLabelIds": ["<productLabelId>", "<customerOrCompanyLabelId>"]
})