How do I install the Maintainer skill?

Run npx skillmds@latest add danielscholl/maintainer in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Maintainer safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Maintainer?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Maintainer free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Maintainer?

danielscholl (@danielscholl) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Maintainer by danielscholl — Agent Skill

Name: Maintainer
Author: danielscholl

Maintainer

Maintainer actions for MR trusted branch sync. Check sync status between source and trusted branches, then push to the trusted branch so the child pipeline can run. Use when the user says 'allow MR', 'sync trusted branch', 'trigger trusted tests', or asks to review and approve an MR for pipeline execution. Not for: code review or pipeline analysis (use mr-review), creating or merging MRs (use glab), or test reliability (use osdu-quality).

danielscholl 9c559db 3.1 KB Updated Sep 17, 2026

File contents

OSDU Maintainer Workflow

Maintainer actions for GitLab MR pipelines. Review MRs and allow them to proceed by syncing the trusted branch.

Background

Developers create MRs on regular branches. The child pipeline requires a "trusted" branch that only maintainers can create/sync. The trigger-trusted-tests job verifies the trusted branch SHA matches the source branch before allowing the child pipeline to run.

Actions

Action	Purpose	Default
`review`	Analyze MR changes, show sync status, provide recommendation	Default
`allow`	Sync trusted branch and retry pipeline job	—

Input Parsing

review or no action → review mode
allow → allow mode
MR number or full GitLab URL accepted
Auto-detect from current branch if omitted

URL Parsing

From https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/merge_requests/904:

Host: community.opengroup.org
Project path: osdu/platform/security-and-compliance/entitlements
MR number: 904

CRITICAL: glab defaults to gitlab.com. For OSDU, ALL glab api commands MUST use:

GITLAB_HOST=community.opengroup.org glab api ...

Review Action

Get MR Metadata — title, author, labels, target branch
Check Milestone & Labels — flag missing milestone, suggest labels based on changed files
Analyze Changes — categorize by risk (Dependencies/CI-CD/Source/Tests/Docs/Secrets)
Show Commit History — check conventional commits
Analyze Code Changes — summarize modifications, purpose, impact
Security Checks — scan for hardcoded secrets, suspicious patterns
Check Sync Status — compare source branch SHA vs trusted branch SHA
Provide Recommendation — APPROVE / REVIEW NEEDED / CAUTION

Label Suggestions

Change Pattern	Suggested Label
Common/shared code	`common`
Azure-specific paths	`Azure`
GCP-specific paths	`GCP`
AWS/IBM-specific paths	`AWS` / `IBM`
pom.xml, package.json	`dependencies`
.gitlab-ci.yml, Dockerfile	`ci/cd`
.md, docs/*	`documentation`

Allow Action

Parse MR number or detect from branch
Derive trusted branch: trusted-<source-branch>
Sync: git push origin <source-branch>:refs/heads/<trusted-branch> --force
Retry trigger-trusted-tests job

Multi-Repo Context

In a multi-repo workspace:

Determine which service repo the MR belongs to
If a local clone exists, use it for git push operations
If no local clone, use a temp clone for the sync
The project ID resolution uses the GitLab API with URL-encoded paths

---name: maintainerdescription: Maintainer actions for MR trusted branch sync. Check sync status between source and trusted branches, then push to the trusted branch so the child pipeline can run. Use when the user says 'allow MR', 'sync trusted branch', 'trigger trusted tests', or asks to review and approve an MR for pipeline execution. Not for: code review or pipeline analysis (use mr-review), creating or merging MRs (use glab), or test reliability (use osdu-quality).---# OSDU Maintainer WorkflowMaintainer actions for GitLab MR pipelines. Review MRs and allow them to proceed by syncing the trusted branch.## BackgroundDevelopers create MRs on regular branches. The child pipeline requires a "trusted" branch that only maintainers can create/sync. The `trigger-trusted-tests` job verifies the trusted branch SHA matches the source branch before allowing the child pipeline to run.## Actions| Action | Purpose | Default ||--------|---------|---------|| `review` | Analyze MR changes, show sync status, provide recommendation | Default || `allow` | Sync trusted branch and retry pipeline job | — |## Input Parsing- `review` or no action → review mode- `allow` → allow mode- MR number or full GitLab URL accepted- Auto-detect from current branch if omitted### URL ParsingFrom `https://community.opengroup.org/osdu/platform/security-and-compliance/entitlements/-/merge_requests/904`:- Host: `community.opengroup.org`- Project path: `osdu/platform/security-and-compliance/entitlements`- MR number: `904`**CRITICAL:** `glab` defaults to gitlab.com. For OSDU, ALL `glab api` commands MUST use:```bashGITLAB_HOST=community.opengroup.org glab api ...```## Review Action1. **Get MR Metadata** — title, author, labels, target branch2. **Check Milestone & Labels** — flag missing milestone, suggest labels based on changed files3. **Analyze Changes** — categorize by risk (Dependencies/CI-CD/Source/Tests/Docs/Secrets)4. **Show Commit History** — check conventional commits5. **Analyze Code Changes** — summarize modifications, purpose, impact6. **Security Checks** — scan for hardcoded secrets, suspicious patterns7. **Check Sync Status** — compare source branch SHA vs trusted branch SHA8. **Provide Recommendation** — APPROVE / REVIEW NEEDED / CAUTION### Label Suggestions| Change Pattern | Suggested Label ||----------------|-----------------|| Common/shared code | `common` || Azure-specific paths | `Azure` || GCP-specific paths | `GCP` || AWS/IBM-specific paths | `AWS` / `IBM` || pom.xml, package.json | `dependencies` || .gitlab-ci.yml, Dockerfile | `ci/cd` || *.md, docs/** | `documentation` |## Allow Action1. Parse MR number or detect from branch2. Derive trusted branch: `trusted-<source-branch>`3. Sync: `git push origin <source-branch>:refs/heads/<trusted-branch> --force`4. Retry `trigger-trusted-tests` job## Multi-Repo ContextIn a multi-repo workspace:1. Determine which service repo the MR belongs to2. If a local clone exists, use it for `git push` operations3. If no local clone, use a temp clone for the sync4. The project ID resolution uses the GitLab API with URL-encoded paths

Frequently asked questions