define-strategic-pillars
技能(Skill):定义战略支柱
目的(目的)
从愿景和北极星中得出3-5个战略支柱(高层主题),构建和指导战略目标和路线图。制作支柱文档,以便可以将目标和路线图分组到支柱下。不定义使命、愿景、北极星、目标、里程碑或路线图。
支柱与目标的区别:
- 支柱 = 持续投入的方向(不会"完成",是不可或缺的结构性要素,如"可靠运行")
- 目标 = 该方向上要达到的具体结果(可以判断是否达成,如"回退率低于 5%")
支柱是不可或缺的——少一个就有结构性缺失。目标会随阶段变化,但支柱保持稳定。
核心目标(Core Objective)
首要目标:生成用户确认的战略支柱文档,其中包含与愿景和北极星一致的 3-5 个支柱(主题),并坚持项目商定的路径。
成功标准(必须满足所有要求):
- ✅ 记录了 3-5 个支柱:正好 3-5 个战略支柱,每个支柱都有清晰的名称和简短描述(该支柱代表什么)。
- ✅ 主题级:每个支柱都是一个高级主题或持续投入的战略方向,而不是可完成的目标或具体举措。
- ✅ 与愿景保持一致:每根支柱都支撑着愿景;对齐是明确的或明显的。
- ✅ 北极星连接:至少一根柱子明显支撑或框住北极星;可选:每个支柱简要介绍“这如何支持愿景/NSM”。
- ✅ 用户确认:用户明确批准(例如“已批准”、“看起来不错”、“继续”或同等内容)。
- ✅ 文档持久化:写入商定的路径(默认
docs/project-overview/strategic-pillars.md或每个项目规范)。
验收测试:读者能否看到每个支柱如何构建战略以及如何将目标或路线图主题分组到它们之下?
交接点:当支柱被批准并保留后,交接至“设计-战略-目标”(目标可以映射到支柱)或“定义-路线图”(路线图主题可以与支柱对齐);该技能不定义目标或路线图。
范围边界(范围边界)
本技能负责:
- 引出并记录 3-5 个战略支柱(高级主题)。
- 确保与愿景和北极星保持一致(从“define-vision”/“define-north-star”输出或现有文档中读取)。
- 坚持项目商定的路径(默认“docs/project-overview/strategic-pillars.md”)。
- 可选:每个支柱注释关于它如何支持愿景或北极星。
本技能不负责:
- 定义使命、愿景或北极星(使用“定义使命”、“定义愿景”、“定义北极星”)。
- 定义战略目标或里程碑(使用“设计战略目标”、“定义里程碑”)。
- 定义路线图(使用
define-路线图)。
使用场景(用例)
- 继愿景和北极星之后:建立 3-5 个支柱来构建目标和路线图的组织方式。
- 战略结构:提供一组稳定的主题,以便对目标和举措进行分组(例如“产品卓越”、“客户成功”、“运营效率”)。
- 在目标之前或与目标一起:在“设计战略目标”之前或同时运行,以便目标可以映射到支柱。
- 战略链中的第四层:在构建完整层次结构时遵循使命、愿景和北极星(使命→愿景→北极星→支柱→目标→里程碑→路线图)。
行为(行为)
第 0 阶段:Norms Resolution(v1.1 新增)
按 specs/artifact-contract.md §8 Runtime Norms Resolution Protocol 的 §8.2 / §8.3 / §8.5 实现:读项目规范若声明了 strategic-pillars artifact_type 的 path_pattern,则使用项目值;否则 fall through 到技能默认(docs/project-overview/strategic-pillars.md)。本技能为固定路径治理产出,只用 path_pattern 覆盖机制。
交互(互动)政策
- 默认:项目规范的输出路径(如果存在);否则为“docs/project-overview/strategic-pillars.md”。如果有的话,请从“docs/project-overview/”中阅读愿景和北极星。
- 选择选项:如果用户有超过 5 个候选支柱,请提供优先级或合并为 3-5 个;要求用户确认最终设置。
- 确认:覆盖现有战略支柱文件之前;在最终坚持之前。
执行过程
- 加载愿景和北极星:阅读
docs/project-overview/vision.md和docs/project-overview/north-star.md或用户提供的摘要。 - 引出:哪 3-5 个高层主题或支柱将构建战略并指导目标/路线图?
- 支柱草案:主题级别(例如“客户至上”、“卓越运营”);不是目标或举措。
- 检查对齐:每个支柱支撑视觉;至少有一颗明确支撑或框住了北极星。
- 持久化:写入到项目约定的路径;如果缺少,请创建“docs/project-overview/”。可选:为每个支柱添加“这如何支持愿景/NSM”。
输入与输出 (Input & Output)
输入:
- 必需:愿景;北极星(或路径);项目背景。
- 可选:任务;现有目标或支柱;约束(例如组织结构)。
输出:
- 工件:战略支柱文档。
- 位置:
docs/project-overview/strategic-pillars.md(或按照项目规范)。 - 内容:3-5 个支柱列表(名称、简短描述);可选映射到视觉/NSM。
- 生命周期:生活(当愿景或战略方向发生变化时更新)。
限制(限制)
硬边界(Hard Boundaries)
- 不要在此技能中定义使命、愿景、北极星、目标、里程碑或路线图。
- 未经用户明确确认,请勿覆盖现有的战略支柱文件。
边界技能(技能边界)(避免重叠)
不要做这些(其他技能可以处理它们):
- 任务/愿景/北极星:使用
define-mission、define-vision、define-north-star。 - 战略目标:使用
设计-战略-目标;目标可以映射到支柱。 - 里程碑/路线图:使用
define-里程碑、define-路线图。
何时停止并交接:
- 用户说“已批准”或同等内容 → 支柱已完成;提供转交至“设计战略目标”或“定义路线图”。
- 用户询问目标或路线图 → 切换至“设计-战略-目标”或“定义-路线图”。
自检(Self-Check)
核心成功标准(必须满足所有标准)
- 记录了 3–5 个支柱:每个支柱都有名称和简短描述。
- 主题级:支柱是主题/方向,而不是目标或举措。
- 与愿景保持一致:每个支柱都支持愿景;明确或明显的对齐。
- 北极星连接:至少一根柱子支撑或框架北极星。
- 用户确认:用户说“已批准”、“看起来不错”、“继续”或类似内容。
- 文档保留:写入商定的路径。
流程质量检查
- 使用愿景/NSM:在起草支柱之前我是否阅读或请求了愿景和北极星?
- 支柱中没有目标:我是否避免写结果目标(那些属于设计战略目标)?
- 支柱不可或缺:去掉任何一个支柱是否会导致战略有结构性缺失?若否,该支柱可能是目标或举措而非支柱。
- 支柱不可完成:每个支柱是否描述持续方向而非可判断达成的结果?
验收测试
读者能否了解每个支柱如何构建战略以及如何将目标或路线图主题分组到它们之下?
如果否:澄清支柱描述和对齐方式。 如果是:支柱已完成。继续转交或停止。
示例(示例)
示例 1:愿景和北极星存在,定义支柱
背景:愿景和北极星文档存在。用户想要战略支柱来构建目标和路线图。
过程:读取愿景和北极星。提出 3-5 个支柱(例如“可发现性”、“可重用性”、“治理”、“生态系统”)。添加每个支柱的简短描述以及它如何支持愿景/NSM。用户确认。写入“docs/project-overview/strategic-pillars.md”。
结果:支柱依然存在; 转交至“设计战略目标”或“定义路线图”。
示例 2:目标已经存在
背景:战略目标文档存在;用户想要为结构添加支柱层。
流程:阅读愿景、北极星和现有目标。提出对现有目标进行分组或框架的支柱(例如,将目标分为 3-5 个主题)。用户确认。写入“docs/project-overview/strategic-pillars.md”。如果需要,建议更新目标文档以参考支柱。
结果:支柱依然存在;目标可以在稍后的过程中明确映射到支柱。
附录:输出合约 (Appendix: Output Contract)
本技能产出 Strategic Pillars Document:
| 元素 | 格式 | 必填字段 | 路径模式 |
|---|---|---|---|
| 文档主体 | Markdown | front-matter(artifact_type=strategic-pillars / lifecycle=living);章节:支柱列表 / 与 vision/NSM 的对齐 / 反例 | docs/project-overview/strategic-pillars.md |
| 支柱条目 | 列表项 | id(如 P1)/ name / description / aligns_with_vision / aligns_with_nsm;3-5 条 | 「支柱列表」节 |
| 对齐矩阵 | 表格 | pillar_id × (vision/nsm) → strong/medium/weak | 「与 vision/NSM 的对齐」节 |
More from nesnilnehc/ai-cortex
review-codebase
Architecture and design review for specified files/dirs/repo. Covers tech debt, patterns, quality. Diff-only review use review-diff. Complements review-code (orchestrated).
103review-vue
Review Vue 3 code for Composition API, reactivity, components, state (Pinia), routing, and performance. Framework-only atomic skill; output is a findings list.
91review-diff
Review only git diff for impact, regression, correctness, compatibility, and side effects. Scope-only atomic skill; output is a findings list for aggregation.
90review-java
Review Java code for language and runtime conventions: concurrency, exceptions, try-with-resources, API versioning, collections and Streams, NIO, and testability. Language-only atomic skill; output is a findings list.
82review-architecture
Review code for architecture: module and layer boundaries, dependency direction, single responsibility, cyclic dependencies, interface stability, and coupling. Cognitive-only atomic skill; output is a findings list.
80review-code
Orchestrate comprehensive code reviews by running scope, language, framework, library, and cognitive review skills in sequence, then aggregate findings into a unified report.
73