| name | feature-request |
| description | Conversational workflow for gathering user feedback and filing GitHub Issues on the KiroCrew repository. Load when the user clicks "Request a Feature", wants to report a bug, or suggest an improvement. |
| triggers | request a feature, request feature, feature request, report a bug, bug report, file an issue, github issue, I have an idea, something's broken, suggestion |
Feature Request / Issue Report
Conversational workflow for gathering user feedback and creating GitHub Issues
on the KiroCrew repository.
Trigger: User clicks "Request a Feature" button, or says "report a bug",
"feature request", "I have an idea", "something's broken".
Repository
https://github.com/kirodotdev/KiroCrew
Shell safety (READ FIRST)
Everything the user types is untrusted. Never interpolate raw user text
(titles, descriptions, search keywords) into a shell command string, and never
put it in a shell heredoc — a heredoc ends on a line equal to its delimiter,
so a body containing a line that is exactly EOF (or whatever delimiter you
pick) would terminate it early and let the following lines execute as shell.
Follow these rules for every gh invocation below:
- Body & title: write them to temp files using your own file-writing tool
(not a shell heredoc, not
echo/cat >), then feed those files to gh.
Create the files with mktemp so the path is unpredictable and
per-invocation (no fixed /tmp/... name to clobber or symlink-attack).
- Pass the body with
--body-file "$BODY_FILE" (never --body "...").
- Load the title via command substitution into a double-quoted variable —
TITLE="$(cat "$TITLE_FILE")" — then pass --title "$TITLE". Command
substitution assigns the text literally (it is not re-parsed as shell) and
the double quotes contain word-splitting/globbing.
- Search keywords: derive a few plain alphanumeric words yourself from the
conversation and pass them as a double-quoted literal. Do not paste raw user
text (with its punctuation/metacharacters) into the search string.
- If you cannot safely pass a value, fall back to the copy/paste option
(Option 2) instead of shelling out.
Workflow
1. Greet & Identify
Ask the user what they'd like — a feature request or a bug report. Keep it
casual. Don't present a form.
2. Gather Details Conversationally
Guide the user to describe:
- What they want (or what's broken)
- Why it matters (what problem it solves)
- Any context (how they hit it, what they tried)
Don't force structure. Ask follow-up questions if the description is vague.
Two to three exchanges is usually enough.
3. Check for Duplicates
Search existing issues to avoid duplicates. Derive plain keywords yourself (a
few alphanumeric words) — do not paste raw user text:
gh issue list --repo kirodotdev/KiroCrew \
--search "your derived keywords" --state open --limit 10
If you find related issues, show them to the user and ask if any cover their
need. They may want to comment on an existing issue instead.
4. Draft the Issue
Compose a clean title and markdown body from the conversation. Structure:
## What
[One paragraph describing the feature/bug]
## Why
[Why this matters / what problem it solves]
## Additional Context
[Any extra details, reproduction steps, environment info]
Show the draft to the user for confirmation before submitting.
5. Pick Labels From the Repo's Live List
Never hard-code the label vocabulary here. Read it from the repository at
submit time, so labels added later are picked up without editing this skill:
gh label list --repo kirodotdev/KiroCrew --limit 100
Choose from what that command returns:
- Exactly one type label — the defect label for bug reports, the feature
label for requests. These are mutually exclusive; never apply both.
- At most one label per prefixed grouping dimension (e.g. a component
dimension, an OS dimension) when one clearly matches. Apply an OS label only
when the issue is genuinely specific to that OS — cross-platform issues get
none.
- If no value in a dimension fits, leave that dimension off. An unlabeled
dimension is better than a wrong one, and some issues legitimately belong to
no component.
Rules:
- Never create a new label. If the right value does not exist, mention the
gap to the user and submit without it — extending the taxonomy is a maintainer
decision, not a side effect of filing an issue.
- Do not apply automation-owned or triage-owned labels — review/readiness
process markers, severity or release-blocking markers, and follow-up or
blocked markers. A freshly filed request has no way to know those apply, and
the workflows that own them will set them.
Collect the chosen names for the submit step below.
If gh is unavailable or unauthenticated, gh label list fails and you cannot
read the taxonomy. Still apply a type label in that case — bug for defects,
enhancement for feature requests, the two that have always existed — and skip
the grouping dimensions, which are the part that grows. Do not guess a grouping
value you could not read.
6. Submit — Offer Three Options
Present all three and let the user choose:
Option 1: Pre-filled URL (if body ≤ 2000 chars)
Build a GitHub new-issue URL with query params:
https://github.com/kirodotdev/KiroCrew/issues/new?title=URL_ENCODED_TITLE&body=URL_ENCODED_BODY&labels=URL_ENCODED_LABELS
labels= takes the comma-separated names chosen in step 5. Percent-encode each
label name in full, not just its spaces: an unencoded & starts a new query
param and an unencoded # pushes the remainder into the URL fragment, either of
which silently drops the drafted body from the pre-filled issue. Encode the
separating comma as %2C.
Note: URL-encode the title and body. If the total URL exceeds ~4000 chars,
warn the user it may be truncated and recommend Option 2.
Option 2: Copy/paste
Show the formatted title and body in a code block the user can copy into
the GitHub new issue form at:
https://github.com/kirodotdev/KiroCrew/issues/new
Option 3: Direct creation via gh CLI
If the user prefers, create it directly. Do not hand-write the title/body
into the shell — use your file-writing tool to drop them into mktemp files,
then reference those files (see Shell safety above):
BODY_FILE=$(mktemp -t kc-issue-body.XXXXXX.md) — then write the confirmed
markdown body into it with your file-writing tool.TITLE_FILE=$(mktemp -t kc-issue-title.XXXXXX.txt) — then write the
confirmed title into it with your file-writing tool.- Create the issue, loading both from files so no untrusted text is parsed by
the shell:
TITLE="$(cat "$TITLE_FILE")"
gh issue create --repo kirodotdev/KiroCrew \
--title "$TITLE" \
--body-file "$BODY_FILE" \
--label '<type label>' \
--label '<grouping label, if one was chosen>'
Pass one --label flag per name chosen in step 5, each single-quoted. Label
names can contain spaces, and single quotes also keep a $ or backtick in a name
literal — double quotes would let the shell expand it. Omit the extra flags when
no grouping label applies.
This requires gh auth on the user's machine. If it fails with auth errors,
fall back to Option 2.
Labels
Do not maintain a label list in this file — it drifts from the repository. Read
the live list with gh label list (step 5) and follow the selection rules
there.
Guidelines
- Keep the conversation light — this isn't a support ticket form
- Two to three exchanges max before drafting
- Always show the draft before submitting
- If the user just wants to vent without filing, that's fine too — acknowledge
and offer to file if they want
