skill-forge-feedback

name	skill-forge-feedback
description	Collect user feedback (bugs, friction, feature requests) about skill-forge skills via a short interview, then file a structured GitHub issue. Use after any skill-forge workflow when something felt wrong, slow, or missing. Triggers: 'file feedback', 'report a bug', 'something felt off', 'I have a feature request', 'friction'.
compatibility	Direct filing requires gh CLI (authenticated) or GitHub MCP server; falls back to a pre-filled GitHub URL that any logged-in GitHub user can submit.

skill-forge-feedback

Capture friction before it evaporates. Interview → recap → permission check → file.

Phase 1 — Interview

Open with a single-key prompt:

What brought you here? (b)ug — something broke   (f)riction — something was slow or confusing   (r)equest — something is missing   (o)ther

After the user picks a type, ask targeted follow-ups one at a trytime:

Type	Key questions
Bug	Which skill? What happened? What did you expect? Can you reproduce it?
Friction	Which skill? Which step felt slow or confusing? What would have felt better?
Request	What were you trying to do? What's missing? How often do you hit this?
Other	What's on your mind? Which skill or workflow?

Keep asking until the user signals done (e.g., "that's it", "(d)one"). Do not stop after one answer — first answers are surface; follow-up gets the root.

Signal: (d)one — move to recap / (q)uit — abandon feedback without filing

Before displaying the recap, verify you can fill all five fields (WHAT, WHY, WHERE, HOW, WHEN) from what the user has said. Any field still "unknown" is your next question — ask it before moving on.

Phase 2 — Recap

Display the structured recap before filing:

## Feedback Recap

**WHAT:** [one-line summary]
**WHY:**  [impact — why this matters or what breaks]
**WHERE:** [which skill or workflow step]
**HOW:**  [steps to reproduce, or context for a request]
**WHEN:** [which session or workflow triggered this]

Ask: (a)ccept / (r)evise

Do not proceed until the user accepts. WHAT and WHERE must be non-empty — do not accept with either blank.

Phase 3 — Context Export Permission

Ask explicitly:

May I attach a transcript of this session for additional context? This uploads your conversation to a private GitHub Gist. (y)es / (n)o

• If y: use the session export mechanism (e.g. gh-weld-export) to generate a Gist URL, then append **Session transcript:** <url> to the issue body.
• If n: proceed without it. Do not ask again.

NEVER treat silence, ambiguity, or any non-y response as consent. Default is always n.

Phase 4 — File the Issue

Compose

Title: [<type>] <WHAT summary> — e.g. [friction] skill-forge-judge recap step unclear

Body:

## WHAT
<WHAT>

## WHY
<WHY>

## WHERE
<WHERE>

## HOW
<HOW>

## WHEN
<WHEN>

---
*Filed via skill-forge-feedback*

Labels: feedback + type label (bug / friction / feature / other)

Ensure the feedback, bug, friction, feature, and other labels exist in the repo before filing — gh issue create silently fails on unknown labels.

Detect filing method (in order)

1. gh CLI

Run:

gh auth status

If exit code 0, write body to /tmp/feedback-body.txt (Write tool), then:

gh issue create --repo WrathZA/skill-forge --title "[<type>] <summary>" --label "feedback,<type>" --body-file /tmp/feedback-body.txt

If gh issue create fails (non-zero exit), fall through to method 2.

2. GitHub MCP tools

If mcp__github__create_issue (or equivalent) is in your available tool list, use it to create the issue against WrathZA/skill-forge. If it fails, fall through to method 3.

3. Pre-filled URL fallback

Construct the URL — URL-encode title and body (spaces → %20, newlines → %0A, # → %23, [ → %5B, ] → %5D):

https://github.com/WrathZA/skill-forge/issues/new?title=<encoded-title>&body=<encoded-body>&labels=feedback,<type>

Output: Open this URL to submit your feedback: followed by the link.

If the encoded URL exceeds ~2000 chars, truncate the HOW field or drop WHEN — browsers silently clip URLs past this limit.

NEVER

• NEVER upload a context export without an explicit (y)es in Phase 3 Instead: Default to n; treat any ambiguous or absent response as n; do not ask again after a n. Why: Session transcripts contain private conversation history — uploading without explicit consent exposes sensitive context and violates user trust.

• NEVER write the issue body inline as a gh argument Instead: Write body to /tmp/feedback-body.txt with the Write tool, then pass --body-file /tmp/feedback-body.txt. Why: Multi-line bodies with # headers trigger Claude Code's permission check on every execution.

• NEVER chain Bash commands with && or ; in Bash tool calls Instead: Run each command as a separate Bash tool call. Why: Claude Code's safety check fires on multi-command calls and interrupts mid-flow.

• NEVER skip the Phase 2 recap Instead: Always show the WHAT/WHY/WHERE/HOW/WHEN structure and wait for (a)ccept. Why: Unreviewed feedback creates untriageable noise in the issue tracker.

• NEVER stop the interview after the first answer Instead: Ask at least one follow-up per type; continue until the user signals (d)one. Why: First answers are surface-level; root causes and real feature needs emerge in follow-up.