Menu
对spec.md、plan.md和tasks.md三个核心文档进行非破坏性跨工件一致性和质量分析。在任务生成后识别不一致、重复、模糊和规范不足的项目。触发词包括："speckit-analyze"、"speckit分析"、"文档一致性分析"、"规范分析"、"质量检查"、"工件分析"、"spec分析"、"plan分析"、"task分析"。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
归档已完成的变更并将规范差异合并到常驻文档。用于变更已部署、准备归档或实施后需要更新规范时。触发词包括 "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}