Skip to content

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

@keting

Description

@keting

Discussed in #65

Originally posted by keting April 30, 2026

这个 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 的边界

非目标

希望讨论的问题

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:backendBackend / Python / FastAPI relatedarea:docsDocumentation, guides, and contributor docsarea:frontendFrontend / React / UI relatedstatus:backlogValid and recorded, but not currently scheduledtype:researchTechnical investigation or feasibility research before implementation scope is known

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions