YOU MUST use this before ANY git push, branch push to remote, merge, or PR creation — regardless of phrasing or language. Covers all irreversible integration actions (committing, pushing, opening a PR, shipping finished work). Also triggers proactively after a fix when the user signals completion (still ask before pushing). Works with any git hosting provider.
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.
A direct command skips the review prompt. Inspect the source before running it.
YOU MUST use this before ANY git push, branch push to remote, merge, or PR creation — regardless of phrasing or language. Covers all irreversible integration actions (committing, pushing, opening a PR, shipping finished work). Also triggers proactively after a fix when the user signals completion (still ask before pushing). Works with any git hosting provider.
license
MIT
compatibility
["claude-code","cursor","copilot","codex"]
platforms
["android","ios","kmp","flutter","react-native"]
Create PR
Create a well-structured pull request for mobile code changes.
When to Use
Match on intent, not specific words or languages. The user's phrasing is a signal, not a keyword match — read meaning in context.
Explicit intent (user directly expresses they want to save, share, or submit changes):
Intent to commit the current work
Intent to push the current branch
Intent to open a pull request
Instruction to "ship", "deliver", "submit", or otherwise mark work as ready
Final step of the mobiai-fix-issue pipeline
When intent is explicit, proceed through the workflow — but still confirm before pushing (see "Never" below).
Implicit intent after completed work (user approves something you just finished):
After you report a fix, review, or implementation as done, any user signal that the work is acceptable — approval, agreement, confirmation, green light, a simple "ok" in any language — is an implicit cue that the next action is probably to ship it. Do not act on implicit intent. Instead, ASK: propose creating the PR and wait for explicit confirmation. The language of your question should match the user's.
Distinguish implicit approval from continued discussion: if the user keeps asking questions, requests more changes, or is still evaluating, do not offer a PR yet.
Never:
Act on implicit intent without asking — always confirm before pushing or opening a PR
Commit directly to protected or long-lived branches (main, master, develop, release/*, staging) — always move to a feature branch first
Push without explicit user confirmation
Skip the changelog/README update step when the project has one
Workflow
Step 1: Prepare the Branch
Check the current branch first. If you're on a protected or long-lived branch (main, master, develop, release/*, staging), NEVER commit there — create a feature branch. Name it after the issue key: fix/<issue-key>, feat/<issue-key>, or chore/<description>:
git checkout -b fix/<issue-key>
If you've already committed to the wrong branch (e.g. a release branch), move the commit to a new feature branch before pushing:
git branch fix/<issue-key> # save the commit under a new branch name
git reset --hard origin/<current-branch> # rewind the protected branch to the remote
git checkout fix/<issue-key> # switch to the feature branch
Stage the changes:
git add <specific-files> # Prefer specific files over git add -A
Commit with a descriptive message:
git commit -m "fix: <short description>
<issue-key>: <what was wrong and why>
- Root cause: <explanation>
- Fix: <what was changed>
- Tests: <what tests were added>"
Step 2: Update Changelog (if applicable)
If the project has a changelog file (CHANGELOG.md, HISTORY.md, or a section in README.md):
Read the changelog to understand the format
Add an entry under the current/unreleased version
Follow the project's existing style (Keep a Changelog, custom format, etc.)
Don't duplicate entries — check if the issue key already exists
Step 3: Determine the Base Branch
CRITICAL: Do NOT assume the PR targets main or master.
Ask the user if they haven't specified: "What branch should this be merged into?"
If the current branch was created from another branch, use that as the base:
# Check what branch this was branched from
git log --oneline --first-parent main..HEAD | tail -1 # if few commits → likely from main
git log --oneline --first-parent develop..HEAD | tail -1 # check develop too
Check the repo's default branch: gh repo view --json defaultBranchRef
If the project uses gitflow or similar (develop, release/*), respect that workflow
Use --base <branch> when creating the PR to target the correct branch.
Step 4: Push and Open the PR
Confirm with the user before pushing (project rule: never push without explicit approval).
Step 4.1: Identify the hosting provider
Inspect the remote to figure out which provider this repo uses:
git remote get-url origin
Adapt the rest of the workflow to that provider. Prefer a native CLI when one is installed and authenticated (it lets you set title, body, and base branch in one shot). Fall back to constructing the provider's web URL for creating a PR/MR when no CLI is available. You are expected to know the conventions for the major providers — if unsure, check the provider's docs rather than guessing URL formats.
Step 4.2: Push the branch
git push -u origin <feature-branch>
Step 4.3: Create the PR / MR
Produce the PR with this exact title format and body template, regardless of provider:
Title: fix: <short description> (or feat:, refactor:, etc. per Conventional Commits, unless the project uses a different style — check git log for the pattern)
Submit via CLI if one is installed and authenticated for the provider — pass the title, body, and base branch as arguments so everything is set in a single command.
Submit via web URL if no CLI is available. Push the branch first, then build the provider's "new PR/MR" URL with source branch and target branch as query parameters. Give the user:
The clickable URL (prefills source and target)
The title to paste
The full body to paste
Do not omit the title or body in the web-URL case — most providers do not auto-populate them from commit messages, and the template is the main value this skill delivers.
Step 5: Verify
After creating the PR:
Verify the diff on the PR looks correct (no unintended files, no secrets)
Report the PR URL to the user
Check CI status if the provider's CLI supports it; otherwise ask the user to confirm the PR was created and CI passed
