Skill feedback loop: let skills collect user feedback for iterative improvement

Resolved 💬 2 comments Opened Mar 19, 2026 by lswith Closed Mar 19, 2026

Problem

There's no way to close the feedback loop on skill quality. When a skill runs and produces a suboptimal result, the user corrects Claude in the conversation — but that feedback disappears when the session ends. There's no mechanism to accumulate feedback over time and use it to improve skills.

Proposed Solution

Add a first-class skill feedback mechanism:

  1. After a skill executes, Claude Code prompts the user for quick feedback (similar to the existing 0-3 session satisfaction prompt, but scoped to the skill)
  2. If negative, capture the user's correction/context
  3. Store feedback locally in a standard location (e.g., skills/<skill-name>/feedback.log or ~/.claude/skill-feedback/)
  4. Make feedback accessible so that skill iteration tooling (like the skill-creator) can read accumulated feedback and use it as test cases for improvement

Possible implementation

A new frontmatter field in SKILL.md:

---
name: my-skill
description: ...
feedback: true  # Prompts for feedback after skill execution
---

When feedback: true, Claude Code:

  • Detects when the skill's execution is "complete" (heuristic or explicit signal)
  • Shows a lightweight prompt: "Did the skill help? (y/n)"
  • If no, captures the next user message as feedback context
  • Appends to a local feedback log with timestamp, prompt, and correction

Why this matters

Skills are most valuable when they teach Claude non-obvious things. But without feedback data, skill authors can't tell:

  • Which parts of the skill are actually helping
  • Which instructions Claude is ignoring or misinterpreting
  • Whether the skill is even triggering when it should

The skill-creator tooling already supports eval loops (run prompts with/without skill, compare, iterate). The missing piece is real-world feedback from actual usage flowing back into that loop.

Alternative considered

  • Hooks: Stop, SessionEnd, and UserPromptSubmit hooks could approximate this, but none of them fire specifically when a skill finishes executing. A PostToolUse hook on the Skill tool could detect skill invocation but can't tell when the skill's "task" is done.
  • Manual tracking: Users can tell Claude to "remember this went wrong" but this relies on the user interrupting their flow and is easy to forget.

Additional Context

This came up while auditing a plugin marketplace. We found that several skills were teaching things Claude already knew or making claims that didn't hold up under testing (e.g., a Slack formatting skill whose main advice was based on a MCP parameter that didn't exist). A feedback loop would surface these issues from real usage rather than requiring manual audits.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗