# Skill Feedback

> Use this skill when the user wants to give feedback on a skill, report a skill issue, suggest a skill improvement, or invokes '/skill-feedback'. Captures structured feedback on an existing skill and writes it to the skill's design or orders directory.

- Skill: `collinthefarmer/skill-feedback` (Agent Skill)
- Install (CLI): `npx skillmds@latest add collinthefarmer/skill-feedback`
- Raw SKILL.md: https://api.skillmd.com/api/skills/collinthefarmer/skill-feedback/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: collinthefarmer (https://skillmd.com/u/collinthefarmer)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/collinthefarmer/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:

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

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

```bash
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:

```bash
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

```markdown
# 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.