AI CORTEX
开始使用 开放工具，共同标准
让 AI 智能体遵循共同的工作方式。
将零散的提示转化为可复用的能力。AI Cortex 为软件交付与项目治理提供技能、契约和质量规则。
采用 MIT 许可证开源，配合你已有的工具使用。
一个资产库，清晰的边界。
在不同项目中复用同一套能力。
能力全景
从全局理解 AI Cortex。
从一个工作目标出发，展开查看相关能力。下方的契约、规则与协议提供共同基础；按任务选择适用资产，无须采用全部内容。
选择工作目标，展开查看全部能力
70 项技能01研究与机会先理解问题，再作投入决定。研究依据 → 机会建议6
02方向与规划让具体工作关联项目目标。项目目标 → 优先级 → 路线图16
- ↗
define-mission明确项目为什么存在
- ↗
define-vision描述项目希望创造的未来
- ↗
define-north-star定义代表用户核心价值的指标
- ↗
define-strategic-pillars将愿景转为少量战略主题
- ↗
design-strategic-goals设计推动愿景实现的长期目标
- ↗
capture-work-items将需求与问题记录为工作项
- ↗
prioritize-backlog依据项目策略确定待办优先级
- ↗
map-item-dependencies识别工作项依赖并判断推进条件
- ↗
define-roadmap先设计路线图结构，再填充有依据的计划
- ↗
promote-roadmap-items将已排序且条件就绪的工作纳入路线图
- ↗
update-roadmap维护工作项状态、日期和变更依据
- ↗
archive-milestone归档已完成的里程碑并保留依据
- ↗
plan-next分析治理现状并建议下一步
- ↗
orchestrate-governance-step执行一项已确定的治理行动
- ↗
orchestrate-roadmap-planning协调路线图结构设计、内容规划与既有计划对齐
- ↗
orchestrate-repair-requirements-loop根据审查发现修复并复核需求
03设计与验证核对意图、实现与验证依据。设计 → 审查发现 → 已验证的变更30
- ↗
review-architecture审查模块职责、依赖方向与契约边界
- ↗
review-codebase审查代码库的组织与技术债
- ↗
review-diff审查本次差异的正确性与影响
- ↗
review-dotnet审查 .NET 语言与运行时约定
- ↗
review-error-surfacing审查错误发现位置与可行动的报错
- ↗
review-functional-design审查功能设计的完整性与可执行性
- ↗
review-go审查 Go 语言、并发与资源使用
- ↗
review-implementation-alignment核对实现与已批准需求、设计和验证依据
- ↗
review-java审查 Java 语言与运行时约定
- ↗
review-observability审查日志、指标、追踪与问题定位能力
- ↗
review-orm-usage审查 ORM 查询、连接和事务使用
- ↗
review-performance审查计算、内存、I/O 与并发成本
- ↗
review-php审查 PHP 类型、异常与模块约定
- ↗
review-powershell审查 PowerShell 参数、对象流与错误处理
- ↗
review-python审查 Python 类型、异常和异步约定
- ↗
review-react审查 React 组件、状态、Hooks 与可访问性
- ↗
review-reliability审查超时、重试、幂等与故障隔离
- ↗
review-requirements审查需求是否明确、完整且可验证
- ↗
review-roadmap审查路线图结构与计划内容
- ↗
review-security审查信任边界、权限与敏感数据处理
- ↗
review-sql审查 SQL 安全、查询效率与事务语义
- ↗
review-tasks审查任务覆盖、依赖与执行条件
- ↗
review-technical-design审查架构、接口与技术取舍
- ↗
review-testing审查测试是否证明了真实行为
- ↗
review-typescript审查 TypeScript 与 JavaScript 类型和异步逻辑
- ↗
review-vue审查 Vue 组件、响应式状态与渲染
- ↗
orchestrate-code-review编排工程审查并汇总发现
- ↗
orchestrate-repair-loop修复实现并复核工程与功能质量
- ↗
automate-tests发现并运行项目测试
- ↗
scaffold-agent-tests依据智能体测试契约生成测试套件
04交付与发布将已审查的工作交付给使用者。提交 → 整合 → 发布8
05沟通与集成在明确的边界内交换信息。契约 → 消息 → 共同理解5
定义成果、约束工作、协调参与方
Spec成果应具有什么结构？21
- ↗
agent-test-modeling定义智能体测试的能力边界、输入与判定依据
- ↗
adr-modeling定义架构决策记录的字段与状态
- ↗
cross-team-contract定义跨团队契约的命名、版本与变更记录
- ↗
claude-md-modeling定义多层 CLAUDE.md 记忆文件的结构与职责
- ↗
findings-list统一审查发现的内容、严重程度与分类
- ↗
functional-design-modeling定义功能、流程、状态、权限及交互设计文档
- ↗
technical-design-modeling定义架构、组件、接口与技术设计文档
- ↗
nats-messaging定义跨项目 NATS 消息的主题、头部与负载
- ↗
opportunity-package定义产品机会建议、状态与证据追溯结构
- ↗
plan-next-preferences定义项目可持久保留的下一步建议偏好
- ↗
research-evidence定义研究来源、发现、冲突与证据缺口
- ↗
roadmap-modeling定义路线图的结构、视图、计划与历史记录
- ↗
requirement-modeling定义需求文档的字段、格式与验收结构
- ↗
rule-modeling定义可治理规则的标识、适用条件与豁免记录
- ↗
release-package定义发布包的版本、材料、质量依据与阶段状态
- ↗
spec-modeling定义规格文档自身的结构与状态
- ↗
skill-source-modeling定义外部技能来源的固定版本、许可与维护记录
- ↗
task-modeling定义任务列表、状态与依赖关系
- ↗
test-case-modeling定义业务测试用例与需求追溯关系
- ↗
test-coverage-modeling定义覆盖报告、追溯矩阵与变异测试摘要
- ↗
universal-notification定义统一通知内容的字段与结构
Rule哪些约束必须成立？33
- ↗
agentic-artifact-paradigm让产出由实际内容驱动，而非机械填写模板
- ↗
architecture-quality检查职责、依赖、边界与契约演进
- ↗
security-quality约束输入处理、授权、凭据与数据安全
- ↗
reliability-quality约束超时、重试、幂等与故障恢复
- ↗
performance-quality约束资源成本、缓存、并发与工作上限
- ↗
error-surfacing-quality约束错误判断位置与可行动的反馈
- ↗
literal-and-copy-quality约束共享值、展示文案、语言覆盖与回退一致性
- ↗
observability-quality约束日志、指标、追踪与运行结果可见性
- ↗
testing-quality约束行为判定、边界覆盖与测试可信度
- ↗
implementation-alignment-quality检查实现与批准意图及验证依据的一致性
- ↗
writing-chinese-technical统一中文技术写作、标点与排版
- ↗
writing-presales-response约束售前回答的证据、范围与信息时效
- ↗
standards-import保持模块引用同步并有序
- ↗
standards-jenkins-job-naming统一 Jenkins 作业目录和名称
- ↗
workflow-documentation约束文档维护、命名与单一权威来源
- ↗
workflow-rule-governance治理规则标识、适用范围、兼容与豁免
- ↗
standards-coding统一代码组织、命名、错误处理与复杂度约定
- ↗
standards-shell统一 Shell 的严格模式、引用与清理方式
- ↗
standards-test-code约束测试目标、隔离、断言与可复现性
- ↗
standards-agent-testing区分确定性测试与真实模型评估
- ↗
requirement-quality检查需求完整性、清晰度与可验证性
- ↗
requirement-intake-triage区分需求、缺陷、方案建议与信息不足
- ↗
functional-design-quality检查功能设计、业务流程与界面决策
- ↗
technical-design-quality检查技术设计的完整性、边界与质量取舍
- ↗
task-quality检查任务信息、依赖与设计覆盖
- ↗
roadmap-quality检查路线图依据、粒度、优先级与交付记录
- ↗
test-case-quality检查业务测试用例的结构与覆盖
- ↗
test-coverage-quality检查覆盖报告的真实性与风险对应关系
- ↗
doc-health-criteria检查文档结构、链接与实现一致性
- ↗
repo-structure-hygiene检查目录、命名、错放内容与过期文件
- ↗
adr-management维护架构决策的准入、状态与历史
- ↗
claude-md-management维护 CLAUDE.md 的篇幅、内容与修订边界
- ↗
diagram-selection依据关系类型选择图形与绘图工具
Protocol多个角色如何协作？1
- ↗
im-notification-delivery协调通知发送方与 IM 渠道的渲染和交付步骤
连线表示资产在库中的分组，不代表依赖关系或必须执行的顺序。展开后即可在站内阅读每项资产的用途；箭头链接供进一步查阅源码。
如何协同使用
共同的标准，
贯穿规划与交付。
这是一条使用示例。可以从当前需要的技能开始，无须一次采用完整流程。
mkdir -p ~/.local/share
git clone --depth 1 https://github.com/nesnilnehc/ai-cortex.git ~/.local/share/ai-cortex
~/.local/share/ai-cortex/bin/cortex install运行前请检查命令。安装器会列出检测到的 IDE，并提示所需的 PATH 配置。
需要启用项目质量规则？阅读配置指南开始之前
你可能关心的问题。
AI Cortex 是智能体还是应用？
它是供智能体使用的资产库，提供可调用的技能、结构规格、交互协议和质量规则。实际工作由你已有的智能体执行。
需要一次采用全部内容吗？
不需要。从适合当前任务的技能开始即可。编排技能可以组合较小的能力，完成更长的流程。项目治理能力需要在项目中明确启用。查看采用指南。
会安装哪些内容？
安装器将技能链接到 ~/.agents/skills 和支持的 IDE 目录，并为检测到的 IDE 同步用户级规则。规格、协议和项目级规则保留在标准克隆目录中，供智能体按需读取。查看安装行为说明。
可以查看和修改资产吗？
可以。本项目采用 MIT 许可证开源，你可以阅读资产、跨项目复用，并通过代码仓库贡献改进。阅读贡献指南。