Run any Skill in Manus with one click

pull-request

Stars2

Forks1

UpdatedApril 1, 2026 at 02:35

Create and manage pull requests with submodule-aware branch handling, auto-generated titles and descriptions from commit history, and safety-first push behavior. Use when asked to open a PR, check PR status, push a branch, or prepare changes for review.

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

mirurobotics

mirurobotics/agent

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	pull-request
description	Create and manage pull requests with submodule-aware branch handling, auto-generated titles and descriptions from commit history, and safety-first push behavior. Use when asked to open a PR, check PR status, push a branch, or prepare changes for review.

Pull Request Workflow

Inputs

repo (optional): constrain scope to one repo path (for example backend, frontend, core, or . for the root repo).
mode (optional): create (default), status, or update.
branch (optional): branch name to use. Auto-generated from commits if omitted.
base (optional): target branch. Defaults to main.
draft (optional): open as draft PR when true.

Procedure

1. Resolve repo scope

If repo is given, operate in that submodule directory.
If omitted, infer from the user's working context or uncommitted changes.
Verify the repo has a GitHub remote (gh repo view).

2. Gather context

git status — confirm working tree state (warn if uncommitted changes exist).
git branch --show-current — identify current branch.
git log --oneline main..HEAD — collect commits that will be in the PR.
git diff main...HEAD --stat — summarize file changes.

3. Create branch (if on main)

If currently on main, create and checkout a new branch.
Follow branch naming conventions: <prefix>/<short-description> using kebab-case.
Derive prefix from commit types when possible (feat commits -> feat/, fix commits -> fix/).
If branch name cannot be inferred, ask the user.

4. Push branch

Push with -u to set upstream tracking: git push -u origin <branch>.
Never force push. If push is rejected, report the conflict and stop.

5. Generate PR content

Title: must use Conventional Commits format: type(scope): summary. Single commit -> use its subject line directly. Multiple commits -> determine the dominant type (feat if any feats, fix if all fixes, chore/refactor/etc. as appropriate) and summarize the theme. Use the same types as commits: feat, fix, refactor, test, docs, chore, perf, ci, build, style. Scope is optional but encouraged when changes target a specific area. Keep under 72 characters.

Body: structured format:

## Summary
<bulleted list derived from commit messages>

Do not ask for approval — create the PR immediately.

6. Create PR

Use gh pr create --title "<title>" --base <base> --body "<body>".
Add --draft flag when requested.
Report the PR URL on success.

7. Status and update modes

status: run gh pr status in the target repo, or gh pr view <number> for a specific PR.
update: push latest commits and run gh pr view to confirm CI status after push.

Safety Rules

Never force push (--force, --force-with-lease).
Never push directly to protected branches (main, production, uat, release/*).
Create PRs without waiting for approval — just do it.
Never mix uncommitted changes into PR scope — warn and stop if working tree is dirty.
Never delete branches without explicit request.

Branch Naming Rules

Format: <prefix>/<short-description> using kebab-case.
Valid prefixes: feat, fix, refactor, test, docs, chore, perf, ci, build, or a person's name.
Keep branch names short and descriptive.

Output Contract

Execution summary (PR URL, branch pushed).
Warnings for any skipped steps (dirty working tree, existing remote branch, push rejection).

More from this repository

same repository

commit

mirurobotics/agent

Prepare and execute high-quality Conventional Commits from working tree changes with repository-aware commit scoping (root repo and submodules) and atomic commit planning. Use when asked to commit, split commits, draft commit messages, or organize staged/unstaged changes into safe commit units.

2026-04-012

design

mirurobotics/agent

Design and implement code changes end-to-end, from requirements clarification through implementation, validation, and documentation updates. Use when writing new code, extending features, fixing bugs, or making structured code changes where correctness, maintainability, and clear tradeoffs matter.

2026-04-012

document

mirurobotics/agent

Add or improve code and repository documentation so behavior, constraints, and usage are clear and current. Use when asked to write/update docs, docstrings, inline rationale comments, architecture notes, or change-related documentation for code updates.

2026-04-012

find-skills

mirurobotics/agent

Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.

2026-04-012

install-skills

mirurobotics/agent

Install skills from skills.sh, rename to short names, and track originals for updates.

2026-04-012

lint

mirurobotics/agent

Run repository linting and formatting checks, fix lint failures, and verify a clean result. Use when asked to lint code, resolve style/tooling violations, or make CI lint checks pass across changed files or whole repositories.

2026-04-012

name	pull-request
description	Create and manage pull requests with submodule-aware branch handling, auto-generated titles and descriptions from commit history, and safety-first push behavior. Use when asked to open a PR, check PR status, push a branch, or prepare changes for review.

Pull Request Workflow

Inputs

repo (optional): constrain scope to one repo path (for example backend, frontend, core, or . for the root repo).
mode (optional): create (default), status, or update.
branch (optional): branch name to use. Auto-generated from commits if omitted.
base (optional): target branch. Defaults to main.
draft (optional): open as draft PR when true.

Procedure

1. Resolve repo scope

If repo is given, operate in that submodule directory.
If omitted, infer from the user's working context or uncommitted changes.
Verify the repo has a GitHub remote (gh repo view).

2. Gather context

git status — confirm working tree state (warn if uncommitted changes exist).
git branch --show-current — identify current branch.
git log --oneline main..HEAD — collect commits that will be in the PR.
git diff main...HEAD --stat — summarize file changes.

3. Create branch (if on main)

If currently on main, create and checkout a new branch.
Follow branch naming conventions: <prefix>/<short-description> using kebab-case.
Derive prefix from commit types when possible (feat commits -> feat/, fix commits -> fix/).
If branch name cannot be inferred, ask the user.

4. Push branch

Push with -u to set upstream tracking: git push -u origin <branch>.
Never force push. If push is rejected, report the conflict and stop.

5. Generate PR content

Title: must use Conventional Commits format: type(scope): summary. Single commit -> use its subject line directly. Multiple commits -> determine the dominant type (feat if any feats, fix if all fixes, chore/refactor/etc. as appropriate) and summarize the theme. Use the same types as commits: feat, fix, refactor, test, docs, chore, perf, ci, build, style. Scope is optional but encouraged when changes target a specific area. Keep under 72 characters.

Body: structured format:

## Summary
<bulleted list derived from commit messages>

Do not ask for approval — create the PR immediately.

6. Create PR

Use gh pr create --title "<title>" --base <base> --body "<body>".
Add --draft flag when requested.
Report the PR URL on success.

7. Status and update modes

status: run gh pr status in the target repo, or gh pr view <number> for a specific PR.
update: push latest commits and run gh pr view to confirm CI status after push.

Safety Rules

Never force push (--force, --force-with-lease).
Never push directly to protected branches (main, production, uat, release/*).
Create PRs without waiting for approval — just do it.
Never mix uncommitted changes into PR scope — warn and stop if working tree is dirty.
Never delete branches without explicit request.

Branch Naming Rules

Format: <prefix>/<short-description> using kebab-case.
Valid prefixes: feat, fix, refactor, test, docs, chore, perf, ci, build, or a person's name.
Keep branch names short and descriptive.

Output Contract

Execution summary (PR URL, branch pushed).
Warnings for any skipped steps (dirty working tree, existing remote branch, push rejection).