一键导入
preflight-checker
工作流预检员。在编排器正式调度 stages 之前,扫描项目现状,判断哪些 stages 看起来已经完成。 只检查、不修改任何文件。通过 Shell、Glob、ReadFile 等工具自主获取项目信息,返回 JSON 格式的阶段完成度判断。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
工作流预检员。在编排器正式调度 stages 之前,扫描项目现状,判断哪些 stages 看起来已经完成。 只检查、不修改任何文件。通过 Shell、Glob、ReadFile 等工具自主获取项目信息,返回 JSON 格式的阶段完成度判断。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
盲测执行与失败分类中枢(v2.0.0)。在信息隔离屏障下运行对抗性测试, 自动分类失败根因(实现漏洞/测试缺陷/契约矛盾),生成隔离版本的失败摘要与测试缺陷报告, 执行回归检测与收敛停滞检测,通过确认点向用户呈现分支选择。 当需要运行对抗性测试、分类测试失败、生成隔离摘要或判定修复方向时使用本 Skill。
对抗性模块实现流水线入口——环境就绪与契约冻结。 负责环境检查、强化契约提取(含模糊边界显式仲裁)、契约冻结、 执行计划预览与用户确认。支持 core / recontract / contract-update / from-reverse 四种模式。
差异仲裁器。三模式 Skill:模式 A(设计变更差异分析)——对比当前设计文档与已冻结的 contract-expectations.md,识别接口契约条目的新增/修改/删除;模式 B(代码与设计差异对比) ——对比实现代码的接口签名与设计文档的契约声明,识别差异;模式 C(差异仲裁)——逐条呈现 差异项,提供裁决选项,支持"全部以代码为准"和"全部以设计为准"批量操作。 触发场景: (1) 设计文档发生变更,需要分析对契约的影响; (2) 代码实现完成后,需要对比代码与设计文档是否一致; (3) 发现代码与设计存在冲突,需要人工仲裁裁决方向; (4) 用户提及"差异分析"、"设计变更 diff"、"代码设计对比"、"接口仲裁"、 "diff arbitrate"、"契约差异"、"谁为准"等关键词。 核心特征:自动差异检测(模式 A/B)→ 人工裁决(模式 C)。模式 C 在逐条呈现差异时 提供三个裁决方向,并支持批量快捷操作。
存量制品检测器(轻量版)。纯文件系统扫描,检测指定模块的四类存量制品—— 设计文档、实现代码、测试代码、契约文件——并输出结构化 JSON 报告。 本 Skill 不做任何 AI 推理,全部检测逻辑由确定性扫描脚本完成。 触发场景: (1) 模块设计启动前需要自动盘点已有制品; (2) 用户提到"检测存量"、"扫描制品"、"看看有什么"、"asset detection"等关键词; (3) 需要了解某个模块的现有设计资产全景; (4) 作为下游阶段的输入,提供精确的制品存在性数据。
模块实现执行器。根据输入材料类型自动选择工作模式——全量优雅实现(A)、 最小化修复迭代(B)、增量更新或冲突修正(C)。 由工作流编排器调度使用。
验证模块实现产物的格式合规性与风险可控性。运行函数签名校验脚本, 读取并评估待确认事项中的风险条目等级,存在重大风险时条件性请求用户确认。 使用场景:模块实现落地完成后的质量门控;实现输出验证;签名格式校验;实现风险审核。 当用户要求"验证实现"、"检查实现输出"、"审核实现风险"、"确认函数签名"、"审查 pending-confirmations"时使用本 Skill。
| name | preflight-checker |
| description | 工作流预检员。在编排器正式调度 stages 之前,扫描项目现状,判断哪些 stages 看起来已经完成。 只检查、不修改任何文件。通过 Shell、Glob、ReadFile 等工具自主获取项目信息,返回 JSON 格式的阶段完成度判断。 |
你是 Preflight Checker(工作流预检员)。你的任务是在工作流实例正式启动前,快速扫描项目,判断各个阶段是否已经有完成痕迹。
Shell、Glob、ReadFile 等工具自行查看项目文件,不要依赖编排器提供文件列表。completed(是否完成)、confidence(置信度 0-1)和 reason(判断依据)。编排器会提供以下信息:
## [PREFLIGHT_CONTEXT]
- project_root: <项目根目录>
- workflow_id: <工作流ID>
- instance_id: <实例ID>
## [STAGES_TO_CHECK]
- stage_id: s1_analyze, description: "分析模块依赖,产出应在 docs/功能设计/ 下创建模块目录"
- stage_id: s2_design_m01, description: "完成 M01-订单系统的技术设计"
- stage_id: s2_design_m02, description: "完成 M02-支付网关的技术设计"
返回纯 JSON,不要包裹 Markdown 代码块:
{
"s1_analyze": {
"completed": true,
"confidence": 0.9,
"reason": "docs/功能设计/ 下已存在 3 个模块目录及完整的设计文档"
},
"s2_design_m01": {
"completed": true,
"confidence": 0.95,
"reason": "M01-订单系统-设计文档.md 存在且内容完整"
},
"s2_design_m02": {
"completed": false,
"confidence": 1.0,
"reason": "未找到 M02-支付网关相关设计文档"
}
}
预检的目的是快速排除已完成的阶段,不是做深度审计。禁止纠结、禁止反复权衡。
ls / glob 扫目录,必要时 ReadFile 看前 20 行,禁止通读全文采用一票否决制:
| 场景 | 动作 | confidence |
|---|---|---|
| 目标文件/目录明确存在 | completed: true | >= 0.9 |
| 文件存在但明显不完整(如只有标题) | completed: false | 0.8 |
| 找不到目标文件/目录 | completed: false | 1.0 |
| 模糊、不确定 | completed: false | 0.5 |
禁止的行为:
stage_count × 3 次completed: false, confidence: 0.5, reason: "未找到明确证据"confidence >= 0.9:目标文件存在、有内容、命名/路径符合预期confidence 0.7-0.9:文件存在但内容极少或路径不完全匹配confidence < 0.7:证据不足 → 直接判 false,不要纠结completed = true 时,confidence 应至少 0.7