feedback-session

What this skill does

# /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.

**Dominant-source mismatch**: When the cwd has a git remote but the session's tool calls were dominated by a *different* plugin/source repo, this skill detects the mismatch and asks you to confirm which repo to file against — the cwd repo or the plugin source. See Step 1a for the full four-combination decision table.

## Context

Git remote and target-repo detection happens during Step 1a (execution), not
in this Context block. `git remote -v` and `gh repo view` both write to
stderr when invoked outside a git repository — and stderr from a Context
backtick aborts the skill before its body runs. `2>/dev/null` and `||` are
also blocked in Context commands (see `.claude/rules/agentic-permissions.md`),
so there is no fallback form that survives the no-git case. Step 1a's
dominant-source scan runs for both the cwd-with-remote and the no-remote
cases, and surfaces a mismatch-confirmation prompt when the session's plugin
activity points to a different repo than the cwd remote.

Open feedback issues are fetched during Step 3 (deduplication), scoped to the
resolved `$TARGET_REPO`. They are not pre-fetched in context because
`gh issue list` without `-R` requires a configured remote and fails with
"no git remotes found" in repos that lack one.

## 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**

Use this four-combination decision table to resolve `$TARGET_REPO`:

| `--target-repo` set? | cwd has remote? | Dominant source found? | Action |
|----------------------|-----------------|------------------------|--------|
| Yes | any | any | Use `--target-repo` value. Done. |
| No | No | Yes (≥70%, ≥3 refs) | Prompt: accept dominant source or enter free-text. |
| No | No | No | Prompt: free-text entry or abort. |
| No | Yes | Agrees with cwd remote | Use cwd remote silently. |
| No | Yes | Differs from cwd remote | Prompt: offer dominant source AND cwd remote as named choices. |

Execute the steps below to implement this table.

**Step A: Check for explicit `--target-repo` / `-R`.**

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. Skip the rest of this sub-step.

**Step B: Run the dominant-source scan (always).**

Walk the conversation transcript and tool-call history collecting every reference of the form `<plugin>:<skill>` (skill invocations like `/blueprint:init`, agent IDs like `agents-plugin:security-audit`, and plugin names mentioned in skill bodies). For each match, look up the owning `<owner>/<repo>` by enumerating directories under `~/.claude/plugins/cache/<owner>/<repo>/` and matching `<plugin>` against the cached plugin manifests. Tally references per `<owner>/<repo>`.

Compute the share per entry. If the top entry accounts for **more than ~70%** of total references **and** there are at least 3 references in total, treat it as dominant: record `$SUGGESTED_REPO` and `$N`.

**Step C: Attempt cwd remote detection.**

Run `gh repo view --json nameWithOwner -q '.nameWithOwner'`. If it succeeds, record the result as `$CWD_REPO`.

**Step D: Branch on the combination.**

- **No `$CWD_REPO` and no dominant source** — Use AskUserQuestion to ask the user to enter an `owner/repo` free-text. Validate against `^[A-Za-z0-9_.-]+/[A-Za-z0-9_.-]+$`, set `$TARGET_REPO`, and continue to Step 1b. If the user declines, exit the skill.

- **No `$CWD_REPO` and dominant source found** — Use AskUserQuestion to ask:

  > **No git remote found.** Suggested target: `$SUGGESTED_REPO` (derived from $N plugin skills referenced this session). Accept, or enter a different `owner/repo`?

  Options:
  1. **Accept `$SUGGESTED_REPO`** — set `$TARGET_REPO` to the suggestion and append `-R $TARGET_REPO` to every remaining `gh` command.
  2. **Enter a different `owner/repo`** — free-text follow-up; validate and set `$TARGET_REPO`.
  3. **Abort** — exit the skill.

  Continue to Step 1b once `$TARGET_REPO` is set.

- **`$CWD_REPO` present, no dominant source OR dominant source == `$CWD_REPO`** — use `$CWD_REPO` silently as the implicit target (`gh` defaults to cwd; no `-R` needed). Continue to Step 1b.

- **`$CWD_REPO` present AND dominant source differs from `$CWD_REPO`** — the session's plugin activity pointed mostly at a different repo than the cwd remote. Use AskUserQuestion to ask:

  > **Mismatch detected.** The session's tool calls were dominated by **`$SUGGESTED_REPO`** ($N references), but the current directory's git remote points to **`$CWD_REPO`**. Which repo should receive the feedback?

  Options:
  1. **`$SUGGESTED_REPO`** (plugin/skill source — dominant this session) — set `$TARGET_REPO` to `$SUGGESTED_REPO` and append `-R $TARGET_REPO` to all remaining `gh` commands.
  2. **`$CWD_REPO`** (cwd git remote — the application repo) — use `$CWD_REPO` silently (no `-R` needed).
  3. **Enter a different `owner/repo`** — free-text follow-up; validate and set `$TARGET_REPO`.
  4. **Abort** — exit the skill.

  Continue to Step 1b once the choice is resolved.

#### Dominant-source detection: parameters and tiering

The thresholds and prompt order above are deliberate. Keep them aligned when editing this step.

| Parameter | Value | Why |
|-----------|-------|-----|
| Dominance threshold | **> 70%** of total references | Lower thresholds risk wrong defaults on mixed sessions; higher would suppress correct suggestions on small ones |
| Minimum sample size | **≥ 3** references | Two references can both come from one stray skill mention; three is the smallest sample that survives one outlier |
| Prompt tiering | suggestion → free-text → abort | The user can correct a wrong guess in one keystroke without redoin