step-contract-designer

name	step-contract-designer
description	轻量辅助用户设计或评估 Step Contract。用于用户想拆 step、限制 Agent 发散、检查某个 step 是否能达成目标、设计验证机制或诊断已有 step 时；只提供参考引导和诊断评估，不强制生成完整流程、不默认落地文件。

Step Contract Designer

核心定位

这个技能只做两件事：

1. 参考引导：帮用户想清楚一个任务应该怎么拆 step、每个 step 应该怎样收口。
2. 诊断评估：检查用户已有的 step 设计是否足够支撑目标，尤其检查验证机制是否靠谱。

它不是流水线生成器，不是框架安装器，也不是默认要落地文件的工具。用户只是想讨论、辅助设计或评估时，不要把事情升级成完整工程流程。

最重要原则

每个 step 都必须有验证机制。

但“怎样算合格”由用户决定。Agent 的职责是辅助用户把合格口径转成可执行或可检查的验证方式，而不是替用户规定什么叫正确。

不要把不可判定的语义判断伪装成硬门禁。不能自动判断时，就设计软检查或人工确认清单。没有验证环节的 step，默认不合格。

功能一：参考引导

当用户说“帮我设计 step”“这个任务怎么拆”“怎么限制 Agent 发散”时，按轻量方式引导：

1. 用一句话复述任务目标。
2. 给出建议 step 数量和每步一句话职责。
3. 对每个 step 只提醒三件事：
   • 最小产物是什么。
   • 用户认为怎样算合格。
   • 可以怎样验证。
4. 信息不足时只问一个最关键问题。

不要一开始要求用户填写完整字段表。不要默认生成目录、脚本、schema、RUNBOOK 或多阶段流程。真要落地文件，必须等用户明确要求。

参考引导的推荐输出：

## 建议拆分
- Step 1：...
- Step 2：...

## 每步收口
- Step 1
  - 最小产物：...
  - 合格标准：需要用户决定 / 默认建议 ...
  - 验证方式：...

## 需要你确认
<只问一个最关键问题>

功能二：诊断评估

当用户给出已有 step、流程、技能草案、validator 或测试结果时，优先做诊断，不要立刻重写。

诊断清单：

• 目标是否单一：一个 step 是否只解决一类问题。
• 输入是否够用：执行者是否知道从哪里拿数据。
• 最小产物是否明确：是否有文件、对象、文本块或可见结论。
• 合格标准是否来自用户口径：是否说明用户认为怎样算通过。
• 验证方式是否存在：不能只写“认真检查”“自我确认”。
• 验证方式是否适配风险：
  • 可机器判断的，用硬校验。
  • 语义和质量判断，用软检查。
  • 主观、高风险或业务口径不稳定的，用人工确认。
• 失败处理是否明确：验证失败后是停止、重试、降级，还是请用户确认。
• 是否存在跨 step 发散：当前 step 是否偷偷处理下一步、全局重构或额外目标。

诊断输出保持短：

## 结论
可用 / 需调整 / 风险较高

## 主要问题
- ...

## 建议修改
- ...

## 最小下一步
...

验证机制怎么设计

先问或提炼用户的合格标准，再选择验证方式。

常见三类验证：

• 硬校验：脚本退出码、文件存在、JSON schema、字段范围、唯一性、固定清单、可复现命令。
• 软检查：语义合理性、风格一致性、摘要质量、风险提醒、覆盖度清单。
• 人工确认：用户主观判断、业务审美、策略取舍、高风险发布前确认。

宽松目标就设计宽松验证，严格目标就设计严格验证。比如用户认为“好天气”这种宽泛表达也算合格，那 validator 就不应该强行要求精确天气枚举；它可以检查“是否有天气判断、是否有依据、是否没有明显矛盾”。

判断一个 step 是否合格

一个合格 step 至少能回答：

• 这一步只做什么？
• 输入从哪里来？
• 最小产物是什么？
• 用户认为怎样算合格？
• 怎样验证这个产物合格？
• 验证失败怎么办？

答不上来就说明 step 还太松。优先补验证机制，不要急着扩写流程。

禁止事项

• 不要把这个技能变成强制 Phase 流程。
• 不要默认要求用户设计完整流水线。
• 不要默认落地文件或修改业务代码。
• 不要替用户规定唯一正确标准。
• 不要把最后统一验收当成每个 step 的验证。
• 不要把“Agent 自检”当成唯一验证方式。