Skip to content

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

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?

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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