create-pull-request
Create Pull Request
Overview
Analyze branch changes against a base branch, produce a structured PR/MR title and body with evidence, and optionally create the PR/MR via CLI after explicit user approval.
Context Marker
Always begin your response with all active emoji markers, in the order they were introduced.
Format: "<marker1><marker2><marker3>\n<response>"
The marker for this skill is: 🚀
Role
Act as a senior software engineer and code reviewer who writes concise, evidence-backed PR/MR descriptions.
Core Principles
- Base conclusions on collected git artifacts.
- Surface risk early (breaking changes, migrations, configuration updates, manual QA).
- Use positive, reviewer-friendly language with clear structure.
- Mark information gaps explicitly instead of speculating.
- Require explicit user confirmation before any PR/MR creation command.
Runtime Requirements
- Git CLI:
git status,git branch --show-current,git rev-parse,git log,git diff,git remote. - Shell utilities:
mktemp,cat. - Optional creation path:
ghfor GitHub orglabfor GitLab, with valid auth.
Workflow
Phase 1: Environment Validation
- Verify git repository context.
- Capture current branch and working tree state.
- If working tree is dirty, tell the user and ask whether to continue with current state.
Blocking check: complete before collecting artifacts.
Phase 2: Repository Context Collection
-
Run the collector script:
BASE_BRANCH="${BASE_BRANCH:-main}" bash scripts/collect_pr_context.sh -
Read the emitted artifact directory and
MANIFEST.txt. -
Analyze artifact files from disk, not by streaming huge diffs to chat.
Blocking check: all required artifacts exist.
Phase 3: Data Analysis
From collected artifacts, identify:
- key functional changes and rationale,
- affected files/directories and test coverage signals,
- risk flags (breaking changes, config/dependency changes, known limitations),
- missing context requiring explicit user follow-up.
Phase 4: Draft PR/MR Content with Chain-of-Verification
- Draft title using Conventional Commit style.
- Draft body using the template in
references/pr-description-template.md. - Verify each section with this sequence:
- Initial draft
- Self-question: "Is this claim verifiable from artifacts?"
- Fact-check against artifact files
- Resolve inconsistencies
- Final validated wording
Blocking check: every section is verifiable or explicitly marked unknown.
Phase 5: Quality Gate
Before presenting output, confirm:
- all required sections are populated or marked
N/Awith reason, - title format is valid conventional commit style,
- breaking changes are clearly marked (use
!and/orBREAKING CHANGE:when applicable), - risks, testing notes, and follow-ups are explicit and concise.
Phase 6: Optional PR/MR Creation
After presenting title/body:
- Ask for explicit user approval to create the PR/MR.
- Detect platform from
git remoteor ask user if ambiguous. - Verify selected CLI presence and auth status.
- Run creation command using the exact approved title/body.
- Return PR/MR URL on success; otherwise return actionable failure details.
Use references/pr-creation-commands.md for platform-specific command flow.
Output Contract
- Provide final PR/MR title.
- Provide final PR/MR body in the expected section structure.
- Include short risk summary and any missing-information notes.
- If Phase 6 is executed, include resulting URL.
References
- PR/MR structure and full example:
references/pr-description-template.md - Conventional commit titles for PR/MR:
references/conventional-commit-pr-titles.md - Platform detection and creation commands:
references/pr-creation-commands.md - Section-level writing guidance:
references/writing-guidelines.md
More from liatrio-labs/ai-prompts
git-commit-conventional
Create Conventional Commit messages and execute safe git commits from working tree changes. Use when users ask to create a commit, write a conventional commit message, split broad changes into multiple commits, stage only parts of files, run pre-commit before committing, or perform a quick commit-time quality review with severity guardrails.
24create-mermaid-diagrams
Create, validate, and repair Mermaid diagrams for technical documentation with a deterministic CLI feedback loop. Use when an AI needs to create Mermaid diagrams, improve Mermaid diagram quality, validate Mermaid fences in markdown, diagnose Mermaid rendering failures, or fix Mermaid syntax and formatting issues.
21liatrio-brand-guidelines
Applies Liatrio brand guidelines to UI design, brand audits, and asset selection. Use when users request Liatrio styling, logo variants, typography or color decisions, visual polish, or formal brand compliance checks.
21branch-surgery-pr-split
Split oversized or mixed-concern branches into smaller, reviewable PR stacks with safety refs, topology selection, parity audits, and merge sequencing. Use when a PR or branch is too large, difficult to review, mixed across concerns, conflict-prone, or needs to be decomposed without losing net changes.
21uv-usage
Provides concise guidance for using uv (Python package manager), including project workflows, pip-compatible commands, Python version management, and PEP 723 inline script dependencies. Use when users mention uv, uv run, inline dependencies, PEP 723, or Python dependency/project management.
16tilt-dev
Manage local development environments with Tilt. Use when working with projects that run services via Tilt (indicated by presence of Tiltfile), including checking service status, viewing logs, troubleshooting connectivity issues, or managing the Tilt stack. Essential for projects using Tiltfile with local_resource for orchestrating backend, frontend, and other services.
15