Create issue

Skill pavelsimo/skills/skills/create-issue

A collection of agent skills for AI-assisted development.

Install

npx -y skills add pavelsimo/skills --skill create-issue

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Turns a rough description into a structured GitHub issue with gitmoji title, problem statement, acceptance criteria, optional interview mode, and posting via gh CLI.

SKILL.md

5.0 KB, as published. Nobody here has run it

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 → bug
  - add / implement / support / new / feature → feat
  - refactor / simplify / clean / reorganize → refactor
  - perf / slow / cache / optimize / speed → perf
  - doc / readme / comment / guide → docs
  - test / spec / coverage → test
  - security / vuln / auth / sanitize / inject → security
  - style / 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