菜单
对spec.md、plan.md和tasks.md三个核心文档进行非破坏性跨工件一致性和质量分析。在任务生成后识别不一致、重复、模糊和规范不足的项目。触发词包括："speckit-analyze"、"speckit分析"、"文档一致性分析"、"规范分析"、"质量检查"、"工件分析"、"spec分析"、"plan分析"、"task分析"。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
归档已完成的变更并将规范差异合并到常驻文档。用于变更已部署、准备归档或实施后需要更新规范时。触发词包括 "openspec归档", "归档", "归档提案", "合并规范", "完成提案", "更新文档", "定稿规范", "标记完成"。
加载项目上下文，列出现有规范与变更，搜索能力与需求。用于用户询问项目状态、现有规范、进行中的变更、可用能力或需要发现上下文时。触发词包括"openspec上下文", "有哪些规范", "显示变更", "列出能力", "项目上下文", "查找规范", "规范包含什么", "展示规范"。
以测试与验证为先的方式，按序执行并实现已批准的规范提案。用于实施变更、应用提案、执行规范任务或按已批准计划构建。触发词包括 "openspec开发", "开发", "实施" "实现提案", "应用变更", "执行规范", "按顺序完成任务", "构建功能", "开始实施"。
通过openspec规范驱动的方法创建结构化的变更提案与规范差异。用于规划功能、创建提案、编写规范、引入新能力或启动开发流程。触发词包括 "openspec提案", "规划", "创建提案", "规划变更", "规范功能", "新功能", "新特性", "新需求", "添加功能规划", "设计规范"。
从交互式或提供的原则输入创建或更新项目章程，确保所有依赖模板保持同步。用于项目管理、规范制定、章程维护和团队协作场景。触发词包括 "speckit章程"、"创建章程"、"更新章程"、"项目章程"、"制定规范"、"团队章程"。
执行实施规划工作流程，使用计划模板生成设计工件。触发词包括："speckit计划"。
| name | speckit-analyze-zh |
| description | 对spec.md、plan.md和tasks.md三个核心文档进行非破坏性跨工件一致性和质量分析。在任务生成后识别不一致、重复、模糊和规范不足的项目。触发词包括："speckit-analyze"、"speckit分析"、"文档一致性分析"、"规范分析"、"质量检查"、"工件分析"、"spec分析"、"plan分析"、"task分析"。 |
$ARGUMENTS
您必须在继续之前考虑用户输入（如果不为空）。
在实现之前，识别三个核心工件（spec.md、plan.md、tasks.md）之间的不一致、重复、歧义和未充分说明的项目。此命令必须仅在 speckit-tasks 成功生成完整的 tasks.md 后运行。
严格只读：不要修改任何文件。输出结构化分析报告。提供可选的补救计划（用户必须明确批准后才能手动调用任何后续编辑命令）。
宪章权威性：项目宪章（.specify/memory/constitution.md）在此分析范围内是不可协商的。宪章冲突自动为关键级别，需要调整规格、计划或任务——而不是稀释、重新解释或默默忽略原则。如果原则本身需要更改，必须在 speckit-analyze 之外的单独、明确的宪章更新中进行。
scripts: sh: .specify/scripts/bash/check-prerequisites.sh --json ps: .specify/scripts/powershell/check-prerequisites.ps1 -Json
从仓库根目录运行一次 {SCRIPT} 并解析 JSON 以获取 FEATURE_DIR 和 AVAILABLE_DOCS。推导绝对路径：
如果缺少任何必需文件，则中止并显示错误消息（指示用户运行缺少的先决条件命令）。 对于参数中的单引号，如 "I'm Groot"，使用转义语法：例如 'I'''m Groot'（或者如果可能的话使用双引号："I'm Groot"）。
仅加载每个工件的最小必要上下文：
来自 spec.md：
来自 plan.md：
来自 tasks.md：
来自 constitution：
.specify/memory/constitution.md 用于原则验证创建内部表示（不要在输出中包含原始工件）：
user-can-upload-file）专注于高信号发现。限制总数为 50 个发现；在溢出摘要中聚合其余发现。
<placeholder> 等）使用此启发式方法来优先处理发现：
输出一个 Markdown 报告（不写入文件）具有以下结构：
| ID | 类别 | 严重性 | 位置 | 摘要 | 建议 |
|---|---|---|---|---|---|
| A1 | 重复 | 高 | spec.md:L120-134 | 两个相似的要求 ... | 合并措辞；保留更清晰的版本 |
（每项发现添加一行；生成以类别首字母为前缀的稳定 ID。）
覆盖摘要表：
| 要求键 | 有任务？ | 任务 ID | 备注 |
|---|
宪章对齐问题：（如果有）
未映射的任务：（如果有）
指标：
在报告末尾，输出一个简洁的下一步行动块：
speckit-implement 之前解决speckit-specify"，"运行 speckit-plan 调整架构"，"手动编辑 tasks.md 添加 'performance-metrics' 的覆盖"询问用户："您希望我为前 N 个问题建议具体的补救编辑吗？"（不要自动应用它们。）
{ARGS}