技能：定义使命
目的
定义并记录使命：项目或组织存在的持久原因。使命宣言回答“为什么会存在这个？”并且在路线图或特征变化时保持稳定。它注重结果（我们服务的目的），而不是实施（我们如何做或我们构建什么）。
使命不同于：
- 愿景：我们旨在创造的长期未来状态（使用
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）。要求用户确认或完善。若使命文件已存在，覆盖前须询问。
结果：使命以结果为中心；功能保留在产品文档中。