技能：定义使命

目的

定义并记录使命：项目或组织存在的持久原因。使命宣言回答“为什么会存在这个？”并且在路线图或特征变化时保持稳定。它注重结果（我们服务的目的），而不是实施（我们如何做或我们构建什么）。

使命不同于：

愿景：我们旨在创造的长期未来状态（使用 define-vision）。
北极星：表示交付价值的单个指标（使用 define-north-star）。
战略目标：实现愿景的 3-5 个结果（使用 design-strategic-goals）。
里程碑：执行的阶段检查点（使用 define-roadmap）。

核心目标（Core Objective）

首要目标：生成单一的、用户确认的使命声明，并持久化到项目商定的路径。

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

✅ 存在使命声明：一到两句话（最多三句话）仅说明基本目的 - 没有未来状态，没有指标，没有目标，没有实现或功能。
✅ 用户确认：用户明确批准（例如已批准、看起来不错、继续或同等内容）。
✅ 文档持久化：写入商定的路径（默认 docs/project-overview/mission.md 或每个项目规范）。
✅ 尊重范围：声明不描述愿景、北极星指标、战略目标或里程碑。
✅ 稳定的措辞：使命独立于功能或时间表；新读者可以在一分钟内推断出我们为何存在。
✅ YAGNI/DRY/简洁：遵循 spec §4 文档制品原则；使命陈述即核心，可选段落（为谁、核心问题）仅当确有需要时添加。

验收测试：新团队成员能否在阅读使命后立即理解该项目存在的原因，而无需阅读其他文档？

交接点：当使命被批准并持久化后，交接至 define-vision 以定义长期未来；或若仅请求使命则停止。

范围边界

这个技能必须做什么

确定核心目的（项目或组织存在的原因）。
确定谁受益（为谁受益）。
阐明根本问题或需要解决的问题。
制作一份简明的使命宣言（最好 1-2 句话，最多 3 句话）。
可选（YAGNI：仅当用户或项目确有需要时）：1–2 行 为谁、解决的核心问题。
持久化到项目约定的路径（默认docs/project-overview/mission.md）。

该技能不能做什么

定义未来状态（使用 define-vision）。
定义指标或北极星（使用 define-north-star）。
定义战略目标（使用 design-strategic-goals）。
定义里程碑（使用 define-roadmap）。
描述实施、功能或路线图（使用需求、设计或规划技巧）。
在使命宣言中包含流行语、实施语言或内部术语。

使命质量指南

强有力的使命宣言应该是：

简短：最好是 1-2 句话；最多 3 个。
目的驱动：说明我们为何存在以及我们解决什么需求，而不是我们建造什么。
以结果为中心：描述结果或价值（例如为团队提供可靠的部署方式）而不是产品（例如我们构建了一个部署工具）。
非专家也能理解：没有内部术语；新的团队成员或利益相关者可以快速掌握它。
随着时间的推移保持稳定：独立于当前功能、路线图或时间表；只有当根本目的改变时才会改变。

使命宣言中避免：

流行语：模糊或流行的术语，无法阐明目的。
实施语言：技术、可交付成果或我们如何做到这一点。
内部术语：需要特定于项目的上下文才能理解的术语。

使用场景

新项目或倡议：在愿景或战略之前确定我们为何存在。
策略刷新：方向不明确时重新定位项目。
一致性讨论：当团队缺乏明确的原因时，提供单一的事实来源。
战略链顶部：构建完整战略层次结构时首先运行（使命→愿景→北极星→目标→里程碑）。

行为

第 0 阶段：Norms Resolution（v1.3 新增）

按 specs/artifact-contract.md §8 Runtime Norms Resolution Protocol 的 §8.2 / §8.3 / §8.5 实现：读项目规范若声明了 mission artifact_type 的 path_pattern，则使用项目值；否则 fall through 到技能默认（docs/project-overview/mission.md）。本技能为固定路径治理产出，只用 path_pattern 覆盖机制。

交互策略

默认：项目规范的输出路径（如果存在）（docs/ARTIFACT_NORMS.md或.ai-cortex/artifact-norms.yaml）；否则为docs/project-overview/mission.md。从自述文件或现有文档（如果有）中推断我们为何存在。
选择选项：如果存在多个看似合理的目的，则提供 1-3 个候选陈述并要求用户进行选择或完善。
确认：覆盖现有使命文件之前；在最终持久化之前。

执行过程

收集上下文：项目/产品名称、领域和当前对目的的理解（来自文档、自述文件或用户）。
引出：这是给谁的？它解决了什么基本问题或需求？为什么值得做？
草案：一份使命宣言（优选 1-2 句话，最多 3 句）；仅有目的——没有未来状态，没有指标，没有目标，没有实现或功能。
验证：应用任务质量指南；询问用户该陈述是否涵盖为什么这个项目存在。
持久化：写入到项目约定的路径；如果缺少，请创建docs/project-overview/。

输入与输出

输入：

必填：项目或产品标识符；访问或总结当前的我们为何存在（来自文档、自述文件或用户）。
可选：现有任务草案、受众描述、问题陈述。

输出：

Artifact：单一使命宣言（首选 1-2 句话，最多 3 句）。
位置：docs/project-overview/mission.md（或按照项目规范）。
内容：使命宣言；可选（YAGNI）1–2 行 为谁、解决核心问题。
生命周期：living（常青，仅当目的改变时更新）。

限制

硬边界（Hard Boundaries）

请勿在使命宣言中包含愿景、北极星指标、战略目标或里程碑。
请勿在使命宣言中包含实施细节、功能或路线图。
未经用户明确确认，请勿覆盖现有使命文件。
不要写超过一件产品；该技能仅生成使命文档。
YAGNI：使命文档以陈述为核心；不添加不必要的可选段落。

Skill Boundaries（避免重叠）

不要做这些（其他技能负责）：

愿景：长期的未来状态 → Use define-vision
北极星指标：单关键指标 → Use define-north-star
战略目标：3-5 个结果 → Use design-strategic-goals
里程碑：阶段检查点 → Use define-roadmap
需求或路线图 → Use analyze-requirements、项目规划或 bootstrap-docs

何时停止并交接：

用户说「已批准」或同等内容 → 使命完成，hand off to define-vision
用户询问愿景或「未来是什么」 → Hand off to define-vision
用户询问指标或目标 → Hand off to define-north-star 或 design-strategic-goals

自检

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

存在使命宣言：一到两句话（最多 3 个），仅用于目的（无愿景、指标、目标、实施）。
用户确认：用户说已批准、看起来不错、继续或类似内容。
文档持久化：写入约定路径（默认 docs/project-overview/mission.md 或项目规范）。
尊重范围：声明中没有愿景、北极星、目标或里程碑。
稳定的措辞：使命独立于功能或时间表。
YAGNI/DRY/简洁：遵循 spec §4 文档制品原则。

流程质量检查

使用的上下文：我是否使用自述文件或现有文档来推断可用的用途？
一个目的：我是否避免了未来状态、指标或实现的混合？
质量指南：我是否应用了使命质量指南（简短、目的驱动、无流行语/行话）？
文档制品原则：是否遵循 YAGNI、DRY、简洁（spec §4）？

验收测试

新团队成员能否阅读使命并立即理解该项目存在的原因？

如果否：使命不完整或与愿景/目标/功能混合。仅出于目的而简化。如果是：使命完成。继续转交或停止。

示例

示例 1：仅使命 — 与愿景分开

背景：用户说我们的部署工具需要一个使命。我们稍后也会考虑我们的愿景。

流程：引出目的：谁（工程团队）、什么问题（手动、容易出错的部署）、为什么重要（可靠性、安全性）。使命草案：我们的存在是为了为工程团队提供一种单一、可靠的方式，以最少的手动步骤和最大的安全性来部署从代码到生产的服务。不要添加未来状态（例如到 2027 年一键部署）。用户确认。持久化到 docs/project-overview/mission.md。

结果：使命只有目的；稍后可使用 define-vision 定义愿景。

示例 2：目的，而不是功能

上下文：Repo README 说我们构建了一个支持 YAML 配置、回滚和审核日志的 CLI。

流程：提取目的：CLI 的存在是为了满足需求（可靠、可审核的部署），而不是构建 CLI。草案：我们的存在是为了为团队提供可靠、可审核的部署方式，并具有回滚和清晰的历史记录。避免在使命中列出功能（YAML、CLI）。要求用户确认或完善。若使命文件已存在，覆盖前须询问。

结果：使命以结果为中心；功能保留在产品文档中。

附录：输出合约 (Appendix: Output Contract)

本技能产出 Mission Statement：

元素	格式	必填字段	路径模式
文档主体	Markdown	front-matter（artifact_type=mission / created_by=define-mission / lifecycle=living）；章节：使命陈述（单句）/ 服务对象 / 解决问题 / 成功定义 / 反例	docs/project-overview/mission.md（或项目 norms 解析路径）
使命陈述	单段	不超过 2 句；包含主体（who）/ 动作（does what）/ 目的（so that）	「使命陈述」节
反例	列表项	至少 2 条，说明此项目「不做什么」以反向澄清边界	「反例」节

define-mission