菜单
Draft and open a structured GitHub issue from a rough idea, with clarifying Q&A, labels, and type.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Research a work item, draft an implementation plan, and begin work after approval.
Guided one-shot install — discover installed plugins (or help install new ones), pick install scope, calibrate risk tolerance into a concrete allowlist + hooks, scaffold or merge CLAUDE.md, and sanity-check the result.
Finalize work — commit via /commit, push, and create PRs on feature branches.
Reviewer-side PR workflow — checks out the branch in a worktree, runs focus-area reviews plus a senior-engineering pass, optionally cross-checks against an autonomous reviewer, and posts inline findings only on explicit approval. Read-only — never edits, commits, or pushes.
Fetch PR review comments, classify by severity and confidence, and fix the selected subset.
Triage CVE and SBOM scanner output (Trivy, Grype, Snyk, Docker Scout, Dependabot) into a ranked, deduplicated action list.
| name | new-issue |
| description | Draft and open a structured GitHub issue from a rough idea, with clarifying Q&A, labels, and type. |
| user-invocable | true |
| disable-model-invocation | true |
| allowed-tools | Read, Grep, Glob, Bash, Agent, AskUserQuestion |
| argument-hint | ["rough idea","or blank to start interactively"] |
Draft and open a well-structured GitHub issue from a rough idea: clarifying Q&A, codebase context, duplicate detection, labels, and issue type — then gh issue create after explicit confirmation.
Sibling to /improve-issues: that skill enriches existing issues; this one authors new ones with the same level of care.
/new-issue <rough idea> — expand a one-line seed into a full issue./new-issue — fully interactive; the skill prompts for the seed./new-issue --batch — loop, drafting multiple issues in one session.Examples:
/new-issue add dark-mode toggle to settings
/new-issue dashboard times out when org has > 500 projects
/new-issue --batch
If an inline argument is present, treat it as the seed. Otherwise, ask via AskUserQuestion:
What problem or change does this issue describe? (one to three sentences)
Classify the seed as problem-first or solution-first. If the seed is solution-first ("add X button"), gently surface the underlying problem in step 2 — issues read better when they describe the problem before proposing a fix.
AskUserQuestionAsk the following questions in a single AskUserQuestion call (multiple questions, one round-trip):
Grep/Glob in step 3)gh label list --json name --jq '[.[].name]'); offer "none" as a valid choiceIf the user cannot articulate acceptance criteria, note this — do not invent them. The drafted issue will include a Needs acceptance criteria note in the body and a needs-triage label suggestion.
Use Grep / Glob against the affected area to surface concrete file references:
Then search for prior art:
gh issue list --state all --search "<keywords from seed>" --json number,title,state,url --limit 10
If a candidate looks like a near-duplicate (similar title or significant body overlap), present it and ask via AskUserQuestion:
Looks similar to #N. Continue creating, comment on the existing one instead, or cancel?
Only proceed past this point on explicit user choice. Never silently dedupe.
Structure every drafted body the same way:
## Summary
One to two sentences stating the problem or change.
## Context
Why this matters now — the motivation, user impact, or constraint that prompted it.
## Acceptance criteria
- [ ] Testable bullet one
- [ ] Testable bullet two
## Affected area
- `path/to/file.ext:42` — what this file does relative to the issue
- `path/to/other.ext` — secondary reference
## Related
- [#N](url) — related issue or PR title (omit section if none)
Title rules:
pr-description convention).[scope] prefixes — labels carry that signal.Show the user a single rendered preview:
Title: <title>
Type: <Bug | Feature | Chore | Docs | Refactor | Question>
Labels: <comma-separated>
<body>
Then ask via AskUserQuestion:
Create this issue, revise, or cancel?
Options: Create as shown / Revise (loop back to step 4 with the user's edits) / Cancel.
Never call gh issue create without an explicit "Create as shown" choice.
On confirmation, create the issue with a HEREDOC pattern so multi-line formatting is preserved:
gh issue create \
--title "<title>" \
--label "<label1>,<label2>" \
--body "$(cat <<'EOF'
<body>
EOF
)"
After creation, set the issue type via GitHub's GraphQL API (same pattern /improve-issues uses for the built-in issue type field — not a label). If the repo has no issue types configured, skip silently.
Report the new issue URL back to the user.
If invoked with --batch, after each successful create ask via AskUserQuestion:
Draft another issue, or finish?
On "Draft another", return to step 1 with no seed (fully interactive). On "Finish", print a one-line summary of every issue created in the session:
Created 3 issues:
- [#412](url) — <title>
- [#413](url) — <title>
- [#414](url) — <title>
gh call per Bash invocation. The repo's never-chain-git rule extends to gh: separate gh label list, gh issue list, and gh issue create into discrete calls so the allowlist matches and intermediate output is inspectable.needs-triage label suggestion.gh label list, not invention. If no suitable label exists, do not propose one — flag it instead and let the user add it manually.