skill-feedback

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Skill Feedback

Skill反馈

Overview

概述

Use this after a completed skill session.

Core principle: produce one

machine-prepared, user-validated

report about one skill, show the full draft, then submit or hand it off without surprises.

Feedback created by this skill always targets

folio-org/folio-eureka-ai-dev

在完成Skill会话后使用此流程。

**核心原则：**生成一份关于单个Skill的「机器预处理、用户验证」报告，展示完整草稿，然后提交或移交，确保无意外情况。

此Skill创建的反馈始终指向

folio-org/folio-eureka-ai-dev

仓库。

When to Use

使用场景

Use when:

a user wants to leave feedback on a skill they just used;
the session is complete and still has enough context to summarize;
the feedback is about skill quality, not a generic product or repository issue.

Do not use when:

the user is still in the middle of using the skill;
the report is really about an unrelated bug or repo problem;
the conversation is about downstream tuning strategy.

适用于以下情况：

用户希望对刚使用过的Skill留下反馈；
会话已完成，且上下文仍足够清晰可总结；
反馈针对Skill质量，而非通用产品或仓库问题。

不适用于以下情况：

用户仍在使用Skill的过程中；
报告实际是关于无关的Bug或仓库问题；
对话内容涉及下游调优策略。

Hard Rules

硬性规则

One report covers one skill and one completed session.
No hidden fields in
```
v1
```
.
Never auto-submit.
Show the user the destination repo, issue title, and full body before submission.
Infer conservatively. If context is unclear, use
```
unknown
```
or leave the field empty.
Describe observed friction, not the user's emotions.
Do not require FOLIO module classification.

一份报告仅覆盖一个Skill和一次已完成的会话；
v1版本中无隐藏字段；
绝不自动提交；
在提交前向用户展示目标仓库、问题标题和完整内容；
保守推断。若上下文不明确，使用
```
unknown
```
或留空字段；
描述观察到的摩擦点，而非用户情绪；
无需要求进行FOLIO模块分类。

Quick Reference

快速参考

Step	Requirement
Target	One skill, one completed session
Contract	Use references/report-template.md for fields, enums, title, and body shape
Intake	One required question, one optional question when useful
Draft	Show all fields, inferred values, destination repo, title, and full body
Decision	`approve` , `edit` , or `cancel`
Submit	GitHub tool, then `gh` , then manual copy/paste

If this repository includes a manual GitHub issue template, keep it aligned with references/report-template.md. The skill must still work without that template.

步骤	要求
目标	单个Skill，一次已完成的会话
规范	使用references/report-template.md定义字段、枚举值、标题和内容结构
收集	一个必填问题，必要时增加一个可选问题
草稿	展示所有字段、推断值、目标仓库、标题和完整内容
决策	`approve` （批准）、 `edit` （编辑）或 `cancel` （取消）
提交	优先使用GitHub工具，其次使用 `gh` 命令，最后手动复制粘贴

若此仓库包含手动GitHub问题模板，需与references/report-template.md保持一致。即使没有该模板，此Skill仍需正常工作。

Workflow

工作流程

Identify the target skill from the session.
If more than one candidate skill appears plausible, ask the user to confirm which skill the report is about.
Read the session and extract only low-risk, useful signals:
- what the user was trying to do;
- what artifact the session produced;
- repeated corrections or reframing;
- format problems, scope drift, or missing context;
- likely
```
work_context
```
  and optional
```
project_hint
```
  .
Ask the user the minimum intake needed:
- Required:
```
What should this skill improve first?
```
- Optional when useful:
```
What worked well?
```
Draft the report using references/report-template.md. Use references/example-report.md only as a style example.
Show the entire draft to the user, including:
- all fields;
- all inferred values;
- the destination repo
```
folio-org/folio-eureka-ai-dev
```
  ;
- the full issue title;
- the full Markdown body.
Ask the user to choose one of:
- ```
approve
```
- ```
edit
```
- ```
cancel
```
If the user chooses
```
edit
```
, update the draft and show the full revised version again.
If the user chooses
```
cancel
```
, stop without creating an issue.
Only if the user chooses
```
approve
```
, submit using the first available path:

a GitHub issue creation tool for repo
```
folio-org/folio-eureka-ai-dev
```
;

write the approved body to

/tmp/skill-feedback.md

, then run

gh issue create --repo folio-org/folio-eureka-ai-dev --label skill-feedback --title "<title>" --body-file /tmp/skill-feedback.md

;

manual submission by handing the user the repo URL, final title, and final Markdown body.

从会话中识别目标Skill；
若有多个候选Skill看似合理，请用户确认报告针对哪个Skill；
读取会话内容，仅提取低风险、有用的信号：
- 用户尝试完成的任务；
- 会话生成的产物；
- 重复的修正或重新表述；
- 格式问题、范围偏离或缺失的上下文；
- 可能的
```
work_context
```
  （工作上下文）和可选的
```
project_hint
```
  （项目提示）。
向用户询问最少必要的信息：
- 必填：「此Skill最应优先改进的点是什么？」
- 必要时可选：「哪些部分表现良好？」
使用references/report-template.md撰写报告草稿。仅将references/example-report.md作为风格示例参考。
向用户展示完整草稿，包括：
- 所有字段；
- 所有推断值；
- 目标仓库
```
folio-org/folio-eureka-ai-dev
```
  ；
- 完整的问题标题；
- 完整的Markdown内容。
请用户选择以下选项之一：
- ```
approve
```
  （批准）
- ```
edit
```
  （编辑）
- ```
cancel
```
  （取消）
若用户选择
```
edit
```
，更新草稿并再次展示完整修订版本；
若用户选择
```
cancel
```
，终止流程，不创建问题；
仅当用户选择
```
approve
```
时，按以下优先级路径提交：
- 针对仓库
```
folio-org/folio-eureka-ai-dev
```
  的GitHub问题创建工具；
- 将批准后的内容写入
```
/tmp/skill-feedback.md
```
  ，然后运行命令
```
gh issue create --repo folio-org/folio-eureka-ai-dev --label skill-feedback --title "<title>" --body-file /tmp/skill-feedback.md
```
  ；
- 手动提交：向用户提供仓库URL、最终标题和最终Markdown内容。

Drafting Rules

草稿撰写规则

Prefer explicit skill usage from the conversation.
If the user named the skill directly, trust that.
If the session suggests multiple skills, do not guess.
Never merge feedback for multiple skills into one report.
Summarize instead of copying large transcript chunks.
Do not include secrets, tokens, private URLs, or unnecessary identifiers.
Avoid long verbatim excerpts.
Omit optional sections that add no value.

Good:

```
Work context: product-requirement
```
```
Project hint: unknown
```

Observed friction signals: repeated scope corrections

Bad:

```
The user was frustrated
```
```
The project was definitely mod-orders
```
```
The prompt design is weak
```

优先使用对话中明确的Skill使用记录；
若用户直接指定了Skill名称，以此为准；
若会话涉及多个Skill，请勿猜测；
绝不将多个Skill的反馈合并到一份报告中；
总结内容，而非复制大段会话记录；
不包含机密信息、令牌、私有URL或不必要的标识符；
避免过长的逐字摘录；
省略无价值的可选部分。

正确示例：

```
Work context: product-requirement
```
```
Project hint: unknown
```

Observed friction signals: repeated scope corrections

错误示例：

```
用户感到沮丧
```
```
项目肯定是mod-orders
```
```
提示设计很差
```

FOLIO Handling

FOLIO相关处理

```
project_hint
```
may contain a FOLIO module, initiative, or area, or remain empty.
Use FOLIO terminology only when it is visible in the session and useful for the report.
Keep the report about the skill itself, even when the work happened in a FOLIO context.

```
project_hint
```
可包含FOLIO模块、计划或领域，也可留空；
仅当会话中可见且对报告有用时，才使用FOLIO术语；
报告需聚焦Skill本身，即使工作场景在FOLIO环境中。

Common Mistakes

常见错误

Turning the intake into a survey instead of a short follow-up.
Treating
```
project_hint
```
as required.
Hiding inferred fields from the user.
Submitting without re-showing the full draft after edits.
Inferring emotions or intent from sparse evidence.
Turning the report into a tuning plan.
Copying raw transcript chunks into the issue body.

将信息收集变成调查，而非简短跟进；
将
```
project_hint
```
视为必填项；
向用户隐藏推断字段；
编辑后未重新展示完整草稿就提交；
根据稀疏证据推断用户情绪或意图；
将报告变成调优计划；
将原始会话片段复制到问题内容中。

Completion Check

完成检查

Before creating the issue, verify all of these are true:

the report is about one skill only;
the user answered the required improvement question;
the destination repo
```
folio-org/folio-eureka-ai-dev
```
was shown to the user;
the full issue title and body were shown to the user;
the user had a clear
```
approve
```
,
```
edit
```
, or
```
cancel
```
choice;
the final version reflects any user edits;
nothing hidden will be submitted.

在创建问题前，验证以下所有条件均已满足：

报告仅针对一个Skill；
用户已回答必填的改进问题；
已向用户展示目标仓库
```
folio-org/folio-eureka-ai-dev
```
；
已向用户展示完整的问题标题和内容；
用户有明确的
```
approve
```
、
```
edit
```
或
```
cancel
```
选项；
最终版本反映了用户的所有编辑；
提交内容无隐藏信息。