create-issue skill
Turn a rough description into a well-structured GitHub issue. The skill formats your input into a consistent template — gitmoji title, problem statement, acceptance criteria, and more — then posts it with gh issue create. An optional --interview mode reads the codebase first and asks targeted questions before drafting anything.
features
- auto-detects issue type (
feat, bug, chore, refactor, perf, docs, test, security, ui) from keywords and prefixes the title with the matching gitmoji
- builds a structured body: 🎯 Problem, 📋 Description, ✅ Acceptance Criteria, 🔁 Steps to Reproduce (bugs only), 💡 Technical Notes (optional)
--interview mode reads git ls-files, README, and key entry-point files before asking targeted questions- shows a full preview before posting — user can accept, edit, or cancel
--dry-run prints the gh issue create command without executing it--type flag lets you override auto-detection- posts via
gh issue create; works with --repo owner/repo for non-current repos
usage
/create-issue <description> # direct — build from description
/create-issue # interactive — ask for title + description
/create-issue --interview # interview mode: read repo, ask questions
/create-issue --type feat|bug|chore|refactor|perf|docs|test|security|ui
/create-issue --labels "bug,needs-triage"
/create-issue --repo owner/repo # target a specific repo
/create-issue --dry-run # preview without posting
workflow
Read reference/issue-format.md when selecting a gitmoji or rendering the issue body template.
parse args: extract <description>, --type, --labels, --repo, --dry-run, --interview
interview mode (if --interview):
- run
git ls-files to understand project structure
- read README and 2–3 key entry-point files for context
- ask in sequence:
- "What problem are you solving?" → 🎯 Problem section
- "Is this a bug, feature, chore, or other?" → determines issue type and gitmoji
- "Which files or areas of the codebase does this touch?" → informs 💡 Technical Notes
- "What does done look like? List acceptance criteria." → ✅ Acceptance Criteria
- "Any implementation hints or constraints? (press enter to skip)" → 💡 Technical Notes
- build the full template from answers
direct / interactive mode:
- if no
<description>: ask "Describe the issue:"
- derive a title from the description (short imperative phrase, no gitmoji yet)
- auto-detect type from keywords:
bug / error / crash / broken / fix → bugadd / implement / support / new / feature → featrefactor / simplify / clean / reorganize → refactorperf / slow / cache / optimize / speed → perfdoc / readme / comment / guide → docstest / spec / coverage → testsecurity / vuln / auth / sanitize / inject → securitystyle / ui / design / layout / css → ui- else →
chore
- if
--type was given, use it; skip auto-detection
- ask for acceptance criteria if none found in description
- ask "Any technical notes? (press enter to skip)"
build template: fill all sections; omit 🔁 Steps to Reproduce for non-bug types; omit 💡 Technical Notes if the user skipped; prefix title with matched gitmoji
show preview: print the full title + body and ask:
Create this issue? [yes / edit / cancel]
- edit: ask what to change, regenerate, show again
- cancel: stop — nothing is posted
- yes: proceed
post:
gh issue create \
--title "<gitmoji> <title>" \
--body "<body>" \
[--label <labels>] \
[--repo <owner/repo>]
- if
--dry-run: print the command above without running it
report: print the issue URL returned by gh
best practices
- never post without confirmation — always show the full preview and wait; never call
gh issue create without user approval
- keep titles short and imperative — one line, lowercase after the gitmoji, no period
- acceptance criteria are checkboxes — always use
- [ ] format so GitHub renders them as task items
- steps to reproduce are for bugs only — omit the section entirely for non-bug issues
- interview mode reads code, not history — use
git ls-files + file reads, not git log; keep it fast (2–3 files max)
- preserve user language — reformat structure but keep the user's words; don't paraphrase their domain knowledge away
- gitmoji goes on the title, not body headings — body section headings use the fixed emoji set from the template above
1---2name: create-issue3description: Turns a rough description into a structured GitHub issue with gitmoji title, problem statement, acceptance criteria, optional interview mode, and posting via gh CLI.4---56# create-issue skill78Turn a rough description into a well-structured GitHub issue. The skill formats your input into a consistent template — gitmoji title, problem statement, acceptance criteria, and more — then posts it with `gh issue create`. An optional `--interview` mode reads the codebase first and asks targeted questions before drafting anything.910## features1112- auto-detects issue type (`feat`, `bug`, `chore`, `refactor`, `perf`, `docs`, `test`, `security`, `ui`) from keywords and prefixes the title with the matching gitmoji13- builds a structured body: 🎯 Problem, 📋 Description, ✅ Acceptance Criteria, 🔁 Steps to Reproduce (bugs only), 💡 Technical Notes (optional)14- `--interview` mode reads `git ls-files`, README, and key entry-point files before asking targeted questions15- shows a full preview before posting — user can accept, edit, or cancel16- `--dry-run` prints the `gh issue create` command without executing it17- `--type` flag lets you override auto-detection18- posts via `gh issue create`; works with `--repo owner/repo` for non-current repos1920## usage2122```23/create-issue <description> # direct — build from description24/create-issue # interactive — ask for title + description25/create-issue --interview # interview mode: read repo, ask questions26/create-issue --type feat|bug|chore|refactor|perf|docs|test|security|ui27/create-issue --labels "bug,needs-triage"28/create-issue --repo owner/repo # target a specific repo29/create-issue --dry-run # preview without posting30```313233## workflow3435Read [reference/issue-format.md](reference/issue-format.md) when selecting a gitmoji or rendering the issue body template.36371. **parse args**: extract `<description>`, `--type`, `--labels`, `--repo`, `--dry-run`, `--interview`38392. **interview mode** (if `--interview`):40 - run `git ls-files` to understand project structure41 - read README and 2–3 key entry-point files for context42 - ask in sequence:43 - "What problem are you solving?" → 🎯 Problem section44 - "Is this a bug, feature, chore, or other?" → determines issue type and gitmoji45 - "Which files or areas of the codebase does this touch?" → informs 💡 Technical Notes46 - "What does done look like? List acceptance criteria." → ✅ Acceptance Criteria47 - "Any implementation hints or constraints? (press enter to skip)" → 💡 Technical Notes48 - build the full template from answers49503. **direct / interactive mode**:51 - if no `<description>`: ask "Describe the issue:"52 - derive a title from the description (short imperative phrase, no gitmoji yet)53 - auto-detect type from keywords:54 - `bug / error / crash / broken / fix` → `bug`55 - `add / implement / support / new / feature` → `feat`56 - `refactor / simplify / clean / reorganize` → `refactor`57 - `perf / slow / cache / optimize / speed` → `perf`58 - `doc / readme / comment / guide` → `docs`59 - `test / spec / coverage` → `test`60 - `security / vuln / auth / sanitize / inject` → `security`61 - `style / ui / design / layout / css` → `ui`62 - else → `chore`63 - if `--type` was given, use it; skip auto-detection64 - ask for acceptance criteria if none found in description65 - ask "Any technical notes? (press enter to skip)"66674. **build template**: fill all sections; omit 🔁 Steps to Reproduce for non-bug types; omit 💡 Technical Notes if the user skipped; prefix title with matched gitmoji68695. **show preview**: print the full title + body and ask:70 `Create this issue? [yes / edit / cancel]`71 - **edit**: ask what to change, regenerate, show again72 - **cancel**: stop — nothing is posted73 - **yes**: proceed74756. **post**:76 ```bash77 gh issue create \78 --title "<gitmoji> <title>" \79 --body "<body>" \80 [--label <labels>] \81 [--repo <owner/repo>]82 ```83 - if `--dry-run`: print the command above without running it84857. **report**: print the issue URL returned by `gh`8687## best practices8889- **never post without confirmation** — always show the full preview and wait; never call `gh issue create` without user approval90- **keep titles short and imperative** — one line, lowercase after the gitmoji, no period91- **acceptance criteria are checkboxes** — always use `- [ ]` format so GitHub renders them as task items92- **steps to reproduce are for bugs only** — omit the section entirely for non-bug issues93- **interview mode reads code, not history** — use `git ls-files` + file reads, not `git log`; keep it fast (2–3 files max)94- **preserve user language** — reformat structure but keep the user's words; don't paraphrase their domain knowledge away95- **gitmoji goes on the title, not body headings** — body section headings use the fixed emoji set from the template above
pavelsimo