skill-forge-feedback

Name: skill-forge-feedback
Author: WrathZA

17stars0forks

How to install skill-forge-feedback?

wrathza/skillforge/skill-forge-feedback

$npx -y skills add WrathZA/skillforge --skill skill-forge-feedback

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# skill-forge-feedback
2
3	Capture friction before it evaporates. Interview → recap → permission check → file.
4
5	## Phase 1 — Interview
6
7	Open with a single-key prompt:
8
9	> What brought you here?
10	> (b)ug — something broke   (f)riction — something was slow or confusing   (r)equest — something is missing   (o)ther
11
12	After the user picks a type, ask targeted follow-ups one at a trytime:
13
14	\| Type \| Key questions \|
15	\|------\|--------------\|
16	\| Bug \| Which skill? What happened? What did you expect? Can you reproduce it? \|
17	\| Friction \| Which skill? Which step felt slow or confusing? What would have felt better? \|
18	\| Request \| What were you trying to do? What's missing? How often do you hit this? \|
19	\| Other \| What's on your mind? Which skill or workflow? \|
20
21	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.
22
23	Signal: (d)one — move to recap / (q)uit — abandon feedback without filing
24
25	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.
26
27	## Phase 2 — Recap
28
29	Display the structured recap before filing:
30
31	```
32	## Feedback Recap
33
34	WHAT: [one-line summary]
35	WHY: [impact — why this matters or what breaks]
36	WHERE: [which skill or workflow step]
37	HOW: [steps to reproduce, or context for a request]
38	WHEN: [which session or workflow triggered this]
39	```
40
41	Ask: (a)ccept / (r)evise
42
43	Do not proceed until the user accepts. WHAT and WHERE must be non-empty — do not accept with either blank.
44
45	## Phase 3 — Context Export Permission
46
47	Ask explicitly:
48
49	> May I attach a transcript of this session for additional context?
50	> This uploads your conversation to a private GitHub Gist.
51	> (y)es / (n)o
52
53	- 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.
54	- If `n`: proceed without it. Do not ask again.
55
56	NEVER treat silence, ambiguity, or any non-`y` response as consent. Default is always `n`.
57
58	## Phase 4 — File the Issue
59
60	### Compose
61
62	Title: `[<type>] <WHAT summary>` — e.g. `[friction] skill-forge-judge recap step unclear`
63
64	Body:
65	```
66	## WHAT
67	<WHAT>
68
69	## WHY
70	<WHY>
71
72	## WHERE
73	<WHERE>
74
75	## HOW
76	<HOW>
77
78	## WHEN
79	<WHEN>
80
81	---
82	Filed via skill-forge-feedback
83	```
84
85	Labels: `feedback` + type label (`bug` / `friction` / `feature` / `other`)
86
87	Ensure the `feedback`, `bug`, `friction`, `feature`, and `other` labels exist in the repo before filing — `gh issue create` silently fails on unknown labels.
88
89	### Detect filing method (in order)
90
91	1. gh CLI
92
93	Run:
94	```bash
95	gh auth status
96	```
97
98	If exit code 0, write body to `/tmp/feedback-body.txt` (Write tool), then:
99	```bash
100	gh issue create --repo WrathZA/skill-forge --title "[<type>] <summary>" --label "feedback,<type>" --body-file /tmp/feedback-body.txt
101	```
102
103	If `gh issue create` fails (non-zero exit), fall through to method 2.
104
105	2. GitHub MCP tools
106
107	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.
108
109	3. Pre-filled URL fallback
110
111	Construct the URL — URL-encode title and body (spaces → `%20`, newlines → `%0A`, `#` → `%23`, `[` → `%5B`, `]` → `%5D`):
112
113	```
114	https://github.com/WrathZA/skill-forge/issues/new?title=<encoded-title>&body=<encoded-body>&labels=feedback,<type>
115	```
116
117	Output: `Open this URL to submit your feedback:` followed by the link.
118
119	If the encoded URL exceeds ~2000 chars, truncate the HOW field or drop WHEN — browsers silently clip URLs past this limit.
120
121	## NEVER
122
123	- NEVER upload a context export without an explicit `(y)es` in Phase 3
124	Instead: Default to `n`; treat any ambiguous or absent response as `n`; do not ask again after a `n`.
125	Why: Session transcripts contain private conversation history — uploading without explicit consent exposes sensitive context and violates user trust.
126
127	- NEVER write the issue body inline as a `gh` argument
128	Instead: Write body to `/tmp/feedback-body.txt` with the Write tool, then pass `--body-file /tmp/feedback-body.txt`.
129	Why: Multi-line bodies with `#` headers trigger Claude Code's permission check on every execution.
130
131	- NEVER chain Bash commands with `&&` or `;` in Bash tool calls
132	**Ins

People who liked this also viewed

6 picks

Type

skill-forge-feedback

17stars0forks

View on GitHub

How to install skill-forge-feedback?

wrathza/skillforge/skill-forge-feedback

$npx -y skills add WrathZA/skillforge --skill skill-forge-feedback

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# skill-forge-feedback
2
3	Capture friction before it evaporates. Interview → recap → permission check → file.
4
5	## Phase 1 — Interview
6
7	Open with a single-key prompt:
8
9	> What brought you here?
10	> (b)ug — something broke   (f)riction — something was slow or confusing   (r)equest — something is missing   (o)ther
11
12	After the user picks a type, ask targeted follow-ups one at a trytime:
13
14	\| Type \| Key questions \|
15	\|------\|--------------\|
16	\| Bug \| Which skill? What happened? What did you expect? Can you reproduce it? \|
17	\| Friction \| Which skill? Which step felt slow or confusing? What would have felt better? \|
18	\| Request \| What were you trying to do? What's missing? How often do you hit this? \|
19	\| Other \| What's on your mind? Which skill or workflow? \|
20
21	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.
22
23	Signal: (d)one — move to recap / (q)uit — abandon feedback without filing
24
25	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.
26
27	## Phase 2 — Recap
28
29	Display the structured recap before filing:
30
31	```
32	## Feedback Recap
33
34	WHAT: [one-line summary]
35	WHY: [impact — why this matters or what breaks]
36	WHERE: [which skill or workflow step]
37	HOW: [steps to reproduce, or context for a request]
38	WHEN: [which session or workflow triggered this]
39	```
40
41	Ask: (a)ccept / (r)evise
42
43	Do not proceed until the user accepts. WHAT and WHERE must be non-empty — do not accept with either blank.
44
45	## Phase 3 — Context Export Permission
46
47	Ask explicitly:
48
49	> May I attach a transcript of this session for additional context?
50	> This uploads your conversation to a private GitHub Gist.
51	> (y)es / (n)o
52
53	- 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.
54	- If `n`: proceed without it. Do not ask again.
55
56	NEVER treat silence, ambiguity, or any non-`y` response as consent. Default is always `n`.
57
58	## Phase 4 — File the Issue
59
60	### Compose
61
62	Title: `[<type>] <WHAT summary>` — e.g. `[friction] skill-forge-judge recap step unclear`
63
64	Body:
65	```
66	## WHAT
67	<WHAT>
68
69	## WHY
70	<WHY>
71
72	## WHERE
73	<WHERE>
74
75	## HOW
76	<HOW>
77
78	## WHEN
79	<WHEN>
80
81	---
82	Filed via skill-forge-feedback
83	```
84
85	Labels: `feedback` + type label (`bug` / `friction` / `feature` / `other`)
86
87	Ensure the `feedback`, `bug`, `friction`, `feature`, and `other` labels exist in the repo before filing — `gh issue create` silently fails on unknown labels.
88
89	### Detect filing method (in order)
90
91	1. gh CLI
92
93	Run:
94	```bash
95	gh auth status
96	```
97
98	If exit code 0, write body to `/tmp/feedback-body.txt` (Write tool), then:
99	```bash
100	gh issue create --repo WrathZA/skill-forge --title "[<type>] <summary>" --label "feedback,<type>" --body-file /tmp/feedback-body.txt
101	```
102
103	If `gh issue create` fails (non-zero exit), fall through to method 2.
104
105	2. GitHub MCP tools
106
107	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.
108
109	3. Pre-filled URL fallback
110
111	Construct the URL — URL-encode title and body (spaces → `%20`, newlines → `%0A`, `#` → `%23`, `[` → `%5B`, `]` → `%5D`):
112
113	```
114	https://github.com/WrathZA/skill-forge/issues/new?title=<encoded-title>&body=<encoded-body>&labels=feedback,<type>
115	```
116
117	Output: `Open this URL to submit your feedback:` followed by the link.
118
119	If the encoded URL exceeds ~2000 chars, truncate the HOW field or drop WHEN — browsers silently clip URLs past this limit.
120
121	## NEVER
122
123	- NEVER upload a context export without an explicit `(y)es` in Phase 3
124	Instead: Default to `n`; treat any ambiguous or absent response as `n`; do not ask again after a `n`.
125	Why: Session transcripts contain private conversation history — uploading without explicit consent exposes sensitive context and violates user trust.
126
127	- NEVER write the issue body inline as a `gh` argument
128	Instead: Write body to `/tmp/feedback-body.txt` with the Write tool, then pass `--body-file /tmp/feedback-body.txt`.
129	Why: Multi-line bodies with `#` headers trigger Claude Code's permission check on every execution.
130
131	- NEVER chain Bash commands with `&&` or `;` in Bash tool calls
132	**Ins

People who liked this also viewed

6 picks

Type