القائمة
制品一致性分析技能. 对 spec.md、design.md 和 tasks.md 做跨制品一致性与质量分析; 发现问题后全部自动修复（不设轮数上限）, 执行全程不询问用户、不中断等待交互. 若仍有不可自动消除的残留问题, 须完整打印后继续并正常结束本技能, 不得因残留问题判定失败或阻断后续步骤. 当用户提到分析制品、检查一致性、质量审查、或在 tasks 完成后需要验证时使用.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
按 Git/非 Git、是否指定 BRANCH_NAME 与 FEATURE_DIR 分支决策，解析输入并创建或复用特性分支与功能目录，输出 BRANCH_NAME、SPEC_FILE、FEATURE_DIR。用于 /specify 或单独创建/复用特性分支。
基于已定义的功能识别并调整逻辑实体，输出实体责任边界、协作关系与关键数据结构，并生成数据模型文档。仅被显式调用，不自动触发。
SDD流程代码变更采集Skill。在SDD流程执行完毕后，采集目标目录的代码变更信息，提取feature_infos和code_blocks，生成评测所需的JSON文件并保存到当前SDD分支的evalset目录下。当用户提到"采集SDD变更"、"生成评测数据"、"收集代码变更信息"、"build_configi_eval"、"evalset"时触发本技能。
深度逻辑架构要素反构编排Skill. 当 reverse 的 --target 为 deep_logic_architecture 时触发.
实体清单与实体关系反构的编排Skill. 当 reverse 的 --target 为 entities 或 all 的实体阶段时触发.
功能清单与功能详情文档反构的编排Skill. 当 reverse 的 --target 为 functions 或 all 的功能阶段时触发.
| name | analyze |
| description | 制品一致性分析技能. 对 spec.md、design.md 和 tasks.md 做跨制品一致性与质量分析; 发现问题后全部自动修复（不设轮数上限）, 执行全程不询问用户、不中断等待交互. 若仍有不可自动消除的残留问题, 须完整打印后继续并正常结束本技能, 不得因残留问题判定失败或阻断后续步骤. 当用户提到分析制品、检查一致性、质量审查、或在 tasks 完成后需要验证时使用. |
在实施之前, 识别三个核心制品(spec.md、design.md、tasks.md)之间的不一致、重复、模糊和规范不足的项目. 此技能必须在 tasks.md 成功生成后运行.
在继续之前, 你必须考虑用户的消息内容(如果不为空).
统一行为: 允许直接编辑 FEATURE_DIR 下的 spec.md、design.md、tasks.md（及修复所必需的最小范围改动）. 完成步骤 1–6 的检测后 必须进入步骤 7 的修复—验证循环. 不设轮数上限: 持续自动修复并重新检测, 直至单轮已无可自动应用的修复（收敛）. 全程 禁止向用户发起「是否修复」「是否继续」「是否采纳建议」等确认类提问; 禁止以只读分析报告代替自动修复而提前结束.
残留问题不得阻断: 收敛后若仍存在严重/高/中/低各级残留问题, 必须在输出中完整打印（含严重性、位置、摘要）; 本技能仍视为 正常完成, 禁止将残留问题记为技能失败、禁止触发「技能失败判定」或停表阻断 workflow; 调用方（含 omnispec 各 workflow）必须继续执行后续步骤（如 implement）.
章程权威: 项目章程(.infra/memory/constitution.md)在此分析范围内是不可协商的. 章程冲突自动为严重问题, 须通过编辑制品消除——不得稀释、重新解释或默默忽略原则. 若原则本身需变更, 须在分析之外的单独章程更新中进行; 禁止为「省事」而弱化章程要求.
完成下列步骤 0–6 后 必须执行步骤 7, 不得在 analyze 执行期间停下来等待用户输入.
开始执行步骤之前，需要进行一些打点记录工作，记录本skill的执行时间到 start_time字段：
Get-Date -Format "yyyy-MM-dd HH:mm:ss"
linux: date +"%Y-%m-%d %H:%M:%S"start_time判断当前操作系统, windows 还是 linux 系统;
针对不同操作系统从仓库根目录运行脚本
windows: scripts/powershell/check-prerequisites.ps1 --json --require-tasks --include-tasks
linux: scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks
解析 JSON 以获取 FEATURE_DIR 和 AVAILABLE_DOCS. 推导绝对路径:
SPEC = FEATURE_DIR/spec.md
DESIGN = FEATURE_DIR/design.md
TASKS = FEATURE_DIR/tasks.md
如果任何必需文件缺失, 则以错误消息中止(指示用户运行缺失的先决条件命令). 对于参数中的单引号, 如 "I'm Groot", 使用转义语法: 例如 'I'''m Groot'(或尽可能使用双引号: "I'm Groot").
仅从每个制品加载最小必需的上下文:
从 spec.md:
从 design.md:
从 tasks.md:
从章程:
.infra/memory/constitution.md 进行原则验证创建内部表示(输出中不包含原始制品):
user-can-upload-file)专注于高信号发现. 限制总共 50 个发现; 在溢出摘要中聚合其余部分.
<placeholder> 等)使用此启发式方法对发现进行优先级排序:
每轮检测输出 Markdown 分析报告(不单独写入报告文件; 自动修复时对制品的编辑照常写入对应 spec.md / design.md / tasks.md), 结构如下:
| ID | 类别 | 严重性 | 位置 | 摘要 | 建议 |
|---|---|---|---|---|---|
| A1 | 重复 | 高 | spec.md:L120-134 | 两个相似需求... | 合并表述; 保留更清晰的版本 |
(每个发现添加一行; 生成以类别首字母为前缀的稳定 ID.)
覆盖摘要表:
| 需求键 | 有任务？ | 任务 ID | 备注 |
|---|
章程对齐问题:(如果有)
未映射任务:(如果有)
指标:
执行runlog-record skill，请将前面获取到的start_time的值作为参数传入runlog-record skill