mr-open
Skill0 starsChanged 10 days agoApache-2.0View on GitHub
Use when committing work and opening or updating a GitLab MR or GitHub PR: "ouvre la MR", "commit & push", "update la MR". Load ticket-conventions with it for the description. Not for merging (mr-batch-merge) or review threads (addressing-gitlab-review-comments).
- Deletes or force-pushes
- Commits and pushes
In this repository19 other files it gives its agents.
- AGENTS.mdAGENTS.md
- addressing-gitlab-review-commentsSkill
- auditing-mobile-layoutSkill
- charting-grafana-metricsSkill
- claude-usage-auditSkill
- confluenceSkill
- gitlab-job-triageSkill
- grafana-cloud-monitoringSkill
- grafana-dashboardsSkill
- handoffSkill
- incident-responseSkill
- jira-cliSkill
- k8s-rightsizingSkill
- pixibixi-wiki-articleSkill
- rss-digestSkill
- scoping-a-websiteSkill
- tf-module-releaseSkill
- ticket-conventionsSkill
- wiki-fact-checkSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 30
Before the first push, fold fix-up commits from review rounds into their scope: the MR carries one commit per scope, not the work history.
- Very specific: line 33
Every commit signed: git log --format="%h %G?
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Open an MR
1. Preflight
| Check | Command | Fix |
Target branch, never assumed main | git symbolic-ref --short refs/remotes/origin/HEAD | |
| Author email set on this repo (there is no global one) | git config user.email | PixiBixi@users.noreply.github.com on anything public; the work address on internal GitLab |
| Signing not disabled locally | git config --get commit.gpgsign is true | git config --local --unset commit.gpgsign |
| An MR already open for the branch | glab mr list --source-branch <branch> -F json / gh pr list --head <branch> | Push to it and update it, never a second one |
| Currently on the target branch | git branch --show-current | Branch first, below |
New branch, always from the freshly fetched remote: a local target branch may carry unpushed commits that would leak into the MR.
TARGET=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's|^origin/||')
git fetch origin "$TARGET"
git checkout -b fix/store-memory-cap "origin/$TARGET"2. Commits
- One commit per scope (
fix(tflint):,feat(module):,chore(live):): two scopes in the diff means two commits, staged by path, nevergit add -A. - Before the first push, fold fix-up commits from review rounds into their scope: the MR carries one commit per scope, not the work history.
- Conventional Commits, English, ticket key in the subject or body when there is one. The body says why, wrapped at 72.
- README updated in the same change when a flag, feature or behavior changed.
- Every commit signed:
git log --format="%h %G? %s" "origin/$TARGET..HEAD"showsGon each line. Repair unsigned ones withgit rebase --exec "git commit --amend --no-edit -S --quiet" "origin/$TARGET", neverreset --hard.
3. Push
git fetch origin "$TARGET"
git rebase "origin/$TARGET"
git push --force-with-lease -u origin HEADRebase locally: a server-side rebase (glab mr rebase, the web button) rewrites the commits unsigned.
4. Create
Description in a file so newlines and backticks survive: what, why, test evidence, rollback for infra changes. English, no narrated investigation, no hard wrap. Wording and length rules: ticket-conventions.
glab mr create \
--target-branch "$TARGET" \
--title "fix(store): cap memory at 6Gi" \
--description-file "$BODY" \
--remove-source-branch \
--yes--yesis mandatory: without itglabwaits for a confirmation nobody can send.- Labels, ticket key placement and any compliance label: whatever the project CLAUDE.md says, applied at creation.
- GitHub:
gh pr create --base "$TARGET" --title ... --body-file "$BODY".
5. After
echo "<url>" | pbcopy, then answer with the link and one line.- New commits on an open MR: push, then rewrite the description to cover them (
glab mr update <iid> --description-file "$BODY"). - Offer the follow-up reminder in one line (
tickler) when the change should move performance or cost.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

