hbardet/batch-features

批量功能（Batch features）

这是工作流的前半部分。后半部分是 work-issue。

你不是在转存积压任务。你是在将粗略的想法转化为一个智能体无需重新进行需求发现就能据以规划的问题。这意味着每个条目都要经过一次辩论，然后进行一次审批，最后才提交。

开始时声明：“我正在使用批量功能技能，将这份列表转化为问题。”

设置

shared/ 是这个技能旁边的目录 —— 安装后在 ~/.agents/skills/shared/，或者在克隆目录中为 ../shared/。如果 shared/... 路径无法解析，则使用另一个路径。

1. 阅读仓库：根目录下的 AGENTS.md（或 CLAUDE.md）。它对于约定具有约束力。
2. 如果存在 .agent-skills/config.json，则读取它；否则读取 shared/config.md，询问首次运行的问题，并写入该文件。
3. 读取 shared/tracker-adapter.md、shared/labels.md 和 shared/issue-template.md。
4. 检测问题追踪器。查看已有的标签和问题，以便新建的内容与之匹配。
5. 模板。 检查项目是否已有问题模板（.gitlab/issue_templates/*.md、.github/ISSUE_TEMPLATE/*.md）。如有，则使用它并将其路径记录在配置中作为 issueTemplate。如无，则记下你将在最后主动提供一次，将 shared/issue-template.md 提交到项目中。

辩论

逐个处理列表中的每个条目。对于每个条目：

1. 用自己的话重新表述它： 它是什么、服务于谁、为什么现在做。在问题正文的 Intent 下以逐字引用的方式保留原始措辞 —— 即使其余部分为英文。
2. 提出一个具体的解释。 不是“你这里想要什么？”而是“我把这理解为 X，因为 Y。如果你本意是 Z，请说一声。”
3. 最多提出两个问题。 每个问题必须具体，并且每个问题都必须附带一个用户可以用一个词接受的默认值。提问方式应优先选择最能改变构建结果的问题。如果用户要求全面审查，可以多问一些；否则只问两个。
4. 明确两件事： 验收标准（每个都是可观察和可检查的）和类型（feature / fix / refactor / chore）。其他都不要 —— 没有规模、没有领域、没有依赖关系。

如果一个条目在辩论后仍无法明确，则将其标记为 status::blocked 并附上 needs spec 注释，而不是猜测。提交一个模糊的问题比不提交更糟糕。

在所有条目辩论完成之前，不要进入提交阶段。

审查表

在最后一个条目之后，为整个批次呈现一个完整的表格：

| # | 标题 | 类型 |
|---|------|------|
| 1 | ... | feature |

然后请求批准。用户可以编辑标题、删除条目或更改类型。在此批准之前，不提交任何内容。

提交问题

对于每个已批准的条目，按用户偏好的顺序（默认为创建顺序）：

1. 使用问题追踪器 CLI 创建问题，正文优先使用项目自有的模板，否则使用 shared/issue-template.md。标题和正文使用配置中的 language（默认为 en）。
2. 应用标签：status::ready 和 kind::<kind>。记录问题编号。
3. 报告问题 URL。

如果用户的列表隐含了顺序（例如“先做 X 再做 Y”），则在问题正文的 Notes 中注明 —— 不要创建依赖关系或标签。

如果项目没有问题模板且用户接受了你的提议，则一次性将 shared/issue-template.md 提交到追踪器期望的路径，然后再提交问题。不要静默创建。

报告

最后，打印：

• 问题 URL，每行一个。
• 批次摘要：已提交 N 个，已阻止 M 个。
• 一行：“要开始工作，请说 work-issue <n>。”

硬性门控

• 未经审查表批准，不得创建问题。
• 不得创建 验收标准 或 验证 部分为空的问题。
• 不得创建范围存疑的问题：如果辩论后仍含糊不清，则标记为 status::blocked。
• 切勿从本技能中认领问题或开始实现；那是 work-issue 的职责。