skill-feedback

技能反馈

概述

在技能会话完成后使用此功能。

**核心原则：**记录用户对某一项技能实际反馈的内容，展示即将发布的确切内容，并且只提交该内容。

使用此技能创建的反馈始终针对 folio-org/folio-eureka-ai-dev。

适用场景

适用于以下情况：

• 用户想要反馈刚使用过的技能；
• 会话已完成，且上下文仍足以进行总结；
• 反馈针对技能质量，而非一般的产品或仓库问题。

以下情况请勿使用：

• 用户仍在使用技能；
• 报告实际针对无关的错误或仓库问题；
• 对话涉及下游调优策略。

硬性规则

• 一份报告仅涵盖一项技能和一次已完成的会话。
• 切勿自动提交。只有在用户明确批准所展示的版本后才能发布。
• 正面反馈或没有重大问题的反馈都是完整有效的报告。
• 谨慎推断。无法根据会话确认的可选字段一律省略。
• 描述观察到的阻碍，而非用户的情绪。
• 不得包含机密、令牌或内部私有 URL。
• 不要求对 FOLIO 模块进行分类。

快速参考

步骤	要求
目标	一项技能，一次已完成的会话
规范	使用 references/report-template.md 中的字段、枚举值、标题和正文格式
收集反馈	使用用户已提供的反馈；最多提出一个中立问题
审阅	展示一次准确的可发布内容预览
决策	approve、edit 或 cancel
提交	依次使用可用的 GitHub issue 工具、已配置的 gh，然后是手动提交

如果此仓库包含手动 GitHub issue 模板，请确保其与 references/report-template.md 保持一致。即使没有该模板，此技能也必须能够正常工作。

工作流

1. 确定目标技能。用户明确指定的技能优先于推断结果。
2. 仅当确实存在多个合理候选时，才询问报告针对哪项技能。每份报告只涵盖一项技能。
3. 阅读会话内容，只提取风险较低且有用的信息：用户想完成什么、会话产出了什么、是否反复修正，以及格式或范围方面的问题。
4. 完成反馈收集（见下文）。
5. 使用 references/report-template.md 起草报告。仅将 references/example-report.md 用作风格示例。
6. 展示一次发布预览并询问用户如何决定（见下文）。
7. 用户选择 edit 时，修改内容并再次展示完整的更新版预览，然后再次询问。
8. 用户选择 cancel 时，停止操作，不创建 issue。
9. 用户批准后，提交（见下文）。
10. 确认提交成功后，返回 issue URL 并简短确认。不要重复显示 approve/edit/cancel 选项，也不要再次打印完整报告。

收集反馈

使用用户已提供的反馈。如果反馈尚不明确，可提出一个中立问题：“您想记录什么反馈——哪些方面效果良好、有哪些需要改进，还是没有重大问题？”正面反馈不需要提出改进建议。不要从普通的反复修改中推断用户不满意，也不要从沉默中推断用户满意。

• Nothing to improve 是有效的正面反馈或无重大问题反馈，不代表取消。
• 明确表示 cancel、do not record this 或撤回反馈时，应结束工作流，不提交任何内容。
• 不要为了填写可选元数据而提问。
• 没有上下文支持时，不要向用户罗列推测的问题。

单条评审内容

展示一份发布预览：仓库（folio-org/folio-eureka-ai-dev）、标签（skill-feedback）、确切的问题标题和完整的 Markdown 正文。所有 Agent 添加的内容和推断的元数据都必须显示在该预览中。不要另行单独评审“草稿字段”。只询问一次，用户是否批准、修改或取消所展示的版本。

明确的自然语言同意即视为批准；用户无需输入 approve 一词。如果标题、正文或任何新增字段之后发生变化，请展示完整的更新后预览，并再次征得批准。将未更改且已获批准的内容改用其他提交路径，本身不需要再次征求对话确认；运行时权限提示仍然适用。

提交

获得批准后，使用可用的 GitHub 问题创建工具；如果该路径不可用或被明确拒绝，则尝试使用已配置的本地 gh CLI。否则，提供已批准的内容供手动提交。超时或未收到响应并不能证明创建失败：再次写入前，先验证结果。发布前请阅读提交。

起草规则

• 优先采用对话中明确提及的技能。
• 如果会话中涉及多个技能，不要猜测。
• 不要将多个技能的反馈合并到一份报告中。
• 总结内容，不要大段复制对话记录。
• 不要包含机密、令牌、私有 URL 或不必要的标识符。
• 省略没有价值的可选部分。不要输出空标题或用 None 填充。

正确示例：

• Work context: product-requirement
• Primary feedback type: no-major-issues
• Observed friction signals: repeated scope corrections

错误示例：

• The user was frustrated
• The project was definitely mod-orders
• 为了避免章节为空而编造改进建议段落

FOLIO 处理

• project_hint 可以包含一个 FOLIO 模块、计划或领域，也可以省略。
• 仅当 FOLIO 术语在会话中明确出现且对报告有用时，才使用这些术语。
• 即使工作是在 FOLIO 环境中完成，报告也应聚焦于技能本身。

常见错误

• 用户表示技能运行良好时，仍追问问题。
• 将信息收集变成调查问卷，而不是简短跟进。
• 在将要发布的内容之外，单独评审草稿字段。
• 编辑后未重新展示完整预览就提交。
• 例行操作中将已批准的短正文写入临时文件。
• 结果不明确时，未经验证便重试写入。
• 根据有限证据推断情绪或意图。
• 将原始对话片段复制到问题正文中。

完成检查清单

创建问题前，请确认以下条件全部满足：

• 目标技能和用户反馈意图明确，且报告仅涉及一项技能；
• 没有编造投诉或正面结果；
• 未自动添加可选元数据或已移除的元数据；
• 已展示待发布的确切内容：仓库、标签、标题和完整正文；
• 用户批准的版本仍是当前版本；
• 提交的内容与获批版本一致，或者已如实说明需要手动提交或结果不确定；
• 未包含任何隐藏内容或敏感信息。