# Skill Forge Feedback

> 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'.

- Skill: `wrathza/skill-forge-feedback` (Agent Skill)
- Install (CLI): `npx skillmds@latest add wrathza/skill-forge-feedback`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wrathza/skill-forge-feedback/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: WrathZA (https://skillmd.com/u/wrathza)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wrathza/skill-forge-feedback

---


# 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:
```bash
gh auth status
```

If exit code 0, write body to `/tmp/feedback-body.txt` (Write tool), then:
```bash
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.