agile-skill-feedback

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Skill Feedback

技能反馈

Use this skill to improve the skill library from real delivery evidence. It is for process maintenance, not generic brainstorming.

Initial context received via slash: $ARGUMENTS

$ARGUMENTS

is filled, use it as the observed case, artifact path, diff, or feedback note. If empty, ask for the observed problem and the skill involved.

使用此技能，基于实际交付证据改进技能库。它用于流程维护，而非一般性头脑风暴。

通过斜杠命令接收的初始上下文：$ARGUMENTS

若

$ARGUMENTS

已填写，将其用作观察案例、工件路径、差异或反馈记录。若为空，则询问用户观察到的问题及涉及的技能。

Language

语言

Write the artifact in the user's language. Apply correct grammar and any required diacritics or script-specific characters.

使用用户的语言编写工件。应用正确的语法及所需的变音符号或特定脚本字符。

Project root

项目根目录

This skill writes artifacts at paths relative to the project root (the repo where the work happens), not the agent's current working directory.

If invoked from inside the project, use the relative paths shown in this skill.
If invoked from another directory (e.g., a sibling repo, or when the project lives elsewhere), prepend
```
<project-root>/
```
to every artifact path.
When the project root is ambiguous, confirm with the user via the harness question tool before writing.

此技能以项目根目录（即开展工作的仓库）为基准写入工件路径，而非Agent的当前工作目录。

若从项目内部调用，使用本技能中显示的相对路径。
若从其他目录调用（例如同级仓库，或项目位于其他位置），在所有工件路径前添加
```
<project-root>/
```
。
当项目根目录不明确时，在写入前通过harness问题工具与用户确认。

Prompting

提示规范

Follow the project-wide convention in

CLAUDE.md

AGENTS.md

("Skill Prompting Conventions"). Use the harness's structured-question tool —

AskUserQuestion

(Claude Code),

ask_user_question

(Codex), or

question

(OpenCode) — for the decision points below. Use free-form text only where a path/name/value cannot be enumerated.

Decision point	Why structured	Suggested options
Action class	Drives the decision rule	Refine · Merge · Split · Deprecate · Remove · Create
Approval status (when finalizing)	Hard-to-undo step	Proposed · Approved · Rejected · Applied · Partially-applied · Withdrawn

Free-form prompts (no structured tool):

Evidence narration
Proposed change text
Rationale and trade-offs

No-pause mode: if the user has explicitly disabled mid-skill clarification, convert every structured prompt into an entry under Open questions (or equivalent) and proceed without blocking.

遵循

CLAUDE.md

AGENTS.md

中的项目级规范（"Skill Prompting Conventions"）。使用harness的结构化问题工具——

AskUserQuestion

（Claude Code）、

ask_user_question

（Codex）或

question

（OpenCode）处理以下决策点。仅当路径/名称/值无法枚举时，才使用自由格式文本。

决策点	使用结构化工具的原因	建议选项
操作类别	驱动决策规则	优化 · 合并 · 拆分 · 弃用 · 移除 · 创建
审批状态（最终确定时）	难以撤销的步骤	已提议 · 已批准 · 已拒绝 · 已应用 · 部分应用 · 已撤回

自由格式提示（不使用结构化工具）：

证据说明
拟议变更文本
理由与权衡

无暂停模式：若用户明确禁用技能执行中的澄清环节，将所有结构化提示转换为未解决问题（或等效项）下的条目，无需等待即可继续执行。

Objective

目标

Capture what happened during real use of a skill
Decide whether the right action is refine, merge, split, deprecate, remove, or create
Keep skill changes small, traceable, and validated against realistic artifacts
Prevent the process library from growing by inertia

记录技能实际使用过程中发生的情况
判断合适的操作：优化、合并、拆分、弃用、移除或创建
确保技能变更小而可追踪，并基于真实工件验证
防止流程库因惯性无限制增长

When to use

使用场景

A skill or template did not support a real project workflow
Two skills overlap or are always used together with duplicated output
A skill is confusing, stale, rarely useful, or too broad
A template is missing required fields or creates weak artifacts
TDD, refinement, sprint planning, retro, or status work exposes missing guidance
A product wants to generate a proposed patch to the skill library

技能或模板无法支持实际项目工作流程
两个技能存在重叠，或总是一起使用且输出重复
技能易混淆、过时、实用性低或范围过广
模板缺失必填字段，或生成的工件质量不佳
测试驱动开发（TDD）、需求细化、 sprint规划、回顾会或状态汇报工作暴露出指导缺失的问题
产品团队希望生成技能库的拟议补丁

When NOT to use

禁用场景

Creating a normal planning artifact -- use the appropriate agile skill
Reviewing application code -- use
```
/agile-refinement
```
Running a sprint retrospective -- use
```
/agile-retro
```
Creating a general-purpose skill from scratch with no agile/process feedback -- use the platform skill creator

创建常规规划工件——使用相应的敏捷技能
审查应用代码——使用
```
/agile-refinement
```
开展sprint回顾会——使用
```
/agile-retro
```
在无敏捷/流程反馈的情况下从头创建通用技能——使用平台技能创建工具

Inputs to collect

需要收集的输入信息

Observed case: project, artifact, story, sprint, PR, or session
Skill/template affected
Trigger that selected the skill, if known
Expected behavior
Actual friction or failure
Evidence: artifact path, diff, test, review finding, user correction, repeated manual step
Impact: confusion, rework, missed validation, bad output, duplicated process, context cost

观察案例：项目、工件、用户故事、sprint、PR或会话
受影响的技能/模板
若已知，选择该技能的触发条件
预期行为
实际遇到的阻碍或失败情况
证据：工件路径、差异、测试、审查结果、用户修正记录、重复的手动步骤
影响：混淆、返工、验证遗漏、输出质量差、流程重复、上下文成本

Decision rules

决策规则

Refine

优化

Use when the skill is right but instructions, template fields, examples, or validation need adjustment.

适用于技能本身合理，但说明、模板字段、示例或验证逻辑需要调整的场景。

Merge

合并

Use when two skills have overlapping triggers, are frequently chained with duplicated outputs, and do not need distinct artifacts or validation gates.

适用于两个技能触发条件重叠、经常链式使用且输出重复，且不需要独立工件或验证关卡的场景。

Split

拆分

Use when one skill handles multiple responsibilities with different audiences, templates, risks, or validation needs.

适用于一个技能承担多项职责，且面向不同受众、使用不同模板、存在不同风险或验证需求的场景。

Deprecate or remove

弃用或移除

Use when a skill has little real use, causes routing confusion, duplicates another skill, or preserves process that no longer helps. Prefer deprecation before removal if installed users may still depend on it.

适用于技能实际使用率低、导致路由混淆、重复其他技能，或保留的流程已无帮助的场景。若已有用户可能仍依赖该技能，优先选择弃用，再考虑移除。

Create

创建

Use only when a recurring workflow has no good home in existing skills and has concrete examples.

仅适用于重复出现的工作流程在现有技能中无合适归属，且有具体案例支撑的场景。

Process

流程

Read the affected
```
SKILL.md
```
and only the relevant local template/reference files.
Inspect the evidence artifact or diff.
Classify the action: refine, merge, split, deprecate, remove, or create.
Fill
```
templates/skill-feedback.md
```
.
Propose the smallest viable change.
Define validation: which artifact, prompt, test, or review will prove the change works.
Require human approval before applying workflow changes that affect a team.

阅读受影响的
```
SKILL.md
```
及相关的本地模板/参考文件。
检查证据工件或差异。
分类操作类型：优化、合并、拆分、弃用、移除或创建。
填写
```
templates/skill-feedback.md
```
。
提出最小可行变更方案。
定义验证方式：通过哪个工件、提示、测试或审查来证明变更有效。
在应用影响团队的工作流程变更前，需获得人工批准。

Rules

规则

Do not create a new skill if a concise change to an existing skill solves the problem.
Do not merge skills just because they are adjacent; merge only when outputs and validation are truly redundant.
Keep
```
SKILL.md
```
concise. Move reusable detail into local
```
templates/
```
,
```
references/
```
, or
```
scripts/
```
only when needed.
Templates must live inside the skill folder under
```
templates/
```
.
Preserve auditability: record source skill version or commit when available.
For AI-generated patches, include the model/provider and the approval status in the feedback artifact when known.

若对现有技能进行简洁修改即可解决问题，则无需创建新技能。
不要仅因技能相关就合并它们；仅当输出和验证确实冗余时才进行合并。
保持
```
SKILL.md
```
简洁。仅当需要时，将可复用细节移至本地
```
templates/
```
、
```
references/
```
或
```
scripts/
```
目录。
模板必须存放在技能文件夹下的
```
templates/
```
目录中。
保留可审计性：若有可用信息，记录源技能的版本或提交记录。
对于AI生成的补丁，在反馈工件中注明模型/提供商及审批状态（若已知）。

Where to save

保存位置

The save location depends on what the feedback is about:

About a project's process artifact →

planning/<initiative>/skill-feedback/<YYYY-MM-DD>-<slug>.md

About a skill in this skills repo →
```
<skills-repo>/feedback/<YYYY-MM-DD>-<skill>.md
```
. Until a dedicated
```
feedback/
```
folder exists at the root, use
```
samples/<sample>/proposals/skill-feedback-<YYYY-MM-DD>-<slug>.md
```
and keep the related evidence (journals, findings) next to it.

保存位置取决于反馈的对象：

针对项目流程工件的反馈 →

planning/<initiative>/skill-feedback/<YYYY-MM-DD>-<slug>.md

。

针对本技能仓库中技能的反馈 →
```
<skills-repo>/feedback/<YYYY-MM-DD>-<skill>.md
```
。在根目录下的专用
```
feedback/
```
文件夹创建前，使用
```
samples/<sample>/proposals/skill-feedback-<YYYY-MM-DD>-<slug>.md
```
，并将相关证据（日志、发现结果）放在其旁边。

Template

模板

Use

templates/skill-feedback.md

as the base artifact. The template includes:

An
```
## Auditability
```
block (source skill version/commit, model/provider, originating session, related findings) — fill what is known.

An extended approval

Status

enum:

proposed / approved / rejected / applied / partially-applied / withdrawn

. Use

partially-applied

honestly when patches landed before formal approval, and fill the

Partial application notes:

sub-field.

以

templates/skill-feedback.md

为基础工件。该模板包含：

```
## 可审计性
```
模块（源技能版本/提交记录、模型/提供商、发起会话、相关发现结果）——填写已知信息。

扩展的审批

状态

枚举：

proposed / approved / rejected / applied / partially-applied / withdrawn

。当补丁在正式批准前已落地时，如实使用

partially-applied

，并填写

Partial application notes:

子字段。

Relationship with the flow

与流程的关系

mermaid

flowchart LR
    A["Real skill usage"] --> B["Observed friction"]
    B --> C["/agile-skill-feedback"]
    C --> D{Decision}
    D --> E["Refine"]
    D --> F["Merge/Split"]
    D --> G["Deprecate/Remove"]
    D --> H["Create"]
    E --> I["Validate on real artifact"]
    F --> I
    G --> I
    H --> I

This skill closes the process feedback loop. It should be used after real work exposes a gap, not as a substitute for doing the work.

mermaid

flowchart LR
    A["Real skill usage"] --> B["Observed friction"]
    B --> C["/agile-skill-feedback"]
    C --> D{Decision}
    D --> E["Refine"]
    D --> F["Merge/Split"]
    D --> G["Deprecate/Remove"]
    D --> H["Create"]
    E --> I["Validate on real artifact"]
    F --> I
    G --> I
    H --> I

此技能闭合了流程反馈循环。它应在实际工作暴露出差距后使用，而非作为完成工作的替代方案。