feedback-session

Installation
SKILL.md
Contains Shell Commands

This skill contains shell command directives (!`command`) that may execute system commands. Review carefully before installing.

/feedback:session

Analyze the current session for skill feedback and create GitHub issues to track bugs, enhancements, and positive patterns.

When to Use This Skill

Use this skill when... Use alternative when...
A skill gave wrong or outdated guidance Want to update skills directly -> /project:distill
A command failed due to skill advice Need static skill quality analysis -> /health:audit
Discovered a better flag or pattern Want to capture general learnings -> /project:distill
A skill worked particularly well Want to track command usage stats -> /analytics-report
End of session, want to file feedback Need to fix a skill right now -> edit the SKILL.md directly
Feedback is about the plugin itself Use --target-repo laurigates/claude-plugins to file against the plugin source

Known Limitations

IaC-managed labels: Some repositories manage GitHub labels declaratively via Terraform, Pulumi, or similar tools. In these repos, gh label create will either be forbidden or cause drift that the IaC tool destroys on the next apply. This skill detects this case and offers a graceful fallback (see Step 1).

Default target repo: By default, this skill files issues against the repository in the current working directory. If you are giving feedback about a plugin skill itself rather than the application code in the session, use --target-repo <owner/repo> to point at the plugin source repo.

Context

  • Git remotes: !git remote -v
  • Open feedback issues: !gh issue list --label session-feedback --state open --json number,title --jq '.[].title'
  • Open positive issues: !gh issue list --label positive-feedback --state open --json number,title --jq '.[].title'

Parameters

Parse these from $ARGUMENTS:

Parameter Description
--dry-run Show findings without creating issues
--bugs-only Only report bugs (wrong/outdated guidance)
--enhancements-only Only report enhancement opportunities
--positive-only Only report positive feedback
--target-repo <owner/repo> File issues against this repo instead of the cwd repo
-R <owner/repo> Alias for --target-repo
[plugin-name] Scope analysis to a specific plugin

After parsing, set $TARGET_REPO to the value of --target-repo/-R if provided. Append -R $TARGET_REPO to all gh commands below when $TARGET_REPO is set.

Execution

Execute this session feedback workflow:

Step 1: Resolve target repo and ensure labels exist

1a. Determine target repo

If --target-repo or -R was passed in $ARGUMENTS, set $TARGET_REPO to that value and append -R $TARGET_REPO to every gh command in the remaining steps.

If not provided, infer the repo from the cwd: gh repo view --json nameWithOwner -q '.nameWithOwner'. Use this as the implicit target (no -R flag needed since gh defaults to cwd).

1b. Check whether labels are IaC-managed

Run: gh label list -R $TARGET_REPO --json name,description --jq '.[].description' (omit -R if no explicit target).

Scan the output for IaC indicators in any label description:

  • Keywords: terraform, pulumi, cdk, managed by, do not create, iac, infrastructure

Also check for labels.tf in the cwd: look for files matching **/labels.tf or **/labels.yaml patterns using Glob.

If IaC indicators are found or labels.tf / labels.yaml exist in the working tree:

  • Display a warning:

    ⚠ IaC-managed labels detected in <repo>.
    The `session-feedback` and `positive-feedback` labels cannot be created
    via `gh label create` — they are managed declaratively and creating them
    out-of-band would cause drift.
    
  • Use AskUserQuestion to ask: How would you like to proceed? Options:

    1. Proceed without session-feedback labels — issues will be created with only bug/enhancement labels; add the two labels to your IaC definition to backfill.
    2. Use a different target repo — enter an owner/repo where you can create labels freely (e.g. laurigates/claude-plugins).
    3. Abort — stop here.

    If user chooses option 2, set $TARGET_REPO to their input and re-run step 1b for the new repo. If user chooses option 3, exit. If user chooses option 1, set $SKIP_SESSION_LABELS=true and continue.

1c. Create missing labels (only when not IaC-managed)

Skip this step if $SKIP_SESSION_LABELS=true.

  1. Check if session-feedback exists: gh label list --json name --jq '.[].name' | grep -q session-feedback
  2. If missing: gh label create session-feedback --description "Feedback from session analysis" --color "d876e3"
  3. Check if positive-feedback exists similarly.
  4. If missing: gh label create positive-feedback --description "Skills that worked well" --color "0e8a16"

Step 2: Analyze conversation history

Review the entire conversation for feedback signals. Look for these categories:

Bugs (label: session-feedback, bug):

  • Skill gave wrong command syntax or outdated flags
  • Command failed because skill guidance was incorrect
  • Skill recommended a pattern that caused errors
  • Skill was missing a critical caveat or prerequisite

Enhancements (label: session-feedback, enhancement):

  • Discovered a better flag or option than what the skill suggests
  • Found a workflow gap the skill should cover
  • Identified a missing pattern or integration
  • Found a more efficient approach than the skill recommends

Positive (label: positive-feedback):

  • Skill provided correct, effective guidance
  • Skill's agentic optimizations saved time
  • Skill's decision table correctly directed to the right tool
  • Skill's patterns worked well in practice

For each finding, record:

  • Category: bug, enhancement, or positive
  • Plugin: which plugin the skill belongs to
  • Skill: which specific skill
  • Description: what happened
  • Evidence: the specific interaction or error that demonstrates it

Filter by $ARGUMENTS:

  • If --bugs-only: only report bugs
  • If --enhancements-only: only report enhancements
  • If --positive-only: only report positive feedback
  • If [plugin-name] specified: only report for that plugin

Step 3: Deduplicate against open issues

For each finding, search for existing issues in $TARGET_REPO:

gh issue list --label session-feedback --search "<skill-name> <key-phrase>" --json number,title --jq '.[].title'

Skip findings that match an existing open issue title. Note skipped items for the summary.

If $SKIP_SESSION_LABELS=true, search without labels: gh issue list --search "feedback(<plugin>)" --json number,title --jq '.[].title'

Step 4: Present findings for review

Use AskUserQuestion to present categorized findings. Group by category:

Format each finding as:

[BUG] plugin-name/skill-name: brief description
[ENH] plugin-name/skill-name: brief description
[POS] plugin-name/skill-name: brief description

Let the user select which findings to file as issues (use multiSelect).

If --dry-run, present findings and stop here.

Step 5: Create approved issues

For each approved finding, create a GitHub issue in $TARGET_REPO:

Title format: feedback(<plugin-name>): <description>

Labels (when not $SKIP_SESSION_LABELS):

  • Bugs: session-feedback, bug
  • Enhancements: session-feedback, enhancement
  • Positive: positive-feedback

Labels (when $SKIP_SESSION_LABELS=true):

  • Bugs: bug
  • Enhancements: enhancement
  • Positive: (no label — omit the --label flag)

Body template:

## Skill

`<plugin-name>/skills/<skill-name>/SKILL.md`

## Category

<Bug | Enhancement | Positive feedback>

## Description

<What happened during the session>

## Evidence

<Specific interaction, error message, or successful outcome>

## Suggested Action

<What should change in the skill, or what should be preserved>

Create each issue:

gh issue create --title "feedback(<plugin>): <desc>" --label "<labels>" --body "<body>"

Append -R $TARGET_REPO when set. Omit --label if no labels apply (positive + $SKIP_SESSION_LABELS).

Step 6: Report summary

Print a summary:

Metric Count
Findings identified N
Duplicates skipped N
Issues created N
Skipped by user N

List created issue numbers with links. If $SKIP_SESSION_LABELS=true, remind the user to add session-feedback and positive-feedback to their IaC label definition.

Agentic Optimizations

Context Command
List feedback issues gh issue list --label session-feedback --json number,title,labels -q '.[]'
Search for duplicates gh issue list --label session-feedback --search "keyword" --json title -q '.[].title'
Detect IaC label signals gh label list --json name,description --jq '.[].description'
Check label exists gh label list --json name -q '.[].name'
Create label gh label create name --description "desc" --color "hex"
Create issue (with target) gh issue create -R owner/repo --title "t" --label "l1,l2" --body "b"
Create issue (no labels) gh issue create -R owner/repo --title "t" --body "b"
Infer current repo gh repo view --json nameWithOwner -q '.nameWithOwner'

Quick Reference

Flag Description
--dry-run Show findings without creating issues
--bugs-only Only bug reports
--enhancements-only Only enhancement suggestions
--positive-only Only positive feedback
--target-repo <owner/repo> File issues against a different repo (e.g. plugin source)
-R <owner/repo> Alias for --target-repo
[plugin-name] Scope to specific plugin
Weekly Installs
33
GitHub Stars
29
First Seen
Feb 27, 2026