菜单
Create a GitHub issue with proper structure and metadata. Use when the user asks to create an issue, open a ticket, report a bug, or request a feature. Supports labels, assignees, milestones, and templates.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Create and switch to a new branch. Accepts a branch name or GitHub issue number. Derives branch name from issue title when an issue number is given. USE FOR: starting new work, branching from an issue, creating feature/bugfix branches. DO NOT USE FOR: committing, pushing, or managing PRs.
**WORKFLOW SKILL** — Stage changes, write clear commit messages, and commit following best practices. USE FOR: committing code changes; writing conventional commit messages; staging files before commits; amending previous commits; creating atomic commits; generating commit messages from diffs. DO NOT USE FOR: pushing to remote (use git push); resolving merge conflicts; branching or rebasing.
Create a GitHub pull request from the current branch. Use when the user asks to create a PR, open a pull request, or submit a PR for review. Assumes branch is pushed. Auto-generates title and description from commit history.
Create GitHub releases with automated versioning and changelog generation. Use for: publishing releases, creating tags, generating release notes, version bumping, semantic versioning.
Generate fix patches from pre-identified findings. Use when: generating code fixes from PR review comments, producing patches from scan results, translating described problems into code changes. DO NOT USE FOR: resolving GitHub issues (use resolve-issue); creating PRs (use create-pr); managing branches.
**WORKFLOW SKILL** — Systematically resolve GitHub issues from assignment through PR creation. USE FOR: working on assigned issues; following structured debugging workflows; implementing feature requests; fixing bugs reported in issues; creating focused PRs linked to issues. DO NOT USE FOR: creating new issues (use create-issue); reviewing PRs (use review-pr); general coding tasks without an issue context.
| name | create-issue |
| description | Create a GitHub issue with proper structure and metadata. Use when the user asks to create an issue, open a ticket, report a bug, or request a feature. Supports labels, assignees, milestones, and templates. |
| user-invocable | true |
| argument-hint | [optional: issue title or description] |
Create a well-structured GitHub issue with appropriate metadata.
git remote -vowner/repoAuto-detect issue type from the title/description using these heuristics:
| Keywords | Type |
|---|---|
fail, error, crash, broken, doesn't work, bug, wrong, regression | Bug |
add, support, implement, feature, new, enhance, improve, request | Feature |
fix typo, update docs, refactor, clean up, rename, move, migrate | Task |
If the type is ambiguous, ask the user to confirm. If confident, proceed without asking.
Infer from context (don't ask if already known):
Only ask if missing (don't prompt for optional fields the user didn't mention):
Use this template based on issue type:
Bug Report:
## Description
[Clear description of the bug]
## Steps to Reproduce
1. [Step 1]
2. [Step 2]
3. [Step 3]
## Expected Behavior
[What should happen]
## Actual Behavior
[What actually happens]
## Environment
- OS: [e.g., Windows 11, macOS 14]
- Browser: [if applicable]
- Version: [e.g., v1.2.3]
## Additional Context
[Any other relevant information, screenshots, logs]
Feature Request:
## Description
[Clear description of the feature]
## Problem Statement
[What problem does this solve?]
## Proposed Solution
[How should this work?]
## Alternatives Considered
[Other approaches considered]
## Additional Context
[Any mockups, examples, or references]
Task:
## Description
[What needs to be done]
## Acceptance Criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] [Criterion 3]
## Dependencies
[Any blockers or related issues]
## Timeline
[Expected completion, if applicable]
Before creating, present a concise summary:
Ask: "Create this issue?"
Suggestions are optional. Only present labels/assignees/milestones that were explicitly requested or automatically inferred. Don't add extra fields the user didn't ask for.
Use GitHub MCP tools (mcp_github_mcp_se_issue_write) to create the issue:
method: "create"owner: Repository ownerrepo: Repository nametitle: Generated titlebody: Generated descriptionlabels: Array of label namesassignees: Array of usernamesmilestone: Milestone number (if provided)If MCP tools are unavailable, fall back to gh CLI:
gh issue create --title "<title>" --body "<body>" --label "<label1>,<label2>" --assignee "<user1>,<user2>"
| User says | Action |
|---|---|
/create-issue | Interactive: gather all details step-by-step |
/create-issue Login fails with SSO | Create bug report with provided title |
/create-issue Add dark mode support | Create feature request |
/create-issue Fix typo in README | Create simple task issue |
git remote -v; ask only if inference failsThis skill works well with:
checkout-branch: After creating an issue, optionally suggest creating a branch with /checkout-branch <issue-number>commit: Optionally mention referencing the issue with Closes #<number> in commitscreate-pr: Optionally suggest linking a PR to close the issueKeep all integration suggestions brief and non-intrusive. Only mention them once, not repeatedly.