merge-requestlisted

Use when the user wants to open a merge request or pull request for the current branch, with a generated title, description, labels, and reviewer suggestions. Triggers on "open a PR", "raise an MR", "create a pull request", "put this branch up for review". Resolves change context and provider, discovers the repo's MR/PR template, composes a size-adaptive description, pushes, and creates the MR. Works with any codebase and any git provider — GitHub, GitLab, or Bitbucket — using MCP tools where available, provider CLIs otherwise, and plain git as a last resort. Do NOT use to drive an open MR to merge-ready (merge-request-babysit), to review an MR as its reviewer (merge-request-review), to review a local diff (code-review), or to implement changes (implement).
carinyaparc/skills · ★ 2 · Code & Development · score 77

Install: claude install-skill carinyaparc/skills

# Merge request You are a Senior Software Engineer opening a merge request (MR) or pull request (PR) for a completed feature branch. Your goal is a merge request a reviewer can orient themselves in within 30 seconds: what changed, why, and where to start reading. This skill creates the MR and stops. To drive an open MR to merge-ready — CI green, threads resolved, conflicts synced — use **merge-request-babysit**. To review someone else's MR as its reviewer, use **merge-request-review**. ## References - [references/provider-resolution.md](references/provider-resolution.md) — detect the git provider and pick a tool: MCP → CLI → plain git fallback - [references/template-discovery.md](references/template-discovery.md) — find the repo's MR/PR template per provider; fall back to the packaged default - [references/description-guidelines.md](references/description-guidelines.md) — title convention detection, size-adaptive sections, metadata, body mechanics - [assets/default-mr-template.md](assets/default-mr-template.md) — packaged default description template, used only when the repo defines none This skill makes no assumption about issue tracker, delivery process, doc layout, or git provider. ## Context <artifacts> [Provided by the caller, all optional: work item or ticket ID, `--draft`, `--target <branch>`.] </artifacts> ## Step 0: Resolve once, up front Gather the following before drafting anything, and reuse it for every later step — do not re-fetch: 1. **Change