在动手写 skill 之前，先确认真实的重复工作。目标不是做问卷，而是避免把一个模糊想法过早包装成错误的结构。
- 用户只给了一个粗想法，还没有说明输入和输出。
- 这个 skill 可能被团队复用或公开发布。
- 触发边界和相邻请求容易混在一起。
- 用户给了上游项目、竞品、提示词或长对话，需要先判断借鉴范围。
如果用户已经给了足够信息，就直接做，并在动手前写出自己的假设。
- 它要长期接住哪一类重复任务。
- 用户或团队实际会给它什么输入。
- 做好以后应该交付什么文件、报告、命令、发布物或结论。
- 哪些相近请求不应该触发它。
- 最重要的标准是什么：速度、一致性、审计性、可发布、跨平台，还是团队风格。
- 有没有要借鉴的公开参考；只借结构和方法，不复制表达。
- 已有资产在哪里：脚本、模板、README、旧 skill、日志、样例。
适合模糊请求：
我们先不急着定结构。你先像聊天一样说说：这个 skill 以后最想帮你稳定接住哪类重复工作？别人通常会丢给它什么材料？它最后交回什么结果才算好用？
适合目标明确请求：
我先按可复用 skill 来做。我的默认假设是：它要处理的重复任务是 X，输入是 Y，输出是 Z，明确不做 A/B。如果这些假设不对，我会在动手前改。
当你能写出一句可防守的能力描述时，就停止追问：
这个 skill 接收 <真实输入>，用于 <重复任务>，输出 <可交付结果>，不处理 <相邻但不该触发的请求>。
不要因为想把结构做完整而继续问不影响设计的问题。