Skill registry：任务方法、Prompt 片段与检查清单配置化

[keting]

这个 Discussion 想解决什么问题？

一句话：HALF 已经能生成通用任务 prompt，也有 process template / workflow preset 方向，但还缺少一层可复用的“任务方法约束”，例如 TDD、Review、Security、Refactor、Docs 这些做事方法无法作为独立对象被选择、版本化并拼进 prompt。

现在的麻烦：
现在可以通过手写任务描述、修改模板 JSON 或临时补充 prompt 来表达“先写测试”“重点审权限和输入校验”“保持外部行为不变”等要求。但这些要求散落在自由文本和模板里，不是可复用、可组合、可版本化的对象。工作流预设可以定义任务结构，却不能稳定表达某个节点应采用哪种执行方法。

不解决的后果：

• prompt 质量仍然依赖负责人当次书写和复制经验
• 团队反复调出来的方法无法稳定复用
• 工作流模板里“开发节点应采用 TDD 方法”“审查节点应采用 Review 方法”这类约束缺少标准承载
• 后续实验对比时，很难说清楚某次结果到底用了哪套方法约束

讨论清楚后能做什么：

• 把 TDD / Review / Security / Refactor / Docs 等方法沉淀成可复用 Skill
• 派任务时选择 Skill，生成 prompt 时自动拼接对应方法约束和检查清单
• 工作流预设可以给节点绑定 Skill，让团队方法被标准化下来

讨论范围

• Skill 的最小定义：prompt 片段、检查清单、任务约束、工具能力，还是工作流子图
• Skill 绑定位置：Task、Agent、Process Template / Workflow Preset、Project
• Skill 是否需要版本管理
• Skill 是否允许用户自定义
• Skill 如何影响任务 prompt
• Skill 与未来 Runner / Harness 的关系

与已有 Issue 的边界

• 与 将 reusable workflow templates 演进为可复用工作流预设 #56 的边界：将 reusable workflow templates 演进为可复用工作流预设 #56 讨论 workflow preset 如何组织节点结构、角色、任务卡片、handoff 和 agent 选择；本 Discussion 只讨论可复用方法约束如何作为 Skill 被绑定到任务、Agent 或 workflow 节点，并最终影响生成 prompt。
• 与 将任务输入输出标准化为结构化任务卡片 #53 的边界：将任务输入输出标准化为结构化任务卡片 #53 讨论任务输入输出 schema；Skill 讨论执行方法和检查清单。

非目标

• 不立即实现完整插件系统
• 不直接接入 MCP
• 不直接实现自动执行
• 不替代现有工作流模板或 将 reusable workflow templates 演进为可复用工作流预设 #56
• 不在近期承诺 Harness / Runner 能力

希望讨论的问题

1. HALF 中 Skill 的最小定义是什么？
2. Skill 应如何影响任务 prompt？
3. Skill 与 workflow preset 如何组合？
4. 首批内置 Skill 应该有哪些？
5. Skill 是否需要版本、适用任务类型、维护者和启用状态？
6. 讨论成熟后应拆成哪些 Issue？