define-north-star

name	define-north-star
description	Define the single most important metric representing the core value delivered to users. Produces North Star Metric with rationale, optional supporting metrics, and anti-pattern examples; persisted to docs.
description_zh	定义代表向用户交付核心价值的单一最重要指标；产出 North Star Metric 及理由、辅助指标与反例。
tags	["documentation","workflow"]
version	1.2.0
license	MIT
recommended_scope	both
metadata	{"author":"ai-cortex"}
triggers	["north star","define north star","North Star Metric","NSM","define NSM"]
input_schema	{"type":"free-form","description":"Project/product description; target users; core value proposition; optional mission/vision or paths"}
output_schema	{"type":"document-artifact","description":"North Star document with NSM, rationale, optional supporting metrics, anti-examples; optional measurement constraints section when metric has known limits","artifact_type":"north-star","path_pattern":"docs/project-overview/north-star.md","lifecycle":"living"}

技能 (Skill)：定义北极星

目的 (Purpose)

定义北极星指标 (NSM)：捕获交付给用户的核心价值的最重要的单一指标。使用 NSM 生成文档，说明为什么它代表用户价值、可选支持指标 (3-5) 以及反北极星示例。不定义使命、愿景、战略目标或里程碑。

---

核心目标（Core Objective）

首要目标：生成一份用户确认的北极星文档，其中包含一个反映用户价值和受产品影响的行为的主要指标，并坚持项目商定的路径。

成功标准（必须满足所有要求）：

1. ✅ 北极星指标定义：一个具有清晰、可衡量定义的主要指标（名称+衡量方式）。
2. ✅ 基本原理记录：解释为什么此指标代表用户价值（不是虚荣或仅收入）。
3. ✅ 满足的原则：NSM反映用户价值，代表用户行为，衡量持续参与度，产品驱动，简单明了。
4. ✅ 用户确认：用户明确批准（例如“已批准”、“看起来不错”、“继续”或同等内容）。
5. ✅ 文档持久化：写入商定的路径（默认 docs/project-overview/north-star.md 或每个项目规范）。
6. ✅ 列出的反模式：至少列出 2-3 个虚荣或反北极星指标作为不应优化的示例（例如收入、总用户数、注册量、下载量、原始页面浏览量）。

验收测试：读者能否在一分钟内理解哪个单一指标定义了该产品的成功以及为什么它反映了用户价值而不是虚荣心？

交接点：当“北极星”获得批准并坚持时，将其移交给“设计-战略-目标”来设定推动 NSM 的目标，或者停止。

---

范围边界 (Scope Boundaries)

本技能负责：

• 从用户价值和产品背景中得出一个主要的北极星指标。
• 记录为什么该指标代表用户价值（而不是虚荣）。
• 可选：3-5 个补充 NSM 的支持指标。
• 列出不应用作北极星的反北极星指标（虚荣示例）。
• 坚持项目同意的路径（默认“docs/project-overview/north-star.md”）。

本技能不负责：

• 定义使命或愿景（使用“定义使命”、“定义愿景”）。
• 定义战略目标或 OKR（使用“设计战略目标”）。
• 定义里程碑（使用“定义里程碑”）。
• 书写路线图、需求或待办（使用项目计划、“分析需求”、“捕获工作项目”）。

---

使用场景（用例）

• 愿景之后：一旦愿景清晰，建立一个最能捕捉“交付价值”的指标。
• 产品优先级：当团队需要一个单一指标来指导优化内容时。
• 取代虚荣指标：当当前的重点是收入、总用户数、下载量或页面浏览量并且团队想要一个用户价值锚时。
• 战略链中的第三层：在构建完整的层次结构时遵循使命和愿景。

---

行为（行为）

交互策略

遵循 Defaults first、Prefer choices、Context inference：

• 默认：从 docs/project-overview/ 或项目规范加载使命/愿景；输出路径取项目规范或 docs/project-overview/north-star.md。无额外输入时直接运行推导框架。
• 选择选项：存在多个候选指标时，提供 1–3 个并说明理由，让用户选择或细化。
• 确认：覆盖现有 north-star 文件前、持久化前必须获得用户批准。若候选为虚荣指标，警告并建议基于行为的替代。

北极星原则（在推导指标时应用）

1. 反映用户价值，而不是仅反映公司收入。
2. 代表用户行为，并非虚荣统计。
3. 衡量持续参与度，而不是一次性事件。
4. 是产品驱动的：产品团队可以影响它。
5. 简单明了：理想情况下是一个可衡量的指标。

推导框架（执行流程）

使用此推理链推导出北极星：

User
  ↓
Core Value Delivered
  ↓
Primary User Action
  ↓
Observable Behavior
  ↓
Measurable Metric (North Star)

1. 上下文：从 docs/project-overview/ 或用户加载使命/愿景；确定目标用户和核心价值主张。
2. 核心价值：产品为用户带来什么价值？ （不是“收入”——用户成果。）
3. 主要操作：反映该值的主要用户操作是什么？
4. 可观察的行为：我们可以观察到哪些行为（例如发送的消息、预订的住宿天数、花费的时间）？
5. 指标：定义一个可衡量的指标来捕获该行为；保持简单。
6. 验证：对照五项原则进行检查；避免虚荣（收入、总用户数、注册量、下载量、原始页面浏览量作为北极星）。
7. 度量与局限（可选）：若指标依赖外部数据源或当前无法直接度量，在产出文档中新增「度量与局限」节，说明依赖与替代策略。
8. 支持指标（可选）：添加 3–5 个支持或补充 NSM 的指标。
9. 反例：列出 2–3 个不应用作北极星的指标并附简短理由。
10. 持久化：写入约定路径；若目录不存在则创建。

反模式（不建议作为北极星）

• 收入（公司成果，而不是用户价值）。
• 用户总数（虚荣心；不反映参与度或价值）。
• 注册（一次性；非持续参与）。
• 下载（一次性；而非行为）。
• 原始页面浏览量（虚荣心；不是价值交付行为）。

这些可能仅作为反北极星示例出现在输出中，而不是作为所选指标。

---

输入与输出 (Input & Output)

输入：

• 必填：项目/产品描述；目标用户；核心价值主张（或使命/愿景路径）。
• 可选：使命/愿景文本或路径；当前指标；限制；类似产品的示例。

输出：

• 制品：北极星文档。
• 路径：docs/project-overview/north-star.md（或项目规范）。
• 结构：指标定义、推导链、原则、可选支持指标、可选度量与局限、反北极星示例。保持简洁（YAGNI、DRY）。
• 生命周期：living（产品或策略变更时更新）。

---

限制（限制）

硬边界（Hard Boundaries）

• 不要在此技能中定义使命、愿景、战略目标或里程碑。
• 不要提出虚荣指标（收入、总用户数、注册量、下载量、原始页面浏览量）作为北极星；仅将它们作为反例列出。
• 未经用户明确确认，请勿覆盖现有的北极星文件。

When to Stop（交接）

• 用户说「已批准」或同等 → 北极星完成；交接至 design-strategic-goals。
• 用户询问目标或里程碑 → 交接至 design-strategic-goals 或 define-roadmap。

技能边界 (Skill Boundaries)（避免重叠）

不要做这些（其他技能可以处理它们）：

• 使命：为何存在 → 使用 define-mission
• 愿景：构建何种未来 → 使用 define-vision
• 战略目标：3–5 个成果 → 使用 design-strategic-goals
• 里程碑：阶段检查点 → 使用 define-roadmap

---

自检（Self-Check）

核心成功标准（必须满足所有标准）

• 北极星指标定义：一个具有清晰、可衡量定义的主要指标。
• 基本原理记录：为什么这个指标代表用户价值（而不是虚荣心）。
• 满足的原则：用户价值、行为、持续参与、产品驱动、简单。
• 用户确认：用户说“已批准”、“看起来不错”、“继续”或类似内容。
• 文档持久化：写入约定路径（默认 docs/project-overview/north-star.md 或项目规范）。
• 列出的反模式：文档中至少有 2-3 个虚荣/反北极星示例。

流程质量检查

• 使用的推导：是否应用用户 → 核心价值 → 行动 → 行为 → 指标链？
• 度量与局限：若指标依赖外部数据或当前不可观测，是否新增「度量与局限」节？
• 无虚荣 NSM：是否避免将收入、总用户数、注册量、下载量或原始页面浏览量作为北极星？

验收测试

读者能否在一分钟内理解哪个单一指标定义了成功以及为什么它反映了用户价值？

如果否：NSM 不明确或虚荣。使用框架和原则重新推导。 如果是：北极星已完成。继续转交或停止。

---

示例（示例）

示例 1：从愿景到北极星

背景：愿景是“每个团队只需单击一下即可在 5 分钟内交付生产。”目标用户：工程团队。核心价值：可靠、快速部署。

流程：核心价值 = 成功、低摩擦的部署。主要操作 = 完成部署。可观察的行为 = 在时间/简单性条内成功的部署数量。指标：“每周成功部署（触发后 5 分钟内完成）”。支持：部署频率、回滚率、部署时间。反例：总用户数、收入、页面浏览量。用户确认。写入“docs/project-overview/north-star.md”。

结果：北极星持续存在； 转交到“设计战略目标”。

示例 2：用户建议虚荣指标

上下文：用户说“我们的北极星应该是注册用户总数。”

流程：应用原则——总用户数是虚荣心，而不是持续的参与或行为。使用推导：用户 → 核心价值（例如“用户完成 X 件事”）→ 主要操作 → 可观察行为 → 指标。提出一种基于行为的替代方案（例如“完成至少一项核心操作的每周活跃用户”）并列出“总注册用户”作为反北极星示例。要求用户确认基于行为的 NSM 或细化。

结果：文档包括所选的 NSM 以及反例“注册用户总数 - 而非持续参与”；持久化完成。

示例 3：指标有度量局限

背景：NSM 为「月度技能采纳量」，但依赖外部生态（如 skills.sh）的 API 开放，当前无法直接获取。

流程：推导出 NSM 后，验证原则均满足。新增「度量与局限」节，说明依赖 vercel-labs/skills#426 或类似能力落地；在此之前无法直接度量。可选补充组织内自建 registry（如 SkillReg、SkillHub）时的统计策略。用户确认后持久化。

结果：文档含 NSM、推导、原则、度量与局限、反例；读者知晓指标定义正确但当前不可观测。