Menu
Create a GitHub issue from a summary description. Drafts the title and body, shows a preview, and asks for confirmation before publishing.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Thorough peer code review of a PR or branch — correctness, bugs, logic errors, edge cases, code quality, simplicity, naming, test coverage. Takes a PR number or base branch argument. Pulls PR metadata via gh if available.
Autonomous Quint formal specification workflow — generate specs (new or from codebase), typecheck, create witnesses, run invariants, and verify. Like plan mode but for formal specs.
Merge a branch into the current branch — detect conflicts, summarize them, and resolve them automatically where possible. Asks the user when unsure which changes to keep.
Write a commit message following the project template and save it to commit.msg
Verify documentation (README, runbooks, module docs) aligns with the actual codebase and fix any drift
Generate a PR summary from all commits since the branch diverged from a given parent branch, written to pr-summary.msg
| name | gh-issue |
| description | Create a GitHub issue from a summary description. Drafts the title and body, shows a preview, and asks for confirmation before publishing. |
| allowed-tools | Bash, Read, Grep, Glob, AskUserQuestion |
Draft and create a GitHub issue from a plain-language description. Always previews before publishing.
Arguments: $ARGUMENTS
If $ARGUMENTS is empty or missing, ask the user:
What's the issue? Give me a summary and I'll draft it up.
Wait for their response before proceeding. Use their response as the issue description.
If $ARGUMENTS is provided, use it as the issue description.
Scan the codebase for relevant context that would make the issue more useful:
CLAUDE.md if it exists for project conventionsgit log --oneline -10 to see if related recent work provides contextDo NOT spend excessive time here — just enough to write a well-informed issue.
Using the user's description and any gathered context, draft:
Title: A concise, specific issue title (under 80 characters). Lead with the area or component if applicable (e.g. "auth: session token not refreshed on password change").
Body: Structure using this format:
## Description
[Clear explanation of the problem or feature request, expanded from the user's summary]
## Context
[Any relevant details discovered from the codebase — affected files, related code, recent changes. Omit this section if there's nothing useful to add.]
## Steps to Reproduce
[If this is a bug report and reproduction steps can be inferred. Omit for feature requests or if unclear.]
## Expected Behavior
[What should happen. Omit if obvious from the description.]
## Acceptance Criteria
[Concrete conditions for this issue to be considered done. Omit for exploratory or investigative issues.]
Omit any sections that don't apply — don't include empty sections or force content that isn't there. Keep it focused.
Present the drafted issue to the user in a clear preview:
--- Issue Preview ---
Title: <drafted title>
<drafted body>
--- End Preview ---
Then ask the user:
Does this look good? I can create it as-is, or you can tell me what to change.
Wait for the user to confirm. Do NOT create the issue until the user explicitly approves. If the user requests changes, revise the draft and preview again.
Once the user confirms, create the issue:
gh issue create --title "<title>" --body "$(cat <<'EOF'
<body>
EOF
)"
Display the resulting issue URL to the user.
After creating the issue, if the user mentioned labels or if labels are obvious from the content (e.g. "bug", "enhancement"), suggest adding them:
gh issue edit <number> --add-label "<label>"
Only suggest — do not add labels without asking.