Token导航 LogoToken导航TokenDH.com
待分类权限需确认github未标认证来源可访问许可证需确认审计通过

define-strategic-pillars定义战略支柱

Agent Skill

define-strategic-pillars 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

696

周安装

29

GitHub Stars

7

下载量

232
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:define-strategic-pillars(定义战略支柱)
来源仓库:https://github.com/nesnilnehc/ai-cortex
仓库路径:skills/define-strategic-pillars
安装命令:
npx skills add https://github.com/nesnilnehc/ai-cortex --skill define-strategic-pillars
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/nesnilnehc/ai-cortex --skill define-strategic-pillars

简介

用于从愿景和北极星推导出3-5个持续投入的战略支柱方向。

  • 区分支柱(结构性要素)与目标(阶段性结果),前者不可或缺后者可变。
  • 每个支柱支撑整体愿景,并与北极星形成明确关联。
  • 输出经用户确认的文档,指导战略目标与路线图的分类归属。
  • define-strategic-pillars 属于待分类类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

技能(Skill):定义战略支柱

目的(目的)

愿景北极星中得出3-5个战略支柱(高层主题),构建和指导战略目标和路线图。制作支柱文档,以便可以将目标和路线图分组到支柱下。不定义使命、愿景、北极星、目标、里程碑或路线图。

支柱与目标的区别

  • 支柱 = 持续投入的方向(不会"完成",是不可或缺的结构性要素,如"可靠运行")
  • 目标 = 该方向上要达到的具体结果(可以判断是否达成,如"回退率低于 5%")

支柱是不可或缺的——少一个就有结构性缺失。目标会随阶段变化,但支柱保持稳定。


核心目标(Core Objective)

首要目标:生成用户确认的战略支柱文档,其中包含与愿景和北极星一致的 3-5 个支柱(主题),并坚持项目商定的路径。

成功标准(必须满足所有要求):

  1. 记录了 3-5 个支柱:正好 3-5 个战略支柱,每个支柱都有清晰的名称和简短描述(该支柱代表什么)。
  2. 主题级:每个支柱都是一个高级主题或持续投入的战略方向,而不是可完成的目标或具体举措。
  3. 与愿景保持一致:每根支柱都支撑着愿景;对齐是明确的或明显的。
  4. 北极星连接:至少一根柱子明显支撑或框住北极星;可选:每个支柱简要介绍“这如何支持愿景/NSM”。
  5. 用户确认:用户明确批准(例如“已批准”、“看起来不错”、“继续”或同等内容)。
  6. 文档持久化:写入商定的路径(默认 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 个;要求用户确认最终设置。
  • 确认:覆盖现有战略支柱文件之前;在最终坚持之前。

执行过程

  1. 加载愿景和北极星:阅读 docs/project-overview/vision.mddocs/project-overview/north-star.md 或用户提供的摘要。
  2. 引出:哪 3-5 个高层主题或支柱将构建战略并指导目标/路线图?
  3. 支柱草案:主题级别(例如“客户至上”、“卓越运营”);不是目标或举措。
  4. 检查对齐:每个支柱支撑视觉;至少有一颗明确支撑或框住了北极星。
  5. 持久化:写入到项目约定的路径;如果缺少,请创建“docs/project-overview/”。可选:为每个支柱添加“这如何支持愿景/NSM”。

输入与输出 (Input & Output)

输入

  • 必需:愿景;北极星(或路径);项目背景。
  • 可选:任务;现有目标或支柱;约束(例如组织结构)。

输出

  • 工件:战略支柱文档。
  • 位置docs/project-overview/strategic-pillars.md(或按照项目规范)。
  • 内容:3-5 个支柱列表(名称、简短描述);可选映射到视觉/NSM。
  • 生命周期:生活(当愿景或战略方向发生变化时更新)。

限制(限制)

硬边界(Hard Boundaries)

  • 不要在此技能中定义使命、愿景、北极星、目标、里程碑或路线图。
  • 未经用户明确确认,请勿覆盖现有的战略支柱文件。

边界技能(技能边界)(避免重叠)

不要做这些(其他技能可以处理它们)

  • 任务/愿景/北极星:使用define-missiondefine-visiondefine-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”。如果需要,建议更新目标文档以参考支柱。

结果:支柱依然存在;目标可以在稍后的过程中明确映射到支柱。

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

37.39%
按下载量换算87

Claude

27.73%
按下载量换算64

Cursor

17.15%
按下载量换算40

Gemini CLI

9.43%
按下载量换算22

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

权限需确认

当前来源未能明确判断权限范围,默认进入异常复核队列。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills