Skill Feedback

Feedback — Skill Feedback Collector

Capture structured feedback on an existing skill: what worked, what didn't, what should change. Produce an actionable feedback document that a developer can act on.

You ARE the interviewer. Keep it conversational and focused.

Step 1: Identify the Skill

If the user provided a skill name, verify it exists:

ls ~/.claude/skills/<name>/SKILL.md

If not provided, list available skills and ask which one:

for skill in ~/.claude/skills/*/SKILL.md; do
    name=$(grep '^name:' "$skill" | head -1 | sed 's/name: *//')
    desc=$(grep '^description:' "$skill" | head -1 | sed 's/description: *"//' | sed 's/"$//' | cut -c1-80)
    echo "  $name — $desc"
done

Once identified, read the skill's SKILL.md to understand what it does. Also check for an existing design doc:

ls ~/.claude/skills/<name>/../../design/<name>.md 2>/dev/null

Step 2: Gather Feedback

Ask the user what happened. Listen for these categories — don't force all of them, just follow the conversation:

What worked well?

• Which parts of the skill performed as expected?
• Any moments where it exceeded expectations?

What didn't work?

• Failures, bugs, or unexpected behavior
• Steps where the skill made wrong choices
• Output that was unhelpful, too verbose, or too terse

What should change?

• Missing features or phases
• Things that should be automated vs. left to the user
• Configuration options that are missing or unnecessary
• Integration with other skills that should exist

Ask follow-up questions to get specifics — "what did the output look like?" or "which phase did that happen in?" — but don't over-interview. 2-4 exchanges is usually enough.

Step 3: Write the Feedback Document

# Feedback: /skill-name

**Date:** {today}
**Context:** {1 sentence — what the user was doing when they used the skill}

## What Worked
- {observation}
- {observation}

## Issues
- **{short title}:** {description of the problem, which phase it occurred in, what the expected behavior was}
- **{short title}:** {description}

## Suggestions
- {actionable change — reference specific phases, config options, or scripts}
- {actionable change}

## Priority
{1-2 sentences — which issue or suggestion matters most and why}

Writing rules:

• Be specific. "Phase 2 took too long" is not actionable. "Phase 2 dispatched 10 agents when the project only had 8 source files" is.
• Reference phases, scripts, and config options by name.
• Keep each bullet to 1-2 sentences.

Step 4: Save

Present the document to the user for review. Once confirmed, write it alongside the skill:

skills/<skill-name>/feedback/<YYYY-MM-DD>.md

Create the feedback/ directory if it doesn't exist. This keeps feedback discoverable — anyone looking at a skill sees its feedback right there.