Run any Skill in Manus with one click

issue-pr

Stars3

Forks0

UpdatedMarch 27, 2026 at 04:07

Create GitHub issues and pull requests using the gh CLI. Use this skill when the user says "/issue-pr", asks to "create an issue", "open a PR", "file a bug", "create a pull request", "make issues for these", or wants to batch-create multiple issues from a plan. Also triggers for "open PR targeting stg" or "create issues from this list".

Installation

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.

Run Skill in Manus

Source

gorira-tatsu

gorira-tatsu/aminet

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	issue-pr
description	Create GitHub issues and pull requests using the gh CLI. Use this skill when the user says "/issue-pr", asks to "create an issue", "open a PR", "file a bug", "create a pull request", "make issues for these", or wants to batch-create multiple issues from a plan. Also triggers for "open PR targeting stg" or "create issues from this list".
argument-hint	issue <title> [--label <label>] \| pr [--base <branch>] \| issues <list>
allowed-tools	["Bash(gh issue:)","Bash(gh pr:)","Bash(git log:)","Bash(git diff:)","Bash(git branch:)","Bash(git push:)","Bash(git remote:*)","Read","Glob","Grep"]

GitHub Issue & PR Creator

Create GitHub issues and pull requests with proper formatting, labels, and cross-references.

Arguments

The user invoked this with: $ARGUMENTS

Parsing the arguments

Determine the mode from the first word:

issue — create a single issue
pr — create a pull request
issues — batch-create multiple issues
If empty or ambiguous, ask the user what they want to create

Safety: preview before creating

Issues and PRs are visible to the team and hard to undo cleanly. By default, always show a preview of what will be created and ask for confirmation before running the gh command. This applies to all modes.

The only exception is when the user explicitly says "just create it", "no preview", or similar — then proceed directly.

Example preview format:

## Preview: PR

Title: feat: add private package support
Base: stg <- feat/private-package-support
Body: [rendered summary]
Labels: (none)
Closes: #5

Create this PR? [y/n]

Mode: Create Issue

Usage: /issue-pr issue "title" [--label bug|enhancement|...] [--body "description"]

Steps

If title or body is missing, infer from conversation context or ask
Check for existing open issues with similar titles to avoid duplicates:
```
gh issue list --state open --search "<title keywords>"
```
If a close match exists, warn the user before proceeding.
Determine the appropriate label from context:
- Bug reports → bug
- New features → enhancement
- Documentation → documentation
Check if the repo has issue templates (.github/ISSUE_TEMPLATE/). If templates exist, structure the body to match the relevant template's sections.

Show preview, then create on confirmation:

gh issue create --title "<title>" --label "<label>" --body "<body>"

Report the issue URL back to the user

Mode: Create PR

Usage: /issue-pr pr [--base <branch>]

Steps

Check for existing PR: Before anything else, check if a PR already exists for this branch:
```
gh pr view --json number,url 2>/dev/null
```
If one exists, show its URL and ask if the user wants to update it or create a new one.
Detect base branch: Use --base if provided. Otherwise, detect intelligently:
```
git branch -r | grep -E 'origin/(stg|staging|develop|main|master)' | head -5
```
Priority order: stg > staging > develop > main > master. If multiple candidates exist, show the options and ask the user.
Gather context:
- git log <base>..HEAD --oneline to see commits in this branch
- git diff <base>...HEAD --stat to see changed files
- Read commit messages to understand the changes

Load PR template: Check for .github/pull_request_template.md. If it exists, use its structure for the PR body. If not, use this default:

## Summary
<1-3 bullet points summarizing the changes>

## Testing
- [ ] Lint passes
- [ ] Tests pass

## Notes
<any additional context>

Link related issues: Scan commit messages for issue references (#N, Closes #N, Fixes #N) and include them in the PR body.
Preview and create:
- Show the full preview (title, base, body, linked issues)
- On confirmation, push the branch if needed: git push -u origin <branch>
- Create the PR: gh pr create --base <base> --title "..." --body "..."
Report the PR URL back to the user.

Mode: Batch Create Issues

Usage: /issue-pr issues (reads from conversation context or a provided list)

Steps

Parse the list of issues from conversation context or explicit argument text
Show a numbered preview of all issues to be created
After confirmation, create each using the single-issue flow
Report all created issue URLs as a summary table

Rules

Always write issue and PR content in English
Use conventional commit prefixes in PR titles when applicable (feat:, fix:, docs:, chore:)
Never create duplicate issues — always check existing open issues first
Include Closes #N in PR body when the PR resolves a known issue
For PRs, always check if the branch needs pushing before creating
Default to preview mode. Only skip preview when the user explicitly opts out.

More from this repository

same repository

issue-implementation-train

gorira-tatsu/aminet

Implement an explicit set of GitHub issues end-to-end for this repository, using isolated worktrees, one branch per issue, targeted tests, pushes, and pull requests against `stg`. Use this when the user asks to implement specific issues, execute a planned batch of roadmap issues, or drive issue work through PR-ready completion. This skill is repo-specific: it never defaults to all open issues, requires an explicit issue set, and stops after initial PR creation rather than handling review follow-up.

2026-03-283

roadmap-issue-batch

gorira-tatsu/aminet

Create a deduplicated batch of GitHub issues from roadmap documents, release plans, or report files. Use this when the user asks to turn a roadmap into issues, create missing issues from a plan, or bulk-file issues for a version or milestone. This skill is repo-specific: it prefers `report/` planning artifacts, uses the repository issue templates, writes issue content in English, and always previews the batch before creation unless the user explicitly opts out.

2026-03-283

roadmap-planning

gorira-tatsu/aminet

Plan long-term milestones and version roadmaps from the current state of issues, pull requests, release history, and project goals. Use this skill when the user says "/roadmap-planning", asks to "plan the next milestone", "decide what goes into the next version", "make a roadmap", "group issues by release", "plan 0.x.y / 1.0", or wants a phased release plan across multiple future versions.

2026-03-283

docs

gorira-tatsu/aminet

Generate or update project documentation based on code changes. Use this skill when the user says "/docs", asks to update documentation, wants to document recent changes, or needs to generate README, CONTRIBUTING, or API docs. Also triggers when the user mentions "update the docs", "write documentation", "document this", "add comments", or "document the code".

2026-03-273

merge-review

gorira-tatsu/aminet

Review a PR's merge readiness for the stg branch. Use this skill when the user says "/merge-review", asks to "check if this PR is ready to merge", "review for stg", "pre-merge check", or wants to validate a PR meets all quality gates before merging into stg. Also triggers for "is this ready to merge" or "merge checklist".

2026-03-273

pr-notify

gorira-tatsu/aminet

Comment on related GitHub issues when a PR is created or updated. Use this skill when the user says "/pr-notify", asks to "notify issues about this PR", "comment on related issues", "link PR to issues", or wants to update issue threads with PR status. Also use proactively after creating a PR that references issues, to keep issue threads informed.

2026-03-273

name	issue-pr
description	Create GitHub issues and pull requests using the gh CLI. Use this skill when the user says "/issue-pr", asks to "create an issue", "open a PR", "file a bug", "create a pull request", "make issues for these", or wants to batch-create multiple issues from a plan. Also triggers for "open PR targeting stg" or "create issues from this list".
argument-hint	issue <title> [--label <label>] \| pr [--base <branch>] \| issues <list>
allowed-tools	["Bash(gh issue:)","Bash(gh pr:)","Bash(git log:)","Bash(git diff:)","Bash(git branch:)","Bash(git push:)","Bash(git remote:*)","Read","Glob","Grep"]

GitHub Issue & PR Creator

Create GitHub issues and pull requests with proper formatting, labels, and cross-references.

Arguments

The user invoked this with: $ARGUMENTS

Parsing the arguments

Determine the mode from the first word:

issue — create a single issue
pr — create a pull request
issues — batch-create multiple issues
If empty or ambiguous, ask the user what they want to create

Safety: preview before creating

The only exception is when the user explicitly says "just create it", "no preview", or similar — then proceed directly.

Example preview format:

## Preview: PR

Title: feat: add private package support
Base: stg <- feat/private-package-support
Body: [rendered summary]
Labels: (none)
Closes: #5

Create this PR? [y/n]

Mode: Create Issue

Usage: /issue-pr issue "title" [--label bug|enhancement|...] [--body "description"]

Steps

If title or body is missing, infer from conversation context or ask
Check for existing open issues with similar titles to avoid duplicates:
```
gh issue list --state open --search "<title keywords>"
```
If a close match exists, warn the user before proceeding.
Determine the appropriate label from context:
- Bug reports → bug
- New features → enhancement
- Documentation → documentation
Check if the repo has issue templates (.github/ISSUE_TEMPLATE/). If templates exist, structure the body to match the relevant template's sections.

Show preview, then create on confirmation:

gh issue create --title "<title>" --label "<label>" --body "<body>"

Report the issue URL back to the user

Mode: Create PR

Usage: /issue-pr pr [--base <branch>]

Steps

Check for existing PR: Before anything else, check if a PR already exists for this branch:
```
gh pr view --json number,url 2>/dev/null
```
If one exists, show its URL and ask if the user wants to update it or create a new one.
Detect base branch: Use --base if provided. Otherwise, detect intelligently:
```
git branch -r | grep -E 'origin/(stg|staging|develop|main|master)' | head -5
```
Priority order: stg > staging > develop > main > master. If multiple candidates exist, show the options and ask the user.
Gather context:
- git log <base>..HEAD --oneline to see commits in this branch
- git diff <base>...HEAD --stat to see changed files
- Read commit messages to understand the changes

Load PR template: Check for .github/pull_request_template.md. If it exists, use its structure for the PR body. If not, use this default:

## Summary
<1-3 bullet points summarizing the changes>

## Testing
- [ ] Lint passes
- [ ] Tests pass

## Notes
<any additional context>

Link related issues: Scan commit messages for issue references (#N, Closes #N, Fixes #N) and include them in the PR body.
Preview and create:
- Show the full preview (title, base, body, linked issues)
- On confirmation, push the branch if needed: git push -u origin <branch>
- Create the PR: gh pr create --base <base> --title "..." --body "..."
Report the PR URL back to the user.

Mode: Batch Create Issues

Usage: /issue-pr issues (reads from conversation context or a provided list)

Steps

Parse the list of issues from conversation context or explicit argument text
Show a numbered preview of all issues to be created
After confirmation, create each using the single-issue flow
Report all created issue URLs as a summary table

Rules

Always write issue and PR content in English
Use conventional commit prefixes in PR titles when applicable (feat:, fix:, docs:, chore:)
Never create duplicate issues — always check existing open issues first
Include Closes #N in PR body when the PR resolves a known issue
For PRs, always check if the branch needs pushing before creating
Default to preview mode. Only skip preview when the user explicitly opts out.