agentsclimarketplace
Sign in

Create issue

Skill pavelsimo/skills/skills/create-issue

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

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.

SKILL.md

5.0 KB, ~1.2k tokens by cl100k_base, 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.

  1. parse args: extract <description>, --type, --labels, --repo, --dry-run, --interview

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

  3. 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)"

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

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

  6. post:

    gh issue create \
  --title "<gitmoji> <title>" \
  --body "<body>" \
  [--label <labels>] \
  [--repo <owner/repo>]
    • if --dry-run: print the command above without running it

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

What ships with it: 3 files

3.5 KB alongside SKILL.md

reference/

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.