Menu
Create or update a GitLab merge request from a pushed branch after local review, base-branch sync, validation, and issue linking.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Bootstrap the issue triage configuration for a repository by analyzing existing issues, labels, and contributors to generate `.gitlab/issue-triage/config.json` and `.gitlab/CODEOWNERS`. Use when setting up triage automation on a new or existing repository for the first time.
Compare a merge request's implementation against spec context in spec_context.md and feed any material mismatches into review.json. Use during MR review when approved or repository spec context is available.
Create a product spec from a GitLab issue in this repository by applying the local shared `write-product-spec` workflow with issue context and output paths. Use when an issue should be turned into a product spec artifact stored under `specs/issue-<issue-number>/product.md` and the agent should prepare file changes only, without creating commits or merge requests itself.
Create a technical spec from a GitLab issue in this repository by applying the local shared `write-tech-spec` workflow with issue context and output paths. Use when an issue should be turned into a tech spec artifact stored under `specs/issue-<issue-number>/tech.md` and the agent should prepare file changes only, without creating commits or merge requests itself.
Repo-specific dedupe guidance . Only the categories declared overridable by the core dedupe-issue skill may be specialized here.
Detect duplicate GitLab issues by comparing the incoming issue's title and description against issue candidates provided by the CI job.
| name | create-mr |
| description | Create or update a GitLab merge request from a pushed branch after local review, base-branch sync, validation, and issue linking. |
Use this after git-push when the user asks to create, update, or open a GitLab merge request.
Create or update a review-ready MR from the current branch after syncing the base branch, reviewing the diff locally, and linking the related task.
Inspect and choose base Run:
git status --short
git branch --show-current
git status -sb
Prefer the repo's default MR base. If repo guidance names a different base, use that. If the worktree is dirty, pause unless the changes are intentionally excluded from the MR.
Review and sync locally Run:
git diff --stat <base>...HEAD
git diff <base>...HEAD
Review the diff for accidental files, secrets, conflict markers, generated churn, and missing tests or docs.
Fetch the base branch and make sure it has been merged or rebased into the current branch before creating or updating the MR.
If conflicts occur, resolve them locally, rerun relevant validation, commit the resolution, and push through git-push so any configured pre-push hook runs.
Build title, body, and issue link Default the title from the issue title or the main commit subject. Infer issue links from the user request, branch name, or commits. Do not invent issue IDs. Keep the body concise and include:
Closes #123, Fixes #123, or Refs #123 when knownCreate or update MR Use GitLab CLI when available. If a MR already exists for the current branch, update it instead of creating a duplicate:
glab mr view <branch> --output json
glab mr update <branch> --title "<title>" --description "<body>"
Before editing an existing MR, read the current body and preserve user-authored content that is not clearly generated by this CI job. Do not overwrite manual notes, review context, checklist items, or release details just to apply the generated summary. If no MR exists, create one:
glab mr create --target-branch <base> --source-branch <branch> --title "<title>" --description "<body>"
If glab is unavailable or not authenticated, report the exact title/body/base/head needed to create or update the MR manually.
After creating or finding a MR, report: