mcpField
A
agile-skill-feedback

agile-skill-feedback

github.com/djalmajrAgent 工作流4104 次安装5 周前更新
代码仓库

关于 agile-skill-feedback

agile-skill-feedback 根据实际交付中的证据改进技能库。它引导团队选择并记录小而可追溯的变更，同时明确验证与审批步骤。

主要功能

  1. 01收集技能使用中的问题证据
  2. 02判断优化、合并、拆分或生命周期操作
  3. 03生成结构化反馈文档
  4. 04提出最小且可追溯的变更
  5. 05定义验证与审批步骤

适用场景

  1. 01记录技能未能支持项目流程的情况
  2. 02评估经常配合使用的技能是否重叠
  3. 03为团队技能库提出经过验证的更新

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/djalmajr/skills --skill agile-skill-feedback

安装后在 Claude Code 中输入/agile-skill-feedback确认已加载。

附带文件templates/skill-feedback.md

详细介绍

技能反馈

使用此技能，根据实际交付证据改进技能库。此技能用于流程维护，而非泛泛构思。

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

如果 $ARGUMENTS 有内容，将其用作观察到的案例、工件路径、差异内容或反馈说明。如果为空，请询问观察到的问题以及涉及的技能。

语言

使用用户的语言编写工件。遵循正确的语法，并使用所需的变音符号或特定文字字符。

项目根目录

此技能会在项目根目录（工作所在的仓库）下的相对路径中写入工件，而不是在 Agent 当前工作目录中写入。

  • 如果在项目内部调用，请使用此技能中列出的相对路径。
  • 如果从其他目录调用（例如，在相邻仓库中调用，或项目位于其他位置），请在每个工件路径前加上 <project-root>/。
  • 如果项目根目录不明确，请在写入前通过 harness 提问工具向用户确认。

提问

遵循 CLAUDE.md / AGENTS.md 中的项目通用约定（“技能提问约定”）。对于以下决策点，使用 harness 的结构化提问工具 — AskUserQuestion（Claude Code）、ask_user_question（Codex）或 question（OpenCode）。

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

自由形式提问（无需结构化工具）：

  • 证据描述
  • 拟议的更改
  • 理由与权衡

无暂停模式：如果用户明确禁用了技能执行中的澄清，将每个结构化问题转换为“未决问题”或同等部分中的条目，并继续执行，不要暂停等待回答。

目标

  • 记录技能在实际使用中发生的情况
  • 决定采取优化、合并、拆分、弃用、移除还是新建
  • 保持技能更改精简、可追溯，并通过真实工件进行验证
  • 防止流程库因惯性而不断膨胀

适用场景

  • 某项技能或模板未能支持实际项目工作流
  • 两项技能存在重叠，或总是搭配使用并产生重复输出
  • 某项技能令人困惑、过时、很少有用或范围过广
  • 某个模板缺少必填字段，或产出的工件质量较低
  • TDD、优化、迭代规划、回顾或状态工作暴露出指导缺失
  • 产品希望生成技能库的拟议补丁

不适用场景

  • 创建常规规划工件 — 使用相应的敏捷技能
  • 审查应用代码 — 使用 /agile-refinement
  • 进行迭代回顾 — 使用 /agile-retro
  • 在没有敏捷或流程反馈的情况下从头创建通用技能 — 使用平台技能创建器

需收集的输入

  • 观察到的案例：项目、工件、用户故事、迭代、PR 或会话
  • 受影响的技能/模板
  • 触发该技能的条件（如果已知）
  • 预期行为
  • 实际摩擦或问题
  • 证据：工件路径、差异内容、测试、审查发现、用户修正或重复的手动步骤
  • 影响：困惑、返工、遗漏验证、输出质量差、流程重复或上下文成本

决策规则

优化

当技能选得正确，但需要调整说明、模板字段、示例或验证时使用。

合并

当两项技能的触发条件重叠、经常连续使用且会产生重复输出，并且不需要各自独立的工件或验证关卡时使用。

拆分
弃用或移除

当某项技能几乎没有实际用途、造成路由混乱、与另一项技能重复，或保留了已不再有帮助的流程时使用。如果已安装的用户可能仍依赖该技能，请优先弃用，再考虑移除。

创建

仅当某个重复出现的工作流在现有技能中没有合适的归属，且有具体示例时使用。

流程

  1. 阅读受影响的 SKILL.md，以及相关的本地模板/参考文件。
  2. 检查证据材料或差异。
  3. 对操作进行分类：优化、合并、拆分、弃用、移除或创建。
  4. 填写 templates/skill-feedback.md。
  5. 提出可行的最小改动。
  6. 定义验证方式：用哪份材料、提示词、测试或审查来证明改动有效。
  7. 对影响团队的工作流变更，必须先获得人工批准。

规则

  • 如果通过简洁地修改现有技能就能解决问题，请勿创建新技能。
  • 不要仅因技能相邻就合并；只有在输出和验证确实重复时才合并。
  • 保持 SKILL.md 简洁。仅在需要时，才将可复用的细节移至本地的 templates/、references/ 或 scripts/。
  • 模板必须放在技能文件夹内的 templates/ 下。
  • 保持可审计性：如果可用，记录源技能版本或提交。
  • 对于 AI 生成的补丁，如果已知，请在反馈材料中注明模型/提供方和审批状态。

保存位置

保存位置取决于反馈的主题：

  • 关于项目的流程材料 → 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，并将相关证据（日志、发现）放在其旁边。

模板

使用 templates/skill-feedback.md 作为基础材料。模板包含：

  • ## Auditability 区块（源技能版本/提交、模型/提供方、发起会话、相关发现）——填写已知信息。
  • 扩展后的审批 Status 枚举：proposed / approved / rejected / applied / partially-applied / withdrawn。如果补丁在正式批准前已落地，请如实使用 partially-applied，并填写 Partial application notes: 子字段。

与流程的关系

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

这项技能用于闭合流程反馈环。应在实际工作暴露出缺口后使用，而不是用来代替实际工作。

评论

支持 Markdown