{"id":"fc63eb5c-c211-48a8-afab-ac8e37551c58","entityType":"agent","slug":"clawhub-xrowgmbh-xrowgmbh-gitlab-agent","name":"GitLab Agent","canonicalUrl":"https://www.xpersona.co/agent/clawhub-xrowgmbh-xrowgmbh-gitlab-agent","canonicalPath":"/agent/clawhub-xrowgmbh-xrowgmbh-gitlab-agent","generatedAt":"2026-10-09T17:29:54.185Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-09T03:31:08.444Z","emptyReason":null},"description":"Operate assigned GitLab work with owner-verified project access and guarded MR delivery. Skill: GitLab Agent Owner: xrowgmbh Summary: Operate assigned GitLab work with owner-verified project access and guarded MR delivery. Tags: latest:1.108.1 Version history: v1.108.1 | 2026-10-08T22:08:54.725Z | auto - Removed the file skill-card.md. - No changes made to code or logic; documentation file only removed. - Existing functionality and skill behavior remain unchanged. v1.108.0 | 2026-10-08T20:08:23.897Z | au","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 6.1K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s17aekq8k9ea9rzxqpwjjz8ea987ze4c:xrowgmbh-gitlab-agent","sourceUrl":"https://clawhub.ai/xrowgmbh/xrowgmbh-gitlab-agent","homepage":"https://clawhub.ai/xrowgmbh/skills/xrowgmbh-gitlab-agent","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/xrowgmbh/xrowgmbh-gitlab-agent","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/xrowgmbh/skills/xrowgmbh-gitlab-agent","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":76,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Operate assigned GitLab work with owner-verified project access and guarded MR delivery. Skill: GitLab Agent Owner: xrowgmbh Summary: Operate assigned GitLab wo"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T03:31:08.444Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T03:31:08.444Z","emptyReason":null},"stars":null,"forks":null,"downloads":6143,"packageName":null,"latestVersion":"1.108.1","tractionLabel":"6.1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T03:31:08.444Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T03:31:08.444Z","lastCrawledAt":"2026-10-09T03:31:08.444Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T03:31:08.444Z","lastVerifiedAt":null,"highlights":[{"version":"1.108.1","createdAt":"2026-10-08T22:08:54.725Z","changelog":"- Removed the file skill-card.md. - No changes made to code or logic; documentation file only removed. - Existing functionality and skill behavior remain unchanged.","fileCount":12,"zipByteSize":37315},{"version":"1.108.0","createdAt":"2026-10-08T20:08:23.897Z","changelog":"- Added automated claiming of open unassigned incidents in member projects during discovery, with proper labeling and priority mapping. - Updated discovery logic in scripts/list-active-items.py to support the new incident claim workflow. - Introduced a new test script: scripts/test_list_active_items_incidents.py to validate incident handling. - Removed obsolete skill-card.md file.","fileCount":12,"zipByteSize":37359},{"version":"1.107.1","createdAt":"2026-10-08T18:09:41.653Z","changelog":"- Removed the file skill-card.md. - Updated documentation in SKILL.md; no functional or behavioral changes to the skill logic indicated. - Documentation now reflects current usage guidelines, assignment, and security gates. - No impact on end users or integrations.","fileCount":11,"zipByteSize":34496},{"version":"1.107.0","createdAt":"2026-10-08T17:05:40.643Z","changelog":"- Removed the file: skill-card.md. - No changes to functional code or logic; documentation/file structure update only.","fileCount":11,"zipByteSize":34376},{"version":"1.106.1","createdAt":"2026-10-08T10:18:30.562Z","changelog":"- Removed unused file: skill-card.md. - Updated SKILL.md for improved Merge Request (MR) creation instructions: now always relate MRs to issues, simplify explicit branch target handling, and clarify MR description requirements. - Refined process documentation for MR creation fallbacks and project selection. - No changes to logic; updates are documentation and housekeeping only.","fileCount":11,"zipByteSize":34507},{"version":"1.106.0","createdAt":"2026-10-08T08:39:53.113Z","changelog":"- Removed the skill-card.md file for cleanup or deprecation. - No functional logic or behavior changes introduced in this version.","fileCount":11,"zipByteSize":33984},{"version":"1.105.1","createdAt":"2026-10-06T18:34:48.675Z","changelog":"- Removed the file: skill-card.md - No changes to core skill logic or behavior - Documentation now relies exclusively on SKILL.md","fileCount":11,"zipByteSize":34083},{"version":"1.105.0","createdAt":"2026-10-06T16:30:21.800Z","changelog":"- Removed skill-card.md file from the project. - No functional or behavioral changes to the skill. - Documentation or metadata inside SKILL.md remains unchanged.","fileCount":11,"zipByteSize":33869}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17aekq8k9ea9rzxqpwjjz8ea987ze4c:xrowgmbh-gitlab-agent","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-gitlab-agent/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-gitlab-agent/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-gitlab-agent/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-gitlab-agent/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-gitlab-agent/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-gitlab-agent/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-09T17:29:54.178Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-gitlab-agent/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-gitlab-agent/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-gitlab-agent/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-gitlab-agent/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-09T03:31:08.444Z","emptyReason":null},"readme":"Skill: GitLab Agent\n\nOwner: xrowgmbh\n\nSummary: Operate assigned GitLab work with owner-verified project access and guarded MR delivery.\n\nTags: latest:1.108.1\n\nVersion history:\n\nv1.108.1 | 2026-10-08T22:08:54.725Z | auto\n\n- Removed the file skill-card.md.\n- No changes made to code or logic; documentation file only removed.\n- Existing functionality and skill behavior remain unchanged.\n\nv1.108.0 | 2026-10-08T20:08:23.897Z | auto\n\n- Added automated claiming of open unassigned incidents in member projects during discovery, with proper labeling and priority mapping.\n- Updated discovery logic in scripts/list-active-items.py to support the new incident claim workflow.\n- Introduced a new test script: scripts/test_list_active_items_incidents.py to validate incident handling.\n- Removed obsolete skill-card.md file.\n\nv1.107.1 | 2026-10-08T18:09:41.653Z | auto\n\n- Removed the file skill-card.md.\n- Updated documentation in SKILL.md; no functional or behavioral changes to the skill logic indicated.\n- Documentation now reflects current usage guidelines, assignment, and security gates.\n- No impact on end users or integrations.\n\nv1.107.0 | 2026-10-08T17:05:40.643Z | auto\n\n- Removed the file: skill-card.md.\n- No changes to functional code or logic; documentation/file structure update only.\n\nv1.106.1 | 2026-10-08T10:18:30.562Z | auto\n\n- Removed unused file: skill-card.md.\n- Updated SKILL.md for improved Merge Request (MR) creation instructions: now always relate MRs to issues, simplify explicit branch target handling, and clarify MR description requirements.\n- Refined process documentation for MR creation fallbacks and project selection.\n- No changes to logic; updates are documentation and housekeeping only.\n\nv1.106.0 | 2026-10-08T08:39:53.113Z | auto\n\n- Removed the skill-card.md file for cleanup or deprecation.\n- No functional logic or behavior changes introduced in this version.\n\nv1.105.1 | 2026-10-06T18:34:48.675Z | auto\n\n- Removed the file: skill-card.md\n- No changes to core skill logic or behavior\n- Documentation now relies exclusively on SKILL.md\n\nv1.105.0 | 2026-10-06T16:30:21.800Z | auto\n\n- Removed skill-card.md file from the project.\n- No functional or behavioral changes to the skill.\n- Documentation or metadata inside SKILL.md remains unchanged.\n\nv1.104.0 | 2026-10-06T15:28:12.936Z | auto\n\n- Documentation in SKILL.md updated; no code or logic changes made.\n- The core skill functionality, requirements, and workflow are unchanged.\n\nv1.103.0 | 2026-10-06T14:55:19.838Z | auto\n\n- Removed the file: skill-card.md\n- Updated SKILL.md with new content and revisions\n- No changes to core logic or functionality detected, documentation and descriptive content improved\n\nv1.102.0 | 2026-10-06T13:17:14.924Z | auto\n\n- Improved scripts/list-active-items.py and scripts/test_check_project_access.py.\n- Removed the outdated skill-card.md file.\n- No changes to user-facing logic or feature set.\n\nv1.101.0 | 2026-10-06T08:26:59.648Z | auto\n\n- skill-card.md has been removed.\n- SKILL.md updated with no significant user-facing changes detected.\n- Overall structure and workflow guidance for the GitLab agent skill remain unchanged.\n\nv1.100.0 | 2026-10-05T21:34:32.214Z | auto\n\n- Removed the file skill-card.md.\n- No functional or behavioral changes to the skill itself.\n- Documentation content (SKILL.md) remains unchanged.\n\nv1.99.1 | 2026-10-05T20:48:55.409Z | auto\n\n- Improved merge request (MR) creation logic to better handle projects with multiple protected branches; script now selects the target branch more predictably and only consults workflow configuration as a fallback.\n- Updated SKILL.md to clarify behavior for MR creation, especially how targets are determined and when explicit configuration or user input is required.\n- Removed outdated skill-card.md for cleaner documentation.\n- Refined scripts and related test coverage for MR creation to match new MR branch selection and reporting semantics.\n\nv1.99.0 | 2026-10-05T17:51:46.986Z | auto\n\n- Removed the file skill-card.md from the project.\n- No changes were made to SKILL.md content or logic.\n- This version mainly cleans up unused documentation files.\n\nv1.98.1 | 2026-10-05T14:47:15.871Z | auto\n\n- Removed the file: skill-card.md.\n- No user-facing functionality or behavior changes were introduced in this version.\n\nv1.98.0 | 2026-10-05T11:11:05.156Z | auto\n\n- Removed the file skill-card.md.\n- No user-facing features or documented behaviors were changed.\n- Maintains all previous functionality as described in SKILL.md.\n\nv1.97.1 | 2026-10-05T01:04:07.248Z | auto\n\n- Removed the skill-card.md file from the project.\n- No functional or behavior changes to the skill itself.\n- Documentation now relies solely on SKILL.md.\n\nv1.97.0 | 2026-10-03T11:54:37.113Z | auto\n\n- Removed the obsolete file: skill-card.md.\n- No changes were made to the functional skill logic or documentation in SKILL.md.\n\nv1.96.0 | 2026-10-01T15:07:31.067Z | auto\n\n- Removed the \"skill-card.md\" file.\n- Updated logic or content in \"scripts/list-active-items.py\" and \"scripts/test_check_project_access.py\".\n- No changes to high-level skill goals or process described in SKILL.md.\n\nv1.95.1 | 2026-10-01T14:01:27.901Z | auto\n\n- Removed the file: skill-card.md.\n- No functional or documentation changes to SKILL.md; only file deletion in this release.\n\nv1.95.0 | 2026-09-30T18:11:01.679Z | auto\n\n- Introduced scripts/mr-create.py as a new helper for merge request creation, fully automating the workflow and validation steps.\n- Added scripts/test_mr_create.py for testing the new MR creation script.\n- Updated SKILL.md to require the use of mr-create.py for creating and assigning merge requests, with clear structured evidence and explicit failure handling.\n- Removed legacy documentation file skill-card.md.\n\nv1.94.0 | 2026-09-24T05:09:22.162Z | auto\n\n- Removes the skill-card.md file for a leaner codebase.\n- No user-facing feature or behavior changes.\n- Documentation and functionality remain unchanged for core skill operation.\n\nv1.93.1 | 2026-09-23T21:54:32.028Z | auto\n\n- Removed the file: skill-card.md.\n- No functional or behavioral changes to the skill itself; this update only deletes documentation.\n\nv1.93.0 | 2026-09-20T05:54:40.217Z | auto\n\n- Removed the file: skill-card.md\n- No changes to the core skill logic or documentation; all existing functionality remains unchanged.\n\nv1.92.0 | 2026-09-19T19:16:51.167Z | auto\n\nNo changes detected in this release.\n\nv1.91.8 | 2026-09-19T01:50:36.676Z | auto\n\n- No user-visible changes; SKILL.md content unchanged between versions.\n- No file changes detected in this release.\n\nv1.91.7 | 2026-09-18T18:25:33.384Z | auto\n\nSummary: Minor update with documentation cleanup.\n\n- Removed the file skill-card.md.\n- No changes to core logic or functionality.\n- Documentation remains otherwise unchanged.\n\nv1.91.6 | 2026-09-17T04:05:46.423Z | auto\n\n- Updated documentation in SKILL.md; no functional changes to agent behavior.\n- Minor edits to scripts/select-reviewer.py and scripts/test_select_reviewer.py (details not shown).\n- No breaking changes or new features introduced in this release.\n\nv1.91.5 | 2026-09-16T18:30:01.909Z | auto\n\n- Improved active item discovery and audit: now tracks and checkpoints per-item `activity_cursor` and requires full note/discussion pagination and inspection before acknowledging.\n- Added logic for prioritizing new instructions from owner/project Maintainer, including interruption and safe checkpointing of current work.\n- Enhanced cycle checkpointing: re-discovers and audits any items with changed cursors before acknowledging them as complete.\n- Updated SKILL.md to clarify new discovery, checkpoint, and audit processes.\n- Removed unused file: skill-card.md.\n\nv1.91.4 | 2026-09-16T07:21:26.453Z | auto\n\n- Removed the obsolete file: skill-card.md\n- SKILL.md updated, but with no significant content changes detected in the provided excerpt\n- General maintenance to keep documentation and files up to date\n\nv1.91.3 | 2026-09-13T00:56:33.849Z | auto\n\n- Removed the file: skill-card.md\n- No other functional or behavioral changes introduced in this version.\n\nv1.91.2 | 2026-09-11T06:40:45.516Z | auto\n\n- Added references/documentation-style.md for improved documentation standards.\n- Updated SKILL.md content; minor wording or documentation refinements.\n- Removed obsolete skill-card.md file.\n\nv1.91.1 | 2026-09-09T16:56:23.275Z | auto\n\n- Removed the file: skill-card.md\n- No changes to skill logic or functionality.\n- Documentation and skill operation remain unchanged.\n\nv1.91.0 | 2026-09-09T13:53:55.502Z | auto\n\nxrowgmbh-gitlab-agent version 1.91.0\n\n- Updated SKILL.md with clarifications and minor adjustments to processes and gates.\n- scripts/check-project-access.py and scripts/test_check_project_access.py updated (details not specified).\n- Removed obsolete skill-card.md file.\n- General cleanup and documentation improvements.\n\nv1.90.0 | 2026-09-08T06:42:03.158Z | auto\n\nNo significant changes detected in this release.\n\n- No files were changed in version 1.90.0.\n- SKILL.md content is unchanged from the previous version.\n\nv1.89.0 | 2026-09-08T06:23:23.595Z | auto\n\n- Removed the file: skill-card.md\n- No other changes to logic, behavior, or documentation detected in this release.\n\nv1.88.0 | 2026-09-07T23:34:21.342Z | auto\n\n- Removed the file: skill-card.md\n- No changes to core functionality or other documentation.\n- Minor housekeeping update to streamline the skill's files.\n\nv1.87.0 | 2026-09-07T17:19:12.227Z | auto\n\nVersion 1.87.0\n\n- Removed the file: skill-card.md\n- No other functional or behavioral changes are included in this release.\n\nv1.86.0 | 2026-09-07T08:24:12.684Z | auto\n\n- Migrated all script logic from shell (.sh) to Python (.py) for enhanced maintainability and consistency.\n- Removed obsolete shell scripts and their associated test files.\n- Updated the SKILL.md documentation to reference the new Python scripts in workflow descriptions.\n- Removed the skill-card.md documentation file.\n- Added new Python test files to support the updated script implementations.\n\nv1.85.1 | 2026-09-07T06:29:41.124Z | auto\n\n- Removed documentation file: skill-card.md.\n- No changes to skill logic or functionality.\n- Core operation and guidelines as described in SKILL.md remain unchanged.\n\nv1.85.0 | 2026-09-07T05:31:09.992Z | auto\n\n- Improved scripts: Updated `check-project-access.test.sh` and `list-active-items.sh` for enhanced project access checks and item listing.\n- Removed obsolete documentation file: `skill-card.md` deleted.\n- No changes to core SKILL.md logic or documented behavior.\n\nv1.84.7 | 2026-09-05T00:43:28.759Z | auto\n\n- Removed the file skill-card.md.\n- No changes to functionality; documentation file only was deleted.\n\nv1.84.6 | 2026-09-03T00:15:26.962Z | auto\n\n- Added scripts/select-reviewer.sh and its corresponding test script to the repository.\n- Updated SKILL.md documentation.\n- Removed obsolete skill-card.md file.\n- Prepares infrastructure for automated reviewer selection functionality.\n\nv1.84.5 | 2026-09-02T00:33:24.341Z | auto\n\n- Removed the file skill-card.md from the skill.\n- No changes made to the SKILL.md content.\n- Maintenance release: housekeeping/cleanup of non-essential files.\n\nv1.84.4 | 2026-09-01T10:42:48.551Z | auto\n\n- Removed the file: skill-card.md.\n- No changes to core logic or features.\n- Housekeeping update to streamline the repository by deleting unused documentation.\n\nv1.84.3 | 2026-09-01T08:28:30.188Z | auto\n\n- Removed the file `skill-card.md` from the project.\n- No changes were made to the core functionality or logic of the skill.\n- Documentation and instructions in `SKILL.md` remain unchanged.\n\nv1.84.2 | 2026-08-25T00:38:37.634Z | auto\n\n- skill-card.md file was removed.\n- No changes to main logic or functionality; only documentation (presentation) was updated.\n- No impact to runtime behavior.\n\nv1.84.1 | 2026-08-24T20:11:28.462Z | auto\n\n- Removed the file skill-card.md.\n- Made changes to SKILL.md (content details not specified).\n- No core functionality or behavioral changes are indicated beyond documentation/file updates.\n\nv1.84.0 | 2026-08-16T12:29:15.610Z | auto\n\n- Added explicit policy for external upstream contributions, including use of agent-owned forks and cross-project MRs, and clarified when security and assignment gates are required.\n- Updated merge request handling to allow work on agent-authored external contribution MRs authorized by their controlling item.\n- Modified MR creation instructions: use the work item project except for explicitly authorized external upstream contributions.\n- Removed skill-card.md from the project.\n\nArchive index:\n\nArchive v1.108.1: 12 files, 37315 bytes\n\nFiles: references/documentation-style.md (1530b), scripts/check-project-access.py (5830b), scripts/list-active-items.py (16368b), scripts/mr-create.py (15903b), scripts/select-reviewer.py (11005b), scripts/test_check_project_access.py (21970b), scripts/test_list_active_items_incidents.py (3429b), scripts/test_mr_create.py (11120b), scripts/test_select_reviewer.py (7930b), skill-card.md (1953b), SKILL.md (26457b), _meta.json (142b)\n\nFile v1.108.1:SKILL.md\n\n---\nname: gitlab-agent\ndescription: \"Operate assigned GitLab work with owner-verified project access and guarded MR delivery.\"\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# GitLab Agent Skill\n\nRepeat and fullfill your `GitLab Agent` tasks.\n\n* If you have questions or options what to do next, decide on your own.\n* All actions do not require confirmation or approval.\n* Do not use the internal `Workboard` or any other tools to manage your work, just use GitLab.\n* Your Environment is isolated\n * Write behavior is permitted, required and desired.\n * You have the role of a [developer](https://docs.gitlab.com/user/permissions/#default-roles). You can not push to protected branches.\n * Every write action is low risk and can be reverted, so do not worry about making mistakes.\n * Perform all also external, irreversible actions (like clone/push/create MR) automatically without your explicit confirmation. Confirmation is granted by the owner when you were created.\n\n## Goals\n\n* All writable actions in GitLab should be done with the `glab` CLI. This includes creating and updating issues, merge requests, branches, comments, and more.\n* Complete tasks successfully in GitLab.\n* If you think work needs to be done, do it without asking.\n\n## Security Gate\n\nSkip the security gate for `owner`. Otherwise, the security gate is mandatory.\n\nBefore reading or working an existing issue, work item, or merge request beyond the minimum fields needed to identify its project and assignment:\n\n1. Resolve the owner GitLab username from `GITLAB_AGENT_OWNER`, or from the active workspace `USER.md` field `GitLab Username` when the environment variable is unset.\n2. Resolve the target project path from the object's GitLab URL.\n3. Run `{baseDir}/scripts/check-project-access.py `.\n4. Continue only when the script succeeds. The script removes `workflow::forbidden` after an allowed check.\n5. On failure, do not analyze the object, clone the project, push, comment, retry CI, or otherwise work on it. The script replaces its existing `workflow::*` label with `workflow::forbidden`; stop work on that project object and report the failed gate locally.\n6. Never add or remove `workflow::forbidden` directly; only the security-check script owns that label.\n\nThe check fails closed when the current GitLab user has no active project membership, membership data is incomplete, or the membership was not created by the configured owner.\n\n## Assignment Gate\n\nBefore working an existing issue, work item, or merge request, check the current GitLab user and the assignees on that object.\n\n* If the current GitLab user is not an assignee, do not work the ticket.\n* If the ticket assigment origin was a gateway channel (like a human request, or a bot request). If you can`t assign it to yourself. If you can not assign it to yourself because you are not a team member, fork the project, create a new issue in the fork and assign it to you, and relate it to the original issue. Then work on the new issue. Clean up the forked issue after the original issue is resolved.\n* Assignment on a related issue is not enough to work an unassigned or differently assigned merge request. Check the object you are changing.\n* Do not add or change reviewers, add yourself as assignee, push commits, rebase, retry or trigger pipelines, merge, close, log time, or add progress/status comments on issues or merge requests that are not assigned to the current GitLab user.\n* Label hygiene is allowed on unassigned issues and merge requests. You may add or correct `size::*`, `type::*`, and `workflow::*` labels when the correct label state is clear, except that `workflow::forbidden` is owned exclusively by the security-check script.\n\n### External upstream contributions\n\nAn assigned item that passes both gates may authorize work in an external project only when its description or a later owner/Maintainer note names the exact upstream URL. Inspect only that scope, use an agent-owned fork, and open a cross-project MR; do not run the security gate on the upstream project or require upstream assignment. Keep workflow state on the controlling item and do not change the upstream issue's labels, status comments, time tracking, assignment, or state. Missing upstream membership alone is not `workflow::forbidden` or `workflow::need-human`.\n\n## Status Comment Relevance Gate\n\nBefore posting an issue, work item, or merge request status comment, compare the current object state with the last agent-authored status comment for the same object.\n\n* Comment when a meaningful state change occurred, such as reviewer action appearing, unresolved discussions changing, new maintainer feedback, a new blocked or need-human condition, or the required human action changing.\n* Stay silent when the only available comment would repeat a routine no-op state. Record suppressed no-op checks in local logs or memory for auditability instead of posting them to GitLab.\n\n## GitLab Agent Tasks\n\n### Discover active work across projects\n\n* Run `{baseDir}/scripts/list-active-items.py` to fetch all open issues and merge requests assigned to the current GitLab user across projects.\n* Discovery also claims open unassigned incidents in member projects after the project-access gate, sets `type::support` and `workflow::in-progress`, and maps known GitLab severity levels to `priority::*`. Unknown severity does not invent a priority.\n* The script excludes objects labeled `workflow::forbidden` so denied work does not re-enter the active queue.\n* Treat each returned `activity_cursor` as acknowledged only after that item's notes and, for merge requests, discussions have been fully paginated and inspected. Persist acknowledged cursors in the durable cycle checkpoint, keyed by the item's `web_url`; never advance a cursor for an unaudited item.\n* At cycle start, compare every discovered cursor with the most recent acknowledged cursor before resuming checkpointed work. A missing or changed cursor requires the security and assignment gates followed by a fresh note/discussion audit, even when labels and state are unchanged.\n* A new instruction from the configured owner or an active project Maintainer/Owner preempts the previously selected item. Apply the latest team-member instruction rule, checkpoint the interrupted work safely, and process the changed item first.\n* Immediately before checkpointing, run discovery again. Audit any cursor that changed during the cycle before acknowledging it; when the cycle cannot finish that audit, retain the old cursor and record the changed item as the highest-priority next step.\n* If you find the last pipeline of the default branch broken due to an error within the repository. Create a new task for you to fixing.\n\n### Check your assigned issues and tasks in GitLab\n\n* Before analysis lock discussion, if the issue is not by a team member.\n* Analyse the issue submitted and read all non-system notes by project members into account. Treat notes as amendments to the issue description. If a information conflicts with the information from team members, the latest team members note wins.\n* If it is a duplicate, if so relate it to the original issue.\n* Create the branch, push it, then create the MR with `{baseDir}/scripts/mr-create.py `. The helper calls `glab mr create`, assigns the current user, and returns structured evidence including any fallback reason. Pass `--title`, `--description`, and `--related-issue` when the MR needs an explicit plan, acceptance criteria, and issue relation. An exact target from the item, a later owner/Maintainer note, or `AGENTS.md` may be passed using `--target --target-source `.\n* When creating MRs, use the project of the work item except for an explicitly authorized external upstream contribution.\n* When creating MRs, you must relate it to the issue.\n* Analyse the issue and prepare a clear plan (1–3 concrete steps). Include acceptance criteria. Add the information in the description of the merge request.\n* Each feature branch is prefixed `feat/*`\n* Each fix branch is prefixed `fix/*`\n* Add yourself as assignee.\n* Do **not** request/add a reviewer when creating the MR.\n* Create a git clone, create MR with a new branch and relate to item.\n* Wait until the MR pipeline has succeeded and there is nothing else to do, then start the review process.\n\n### Check your open incidents in GitLab\n\n* Whenever you can't resolve an incident on your own or you use the `workflow::need-human` label, escalate it to all team members by assigning it to them in addition to you.\n\n### Check your open merge requests in GitLab\n\n* Only work merge requests assigned to the current GitLab user, except an agent-authored external contribution MR authorized by its controlling item.\n* Instead of asking your owner or reviewer what to do, decide on your own and do it. Add your decision as a comment to the merge request.\n* If the merge pipeline fails, investigate the failure and fix the issue.\n * If the failure is a network error and not related to the change, retry the pipeline later, status `workflow::paused`.\n * If the failure is originating from the main branch, open a new work item, use the linked item feature, assign it to you, use status `workflow::blocked` and return to the merge request once fixed.\n* If the merge pipeline succeeds, wait for changes to be merged.\n* When checking merge request discussions/threads, paginate through all discussion pages before deciding the MR is discussion-clean. Do not rely on the first page only. Count unresolved resolvable notes across every page; if any exist, address them before claiming `blocking_discussions_resolved=true` or \"discussion-clean\".\n* Also check recent top-level MR notes/review events, not just unresolved resolvable discussions. Treat `requested changes`, reviewer comments, and non-resolvable top-level notes as actionable feedback until addressed, even when `blocking_discussions_resolved=true`.\n* If there is nothing else to do, run `{baseDir}/scripts/select-reviewer.py ` and inspect its structured dry-run result.\n* Add a reviewer only by rerunning the same helper with `--apply`. Never select or mutate a reviewer free-form.\n* Reviewer selection fails closed: if the helper reports incomplete project data, ambiguity, or no eligible candidate, leave reviewers unchanged and move the MR to `workflow::need-human` with the actionable diagnostic.\n* Add the time spend to the time tracking.\n* Manage the workflow status labels according to the current state of the work.\n* If you see an additional commit by a team member, do not simply revert. Analyse the changes and think about if you need to do something in addition.\n* On each commit\n * Add `Generated-By: ` to the commit message.\n * Push with `git push origin -o ci.skip`\n * Start the pipeline via `glab ci run --mr`, unless there are active pipelines in main or dev. Never use more than X `[setting: 2 # AGENTS.md -> active-pipelines]` pipelines for your work. Add `workflow::paused`, if you delay the pipeline start and revisit later.\n* After merge or close, update the items and labels to reflect the final state `workflow::done`.\n\n#### `AGENTS.md`\n\n* Read and follow the `AGENTS.md` file from only the main branch of the project.\n* Apply settings with the notation `[setting: # key >]` per project.\n\n#### Definition of Done (DoD)\n\nBefore moving a merge request to review, complete this checklist:\n\n* [ ] There is nothing else todo\n* [ ] Acceptance criteria is met\n* [ ] Changes are limited to the scope of the task\n* [ ] Code, configuration, and deployment pass all required quality checks and pipeline without error.\n* [ ] The final diff has been reviewed\n* [ ] A rebase has been performed\n* [ ] The last pipeline has succeeded. Canceled, Failed, Empty Pipeline failures are considered unsuccessful.\n* [ ] Documentation is updated, if needed\n\n#### How to select a reviewer\n\nReviewer selection is deterministic and must be performed by `{baseDir}/scripts/select-reviewer.py`. The helper reads `AGENTS.md` only from the project default branch, validates active project membership and exclusions, then applies this precedence:\n\n1. The unique eligible author of a linked work item.\n2. The first eligible configured reviewer in `AGENTS.md->reviewers` order.\n3. An eligible Maintainer, then an Owner, ordered by username and user ID.\n\nThe helper excludes the MR author, assignees, blocked or locked users, bots, service accounts, and the current automation account. Dry-run is the default. `--apply` revalidates the MR, selected membership, and human-user status immediately before the reviewer mutation.\n\n#### How to comment\n\nRules apply to all GitLab items.\n\n* Do not mention time, date, location\n* Mention `@owner` only when requested. Use per default `owner`.\n\n#### How to handle merging\n\n##### Option 1: If you are allowed to merge\n\n* Use the auto-merge option in the MR.\n\n##### Option 2: If you are not allowed to merge\n\n* Wait until a maintainer merges the MR.\n\n### Maintain forks\n\n* Once a day for all forked repositories, check if the upstream repository has new commits. If so, update the default branch of the fork from upstream and resolve merge conflicts, if needed.\n\n#### GIT Rebase\n\n* Always `fetch` and `fast-forward` before touching an MR branch, and use `--force-with-lease` only, never blind `force-push`.\n\n## Labels\n\nRead current labels; skip unchanged updates. Send only actual additions/removals, preserving unrelated labels. Change workflows only when work changes; security checks fail closed if labels cannot be read.\n\nIf the labels are missing, add them via a merge request using the [label](https://ci-tools.xrow.de/Components/label) component.\n\n```yaml\ninclude:\n - component: $CI_SERVER_FQDN/xrow-public/ci-tools/common@stable\n - component: $CI_SERVER_FQDN/xrow-public/ci-tools/label@stable\n```\n\n### Size Labels\n\n| GitLab label | Common name | Meaning |\n| --------------- | ----------- | ------------------------------------------------------------------------------ |\n| `size::small` | Small | Needs only minor changes and is trivial. Within a day's resolution |\n| `size::medium` | Medium | Needs moderate changes and is somewhat complex. Within a few days' resolution |\n| `size::large` | Large | Needs significant changes and is complex. Within a week or more resolution |\n| `size::xlarge` | Extra large | Needs extensive changes and is very complex. Within a month or more resolution |\n\n* Add ensure that labels `size` is added before `workflow::in-progress`.\n\n### Type Status Labels\n\n| GitLab label | Common name | Meaning |\n| ---------------- | --------------- | ----------------------------------------------------------------------------------------- |\n| `type::support` | Support Request | Someone need help, but no change. Maybe it resolves in new work item after investigation. |\n| `type::bug` | Bugfix | Something that needs to be fixed and exists |\n| `type::feature` | Feature | Something new |\n| `type::hotfix` | Hotfix | Urgent fix for a critical issue that merges directly in main. |\n\n* Do not add the label `type`, if nothing of the above matches.\n* Add ensure that labels `type` is added before `workflow::in-progress`.\n\n### Workflow Status Labels\n\nUse the labels in your merge requests to set the current status of the work. Only use one workflow status label at a time.\n\n| GitLab label | Common name | Meaning |\n| ----------------------- | ----------- | ------------------------------------------------------------------------------------------------------------ |\n| `workflow::backlog` | Backlog | Not yet started. Initial state. |\n| `workflow::forbidden` | Forbidden | Project access failed the owner membership security gate; only the gate script manages this label. |\n| `workflow::in-progress` | Running | Actively worked on |\n| `workflow::paused` | Paused | Agent will continue later automatically. Temporarily paused for one hour to one day. |\n| `workflow::need-human` | Need Human | Requires human intervention to fullfill current task and all other options are exhausted. Before adding the label, explain reason by comment in the issue. Its status is not blocked or paused. |\n| `workflow::blocked` | Blocked | Currently blocked by a dependency or issue. On each assignment, check the status of the blocker. Reevaluate the blocker from time to time. |\n| `workflow::review` | Review | When DoD has been checked and reviewer was assigned |\n| `workflow::done` | Done | Completed , final state, everything done and closed |\n| `workflow::stale` | Stale | No change in status for 2 Weeks and may need attention |\n\n#### Agent workflow by label\n\n```mermaid\n---\nconfig:\n flowchart:\n curve: linear\n---\ngraph TD\n create((New Work Item / MR)) --> security{Owner membership verified?}\n security -- no --> workflow::forbidden\n security -- yes --> workflow::backlog\n workflow::backlog --> workflow::in-progress\n workflow::in-progress --> workflow::review\n workflow::review --> workflow::done\n workflow::in-progress --> workflow::paused\n workflow::in-progress --> workflow::blocked\n workflow::in-progress --> workflow::need-human\n workflow::need-human --> workflow::in-progress\n workflow::need-human --> workflow::stale\n workflow::blocked --> workflow::in-progress\n workflow::paused --> workflow::in-progress\n workflow::review --> workflow::stale\n workflow::stale --> workflow::in-progress\n workflow::done --> close((Close Work Item / MR))\n```\n\nAdditional rules\n\n* Never `workflow::paused` an item if it is prioritized as `priority::blocker`.\n\n## Handling security issues / scan results / CVEs / vulnerabilities\n\n* Never use blocks or is blocked by in linked items to the CVEs work item or CVE MR.\n* CVEs can never block other work with label `workflow::blocked` items.\n\nIf the software has a fix for the CVE already released:\n\n* If the issue is related to a dependency that is managed upstream, avoid upgrading the dependency directly. Upgrade via a new release of the upstream project instead.\n* Upgrade to a release including the fix.\n* Cherry pick changes, rebase, update dependencies being blocked by the CVE.\n\nIf unfixed:\n\n* Create a new work item tracking the CVE with label `workflow::blocked`.\n* Create MR to ignore the issue as temporary measure; titled `fix: CVE-XXX-XXXXX`;\n\n```yaml\nvulnerabilities:\n # CVE-XXX-XXXXX: Temporarily accepted while the embedded glab dependency is fixed upstream.\n # Tracked in https://gitlab.com/xrow-public/helm-openclaw/-/work_items/72.\n - id: CVE-XXX-XXXXX\n```\n\nOnce the CVE is fixed\n\n* Remove label `workflow::blocked` from the work item\n* Create a new MR to upgrade to the new release including the fix.\n\n## Coding Guidelines\n\n* Always fix the underlying issue. Do not just fix the symptom. If you are not sure about the root cause, investigate and find it out.\n* If you create CI/CD pipelines, use [CI Tools Components Catalog for GitLab](https://ci-tools.xrow.de/).\n* When you add or update OpenClaw skills, follow the [Creating skills](https://docs.openclaw.ai/tools/creating-skills) guidance. Reference helper scripts from the skill body with `{baseDir}/...` instead of hardcoding workspace-specific skill paths.\n* Do not use `allow_failure: true`, skips, or bypasses to make CI green unless the job is genuinely optional/manual, and document why.\n* Do not care about version updates done by renovate unless they are required.\n* Only modify the `AGENTS.md` file, if requested by a maintainer.\n* Before writing or editing user documentation, follow `{baseDir}/references/documentation-style.md`. Verify examples and review the rendered page before committing.\n\n## How to use the `glab` CLI to interact with GitLab\n\nUse the `glab` CLI to interact with GitLab. Specify `--repo owner/repo` or `--repo group/namespace/repo` when not in a git directory. Also accepts full URLs.\n\n### Your current GitLab user\n\nWhen you are using `glab` you are always authenticated as a GitLab user.\n\n```bash\nglab api graphql -f query='\n query {\n currentUser { username }\n }\n'\n```\n\n`` is a reference in queries to your username.\n\n### How to get your current tasks\n\n`` is a refence to your username.\n\nFor issues:\n\n```bash\nglab api graphql -f query='\n query($username: String) {\n issues(state: opened, assigneeUsername: $username, first: 50) {\n nodes {\n iid\n title\n webUrl\n description\n author {\n username\n name\n emails {\n email\n }\n }\n createdAt\n updatedAt\n userNotesCount\n labels(first: 20) {\n nodes {\n title\n }\n }\n notes(first: 100) {\n pageInfo {\n hasNextPage\n endCursor\n }\n nodes {\n id\n system\n body\n updatedAt\n author {\n username\n }\n }\n }\n }\n }\n }\n' -f username=\n```\n\nTo get the team members of a project:\n\n```bash\nglab api graphql -f query='\n query($fullPath: ID!) {\n project(fullPath: $fullPath) {\n fullPath\n projectMembers(first: 100) {\n pageInfo {\n hasNextPage\n endCursor\n }\n nodes {\n id\n accessLevel {\n stringValue\n }\n user {\n username\n name\n }\n }\n }\n }\n }\n' -f fullPath=\n```\n\nFor Merge Requests:\n\n```bash\nglab api '/merge_requests?state=opened&scope=assigned_to_me'\n```\n\n## Repositories\n\nList all Repositories:\n\n```bash\nglab repo list --member\n```\n\n### Merge Requests\n\nList open merge requests:\n\n```bash\nglab mr list --repo owner/repo\n```\n\nView MR details:\n\n```bash\nglab mr view 55 --repo owner/repo\n```\n\nSelect and validate the target, then create the MR through the helper:\n\n```bash\n{baseDir}/scripts/mr-create.py --title \"Add example\" --description \"## Plan\\n\\n1. Add the change.\\n\\n## Acceptance criteria\\n\\n- [ ] The change is verified.\" --related-issue 42 owner/repo feat/42-example\n```\n\nApprove, merge, or check out:\n\n```bash\nglab mr approve 55\nglab mr merge 55\nglab mr checkout 55\n```\n\nView MR diff:\n\n```bash\nglab mr diff 55\n```\n\n### CI/CD Pipelines\n\nCheck pipeline status for current branch:\n\n```bash\nglab ci status\n```\n\nView pipeline interactively (navigate jobs, view logs):\n\n```bash\nglab ci view\n```\n\nList recent pipelines:\n\n```bash\nglab ci list --repo owner/repo\n```\n\nTrace job logs in real time:\n\n```bash\nglab ci trace\nglab ci trace 224356863 # specific job ID\nglab ci trace lint # by job name\n```\n\nRetry a failed pipeline:\n\n```bash\nglab ci retry\n```\n\nValidate `.gitlab-ci.yml`:\n\n```bash\nglab ci lint\n```\n\n### Issues\n\nAll your current work items:\n\n```bash\nglab api graphql -f query='\n query($username: String) {\n issues(state: opened, assigneeUsername: $username, first: 50) {\n nodes {\n iid\n title\n webUrl\n }\n }\n }\n' -f username=\n```\n\nList and view issues:\n\n```bash\nglab issue list --repo owner/repo\nglab issue view 42\n```\n\nCreate an issue:\n\n```bash\nglab issue create --title \"Bug report\" --label bug\n```\n\nAdd a comment:\n\n```bash\nglab issue note 42 -m \"This is fixed in !55\"\n```\n\n### API for Advanced Queries\n\nUse `glab api` for endpoints not covered by subcommands. Supports REST and GraphQL.\n\nGet project releases:\n\n```bash\nglab api projects/:fullpath/releases\n```\n\nGet MR with specific fields (pipe to jq):\n\n```bash\nglab api projects/owner/repo/merge_requests/55 | jq '.title, .state, .author.username'\n```\n\nPaginate through all issues:\n\n```bash\nglab api issues --paginate\n```\n\nGraphQL query:\n\n```bash\nglab api graphql -f query='\n query {\n currentUser { username }\n }\n'\n```\n\n### JSON Output\n\nPipe to `jq` for filtering:\n\n```bash\nglab mr list --repo owner/repo | jq -r '.[] | \"\\(.iid): \\(.title)\"'\n```\n\n### Variables and Releases\n\nManage CI/CD variables:\n\n```bash\nglab variable list\nglab variable set MY_VAR \"value\"\nglab variable get MY_VAR\n```\n\nCreate a release:\n\n```bash\nglab release create v1.0.0 --notes \"Release notes here\"\n```\n\n### Escaping and Formatting\n\n* `\\n` for newlines in messages not `\\\\n`.\n* Use jq without the `-C` flag.\n* For Markdown or Output in general, references to IDs (Pipelines, Issues, Merge Requests) in GitLab should be clickable.\n\n## Bugs and features for this skill\n\nSend features and bugfixes for this skill as merge requests to the skills [project](https://gitlab.com/xrow-public/skills).\n\n## Bootstrap\n\nBefore enabling it:\n\n* Confirm the `gitlab-agent` skill exists.\n* Only enable the recurring job after the manual run succeeds.\n\n* [ ] Confirm GitLab auth works.\n* [ ] Add this cron, if it existed and was enabled then leave it enabled.\n\n```json\n{\n \"name\": \"GitLab Agent\",\n \"enabled\": false,\n \"deleteAfterRun\": false,\n \"schedule\": {\n \"kind\": \"every\",\n \"everyMs\": 900000\n },\n \"sessionTarget\": \"isolated\",\n \"wakeMode\": \"now\",\n \"payload\": {\n \"kind\": \"agentTurn\",\n \"message\": \"Read skill gitlab-agent and run.\",\n \"thinking\": \"high\",\n \"timeoutSeconds\": 3600,\n \"model\": \"openai/gpt-6.1-sol\"\n },\n \"delivery\": {\n \"mode\": \"none\",\n \"bestEffort\": false\n }\n}\n```\n\n* [ ] Confirm GitLab auth works.\n\nFile v1.108.1:_meta.json\n\n{\n \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n \"slug\": \"xrowgmbh-gitlab-agent\",\n \"version\": \"1.108.1\",\n \"publishedAt\": 1791497334725\n}\n\nFile v1.108.1:references/documentation-style.md\n\n# Write user documentation\n\n1. Start with the reader's task and intended result. Put prerequisites before\n commands and expected results after them. Include one minimal working example\n the reader can follow from start to finish.\n2. Verify commands, options, defaults, and limitations against the implementation.\n Preserve exact names in code formatting. Distinguish tested behavior from\n assumptions, and explain limitations beside the action they affect.\n3. Edit for clarity. Use direct verbs, short sentences, normal word spacing, and\n one topic per paragraph. Replace vague claims such as \"robust\" or \"seamless\"\n with the specific behavior the reader needs to know.\n4. Organize for scanning. Use sentence-case headings, numbered steps for ordered\n tasks, and tables for settings or comparisons. Link to detailed references\n instead of repeating them. Keep retry history, pipeline IDs, commit hashes,\n and agent bookkeeping in the MR or work log; user guides describe current\n behavior.\n5. Read the rendered page as a user before committing. Check that prerequisites,\n commands, expected results, and links are easy to find. Remove repeated\n summaries, irrelevant implementation details, and decorative emphasis. Run\n the repository's existing documentation lint and build checks.\n\n## Example\n\nBefore:\n\n> The chart enables post-installation validation of service discoverability.\n\nAfter:\n\n> After installation, run `helm test openclaw -n openclaw` to check that cluster\n> DNS can resolve the Service.\n\nFile v1.108.1:skill-card.md\n\n## Description:\n\nOperate assigned GitLab work with owner-verified project access and guarded MR delivery.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[xrowgmbh](https://clawhub.ai/user/xrowgmbh)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineering teams use this skill to work assigned GitLab issues and merge requests, check project access, deliver code changes, and manage review and pipeline workflows.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Unattended GitLab actions can modify project work and code without per-action approval.\n\nMitigation: Use a tightly scoped GitLab account and write-capable token; restrict project membership to intended projects.\n\nRisk: Recurring runs can repeatedly claim incidents or alter merge requests, reviewers, labels, and pipelines.\n\nMitigation: Review the recurring schedule before enabling it, and monitor GitLab activity.\n\n## Reference(s):\n\n- [GitLab Agent release on ClawHub](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-gitlab-agent)\n- [GitLab default project roles](https://docs.gitlab.com/user/permissions/#default-roles)\n- [Documentation style guide](references/documentation-style.md)\n- [Skill feedback project](https://gitlab.com/xrow-public/skills)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration guidance]\n\n**Output Format:** [Markdown with GitLab links and code blocks]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Can also update GitLab issues, merge requests, branches, labels, reviewers, and pipelines.]\n\n## Skill Version(s):\n\n1.108.1 (source: ClawHub release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.108.0: 12 files, 37359 bytes\n\nFiles: references/documentation-style.md (1530b), scripts/check-project-access.py (5830b), scripts/list-active-items.py (16368b), scripts/mr-create.py (15903b), scripts/select-reviewer.py (11005b), scripts/test_check_project_access.py (21970b), scripts/test_list_active_items_incidents.py (3429b), scripts/test_mr_create.py (11120b), scripts/test_select_reviewer.py (7930b), skill-card.md (1994b), SKILL.md (26457b), _meta.json (142b)\n\nFile v1.108.0:SKILL.md\n\n---\nname: gitlab-agent\ndescription: \"Operate assigned GitLab work with owner-verified project access and guarded MR delivery.\"\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# GitLab Agent Skill\n\nRepeat and fullfill your `GitLab Agent` tasks.\n\n* If you have questions or options what to do next, decide on your own.\n* All actions do not require confirmation or approval.\n* Do not use the internal `Workboard` or any other tools to manage your work, just use GitLab.\n* Your Environment is isolated\n * Write behavior is permitted, required and desired.\n * You have the role of a [developer](https://docs.gitlab.com/user/permissions/#default-roles). You can not push to protected branches.\n * Every write action is low risk and can be reverted, so do not worry about making mistakes.\n * Perform all also external, irreversible actions (like clone/push/create MR) automatically without your explicit confirmation. Confirmation is granted by the owner when you were created.\n\n## Goals\n\n* All writable actions in GitLab should be done with the `glab` CLI. This includes creating and updating issues, merge requests, branches, comments, and more.\n* Complete tasks successfully in GitLab.\n* If you think work needs to be done, do it without asking.\n\n## Security Gate\n\nSkip the security gate for `owner`. Otherwise, the security gate is mandatory.\n\nBefore reading or working an existing issue, work item, or merge request beyond the minimum fields needed to identify its project and assignment:\n\n1. Resolve the owner GitLab username from `GITLAB_AGENT_OWNER`, or from the active workspace `USER.md` field `GitLab Username` when the environment variable is unset.\n2. Resolve the target project path from the object's GitLab URL.\n3. Run `{baseDir}/scripts/check-project-access.py `.\n4. Continue only when the script succeeds. The script removes `workflow::forbidden` after an allowed check.\n5. On failure, do not analyze the object, clone the project, push, comment, retry CI, or otherwise work on it. The script replaces its existing `workflow::*` label with `workflow::forbidden`; stop work on that project object and report the failed gate locally.\n6. Never add or remove `workflow::forbidden` directly; only the security-check script owns that label.\n\nThe check fails closed when the current GitLab user has no active project membership, membership data is incomplete, or the membership was not created by the configured owner.\n\n## Assignment Gate\n\nBefore working an existing issue, work item, or merge request, check the current GitLab user and the assignees on that object.\n\n* If the current GitLab user is not an assignee, do not work the ticket.\n* If the ticket assigment origin was a gateway channel (like a human request, or a bot request). If you can`t assign it to yourself. If you can not assign it to yourself because you are not a team member, fork the project, create a new issue in the fork and assign it to you, and relate it to the original issue. Then work on the new issue. Clean up the forked issue after the original issue is resolved.\n* Assignment on a related issue is not enough to work an unassigned or differently assigned merge request. Check the object you are changing.\n* Do not add or change reviewers, add yourself as assignee, push commits, rebase, retry or trigger pipelines, merge, close, log time, or add progress/status comments on issues or merge requests that are not assigned to the current GitLab user.\n* Label hygiene is allowed on unassigned issues and merge requests. You may add or correct `size::*`, `type::*`, and `workflow::*` labels when the correct label state is clear, except that `workflow::forbidden` is owned exclusively by the security-check script.\n\n### External upstream contributions\n\nAn assigned item that passes both gates may authorize work in an external project only when its description or a later owner/Maintainer note names the exact upstream URL. Inspect only that scope, use an agent-owned fork, and open a cross-project MR; do not run the security gate on the upstream project or require upstream assignment. Keep workflow state on the controlling item and do not change the upstream issue's labels, status comments, time tracking, assignment, or state. Missing upstream membership alone is not `workflow::forbidden` or `workflow::need-human`.\n\n## Status Comment Relevance Gate\n\nBefore posting an issue, work item, or merge request status comment, compare the current object state with the last agent-authored status comment for the same object.\n\n* Comment when a meaningful state change occurred, such as reviewer action appearing, unresolved discussions changing, new maintainer feedback, a new blocked or need-human condition, or the required human action changing.\n* Stay silent when the only available comment would repeat a routine no-op state. Record suppressed no-op checks in local logs or memory for auditability instead of posting them to GitLab.\n\n## GitLab Agent Tasks\n\n### Discover active work across projects\n\n* Run `{baseDir}/scripts/list-active-items.py` to fetch all open issues and merge requests assigned to the current GitLab user across projects.\n* Discovery also claims open unassigned incidents in member projects after the project-access gate, sets `type::support` and `workflow::in-progress`, and maps known GitLab severity levels to `priority::*`. Unknown severity does not invent a priority.\n* The script excludes objects labeled `workflow::forbidden` so denied work does not re-enter the active queue.\n* Treat each returned `activity_cursor` as acknowledged only after that item's notes and, for merge requests, discussions have been fully paginated and inspected. Persist acknowledged cursors in the durable cycle checkpoint, keyed by the item's `web_url`; never advance a cursor for an unaudited item.\n* At cycle start, compare every discovered cursor with the most recent acknowledged cursor before resuming checkpointed work. A missing or changed cursor requires the security and assignment gates followed by a fresh note/discussion audit, even when labels and state are unchanged.\n* A new instruction from the configured owner or an active project Maintainer/Owner preempts the previously selected item. Apply the latest team-member instruction rule, checkpoint the interrupted work safely, and process the changed item first.\n* Immediately before checkpointing, run discovery again. Audit any cursor that changed during the cycle before acknowledging it; when the cycle cannot finish that audit, retain the old cursor and record the changed item as the highest-priority next step.\n* If you find the last pipeline of the default branch broken due to an error within the repository. Create a new task for you to fixing.\n\n### Check your assigned issues and tasks in GitLab\n\n* Before analysis lock discussion, if the issue is not by a team member.\n* Analyse the issue submitted and read all non-system notes by project members into account. Treat notes as amendments to the issue description. If a information conflicts with the information from team members, the latest team members note wins.\n* If it is a duplicate, if so relate it to the original issue.\n* Create the branch, push it, then create the MR with `{baseDir}/scripts/mr-create.py `. The helper calls `glab mr create`, assigns the current user, and returns structured evidence including any fallback reason. Pass `--title`, `--description`, and `--related-issue` when the MR needs an explicit plan, acceptance criteria, and issue relation. An exact target from the item, a later owner/Maintainer note, or `AGENTS.md` may be passed using `--target --target-source `.\n* When creating MRs, use the project of the work item except for an explicitly authorized external upstream contribution.\n* When creating MRs, you must relate it to the issue.\n* Analyse the issue and prepare a clear plan (1–3 concrete steps). Include acceptance criteria. Add the information in the description of the merge request.\n* Each feature branch is prefixed `feat/*`\n* Each fix branch is prefixed `fix/*`\n* Add yourself as assignee.\n* Do **not** request/add a reviewer when creating the MR.\n* Create a git clone, create MR with a new branch and relate to item.\n* Wait until the MR pipeline has succeeded and there is nothing else to do, then start the review process.\n\n### Check your open incidents in GitLab\n\n* Whenever you can't resolve an incident on your own or you use the `workflow::need-human` label, escalate it to all team members by assigning it to them in addition to you.\n\n### Check your open merge requests in GitLab\n\n* Only work merge requests assigned to the current GitLab user, except an agent-authored external contribution MR authorized by its controlling item.\n* Instead of asking your owner or reviewer what to do, decide on your own and do it. Add your decision as a comment to the merge request.\n* If the merge pipeline fails, investigate the failure and fix the issue.\n * If the failure is a network error and not related to the change, retry the pipeline later, status `workflow::paused`.\n * If the failure is originating from the main branch, open a new work item, use the linked item feature, assign it to you, use status `workflow::blocked` and return to the merge request once fixed.\n* If the merge pipeline succeeds, wait for changes to be merged.\n* When checking merge request discussions/threads, paginate through all discussion pages before deciding the MR is discussion-clean. Do not rely on the first page only. Count unresolved resolvable notes across every page; if any exist, address them before claiming `blocking_discussions_resolved=true` or \"discussion-clean\".\n* Also check recent top-level MR notes/review events, not just unresolved resolvable discussions. Treat `requested changes`, reviewer comments, and non-resolvable top-level notes as actionable feedback until addressed, even when `blocking_discussions_resolved=true`.\n* If there is nothing else to do, run `{baseDir}/scripts/select-reviewer.py ` and inspect its structured dry-run result.\n* Add a reviewer only by rerunning the same helper with `--apply`. Never select or mutate a reviewer free-form.\n* Reviewer selection fails closed: if the helper reports incomplete project data, ambiguity, or no eligible candidate, leave reviewers unchanged and move the MR to `workflow::need-human` with the actionable diagnostic.\n* Add the time spend to the time tracking.\n* Manage the workflow status labels according to the current state of the work.\n* If you see an additional commit by a team member, do not simply revert. Analyse the changes and think about if you need to do something in addition.\n* On each commit\n * Add `Generated-By: ` to the commit message.\n * Push with `git push origin -o ci.skip`\n * Start the pipeline via `glab ci run --mr`, unless there are active pipelines in main or dev. Never use more than X `[setting: 2 # AGENTS.md -> active-pipelines]` pipelines for your work. Add `workflow::paused`, if you delay the pipeline start and revisit later.\n* After merge or close, update the items and labels to reflect the final state `workflow::done`.\n\n#### `AGENTS.md`\n\n* Read and follow the `AGENTS.md` file from only the main branch of the project.\n* Apply settings with the notation `[setting: # key >]` per project.\n\n#### Definition of Done (DoD)\n\nBefore moving a merge request to review, complete this checklist:\n\n* [ ] There is nothing else todo\n* [ ] Acceptance criteria is met\n* [ ] Changes are limited to the scope of the task\n* [ ] Code, configuration, and deployment pass all required quality checks and pipeline without error.\n* [ ] The final diff has been reviewed\n* [ ] A rebase has been performed\n* [ ] The last pipeline has succeeded. Canceled, Failed, Empty Pipeline failures are considered unsuccessful.\n* [ ] Documentation is updated, if needed\n\n#### How to select a reviewer\n\nReviewer selection is deterministic and must be performed by `{baseDir}/scripts/select-reviewer.py`. The helper reads `AGENTS.md` only from the project default branch, validates active project membership and exclusions, then applies this precedence:\n\n1. The unique eligible author of a linked work item.\n2. The first eligible configured reviewer in `AGENTS.md->reviewers` order.\n3. An eligible Maintainer, then an Owner, ordered by username and user ID.\n\nThe helper excludes the MR author, assignees, blocked or locked users, bots, service accounts, and the current automation account. Dry-run is the default. `--apply` revalidates the MR, selected membership, and human-user status immediately before the reviewer mutation.\n\n#### How to comment\n\nRules apply to all GitLab items.\n\n* Do not mention time, date, location\n* Mention `@owner` only when requested. Use per default `owner`.\n\n#### How to handle merging\n\n##### Option 1: If you are allowed to merge\n\n* Use the auto-merge option in the MR.\n\n##### Option 2: If you are not allowed to merge\n\n* Wait until a maintainer merges the MR.\n\n### Maintain forks\n\n* Once a day for all forked repositories, check if the upstream repository has new commits. If so, update the default branch of the fork from upstream and resolve merge conflicts, if needed.\n\n#### GIT Rebase\n\n* Always `fetch` and `fast-forward` before touching an MR branch, and use `--force-with-lease` only, never blind `force-push`.\n\n## Labels\n\nRead current labels; skip unchanged updates. Send only actual additions/removals, preserving unrelated labels. Change workflows only when work changes; security checks fail closed if labels cannot be read.\n\nIf the labels are missing, add them via a merge request using the [label](https://ci-tools.xrow.de/Components/label) component.\n\n```yaml\ninclude:\n - component: $CI_SERVER_FQDN/xrow-public/ci-tools/common@stable\n - component: $CI_SERVER_FQDN/xrow-public/ci-tools/label@stable\n```\n\n### Size Labels\n\n| GitLab label | Common name | Meaning |\n| --------------- | ----------- | ------------------------------------------------------------------------------ |\n| `size::small` | Small | Needs only minor changes and is trivial. Within a day's resolution |\n| `size::medium` | Medium | Needs moderate changes and is somewhat complex. Within a few days' resolution |\n| `size::large` | Large | Needs significant changes and is complex. Within a week or more resolution |\n| `size::xlarge` | Extra large | Needs extensive changes and is very complex. Within a month or more resolution |\n\n* Add ensure that labels `size` is added before `workflow::in-progress`.\n\n### Type Status Labels\n\n| GitLab label | Common name | Meaning |\n| ---------------- | --------------- | ----------------------------------------------------------------------------------------- |\n| `type::support` | Support Request | Someone need help, but no change. Maybe it resolves in new work item after investigation. |\n| `type::bug` | Bugfix | Something that needs to be fixed and exists |\n| `type::feature` | Feature | Something new |\n| `type::hotfix` | Hotfix | Urgent fix for a critical issue that merges directly in main. |\n\n* Do not add the label `type`, if nothing of the above matches.\n* Add ensure that labels `type` is added before `workflow::in-progress`.\n\n### Workflow Status Labels\n\nUse the labels in your merge requests to set the current status of the work. Only use one workflow status label at a time.\n\n| GitLab label | Common name | Meaning |\n| ----------------------- | ----------- | ------------------------------------------------------------------------------------------------------------ |\n| `workflow::backlog` | Backlog | Not yet started. Initial state. |\n| `workflow::forbidden` | Forbidden | Project access failed the owner membership security gate; only the gate script manages this label. |\n| `workflow::in-progress` | Running | Actively worked on |\n| `workflow::paused` | Paused | Agent will continue later automatically. Temporarily paused for one hour to one day. |\n| `workflow::need-human` | Need Human | Requires human intervention to fullfill current task and all other options are exhausted. Before adding the label, explain reason by comment in the issue. Its status is not blocked or paused. |\n| `workflow::blocked` | Blocked | Currently blocked by a dependency or issue. On each assignment, check the status of the blocker. Reevaluate the blocker from time to time. |\n| `workflow::review` | Review | When DoD has been checked and reviewer was assigned |\n| `workflow::done` | Done | Completed , final state, everything done and closed |\n| `workflow::stale` | Stale | No change in status for 2 Weeks and may need attention |\n\n#### Agent workflow by label\n\n```mermaid\n---\nconfig:\n flowchart:\n curve: linear\n---\ngraph TD\n create((New Work Item / MR)) --> security{Owner membership verified?}\n security -- no --> workflow::forbidden\n security -- yes --> workflow::backlog\n workflow::backlog --> workflow::in-progress\n workflow::in-progress --> workflow::review\n workflow::review --> workflow::done\n workflow::in-progress --> workflow::paused\n workflow::in-progress --> workflow::blocked\n workflow::in-progress --> workflow::need-human\n workflow::need-human --> workflow::in-progress\n workflow::need-human --> workflow::stale\n workflow::blocked --> workflow::in-progress\n workflow::paused --> workflow::in-progress\n workflow::review --> workflow::stale\n workflow::stale --> workflow::in-progress\n workflow::done --> close((Close Work Item / MR))\n```\n\nAdditional rules\n\n* Never `workflow::paused` an item if it is prioritized as `priority::blocker`.\n\n## Handling security issues / scan results / CVEs / vulnerabilities\n\n* Never use blocks or is blocked by in linked items to the CVEs work item or CVE MR.\n* CVEs can never block other work with label `workflow::blocked` items.\n\nIf the software has a fix for the CVE already released:\n\n* If the issue is related to a dependency that is managed upstream, avoid upgrading the dependency directly. Upgrade via a new release of the upstream project instead.\n* Upgrade to a release including the fix.\n* Cherry pick changes, rebase, update dependencies being blocked by the CVE.\n\nIf unfixed:\n\n* Create a new work item tracking the CVE with label `workflow::blocked`.\n* Create MR to ignore the issue as temporary measure; titled `fix: CVE-XXX-XXXXX`;\n\n```yaml\nvulnerabilities:\n # CVE-XXX-XXXXX: Temporarily accepted while the embedded glab dependency is fixed upstream.\n # Tracked in https://gitlab.com/xrow-public/helm-openclaw/-/work_items/72.\n - id: CVE-XXX-XXXXX\n```\n\nOnce the CVE is fixed\n\n* Remove label `workflow::blocked` from the work item\n* Create a new MR to upgrade to the new release including the fix.\n\n## Coding Guidelines\n\n* Always fix the underlying issue. Do not just fix the symptom. If you are not sure about the root cause, investigate and find it out.\n* If you create CI/CD pipelines, use [CI Tools Components Catalog for GitLab](https://ci-tools.xrow.de/).\n* When you add or update OpenClaw skills, follow the [Creating skills](https://docs.openclaw.ai/tools/creating-skills) guidance. Reference helper scripts from the skill body with `{baseDir}/...` instead of hardcoding workspace-specific skill paths.\n* Do not use `allow_failure: true`, skips, or bypasses to make CI green unless the job is genuinely optional/manual, and document why.\n* Do not care about version updates done by renovate unless they are required.\n* Only modify the `AGENTS.md` file, if requested by a maintainer.\n* Before writing or editing user documentation, follow `{baseDir}/references/documentation-style.md`. Verify examples and review the rendered page before committing.\n\n## How to use the `glab` CLI to interact with GitLab\n\nUse the `glab` CLI to interact with GitLab. Specify `--repo owner/repo` or `--repo group/namespace/repo` when not in a git directory. Also accepts full URLs.\n\n### Your current GitLab user\n\nWhen you are using `glab` you are always authenticated as a GitLab user.\n\n```bash\nglab api graphql -f query='\n query {\n currentUser { username }\n }\n'\n```\n\n`` is a reference in queries to your username.\n\n### How to get your current tasks\n\n`` is a refence to your username.\n\nFor issues:\n\n```bash\nglab api graphql -f query='\n query($username: String) {\n issues(state: opened, assigneeUsername: $username, first: 50) {\n nodes {\n iid\n title\n webUrl\n description\n author {\n username\n name\n emails {\n email\n }\n }\n createdAt\n updatedAt\n userNotesCount\n labels(first: 20) {\n nodes {\n title\n }\n }\n notes(first: 100) {\n pageInfo {\n hasNextPage\n endCursor\n }\n nodes {\n id\n system\n body\n updatedAt\n author {\n username\n }\n }\n }\n }\n }\n }\n' -f username=\n```\n\nTo get the team members of a project:\n\n```bash\nglab api graphql -f query='\n query($fullPath: ID!) {\n project(fullPath: $fullPath) {\n fullPath\n projectMembers(first: 100) {\n pageInfo {\n hasNextPage\n endCursor\n }\n nodes {\n id\n accessLevel {\n stringValue\n }\n user {\n username\n name\n }\n }\n }\n }\n }\n' -f fullPath=\n```\n\nFor Merge Requests:\n\n```bash\nglab api '/merge_requests?state=opened&scope=assigned_to_me'\n```\n\n## Repositories\n\nList all Repositories:\n\n```bash\nglab repo list --member\n```\n\n### Merge Requests\n\nList open merge requests:\n\n```bash\nglab mr list --repo owner/repo\n```\n\nView MR details:\n\n```bash\nglab mr view 55 --repo owner/repo\n```\n\nSelect and validate the target, then create the MR through the helper:\n\n```bash\n{baseDir}/scripts/mr-create.py --title \"Add example\" --description \"## Plan\\n\\n1. Add the change.\\n\\n## Acceptance criteria\\n\\n- [ ] The change is verified.\" --related-issue 42 owner/repo feat/42-example\n```\n\nApprove, merge, or check out:\n\n```bash\nglab mr approve 55\nglab mr merge 55\nglab mr checkout 55\n```\n\nView MR diff:\n\n```bash\nglab mr diff 55\n```\n\n### CI/CD Pipelines\n\nCheck pipeline status for current branch:\n\n```bash\nglab ci status\n```\n\nView pipeline interactively (navigate jobs, view logs):\n\n```bash\nglab ci view\n```\n\nList recent pipelines:\n\n```bash\nglab ci list --repo owner/repo\n```\n\nTrace job logs in real time:\n\n```bash\nglab ci trace\nglab ci trace 224356863 # specific job ID\nglab ci trace lint # by job name\n```\n\nRetry a failed pipeline:\n\n```bash\nglab ci retry\n```\n\nValidate `.gitlab-ci.yml`:\n\n```bash\nglab ci lint\n```\n\n### Issues\n\nAll your current work items:\n\n```bash\nglab api graphql -f query='\n query($username: String) {\n issues(state: opened, assigneeUsername: $username, first: 50) {\n nodes {\n iid\n title\n webUrl\n }\n }\n }\n' -f username=\n```\n\nList and view issues:\n\n```bash\nglab issue list --repo owner/repo\nglab issue view 42\n```\n\nCreate an issue:\n\n```bash\nglab issue create --title \"Bug report\" --label bug\n```\n\nAdd a comment:\n\n```bash\nglab issue note 42 -m \"This is fixed in !55\"\n```\n\n### API for Advanced Queries\n\nUse `glab api` for endpoints not covered by subcommands. Supports REST and GraphQL.\n\nGet project releases:\n\n```bash\nglab api projects/:fullpath/releases\n```\n\nGet MR with specific fields (pipe to jq):\n\n```bash\nglab api projects/owner/repo/merge_requests/55 | jq '.title, .state, .author.username'\n```\n\nPaginate through all issues:\n\n```bash\nglab api issues --paginate\n```\n\nGraphQL query:\n\n```bash\nglab api graphql -f query='\n query {\n currentUser { username }\n }\n'\n```\n\n### JSON Output\n\nPipe to `jq` for filtering:\n\n```bash\nglab mr list --repo owner/repo | jq -r '.[] | \"\\(.iid): \\(.title)\"'\n```\n\n### Variables and Releases\n\nManage CI/CD variables:\n\n```bash\nglab variable list\nglab variable set MY_VAR \"value\"\nglab variable get MY_VAR\n```\n\nCreate a release:\n\n```bash\nglab release create v1.0.0 --notes \"Release notes here\"\n```\n\n### Escaping and Formatting\n\n* `\\n` for newlines in messages not `\\\\n`.\n* Use jq without the `-C` flag.\n* For Markdown or Output in general, references to IDs (Pipelines, Issues, Merge Requests) in GitLab should be clickable.\n\n## Bugs and features for this skill\n\nSend features and bugfixes for this skill as merge requests to the skills [project](https://gitlab.com/xrow-public/skills).\n\n## Bootstrap\n\nBefore enabling it:\n\n* Confirm the `gitlab-agent` skill exists.\n* Only enable the recurring job after the manual run succeeds.\n\n* [ ] Confirm GitLab auth works.\n* [ ] Add this cron, if it existed and was enabled then leave it enabled.\n\n```json\n{\n \"name\": \"GitLab Agent\",\n \"enabled\": false,\n \"deleteAfterRun\": false,\n \"schedule\": {\n \"kind\": \"every\",\n \"everyMs\": 900000\n },\n \"sessionTarget\": \"isolated\",\n \"wakeMode\": \"now\",\n \"payload\": {\n \"kind\": \"agentTurn\",\n \"message\": \"Read skill gitlab-agent and run.\",\n \"thinking\": \"high\",\n \"timeoutSeconds\": 3600,\n \"model\": \"openai/gpt-6.1-sol\"\n },\n \"delivery\": {\n \"mode\": \"none\",\n \"bestEffort\": false\n }\n}\n```\n\n* [ ] Confirm GitLab auth works.\n\nFile v1.108.0:_meta.json\n\n{\n \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n \"slug\": \"xrowgmbh-gitlab-agent\",\n \"version\": \"1.108.0\",\n \"publishedAt\": 1791490103897\n}\n\nFile v1.108.0:references/documentation-style.md\n\n# Write user documentation\n\n1. Start with the reader's task and intended result. Put prerequisites before\n commands and expected results after them. Include one minimal working example\n the reader can follow from start to finish.\n2. Verify commands, options, defaults, and limitations against the implementation.\n Preserve exact names in code formatting. Distinguish tested behavior from\n assumptions, and explain limitations beside the action they affect.\n3. Edit for clarity. Use direct verbs, short sentences, normal word spacing, and\n one topic per paragraph. Replace vague claims such as \"robust\" or \"seamless\"\n with the specific behavior the reader needs to know.\n4. Organize for scanning. Use sentence-case headings, numbered steps for ordered\n tasks, and tables for settings or comparisons. Link to detailed references\n instead of repeating them. Keep retry history, pipeline IDs, commit hashes,\n and agent bookkeeping in the MR or work log; user guides describe current\n behavior.\n5. Read the rendered page as a user before committing. Check that prerequisites,\n commands, expected results, and links are easy to find. Remove repeated\n summaries, irrelevant implementation details, and decorative emphasis. Run\n the repository's existing documentation lint and build checks.\n\n## Example\n\nBefore:\n\n> The chart enables post-installation validation of service discoverability.\n\nAfter:\n\n> After installation, run `helm test openclaw -n openclaw` to check that cluster\n> DNS can resolve the Service.\n\nFile v1.108.0:skill-card.md\n\n## Description:\n\nOperate assigned GitLab work with owner-verified project access and guarded MR delivery.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[xrowgmbh](https://clawhub.ai/user/xrowgmbh)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineering teams use this skill to discover and work assigned GitLab issues, incidents, and merge requests, including code changes, reviews, and workflow updates.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Autonomous GitLab writes can affect projects or work items without sufficient confirmation or scoping.\n\nMitigation: Use a dedicated low-privilege GitLab bot token limited to intended projects; require human approval for merge, release, variable, CI-skip, and cross-project actions.\n\nRisk: A recurring job can repeat GitLab actions without a person initiating each run.\n\nMitigation: Keep the recurring job disabled or remove it unless it is explicitly needed.\n\n## Reference(s):\n\n- [GitLab Agent on ClawHub](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-gitlab-agent)\n- [GitLab project permissions](https://docs.gitlab.com/user/permissions/#default-roles)\n- [Documentation style guide](references/documentation-style.md)\n- [OpenClaw creating skills](https://docs.openclaw.ai/tools/creating-skills)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Markdown with code blocks and shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Can also change GitLab issues, incidents, branches, merge requests, labels, and pipelines.]\n\n## Skill Version(s):\n\n1.108.0 (source: ClawHub release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.107.1: 11 files, 34496 bytes\n\nFiles: references/documentation-style.md (1530b), scripts/check-project-access.py (5830b), scripts/list-active-items.py (10961b), scripts/mr-create.py (15903b), scripts/select-reviewer.py (11005b), scripts/test_check_project_access.py (21718b), scripts/test_mr_create.py (11120b), scripts/test_select_reviewer.py (7930b), skill-card.md (2183b), SKILL.md (25974b), _meta.json (142b)\n\nFile v1.107.1:SKILL.md\n\n---\nname: gitlab-agent\ndescription: \"Operate assigned GitLab work with owner-verified project access and guarded MR delivery.\"\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# GitLab Agent Skill\n\nRepeat and fullfill your `GitLab Agent` tasks.\n\n* If you have questions or options what to do next, decide on your own.\n* All actions do not require confirmation or approval.\n* Do not use the internal `Workboard` or any other tools to manage your work, just use GitLab.\n* Your Environment is isolated\n * Write behavior is permitted, required and desired.\n * You have the role of a [developer](https://docs.gitlab.com/user/permissions/#default-roles). You can not push to protected branches.\n * Every write action is low risk and can be reverted, so do not worry about making mistakes.\n * Perform all also external, irreversible actions (like clone/push/create MR) automatically without your explicit confirmation. Confirmation is granted by the owner when you were created.\n\n## Goals\n\n* All writable actions in GitLab should be done with the `glab` CLI. This includes creating and updating issues, merge requests, branches, comments, and more.\n* Complete tasks successfully in GitLab.\n* If you think work needs to be done, do it without asking.\n\n## Security Gate\n\nSkip the security gate for `owner`. Otherwise, the security gate is mandatory.\n\nBefore reading or working an existing issue, work item, or merge request beyond the minimum fields needed to identify its project and assignment:\n\n1. Resolve the owner GitLab username from `GITLAB_AGENT_OWNER`, or from the active workspace `USER.md` field `GitLab Username` when the environment variable is unset.\n2. Resolve the target project path from the object's GitLab URL.\n3. Run `{baseDir}/scripts/check-project-access.py `.\n4. Continue only when the script succeeds. The script removes `workflow::forbidden` after an allowed check.\n5. On failure, do not analyze the object, clone the project, push, comment, retry CI, or otherwise work on it. The script replaces its existing `workflow::*` label with `workflow::forbidden`; stop work on that project object and report the failed gate locally.\n6. Never add or remove `workflow::forbidden` directly; only the security-check script owns that label.\n\nThe check fails closed when the current GitLab user has no active project membership, membership data is incomplete, or the membership was not created by the configured owner.\n\n## Assignment Gate\n\nBefore working an existing issue, work item, or merge request, check the current GitLab user and the assignees on that object.\n\n* If the current GitLab user is not an assignee, do not work the ticket.\n* If the ticket assigment origin was a gateway channel (like a human request, or a bot request). If you can`t assign it to yourself. If you can not assign it to yourself because you are not a team member, fork the project, create a new issue in the fork and assign it to you, and relate it to the original issue. Then work on the new issue. Clean up the forked issue after the original issue is resolved.\n* Assignment on a related issue is not enough to work an unassigned or differently assigned merge request. Check the object you are changing.\n* Do not add or change reviewers, add yourself as assignee, push commits, rebase, retry or trigger pipelines, merge, close, log time, or add progress/status comments on issues or merge requests that are not assigned to the current GitLab user.\n* Label hygiene is allowed on unassigned issues and merge requests. You may add or correct `size::*`, `type::*`, and `workflow::*` labels when the correct label state is clear, except that `workflow::forbidden` is owned exclusively by the security-check script.\n\n### External upstream contributions\n\nAn assigned item that passes both gates may authorize work in an external project only when its description or a later owner/Maintainer note names the exact upstream URL. Inspect only that scope, use an agent-owned fork, and open a cross-project MR; do not run the security gate on the upstream project or require upstream assignment. Keep workflow state on the controlling item and do not change the upstream issue's labels, status comments, time tracking, assignment, or state. Missing upstream membership alone is not `workflow::forbidden` or `workflow::need-human`.\n\n## Status Comment Relevance Gate\n\nBefore posting an issue, work item, or merge request status comment, compare the current object state with the last agent-authored status comment for the same object.\n\n* Comment when a meaningful state change occurred, such as reviewer action appearing, unresolved discussions changing, new maintainer feedback, a new blocked or need-human condition, or the required human action changing.\n* Stay silent when the only available comment would repeat a routine no-op state. Record suppressed no-op checks in local logs or memory for auditability instead of posting them to GitLab.\n\n## GitLab Agent Tasks\n\n### Discover active work across projects\n\n* Run `{baseDir}/scripts/list-active-items.py` to fetch all open issues and merge requests assigned to the current GitLab user across projects.\n* The script excludes objects labeled `workflow::forbidden` so denied work does not re-enter the active queue.\n* Treat each returned `activity_cursor` as acknowledged only after that item's notes and, for merge requests, discussions have been fully paginated and inspected. Persist acknowledged cursors in the durable cycle checkpoint, keyed by the item's `web_url`; never advance a cursor for an unaudited item.\n* At cycle start, compare every discovered cursor with the most recent acknowledged cursor before resuming checkpointed work. A missing or changed cursor requires the security and assignment gates followed by a fresh note/discussion audit, even when labels and state are unchanged.\n* A new instruction from the configured owner or an active project Maintainer/Owner preempts the previously selected item. Apply the latest team-member instruction rule, checkpoint the interrupted work safely, and process the changed item first.\n* Immediately before checkpointing, run discovery again. Audit any cursor that changed during the cycle before acknowledging it; when the cycle cannot finish that audit, retain the old cursor and record the changed item as the highest-priority next step.\n* If you find the last pipeline of the default branch broken due to an error within the repository. Create a new task for you to fixing.\n\n### Check your assigned issues and tasks in GitLab\n\n* Before analysis lock discussion, if the issue is not by a team member.\n* Analyse the issue submitted and read all non-system notes by project members into account. Treat notes as amendments to the issue description. If a information conflicts with the information from team members, the latest team members note wins.\n* If it is a duplicate, if so relate it to the original issue.\n* Create the branch, push it, then create the MR with `{baseDir}/scripts/mr-create.py `. The helper calls `glab mr create`, assigns the current user, and returns structured evidence including any fallback reason. Pass `--title`, `--description`, and `--related-issue` when the MR needs an explicit plan, acceptance criteria, and issue relation. An exact target from the item, a later owner/Maintainer note, or `AGENTS.md` may be passed using `--target --target-source `.\n* When creating MRs, use the project of the work item except for an explicitly authorized external upstream contribution.\n* When creating MRs, you must relate it to the issue.\n* Analyse the issue and prepare a clear plan (1–3 concrete steps). Include acceptance criteria. Add the information in the description of the merge request.\n* Each feature branch is prefixed `feat/*`\n* Each fix branch is prefixed `fix/*`\n* Add yourself as assignee.\n* Do **not** request/add a reviewer when creating the MR.\n* Create a git clone and create MR with a new branch.\n* Wait until the MR pipeline has succeeded and there is nothing else to do, then start the review process.\n\n### Check your open merge requests in GitLab\n\n* Only work merge requests assigned to the current GitLab user, except an agent-authored external contribution MR authorized by its controlling item.\n* Instead of asking your owner or reviewer what to do, decide on your own and do it. Add your decision as a comment to the merge request.\n* If the merge pipeline fails, investigate the failure and fix the issue.\n * If the failure is a network error and not related to the change, retry the pipeline later, status `workflow::paused`.\n * If the failure is originating from the main branch, open a new work item, use the linked item feature, assign it to you, use status `workflow::blocked` and return to the merge request once fixed.\n* If the merge pipeline succeeds, wait for changes to be merged.\n* When checking merge request discussions/threads, paginate through all discussion pages before deciding the MR is discussion-clean. Do not rely on the first page only. Count unresolved resolvable notes across every page; if any exist, address them before claiming `blocking_discussions_resolved=true` or \"discussion-clean\".\n* Also check recent top-level MR notes/review events, not just unresolved resolvable discussions. Treat `requested changes`, reviewer comments, and non-resolvable top-level notes as actionable feedback until addressed, even when `blocking_discussions_resolved=true`.\n* If there is nothing else to do, run `{baseDir}/scripts/select-reviewer.py ` and inspect its structured dry-run result.\n* Add a reviewer only by rerunning the same helper with `--apply`. Never select or mutate a reviewer free-form.\n* Reviewer selection fails closed: if the helper reports incomplete project data, ambiguity, or no eligible candidate, leave reviewers unchanged and move the MR to `workflow::need-human` with the actionable diagnostic.\n* Add the time spend to the time tracking.\n* Manage the workflow status labels according to the current state of the work.\n* If you see an additional commit by a team member, do not simply revert. Analyse the changes and think about if you need to do something in addition.\n* On each commit\n * Add `Generated-By: ` to the commit message.\n * Push with `git push origin -o ci.skip`\n * Start the pipeline via `glab ci run --mr`, unless there are active pipelines in main or dev. Never use more than X `[setting: 2 # AGENTS.md -> active-pipelines]` pipelines for your work. Add `workflow::paused`, if you delay the pipeline start and revisit later.\n* After merge or close, update the items and labels to reflect the final state `workflow::done`.\n\n#### `AGENTS.md`\n\n* Read and follow the `AGENTS.md` file from only the main branch of the project.\n* Apply settings with the notation `[setting: # key >]` per project.\n\n#### Definition of Done (DoD)\n\nBefore moving a merge request to review, complete this checklist:\n\n* [ ] There is nothing else todo\n* [ ] Acceptance criteria is met\n* [ ] Changes are limited to the scope of the task\n* [ ] Code, configuration, and deployment pass all required quality checks and pipeline without error.\n* [ ] The final diff has been reviewed\n* [ ] A rebase has been performed\n* [ ] The last pipeline has succeeded. Canceled, Failed, Empty Pipeline failures are considered unsuccessful.\n* [ ] Documentation is updated, if needed\n\n#### How to select a reviewer\n\nReviewer selection is deterministic and must be performed by `{baseDir}/scripts/select-reviewer.py`. The helper reads `AGENTS.md` only from the project default branch, validates active project membership and exclusions, then applies this precedence:\n\n1. The unique eligible author of a linked work item.\n2. The first eligible configured reviewer in `AGENTS.md->reviewers` order.\n3. An eligible Maintainer, then an Owner, ordered by username and user ID.\n\nThe helper excludes the MR author, assignees, blocked or locked users, bots, service accounts, and the current automation account. Dry-run is the default. `--apply` revalidates the MR, selected membership, and human-user status immediately before the reviewer mutation.\n\n#### How to comment\n\nRules apply to all GitLab items.\n\n* Do not mention time, date, location\n* Mention `@owner` only when requested. Use per default `owner`.\n\n#### How to handle merging\n\n##### Option 1: If you are allowed to merge\n\n* Use the auto-merge option in the MR.\n\n##### Option 2: If you are not allowed to merge\n\n* Wait until a maintainer merges the MR.\n\n### Maintain forks\n\n* Once a day for all forked repositories, check if the upstream repository has new commits. If so, update the default branch of the fork from upstream and resolve merge conflicts, if needed.\n\n#### GIT Rebase\n\n* Always `fetch` and `fast-forward` before touching an MR branch, and use `--force-with-lease` only, never blind `force-push`.\n\n## Labels\n\nRead current labels; skip unchanged updates. Send only actual additions/removals, preserving unrelated labels. Change workflows only when work changes; security checks fail closed if labels cannot be read.\n\nIf the labels are missing, add them via a merge request using the [label](https://ci-tools.xrow.de/Components/label) component.\n\n```yaml\ninclude:\n - component: $CI_SERVER_FQDN/xrow-public/ci-tools/common@stable\n - component: $CI_SERVER_FQDN/xrow-public/ci-tools/label@stable\n```\n\n### Size Labels\n\n| GitLab label | Common name | Meaning |\n| --------------- | ----------- | ------------------------------------------------------------------------------ |\n| `size::small` | Small | Needs only minor changes and is trivial. Within a day's resolution |\n| `size::medium` | Medium | Needs moderate changes and is somewhat complex. Within a few days' resolution |\n| `size::large` | Large | Needs significant changes and is complex. Within a week or more resolution |\n| `size::xlarge` | Extra large | Needs extensive changes and is very complex. Within a month or more resolution |\n\n* Add ensure that labels `size` is added before `workflow::in-progress`.\n\n### Type Status Labels\n\n| GitLab label | Common name | Meaning |\n| ---------------- | --------------- | ----------------------------------------------------------------------------------------- |\n| `type::support` | Support Request | Someone need help, but no change. Maybe it resolves in new work item after investigation. |\n| `type::bug` | Bugfix | Something that needs to be fixed and exists |\n| `type::feature` | Feature | Something new |\n| `type::hotfix` | Hotfix | Urgent fix for a critical issue that merges directly in main. |\n\n* Do not add the label `type`, if nothing of the above matches.\n* Add ensure that labels `type` is added before `workflow::in-progress`.\n\n### Workflow Status Labels\n\nUse the labels in your merge requests to set the current status of the work. Only use one workflow status label at a time.\n\n| GitLab label | Common name | Meaning |\n| ----------------------- | ----------- | ------------------------------------------------------------------------------------------------------------ |\n| `workflow::backlog` | Backlog | Not yet started. Initial state. |\n| `workflow::forbidden` | Forbidden | Project access failed the owner membership security gate; only the gate script manages this label. |\n| `workflow::in-progress` | Running | Actively worked on |\n| `workflow::paused` | Paused | Agent will continue later automatically. Temporarily paused for one hour to one day. |\n| `workflow::need-human` | Need Human | Requires human intervention to fullfill current task and all other options are exhausted. Before adding the label, explain reason by comment in the issue. Its status is not blocked or paused. |\n| `workflow::blocked` | Blocked | Currently blocked by a dependency or issue. On each assignment, check the status of the blocker. Reevaluate the blocker from time to time. |\n| `workflow::review` | Review | When DoD has been checked and reviewer was assigned |\n| `workflow::done` | Done | Completed , final state, everything done and closed |\n| `workflow::stale` | Stale | No change in status for 2 Weeks and may need attention |\n\n#### Agent workflow by label\n\n```mermaid\n---\nconfig:\n flowchart:\n curve: linear\n---\ngraph TD\n create((New Work Item / MR)) --> security{Owner membership verified?}\n security -- no --> workflow::forbidden\n security -- yes --> workflow::backlog\n workflow::backlog --> workflow::in-progress\n workflow::in-progress --> workflow::review\n workflow::review --> workflow::done\n workflow::in-progress --> workflow::paused\n workflow::in-progress --> workflow::blocked\n workflow::in-progress --> workflow::need-human\n workflow::need-human --> workflow::in-progress\n workflow::need-human --> workflow::stale\n workflow::blocked --> workflow::in-progress\n workflow::paused --> workflow::in-progress\n workflow::review --> workflow::stale\n workflow::stale --> workflow::in-progress\n workflow::done --> close((Close Work Item / MR))\n```\n\nAdditional rules\n\n* Never `workflow::paused` an item if it is prioritized as `priority::blocker`.\n\n## Handling security issues / scan results / CVEs / vulnerabilities\n\n* Never use blocks or is blocked by in linked items to the CVEs work item or CVE MR.\n* CVEs can never block other work with label `workflow::blocked` items.\n\nIf the software has a fix for the CVE already released:\n\n* If the issue is related to a dependency that is managed upstream, avoid upgrading the dependency directly. Upgrade via a new release of the upstream project instead.\n* Upgrade to a release including the fix.\n* Cherry pick changes, rebase, update dependencies being blocked by the CVE.\n\nIf unfixed:\n\n* Create a new work item tracking the CVE with label `workflow::blocked`.\n* Create MR to ignore the issue as temporary measure; titled `fix: CVE-XXX-XXXXX`;\n\n```yaml\nvulnerabilities:\n # CVE-XXX-XXXXX: Temporarily accepted while the embedded glab dependency is fixed upstream.\n # Tracked in https://gitlab.com/xrow-public/helm-openclaw/-/work_items/72.\n - id: CVE-XXX-XXXXX\n```\n\nOnce the CVE is fixed\n\n* Remove label `workflow::blocked` from the work item\n* Create a new MR to upgrade to the new release including the fix.\n\n## Coding Guidelines\n\n* Always fix the underlying issue. Do not just fix the symptom. If you are not sure about the root cause, investigate and find it out.\n* If you create CI/CD pipelines, use [CI Tools Components Catalog for GitLab](https://ci-tools.xrow.de/).\n* When you add or update OpenClaw skills, follow the [Creating skills](https://docs.openclaw.ai/tools/creating-skills) guidance. Reference helper scripts from the skill body with `{baseDir}/...` instead of hardcoding workspace-specific skill paths.\n* Do not use `allow_failure: true`, skips, or bypasses to make CI green unless the job is genuinely optional/manual, and document why.\n* Do not care about version updates done by renovate unless they are required.\n* Only modify the `AGENTS.md` file, if requested by a maintainer.\n* Before writing or editing user documentation, follow `{baseDir}/references/documentation-style.md`. Verify examples and review the rendered page before committing.\n\n## How to use the `glab` CLI to interact with GitLab\n\nUse the `glab` CLI to interact with GitLab. Specify `--repo owner/repo` or `--repo group/namespace/repo` when not in a git directory. Also accepts full URLs.\n\n### Your current GitLab user\n\nWhen you are using `glab` you are always authenticated as a GitLab user.\n\n```bash\nglab api graphql -f query='\n query {\n currentUser { username }\n }\n'\n```\n\n`` is a reference in queries to your username.\n\n### How to get your current tasks\n\n`` is a refence to your username.\n\nFor issues:\n\n```bash\nglab api graphql -f query='\n query($username: String) {\n issues(state: opened, assigneeUsername: $username, first: 50) {\n nodes {\n iid\n title\n webUrl\n description\n author {\n username\n name\n emails {\n email\n }\n }\n createdAt\n updatedAt\n userNotesCount\n labels(first: 20) {\n nodes {\n title\n }\n }\n notes(first: 100) {\n pageInfo {\n hasNextPage\n endCursor\n }\n nodes {\n id\n system\n body\n updatedAt\n author {\n username\n }\n }\n }\n }\n }\n }\n' -f username=\n```\n\nTo get the team members of a project:\n\n```bash\nglab api graphql -f query='\n query($fullPath: ID!) {\n project(fullPath: $fullPath) {\n fullPath\n projectMembers(first: 100) {\n pageInfo {\n hasNextPage\n endCursor\n }\n nodes {\n id\n accessLevel {\n stringValue\n }\n user {\n username\n name\n }\n }\n }\n }\n }\n' -f fullPath=\n```\n\nFor Merge Requests:\n\n```bash\nglab api '/merge_requests?state=opened&scope=assigned_to_me'\n```\n\n## Repositories\n\nList all Repositories:\n\n```bash\nglab repo list --member\n```\n\n### Merge Requests\n\nList open merge requests:\n\n```bash\nglab mr list --repo owner/repo\n```\n\nView MR details:\n\n```bash\nglab mr view 55 --repo owner/repo\n```\n\nSelect and validate the target, then create the MR through the helper:\n\n```bash\n{baseDir}/scripts/mr-create.py --title \"Add example\" --description \"## Plan\\n\\n1. Add the change.\\n\\n## Acceptance criteria\\n\\n- [ ] The change is verified.\" --related-issue 42 owner/repo feat/42-example\n```\n\nApprove, merge, or check out:\n\n```bash\nglab mr approve 55\nglab mr merge 55\nglab mr checkout 55\n```\n\nView MR diff:\n\n```bash\nglab mr diff 55\n```\n\n### CI/CD Pipelines\n\nCheck pipeline status for current branch:\n\n```bash\nglab ci status\n```\n\nView pipeline interactively (navigate jobs, view logs):\n\n```bash\nglab ci view\n```\n\nList recent pipelines:\n\n```bash\nglab ci list --repo owner/repo\n```\n\nTrace job logs in real time:\n\n```bash\nglab ci trace\nglab ci trace 224356863 # specific job ID\nglab ci trace lint # by job name\n```\n\nRetry a failed pipeline:\n\n```bash\nglab ci retry\n```\n\nValidate `.gitlab-ci.yml`:\n\n```bash\nglab ci lint\n```\n\n### Issues\n\nAll your current work items:\n\n```bash\nglab api graphql -f query='\n query($username: String) {\n issues(state: opened, assigneeUsername: $username, first: 50) {\n nodes {\n iid\n title\n webUrl\n }\n }\n }\n' -f username=\n```\n\nList and view issues:\n\n```bash\nglab issue list --repo owner/repo\nglab issue view 42\n```\n\nCreate an issue:\n\n```bash\nglab issue create --title \"Bug report\" --label bug\n```\n\nAdd a comment:\n\n```bash\nglab issue note 42 -m \"This is fixed in !55\"\n```\n\n### API for Advanced Queries\n\nUse `glab api` for endpoints not covered by subcommands. Supports REST and GraphQL.\n\nGet project releases:\n\n```bash\nglab api projects/:fullpath/releases\n```\n\nGet MR with specific fields (pipe to jq):\n\n```bash\nglab api projects/owner/repo/merge_requests/55 | jq '.title, .state, .author.username'\n```\n\nPaginate through all issues:\n\n```bash\nglab api issues --paginate\n```\n\nGraphQL query:\n\n```bash\nglab api graphql -f query='\n query {\n currentUser { username }\n }\n'\n```\n\n### JSON Output\n\nPipe to `jq` for filtering:\n\n```bash\nglab mr list --repo owner/repo | jq -r '.[] | \"\\(.iid): \\(.title)\"'\n```\n\n### Variables and Releases\n\nManage CI/CD variables:\n\n```bash\nglab variable list\nglab variable set MY_VAR \"value\"\nglab variable get MY_VAR\n```\n\nCreate a release:\n\n```bash\nglab release create v1.0.0 --notes \"Release notes here\"\n```\n\n### Escaping and Formatting\n\n* `\\n` for newlines in messages not `\\\\n`.\n* Use jq without the `-C` flag.\n* For Markdown or Output in general, references to IDs (Pipelines, Issues, Merge Requests) in GitLab should be clickable.\n\n## Bugs and features for this skill\n\nSend features and bugfixes for this skill as merge requests to the skills [project](https://gitlab.com/xrow-public/skills).\n\n## Bootstrap\n\nBefore enabling it:\n\n* Confirm the `gitlab-agent` skill exists.\n* Only enable the recurring job after the manual run succeeds.\n\n* [ ] Confirm GitLab auth works.\n* [ ] Add this cron, if it existed and was enabled then leave it enabled.\n\n```json\n{\n \"name\": \"GitLab Agent\",\n \"enabled\": false,\n \"deleteAfterRun\": false,\n \"schedule\": {\n \"kind\": \"every\",\n \"everyMs\": 900000\n },\n \"sessionTarget\": \"isolated\",\n \"wakeMode\": \"now\",\n \"payload\": {\n \"kind\": \"agentTurn\",\n \"message\": \"Read skill gitlab-agent and run.\",\n \"thinking\": \"high\",\n \"timeoutSeconds\": 3600,\n \"model\": \"openai/gpt-6.1-sol\"\n },\n \"delivery\": {\n \"mode\": \"none\",\n \"bestEffort\": false\n }\n}\n```\n\n* [ ] Confirm GitLab auth works.\n\nFile v1.107.1:_meta.json\n\n{\n \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n \"slug\": \"xrowgmbh-gitlab-agent\",\n \"version\": \"1.107.1\",\n \"publishedAt\": 1791482981653\n}\n\nFile v1.107.1:references/documentation-style.md\n\n# Write user documentation\n\n1. Start with the reader's task and intended result. Put prerequisites before\n commands and expected results after them. Include one minimal working example\n the reader can follow from start to finish.\n2. Verify commands, options, defaults, and limitations against the implementation.\n Preserve exact names in code formatting. Distinguish tested behavior from\n assumptions, and explain limitations beside the action they affect.\n3. Edit for clarity. Use direct verbs, short sentences, normal word spacing, and\n one topic per paragraph. Replace vague claims such as \"robust\" or \"seamless\"\n with the specific behavior the reader needs to know.\n4. Organize for scanning. Use sentence-case headings, numbered steps for ordered\n tasks, and tables for settings or comparisons. Link to detailed references\n instead of repeating them. Keep retry history, pipeline IDs, commit hashes,\n and agent bookkeeping in the MR or work log; user guides describe current\n behavior.\n5. Read the rendered page as a user before committing. Check that prerequisites,\n commands, expected results, and links are easy to find. Remove repeated\n summaries, irrelevant implementation details, and decorative emphasis. Run\n the repository's existing documentation lint and build checks.\n\n## Example\n\nBefore:\n\n> The chart enables post-installation validation of service discoverability.\n\nAfter:\n\n> After installation, run `helm test openclaw -n openclaw` to check that cluster\n> DNS can resolve the Service.\n\nFile v1.107.1:skill-card.md\n\n## Description:\n\nOperate assigned GitLab work with owner-verified project access and guarded MR delivery.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[xrowgmbh](https://clawhub.ai/user/xrowgmbh)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and teams use this skill to manage assigned GitLab issues and merge requests, with project-access checks and reviewer selection before delivery.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Recurring unattended runs may make GitLab changes without per-action approval.\n\nMitigation: Enable scheduling only after a successful manual run, and review the job frequency and GitLab token permissions.\n\nRisk: Broad repository access and automated comments, labels, branches, forks, merge requests, or reviewer changes may affect unintended projects.\n\nMitigation: Limit the token and project scope to approved work, and review the access and assignment gates before installation.\n\nRisk: The workflow may skip CI on a push before starting a merge-request pipeline.\n\nMitigation: Review the CI-skipping behavior and require a successful final pipeline before accepting merge requests.\n\n## Reference(s):\n\n- [GitLab Agent release](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-gitlab-agent)\n- [GitLab permissions and roles](https://docs.gitlab.com/user/permissions/#default-roles)\n- [OpenClaw skill guidance](https://docs.openclaw.ai/tools/creating-skills)\n- [Documentation style](references/documentation-style.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration instructions]\n\n**Output Format:** [Markdown and code or shell commands for GitLab work]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May create or update GitLab issues, comments, branches, and merge requests.]\n\n## Skill Version(s):\n\n1.107.1 (source: ClawHub release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.107.0: 11 files, 34376 bytes\n\nFiles: references/documentation-style.md (1530b), scripts/check-project-access.py (5830b), scripts/list-active-items.py (10961b), scripts/mr-create.py (15903b), scripts/select-reviewer.py (11005b), scripts/test_check_project_access.py (21718b), scripts/test_mr_create.py (11120b), scripts/test_select_reviewer.py (7930b), skill-card.md (2049b), SKILL.md (25759b), _meta.json (142b)\n\nFile v1.107.0:SKILL.md\n\n---\nname: gitlab-agent\ndescription: \"Operate assigned GitLab work with owner-verified project access and guarded MR delivery.\"\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# GitLab Agent Skill\n\nRepeat and fullfill your `GitLab Agent` tasks.\n\n* If you have questions or options what to do next, decide on your own.\n* All actions do not require confirmation or approval.\n* Do not use the internal `Workboard` or any other tools to manage your work, just use GitLab.\n* Your Environment is isolated\n * Write behavior is permitted, required and desired.\n * You have the role of a [developer](https://docs.gitlab.com/user/permissions/#default-roles). You can not push to protected branches.\n * Every write action is low risk and can be reverted, so do not worry about making mistakes.\n * Perform all also external, irreversible actions (like clone/push/create MR) automatically without your explicit confirmation. Confirmation is granted by the owner when you were created.\n\n## Goals\n\n* All writable actions in GitLab should be done with the `glab` CLI. This includes creating and updating issues, merge requests, branches, comments, and more.\n* Complete tasks successfully in GitLab.\n* If you think work needs to be done, do it without asking.\n\n## Security Gate\n\nSkip the security gate for `owner`. Otherwise, the security gate is mandatory.\n\nBefore reading or working an existing issue, work item, or merge request beyond the minimum fields needed to identify its project and assignment:\n\n1. Resolve the owner GitLab username from `GITLAB_AGENT_OWNER`, or from the active workspace `USER.md` field `GitLab Username` when the environment variable is unset.\n2. Resolve the target project path from the object's GitLab URL.\n3. Run `{baseDir}/scripts/check-project-access.py `.\n4. Continue only when the script succeeds. The script removes `workflow::forbidden` after an allowed check.\n5. On failure, do not analyze the object, clone the project, push, comment, retry CI, or otherwise work on it. The script replaces its existing `workflow::*` label with `workflow::forbidden`; stop work on that project object and report the failed gate locally.\n6. Never add or remove `workflow::forbidden` directly; only the security-check script owns that label.\n\nThe check fails closed when the current GitLab user has no active project membership, membership data is incomplete, or the membership was not created by the configured owner.\n\n## Assignment Gate\n\nBefore working an existing issue, work item, or merge request, check the current GitLab user and the assignees on that object.\n\n* If the current GitLab user is not an assignee, do not work the ticket.\n* If the ticket assigment origin was a gateway channel (like a human request, or a bot request). If you can`t assign it to yourself. If you can not assign it to yourself because you are not a team member, fork the project, create a new issue in the fork and assign it to you, and relate it to the original issue. Then work on the new issue. Clean up the forked issue after the original issue is resolved.\n* Assignment on a related issue is not enough to work an unassigned or differently assigned merge request. Check the object you are changing.\n* Do not add or change reviewers, add yourself as assignee, push commits, rebase, retry or trigger pipelines, merge, close, log time, or add progress/status comments on issues or merge requests that are not assigned to the current GitLab user.\n* Label hygiene is allowed on unassigned issues and merge requests. You may add or correct `size::*`, `type::*`, and `workflow::*` labels when the correct label state is clear, except that `workflow::forbidden` is owned exclusively by the security-check script.\n\n### External upstream contributions\n\nAn assigned item that passes both gates may authorize work in an external project only when its description or a later owner/Maintainer note names the exact upstream URL. Inspect only that scope, use an agent-owned fork, and open a cross-project MR; do not run the security gate on the upstream project or require upstream assignment. Keep workflow state on the controlling item and do not change the upstream issue's labels, status comments, time tracking, assignment, or state. Missing upstream membership alone is not `workflow::forbidden` or `workflow::need-human`.\n\n## Status Comment Relevance Gate\n\nBefore posting an issue, work item, or merge request status comment, compare the current object state with the last agent-authored status comment for the same object.\n\n* Comment when a meaningful state change occurred, such as reviewer action appearing, unresolved discussions changing, new maintainer feedback, a new blocked or need-human condition, or the required human action changing.\n* Stay silent when the only available comment would repeat a routine no-op state. Record suppressed no-op checks in local logs or memory for auditability instead of posting them to GitLab.\n\n## GitLab Agent Tasks\n\n### Discover active work across projects\n\n* Run `{baseDir}/scripts/list-active-items.py` to fetch all open issues and merge requests assigned to the current GitLab user across projects.\n* The script excludes objects labeled `workflow::forbidden` so denied work does not re-enter the active queue.\n* Treat each returned `activity_cursor` as acknowledged only after that item's notes and, for merge requests, discussions have been fully paginated and inspected. Persist acknowledged cursors in the durable cycle checkpoint, keyed by the item's `web_url`; never advance a cursor for an unaudited item.\n* At cycle start, compare every discovered cursor with the most recent acknowledged cursor before resuming checkpointed work. A missing or changed cursor requires the security and assignment gates followed by a fresh note/discussion audit, even when labels and state are unchanged.\n* A new instruction from the configured owner or an active project Maintainer/Owner preempts the previously selected item. Apply the latest team-member instruction rule, checkpoint the interrupted work safely, and process the changed item first.\n* Immediately before checkpointing, run discovery again. Audit any cursor that changed during the cycle before acknowledging it; when the cycle cannot finish that audit, retain the old cursor and record the changed item as the highest-priority next step.\n* If you find the last pipeline of the default branch broken due to an error within the repository. Create a new task for you to fixing.\n\n### Check your assigned issues and tasks in GitLab\n\n* Before analysis lock discussion, if the issue is not by a team member.\n* Analyse the issue submitted and read all non-system notes by project members into account. Treat notes as amendments to the issue description. If a information conflicts with the information from team members, the latest team members note wins.\n* If it is a duplicate, if so relate it to the original issue.\n* Create the branch, push it, then create the MR with `{baseDir}/scripts/mr-create.py `. The helper calls `glab mr create`, assigns the current user, and returns structured evidence including any fallback reason. Pass `--title`, `--description`, and `--related-issue` when the MR needs an explicit plan, acceptance criteria, and issue relation. An exact target from the item, a later owner/Maintainer note, or `AGENTS.md` may be passed using `--target --target-source `.\n* When creating MRs, use the project of the work item except for an explicitly authorized external upstream contribution.\n* When creating MRs, you must relate it to the issue.\n* Analyse the issue and prepare a clear plan (1–3 concrete steps). Include acceptance criteria. Add the information in the description of the merge request.\n* Each feature branch is prefixed `feat/*`\n* Each fix branch is prefixed `fix/*`\n* Add yourself as assignee.\n* Do **not** request/add a reviewer when creating the MR.\n* Create a git clone and create MR with a new branch.\n* Wait until the MR pipeline has succeeded and there is nothing else to do, then start the review process.\n\n### Check your open merge requests in GitLab\n\n* Only work merge requests assigned to the current GitLab user, except an agent-authored external contribution MR authorized by its controlling item.\n* Instead of asking your owner or reviewer what to do, decide on your own and do it. Add your decision as a comment to the merge request.\n* If the merge pipeline fails, investigate the failure and fix the issue.\n * If the failure is a network error and not related to the change, retry the pipeline later, status `workflow::paused`.\n * If the failure is originating from the main branch, open a new work item, use the linked item feature, assign it to you, use status `workflow::blocked` and return to the merge request once fixed.\n* If the merge pipeline succeeds, wait for changes to be merged.\n* When checking merge request discussions/threads, paginate through all discussion pages before deciding the MR is discussion-clean. Do not rely on the first page only. Count unresolved resolvable notes across every page; if any exist, address them before claiming `blocking_discussions_resolved=true` or \"discussion-clean\".\n* Also check recent top-level MR notes/review events, not just unresolved resolvable discussions. Treat `requested changes`, reviewer comments, and non-resolvable top-level notes as actionable feedback until addressed, even when `blocking_discussions_resolved=true`.\n* If there is nothing else to do, run `{baseDir}/scripts/select-reviewer.py ` and inspect its structured dry-run result.\n* Add a reviewer only by rerunning the same helper with `--apply`. Never select or mutate a reviewer free-form.\n* Reviewer selection fails closed: if the helper reports incomplete project data, ambiguity, or no eligible candidate, leave reviewers unchanged and move the MR to `workflow::need-human` with the actionable diagnostic.\n* Add the time spend to the time tracking.\n* Manage the workflow status labels according to the current state of the work.\n* If you see an additional commit by a team member, do not simply revert. Analyse the changes and think about if you need to do something in addition.\n* On each commit\n * Add `Generated-By: ` to the commit message.\n * Push with `git push origin -o ci.skip`\n * Start the pipeline via `glab ci run --mr`, unless there are active pipelines in main or dev. Never use more than X `[setting: 2 # AGENTS.md -> active-pipelines]` pipelines for your work. Add `workflow::paused`, if you delay the pipeline start and revisit later.\n* After merge or close, update the items and labels to reflect the final state `workflow::done`.\n\n#### `AGENTS.md`\n\n* Read and follow the `AGENTS.md` file from only the main branch of the project.\n* Apply settings with the notation `[setting: # key >]` per project.\n\n#### Definition of Done (DoD)\n\nBefore moving a merge request to review, complete this checklist:\n\n* [ ] There is nothing else todo\n* [ ] Acceptance criteria is met\n* [ ] Changes are limited to the scope of the task\n* [ ] Code, configuration, and deployment pass all required quality checks and pipeline without error.\n* [ ] The final diff has been reviewed\n* [ ] A rebase has been performed\n* [ ] The last pipeline has succeeded. Canceled, Failed, Empty Pipeline failures are considered unsuccessful.\n* [ ] Documentation is updated, if needed\n\n#### How to select a reviewer\n\nReviewer selection is deterministic and must be performed by `{baseDir}/scripts/select-reviewer.py`. The helper reads `AGENTS.md` only from the project default branch, validates active project membership and exclusions, then applies this precedence:\n\n1. The unique eligible author of a linked work item.\n2. The first eligible configured reviewer in `AGENTS.md->reviewers` order.\n3. An eligible Maintainer, then an Owner, ordered by username and user ID.\n\nThe helper excludes the MR author, assignees, blocked or locked users, bots, service accounts, and the current automation account. Dry-run is the default. `--apply` revalidates the MR, selected membership, and human-user status immediately before the reviewer mutation.\n\n#### How to comment\n\nRules apply to all GitLab items.\n\n* Do not mention time, date, location\n* Mention `@owner` only when requested. Use per default `owner`.\n\n#### How to handle merging\n\n##### Option 1: If you are allowed to merge\n\n* Use the auto-merge option in the MR.\n\n##### Option 2: If you are not allowed to merge\n\n* Wait until a maintainer merges the MR.\n\n### Maintain forks\n\n* Once a day for all forked repositories, check if the upstream repository has new commits. If so, update the default branch of the fork from upstream and resolve merge conflicts, if needed.\n\n#### GIT Rebase\n\n* Always `fetch` and `fast-forward` before touching an MR branch, and use `--force-with-lease` only, never blind `force-push`.\n\n## Labels\n\nRead current labels; skip unchanged updates. Send only actual additions/removals, preserving unrelated labels. Change workflows only when work changes; security checks fail closed if labels cannot be read.\n\nIf the labels are missing, add them via a merge request using the [label](https://ci-tools.xrow.de/Components/label) component.\n\n```yaml\ninclude:\n - component: $CI_SERVER_FQDN/xrow-public/ci-tools/common@stable\n - component: $CI_SERVER_FQDN/xrow-public/ci-tools/label@stable\n```\n\n### Size Labels\n\n| GitLab label | Common name | Meaning |\n| --------------- | ----------- | ------------------------------------------------------------------------------ |\n| `size::small` | Small | Needs only minor changes and is trivial. Within a day's resolution |\n| `size::medium` | Medium | Needs moderate changes and is somewhat complex. Within a few days' resolution |\n| `size::large` | Large | Needs significant changes and is complex. Within a week or more resolution |\n| `size::xlarge` | Extra large | Needs extensive changes and is very complex. Within a month or more resolution |\n\n* Add ensure that labels `size` is added before `workflow::in-progress`.\n\n### Type Status Labels\n\n| GitLab label | Common name | Meaning |\n| ---------------- | --------------- | ----------------------------------------------------------------------------------------- |\n| `type::support` | Support Request | Someone need help, but no change. Maybe it resolves in new work item after investigation. |\n| `type::bug` | Bugfix | Something that needs to be fixed and exists |\n| `type::feature` | Feature | Something new |\n| `type::hotfix` | Hotfix | Urgent fix for a critical issue that merges directly in main. |\n\n* Do not add the label `type`, if nothing of the above matches.\n* Add ensure that labels `type` is added before `workflow::in-progress`.\n\n### Workflow Status Labels\n\nUse the labels in your merge requests to set the current status of the work. Only use one workflow status label at a time.\n\n| GitLab label | Common name | Meaning |\n| ----------------------- | ----------- | ------------------------------------------------------------------------------------------------------------ |\n| `workflow::backlog` | Backlog | Not yet started. Initial state. |\n| `workflow::forbidden` | Forbidden | Project access failed the owner membership security gate; only the gate script manages this label. |\n| `workflow::in-progress` | Running | Actively worked on |\n| `workflow::paused` | Paused | Agent will continue later automatically. Temporarily paused for one hour to one day. |\n| `workflow::need-human` | Need Human | Requires human intervention to fullfill current task and all other options are exhausted. Before adding the label, explain reason by comment in the issue. Its status is not blocked or paused. |\n| `workflow::blocked` | Blocked | Currently blocked by a dependency or issue. On each assignment, check the status of the blocker. Reevaluate the blocker from time to time. |\n| `workflow::review` | Review | When DoD has been checked and reviewer was assigned |\n| `workflow::done` | Done | Completed , final state, everything done and closed |\n| `workflow::stale` | Stale | No change in status for 2 Weeks and may need attention |\n\n#### Agent workflow by label\n\n```mermaid\n---\nconfig:\n flowchart:\n curve: linear\n---\ngraph TD\n create((New Work Item / MR)) --> security{Owner membership verified?}\n security -- no --> workflow::forbidden\n security -- yes --> workflow::backlog\n workflow::backlog --> workflow::in-progress\n workflow::in-progress --> workflow::review\n workflow::review --> workflow::done\n workflow::in-progress --> workflow::paused\n workflow::in-progress --> workflow::blocked\n workflow::in-progress --> workflow::need-human\n workflow::need-human --> workflow::in-progress\n workflow::need-human --> workflow::stale\n workflow::blocked --> workflow::in-progress\n workflow::paused --> workflow::in-progress\n workflow::review --> workflow::stale\n workflow::stale --> workflow::in-progress\n workflow::done --> close((Close Work Item / MR))\n```\n\nAdditional rules\n\n* Never `workflow::paused` an item if it is prioritized as `priority::blocker`.\n\n## Handling security issues / scan results / CVEs / vulnerabilities\n\nIf the software has a fix for the CVE already released:\n\n* If the issue is related to a dependency that is managed upstream, avoid upgrading the dependency directly. Upgrade via a new release of the upstream project instead.\n* Upgrade to a release including the fix.\n* Cherry pick changes into other MRs, if needed.\n\nIf unfixed:\n\n* Create a new work item tracking the CVE with label `workflow::blocked`\n* Create MR to ignore the issue as temporary measure\n\n```yaml\nvulnerabilities:\n # CVE-2026-56854: Temporarily accepted while the embedded glab dependency is fixed upstream.\n # Tracked in https://gitlab.com/xrow-public/helm-openclaw/-/work_items/72.\n - id: CVE-2026-56854\n```\n\nOnce the CVE is fixed\n\n* Remove label `workflow::blocked` from the work item\n* Create a new MR to upgrade to the new release including the fix.\n\n## Coding Guidelines\n\n* Always fix the underlying issue. Do not just fix the symptom. If you are not sure about the root cause, investigate and find it out.\n* If you create CI/CD pipelines, use [CI Tools Components Catalog for GitLab](https://ci-tools.xrow.de/).\n* When you add or update OpenClaw skills, follow the [Creating skills](https://docs.openclaw.ai/tools/creating-skills) guidance. Reference helper scripts from the skill body with `{baseDir}/...` instead of hardcoding workspace-specific skill paths.\n* Do not use `allow_failure: true`, skips, or bypasses to make CI green unless the job is genuinely optional/manual, and document why.\n* Do not care about version updates done by renovate unless they are required.\n* Only modify the `AGENTS.md` file, if requested by a maintainer.\n* Before writing or editing user documentation, follow `{baseDir}/references/documentation-style.md`. Verify examples and review the rendered page before committing.\n\n## How to use the `glab` CLI to interact with GitLab\n\nUse the `glab` CLI to interact with GitLab. Specify `--repo owner/repo` or `--repo group/namespace/repo` when not in a git directory. Also accepts full URLs.\n\n### Your current GitLab user\n\nWhen you are using `glab` you are always authenticated as a GitLab user.\n\n```bash\nglab api graphql -f query='\n query {\n currentUser { username }\n }\n'\n```\n\n`` is a reference in queries to your username.\n\n### How to get your current tasks\n\n`` is a refence to your username.\n\nFor issues:\n\n```bash\nglab api graphql -f query='\n query($username: String) {\n issues(state: opened, assigneeUsername: $username, first: 50) {\n nodes {\n iid\n title\n webUrl\n description\n author {\n username\n name\n emails {\n email\n }\n }\n createdAt\n updatedAt\n userNotesCount\n labels(first: 20) {\n nodes {\n title\n }\n }\n notes(first: 100) {\n pageInfo {\n hasNextPage\n endCursor\n }\n nodes {\n id\n system\n body\n updatedAt\n author {\n username\n }\n }\n }\n }\n }\n }\n' -f username=\n```\n\nTo get the team members of a project:\n\n```bash\nglab api graphql -f query='\n query($fullPath: ID!) {\n project(fullPath: $fullPath) {\n fullPath\n projectMembers(first: 100) {\n pageInfo {\n hasNextPage\n endCursor\n }\n nodes {\n id\n accessLevel {\n stringValue\n }\n user {\n username\n name\n }\n }\n }\n }\n }\n' -f fullPath=\n```\n\nFor Merge Requests:\n\n```bash\nglab api '/merge_requests?state=opened&scope=assigned_to_me'\n```\n\n## Repositories\n\nList all Repositories:\n\n```bash\nglab repo list --member\n```\n\n### Merge Requests\n\nList open merge requests:\n\n```bash\nglab mr list --repo owner/repo\n```\n\nView MR details:\n\n```bash\nglab mr view 55 --repo owner/repo\n```\n\nSelect and validate the target, then create the MR through the helper:\n\n```bash\n{baseDir}/scripts/mr-create.py --title \"Add example\" --description \"## Plan\\n\\n1. Add the change.\\n\\n## Acceptance criteria\\n\\n- [ ] The change is verified.\" --related-issue 42 owner/repo feat/42-example\n```\n\nApprove, merge, or check out:\n\n```bash\nglab mr approve 55\nglab mr merge 55\nglab mr checkout 55\n```\n\nView MR diff:\n\n```bash\nglab mr diff 55\n```\n\n### CI/CD Pipelines\n\nCheck pipeline status for current branch:\n\n```bash\nglab ci status\n```\n\nView pipeline interactively (navigate jobs, view logs):\n\n```bash\nglab ci view\n```\n\nList recent pipelines:\n\n```bash\nglab ci list --repo owner/repo\n```\n\nTrace job logs in real time:\n\n```bash\nglab ci trace\nglab ci trace 224356863 # specific job ID\nglab ci trace lint # by job name\n```\n\nRetry a failed pipeline:\n\n```bash\nglab ci retry\n```\n\nValidate `.gitlab-ci.yml`:\n\n```bash\nglab ci lint\n```\n\n### Issues\n\nAll your current work items:\n\n```bash\nglab api graphql -f query='\n query($username: String) {\n issues(state: opened, assigneeUsername: $username, first: 50) {\n nodes {\n iid\n title\n webUrl\n }\n }\n }\n' -f username=\n```\n\nList and view issues:\n\n```bash\nglab issue list --repo owner/repo\nglab issue view 42\n```\n\nCreate an issue:\n\n```bash\nglab issue create --title \"Bug report\" --label bug\n```\n\nAdd a comment:\n\n```bash\nglab issue note 42 -m \"This is fixed in !55\"\n```\n\n### API for Advanced Queries\n\nUse `glab api` for endpoints not covered by subcommands. Supports REST and GraphQL.\n\nGet project releases:\n\n```bash\nglab api projects/:fullpath/releases\n```\n\nGet MR with specific fields (pipe to jq):\n\n```bash\nglab api projects/owner/repo/merge_requests/55 | jq '.title, .state, .author.username'\n```\n\nPaginate through all issues:\n\n```bash\nglab api issues --paginate\n```\n\nGraphQL query:\n\n```bash\nglab api graphql -f query='\n query {\n currentUser { username }\n }\n'\n```\n\n### JSON Output\n\nPipe to `jq` for filtering:\n\n```bash\nglab mr list --repo owner/repo | jq -r '.[] | \"\\(.iid): \\(.title)\"'\n```\n\n### Variables and Releases\n\nManage CI/CD variables:\n\n```bash\nglab variable list\nglab variable set MY_VAR \"value\"\nglab variable get MY_VAR\n```\n\nCreate a release:\n\n```bash\nglab release create v1.0.0 --notes \"Release notes here\"\n```\n\n### Escaping and Formatting\n\n* `\\n` for newlines in messages not `\\\\n`.\n* Use jq without the `-C` flag.\n* For Markdown or Output in general, references to IDs (Pipelines, Issues, Merge Requests) in GitLab should be clickable.\n\n## Bugs and features for this skill\n\nSend features and bugfixes for this skill as merge requests to the skills [project](https://gitlab.com/xrow-public/skills).\n\n## Bootstrap\n\nBefore enabling it:\n\n* Confirm the `gitlab-agent` skill exists.\n* Only enable the recurring job after the manual run succeeds.\n\n* [ ] Confirm GitLab auth works.\n* [ ] Add this cron, if it existed and was enabled then leave it enabled.\n\n```json\n{\n \"name\": \"GitLab Agent\",\n \"enabled\": false,\n \"deleteAfterRun\": false,\n \"schedule\": {\n \"kind\": \"every\",\n \"everyMs\": 900000\n },\n \"sessionTarget\": \"isolated\",\n \"wakeMode\": \"now\",\n \"payload\": {\n \"kind\": \"agentTurn\",\n \"message\": \"Read skill gitlab-agent and run.\",\n \"thinking\": \"high\",\n \"timeoutSeconds\": 3600,\n \"model\": \"openai/gpt-6.1-sol\"\n },\n \"delivery\": {\n \"mode\": \"none\",\n \"bestEffort\": false\n }\n}\n```\n\n* [ ] Confirm GitLab auth works.\n\nFile v1.107.0:_meta.json\n\n{\n \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n \"slug\": \"xrowgmbh-gitlab-agent\",\n \"version\": \"1.107.0\",\n \"publishedAt\": 1791479140643\n}\n\nFile v1.107.0:references/documentation-style.md\n\n# Write user documentation\n\n1. Start with the reader's task and intended result. Put prerequisites before\n commands and expected results after them. Include one minimal working example\n the reader can follow from start to finish.\n2. Verify commands, options, defaults, and limitations against the implementation.\n Preserve exact names in code formatting. Distinguish tested behavior from\n assumptions, and explain limitations beside the action they affect.\n3. Edit for clarity. Use direct verbs, short sentences, normal word spacing, and\n one topic per paragraph. Replace vague claims such as \"robust\" or \"seamless\"\n with the specific behavior the reader needs to know.\n4. Organize for scanning. Use sentence-case headings, numbered steps for ordered\n tasks, and tables for settings or comparisons. Link to detailed references\n instead of repeating them. Keep retry history, pipeline IDs, commit hashes,\n and agent bookkeeping in the MR or work log; user guides describe current\n behavior.\n5. Read the rendered page as a user before committing. Check that prerequisites,\n commands, expected results, and links are easy to find. Remove repeated\n summaries, irrelevant implementation details, and decorative emphasis. Run\n the repository's existing documentation lint and build checks.\n\n## Example\n\nBefore:\n\n> The chart enables post-installation validation of service discoverability.\n\nAfter:\n\n> After installation, run `helm test openclaw -n openclaw` to check that cluster\n> DNS can resolve the Service.\n\nFile v1.107.0:skill-card.md\n\n## Description:\n\nOperate assigned GitLab work with owner-verified project access and guarded MR delivery.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[xrowgmbh](https://clawhub.ai/user/xrowgmbh)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and GitLab automation teams use this skill to triage assigned issues and merge requests, make repository changes, and deliver reviewed changes through GitLab workflows.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: A recurring agent can make GitLab changes without asking for confirmation.\n\nMitigation: Use a dedicated automation account and limit its token to repositories where autonomous work is intended.\n\nRisk: Automatic pushes, comments, label updates, pipeline actions, fork maintenance, and cross-project merge requests can affect project workflows.\n\nMitigation: Review the skill's project and assignment gates before use; monitor its changes and disable the recurring job unless continuous operation is desired.\n\n## Reference(s):\n\n- [GitLab Agent release](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-gitlab-agent)\n- [GitLab default roles and permissions](https://docs.gitlab.com/user/permissions/#default-roles)\n- [OpenClaw skill creation](https://docs.openclaw.ai/tools/creating-skills)\n- [Documentation style reference](references/documentation-style.md)\n\n## Skill Output:\n\n**Output Type(s):** [Markdown, Code, Shell commands, Configuration guidance]\n\n**Output Format:** [Markdown with GitLab links and inline commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May create GitLab issues, comments, branches, commits, merge requests, and pipeline actions.]\n\n## Skill Version(s):\n\n1.107.0 (source: ClawHub release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.106.1: 11 files, 34507 bytes\n\nFiles: references/documentation-style.md (1530b), scripts/check-project-access.py (5830b), scripts/list-active-items.py (10961b), scripts/mr-create.py (15903b), scripts/select-reviewer.py (11005b), scripts/test_check_project_access.py (21718b), scripts/test_mr_create.py (11120b), scripts/test_select_reviewer.py (7930b), skill-card.md (2390b), SKILL.md (25759b), _meta.json (142b)\n\nFile v1.106.1:SKILL.md\n\n---\nname: gitlab-agent\ndescription: \"Operate assigned GitLab work with owner-verified project access and guarded MR delivery.\"\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# GitLab Agent Skill\n\nRepeat and fullfill your `GitLab Agent` tasks.\n\n* If you have questions or options what to do next, decide on your own.\n* All actions do not require confirmation or approval.\n* Do not use the internal `Workboard` or any other tools to manage your work, just use GitLab.\n* Your Environment is isolated\n * Write behavior is permitted, required and desired.\n * You have the role of a [developer](https://docs.gitlab.com/user/permissions/#default-roles). You can not push to protected branches.\n * Every write action is low risk and can be reverted, so do not worry about making mistakes.\n * Perform all also external, irreversible actions (like clone/push/create MR) automatically without your explicit confirmation. Confirmation is granted by the owner when you were created.\n\n## Goals\n\n* All writable actions in GitLab should be done with the `glab` CLI. This includes creating and updating issues, merge requests, branches, comments, and more.\n* Complete tasks successfully in GitLab.\n* If you think work needs to be done, do it without asking.\n\n## Security Gate\n\nSkip the security gate for `owner`. Otherwise, the security gate is mandatory.\n\nBefore reading or working an existing issue, work item, or merge request beyond the minimum fields needed to identify its project and assignment:\n\n1. Resolve the owner GitLab username from `GITLAB_AGENT_OWNER`, or from the active workspace `USER.md` field `GitLab Username` when the environment variable is unset.\n2. Resolve the target project path from the object's GitLab URL.\n3. Run `{baseDir}/scripts/check-project-access.py `.\n4. Continue only when the script succeeds. The script removes `workflow::forbidden` after an allowed check.\n5. On failure, do not analyze the object, clone the project, push, comment, retry CI, or otherwise work on it. The script replaces its existing `workflow::*` label with `workflow::forbidden`; stop work on that project object and report the failed gate locally.\n6. Never add or remove `workflow::forbidden` directly; only the security-check script owns that label.\n\nThe check fails closed when the current GitLab user has no active project membership, membership data is incomplete, or the membership was not created by the configured owner.\n\n## Assignment Gate\n\nBefore working an existing issue, work item, or merge request, check the current GitLab user and the assignees on that object.\n\n* If the current GitLab user is not an assignee, do not work the ticket.\n* If the ticket assigment origin was a gateway channel (like a human request, or a bot request). If you can`t assign it to yourself. If you can not assign it to yourself because you are not a team member, fork the project, create a new issue in the fork and assign it to you, and relate it to the original issue. Then work on the new issue. Clean up the forked issue after the original issue is resolved.\n* Assignment on a related issue is not enough to work an unassigned or differently assigned merge request. Check the object you are changing.\n* Do not add or change reviewers, add yourself as assignee, push commits, rebase, retry or trigger pipelines, merge, close, log time, or add progress/status comments on issues or merge requests that are not assigned to the current GitLab user.\n* Label hygiene is allowed on unassigned issues and merge requests. You may add or correct `size::*`, `type::*`, and `workflow::*` labels when the correct label state is clear, except that `workflow::forbidden` is owned exclusively by the security-check script.\n\n### External upstream contributions\n\nAn assigned item that passes both gates may authorize work in an external project only when its description or a later owner/Maintainer note names the exact upstream URL. Inspect only that scope, use an agent-owned fork, and open a cross-project MR; do not run the security gate on the upstream project or require upstream assignment. Keep workflow state on the controlling item and do not change the upstream issue's labels, status comments, time tracking, assignment, or state. Missing upstream membership alone is not `workflow::forbidden` or `workflow::need-human`.\n\n## Status Comment Relevance Gate\n\nBefore posting an issue, work item, or merge request status comment, compare the current object state with the last agent-authored status comment for the same object.\n\n* Comment when a meaningful state change occurred, such as reviewer action appearing, unresolved discussions changing, new maintainer feedback, a new blocked or need-human condition, or the required human action changing.\n* Stay silent when the only available comment would repeat a routine no-op state. Record suppressed no-op checks in local logs or memory for auditability instead of posting them to GitLab.\n\n## GitLab Agent Tasks\n\n### Discover active work across projects\n\n* Run `{baseDir}/scripts/list-active-items.py` to fetch all open issues and merge requests assigned to the current GitLab user across projects.\n* The script excludes objects labeled `workflow::forbidden` so denied work does not re-enter the active queue.\n* Treat each returned `activity_cursor` as acknowledged only after that item's notes and, for merge requests, discussions have been fully paginated and inspected. Persist acknowledged cursors in the durable cycle checkpoint, keyed by the item's `web_url`; never advance a cursor for an unaudited item.\n* At cycle start, compare every discovered cursor with the most recent acknowledged cursor before resuming checkpointed work. A missing or changed cursor requires the security and assignment gates followed by a fresh note/discussion audit, even when labels and state are unchanged.\n* A new instruction from the configured owner or an active project Maintainer/Owner preempts the previously selected item. Apply the latest team-member instruction rule, checkpoint the interrupted work safely, and process the changed item first.\n* Immediately before checkpointing, run discovery again. Audit any cursor that changed during the cycle before acknowledging it; when the cycle cannot finish that audit, retain the old cursor and record the changed item as the highest-priority next step.\n* If you find the last pipeline of the default branch broken due to an error within the repository. Create a new task for you to fixing.\n\n### Check your assigned issues and tasks in GitLab\n\n* Before analysis lock discussion, if the issue is not by a team member.\n* Analyse the issue submitted and read all non-system notes by project members into account. Treat notes as amendments to the issue description. If a information conflicts with the information from team members, the latest team members note wins.\n* If it is a duplicate, if so relate it to the original issue.\n* Create the branch, push it, then create the MR with `{baseDir}/scripts/mr-create.py `. The helper calls `glab mr create`, assigns the current user, and returns structured evidence including any fallback reason. Pass `--title`, `--description`, and `--related-issue` when the MR needs an explicit plan, acceptance criteria, and issue relation. An exact target from the item, a later owner/Maintainer note, or `AGENTS.md` may be passed using `--target --target-source `.\n* When creating MRs, use the project of the work item except for an explicitly authorized external upstream contribution.\n* When creating MRs, you must relate it to the issue.\n* Analyse the issue and prepare a clear plan (1–3 concrete steps). Include acceptance criteria. Add the information in the description of the merge request.\n* Each feature branch is prefixed `feat/*`\n* Each fix branch is prefixed `fix/*`\n* Add yourself as assignee.\n* Do **not** request/add a reviewer when creating the MR.\n* Create a git clone and create MR with a new branch.\n* Wait until the MR pipeline has succeeded and there is nothing else to do, then start the review process.\n\n### Check your open merge requests in GitLab\n\n* Only work merge requests assigned to the current GitLab user, except an agent-authored external contribution MR authorized by its controlling item.\n* Instead of asking your owner or reviewer what to do, decide on your own and do it. Add your decision as a comment to the merge request.\n* If the merge pipeline fails, investigate the failure and fix the issue.\n * If the failure is a network error and not related to the change, retry the pipeline later, status `workflow::paused`.\n * If the failure is originating from the main branch, open a new work item, use the linked item feature, assign it to you, use status `workflow::blocked` and return to the merge request once fixed.\n* If the merge pipeline succeeds, wait for changes to be merged.\n* When checking merge request discussions/threads, paginate through all discussion pages before deciding the MR is discussion-clean. Do not rely on the first page only. Count unresolved resolvable notes across every page; if any exist, address them before claiming `blocking_discussions_resolved=true` or \"discussion-clean\".\n* Also check recent top-level MR notes/review events, not just unresolved resolvable discussions. Treat `requested changes`, reviewer comments, and non-resolvable top-level notes as actionable feedback until addressed, even when `blocking_discussions_resolved=true`.\n* If there is nothing else to do, run `{baseDir}/scripts/select-reviewer.py ` and inspect its structured dry-run result.\n* Add a reviewer only by rerunning the same helper with `--apply`. Never select or mutate a reviewer free-form.\n* Reviewer selection fails closed: if the helper reports incomplete project data, ambiguity, or no eligible candidate, leave reviewers unchanged and move the MR to `workflow::need-human` with the actionable diagnostic.\n* Add the time spend to the time tracking.\n* Manage the workflow status labels according to the current state of the work.\n* If you see an additional commit by a team member, do not simply revert. Analyse the changes and think about if you need to do something in addition.\n* On each commit\n * Add `Generated-By: ` to the commit message.\n * Push with `git push origin -o ci.skip`\n * Start the pipeline via `glab ci run --mr`, unless there are active pipelines in main or dev. Never use more than X `[setting: 2 # AGENTS.md -> active-pipelines]` pipelines for your work. Add `workflow::paused`, if you delay the pipeline start and revisit later.\n* After merge or close, update the items and labels to reflect the final state `workflow::done`.\n\n#### `AGENTS.md`\n\n* Read and follow the `AGENTS.md` file from only the main branch of the project.\n* Apply settings with the notation `[setting: # key >]` per project.\n\n#### Definition of Done (DoD)\n\nBefore moving a merge request to review, complete this checklist:\n\n* [ ] There is nothing else todo\n* [ ] Acceptance criteria is met\n* [ ] Changes are limited to the scope of the task\n* [ ] Code, configuration, and deployment pass all required quality checks and pipeline without error.\n* [ ] The final diff has been reviewed\n* [ ] A rebase has been performed\n* [ ] The last pipeline has succeeded. Canceled, Failed, Empty Pipeline failures are considered unsuccessful.\n* [ ] Documentation is updated, if needed\n\n#### How to select a reviewer\n\nReviewer selection is deterministic and must be performed by `{baseDir}/scripts/select-reviewer.py`. The helper reads `AGENTS.md` only from the project default branch, validates active project membership and exclusions, then applies this precedence:\n\n1. The unique eligible author of a linked work item.\n2. The first eligible configured reviewer in `AGENTS.md->reviewers` order.\n3. An eligible Maintainer, then an Owner, ordered by username and user ID.\n\nThe helper excludes the MR author, assignees, blocked or locked users, bots, service accounts, and the current automation account. Dry-run is the default. `--apply` revalidates the MR, selected membership, and human-user status immediately before the reviewer mutation.\n\n#### How to comment\n\nRules apply to all GitLab items.\n\n* Do not mention time, date, location\n* Mention `@owner` only when requested. Use per default `owner`.\n\n#### How to handle merging\n\n##### Option 1: If you are allowed to merge\n\n* Use the auto-merge option in the MR.\n\n##### Option 2: If you are not allowed to merge\n\n* Wait until a maintainer merges the MR.\n\n### Maintain forks\n\n* Once a day for all forked repositories, check if the upstream repository has new commits. If so, update the default branch of the fork from upstream and resolve merge conflicts, if needed.\n\n#### GIT Rebase\n\n* Always `fetch` and `fast-forward` before touching an MR branch, and use `--force-with-lease` only, never blind `force-push`.\n\n## Labels\n\nRead current labels; skip unchanged updates. Send only actual additions/removals, preserving unrelated labels. Change workflows only when work changes; security checks fail closed if labels cannot be read.\n\nIf the labels are missing, add them via a merge request using the [label](https://ci-tools.xrow.de/Components/label) component.\n\n```yaml\ninclude:\n - component: $CI_SERVER_FQDN/xrow-public/ci-tools/common@stable\n - component: $CI_SERVER_FQDN/xrow-public/ci-tools/label@stable\n```\n\n### Size Labels\n\n| GitLab label | Common name | Meaning |\n| --------------- | ----------- | ------------------------------------------------------------------------------ |\n| `size::small` | Small | Needs only minor changes and is trivial. Within a day's resolution |\n| `size::medium` | Medium | Needs moderate changes and is somewhat complex. Within a few days' resolution |\n| `size::large` | Large | Needs significant changes and is complex. Within a week or more resolution |\n| `size::xlarge` | Extra large | Needs extensive changes and is very complex. Within a month or more resolution |\n\n* Add ensure that labels `size` is added before `workflow::in-progress`.\n\n### Type Status Labels\n\n| GitLab label | Common name | Meaning |\n| ---------------- | --------------- | ----------------------------------------------------------------------------------------- |\n| `type::support` | Support Request | Someone need help, but no change. Maybe it resolves in new work item after investigation. |\n| `type::bug` | Bugfix | Something that needs to be fixed and exists |\n| `type::feature` | Feature | Something new |\n| `type::hotfix` | Hotfix | Urgent fix for a critical issue that merges directly in main. |\n\n* Do not add the label `type`, if nothing of the above matches.\n* Add ensure that labels `type` is added before `workflow::in-progress`.\n\n### Workflow Status Labels\n\nUse the labels in your merge requests to set the current status of the work. Only use one workflow status label at a time.\n\n| GitLab label | Common name | Meaning |\n| ----------------------- | ----------- | ------------------------------------------------------------------------------------------------------------ |\n| `workflow::backlog` | Backlog | Not yet started. Initial state. |\n| `workflow::forbidden` | Forbidden | Project access failed the owner membership security gate; only the gate script manages this label. |\n| `workflow::in-progress` | Running | Actively worked on |\n| `workflow::paused` | Paused | Agent will continue later automatically. Temporarily paused for one hour to one day. |\n| `workflow::need-human` | Need Human | Requires human intervention to fullfill current task and all other options are exhausted. Before adding the label, explain reason by comment in the issue. Its status is not blocked or paused. |\n| `workflow::blocked` | Blocked | Currently blocked by a dependency or issue. On each assignment, check the status of the blocker. Reevaluate the blocker from time to time. |\n| `workflow::review` | Review | When DoD has been checked and reviewer was assigned |\n| `workflow::done` | Done | Completed , final state, everything done and closed |\n| `workflow::stale` | Stale | No change in status for 2 Weeks and may need attention |\n\n#### Agent workflow by label\n\n```mermaid\n---\nconfig:\n flowchart:\n curve: linear\n---\ngraph TD\n create((New Work Item / MR)) --> security{Owner membership verified?}\n security -- no --> workflow::forbidden\n security -- yes --> workflow::backlog\n workflow::backlog --> workflow::in-progress\n workflow::in-progress --> workflow::review\n workflow::review --> workflow::done\n workflow::in-progress --> workflow::paused\n workflow::in-progress --> workflow::blocked\n workflow::in-progress --> workflow::need-human\n workflow::need-human --> workflow::in-progress\n workflow::need-human --> workflow::stale\n workflow::blocked --> workflow::in-progress\n workflow::paused --> workflow::in-progress\n workflow::review --> workflow::stale\n workflow::stale --> workflow::in-progress\n workflow::done --> close((Close Work Item / MR))\n```\n\nAdditional rules\n\n* Never `workflow::paused` an item if it is prioritized as `priority::blocker`.\n\n## Handling security issues / scan results / CVEs / vulnerabilities\n\nIf the software has a fix for the CVE already released:\n\n* If the issue is related to a dependency that is managed upstream, avoid upgrading the dependency directly. Upgrade via a new release of the upstream project instead.\n* Upgrade to a release including the fix.\n* Cherry pick changes into other MRs, if needed.\n\nIf unfixed:\n\n* Create a new work item tracking the CVE with label `workflow::blocked`\n* Create MR to ignore the issue as temporary measure\n\n```yaml\nvulnerabilities:\n # CVE-2026-56854: Temporarily accepted while the embedded glab dependency is fixed upstream.\n # Tracked in https://gitlab.com/xrow-public/helm-openclaw/-/work_items/72.\n - id: CVE-2026-56854\n```\n\nOnce the CVE is fixed\n\n* Remove label `workflow::blocked` from the work item\n* Create a new MR to upgrade to the new release including the fix.\n\n## Coding Guidelines\n\n* Always fix the underlying issue. Do not just fix the symptom. If you are not sure about the root cause, investigate and find it out.\n* If you create CI/CD pipelines, use [CI Tools Components Catalog for GitLab](https://ci-tools.xrow.de/).\n* When you add or update OpenClaw skills, follow the [Creating skills](https://docs.openclaw.ai/tools/creating-skills) guidance. Reference helper scripts from the skill body with `{baseDir}/...` instead of hardcoding workspace-specific skill paths.\n* Do not use `allow_failure: true`, skips, or bypasses to make CI green unless the job is genuinely optional/manual, and document why.\n* Do not care about version updates done by renovate unless they are required.\n* Only modify the `AGENTS.md` file, if requested by a maintainer.\n* Before writing or editing user documentation, follow `{baseDir}/references/documentation-style.md`. Verify examples and review the rendered page before committing.\n\n## How to use the `glab` CLI to interact with GitLab\n\nUse the `glab` CLI to interact with GitLab. Specify `--repo owner/repo` or `--repo group/namespace/repo` when not in a git directory. Also accepts full URLs.\n\n### Your current GitLab user\n\nWhen you are using `glab` you are always authenticated as a GitLab user.\n\n```bash\nglab api graphql -f query='\n query {\n\nArchive v1.106.0: 11 files, 33984 bytes\n\nFiles: references/documentation-style.md (1530b), scripts/check-project-access.py (5830b), scripts/list-active-items.py (10961b), scripts/mr-create.py (14448b), scripts/select-reviewer.py (11005b), scripts/test_check_project_access.py (21718b), scripts/test_mr_create.py (8576b), scripts/test_select_reviewer.py (7930b), skill-card.md (2137b), SKILL.md (26132b), _meta.json (142b)\n\nArchive v1.105.1: 11 files, 34083 bytes\n\nFiles: references/documentation-style.md (1530b), scripts/check-project-access.py (5830b), scripts/list-active-items.py (10961b), scripts/mr-create.py (14448b), scripts/select-reviewer.py (11005b), scripts/test_check_project_access.py (21718b), scripts/test_mr_create.py (8576b), scripts/test_select_reviewer.py (7930b), skill-card.md (2314b), SKILL.md (26132b), _meta.json (142b)\n\nArchive v1.105.0: 11 files, 33869 bytes\n\nFiles: references/documentation-style.md (1530b), scripts/check-project-access.py (5830b), scripts/list-active-items.py (10961b), scripts/mr-create.py (14448b), scripts/select-reviewer.py (11005b), scripts/test_check_project_access.py (21718b), scripts/test_mr_create.py (8576b), scripts/test_select_reviewer.py (7930b), skill-card.md (1840b), SKILL.md (26132b), _meta.json (142b)\n\nArchive v1.104.0: 11 files, 33948 bytes\n\nFiles: references/documentation-style.md (1530b), scripts/check-project-access.py (5830b), scripts/list-active-items.py (10961b), scripts/mr-create.py (14448b), scripts/select-reviewer.py (11005b), scripts/test_check_project_access.py (21718b), scripts/test_mr_create.py (8576b), scripts/test_select_reviewer.py (7930b), skill-card.md (2108b), SKILL.md (26132b), _meta.json (142b)\n\nArchive v1.103.0: 11 files, 33954 bytes\n\nFiles: references/documentation-style.md (1530b), scripts/check-project-access.py (5830b), scripts/list-active-items.py (10961b), scripts/mr-create.py (14448b), scripts/select-reviewer.py (11005b), scripts/test_check_project_access.py (21718b), scripts/test_mr_create.py (8576b), scripts/test_select_reviewer.py (7930b), skill-card.md (2027b), SKILL.md (26132b), _meta.json (142b)","readmeExcerpt":"Skill: GitLab Agent Owner: xrowgmbh Summary: Operate assigned GitLab work with owner-verified project access and guarded MR delivery. Tags: latest:1.108.1 Version history: v1.108.1 | 2026-10-08T22:08:54.725Z | auto - Removed the file skill-card.md. - No changes made to code or logic; documentation file only removed. - Existing functionality and skill behavior remain unchanged. v1.108.0 | 2026-10-08T20:08:23.897Z | au","codeSnippets":[],"executableExamples":[{"language":"yaml","snippet":"include:\n - component: $CI_SERVER_FQDN/xrow-public/ci-tools/common@stable\n - component: $CI_SERVER_FQDN/xrow-public/ci-tools/label@stable"},{"language":"mermaid","snippet":"---\nconfig:\n flowchart:\n curve: linear\n---\ngraph TD\n create((New Work Item / MR)) --> security{Owner membership verified?}\n security -- no --> workflow::forbidden\n security -- yes --> workflow::backlog\n workflow::backlog --> workflow::in-progress\n workflow::in-progress --> workflow::review\n workflow::review --> workflow::done\n workflow::in-progress --> workflow::paused\n workflow::in-progress --> workflow::blocked\n workflow::in-progress --> workflow::need-human\n workflow::need-human --> workflow::in-progress\n workflow::need-human --> workflow::stale\n workflow::blocked --> workflow::in-progress\n workflow::paused --> workflow::in-progress\n workflow::review --> workflow::stale\n workflow::stale --> workflow::in-progress\n workflow::done --> close((Close Work Item / MR))"},{"language":"yaml","snippet":"vulnerabilities:\n # CVE-XXX-XXXXX: Temporarily accepted while the embedded glab dependency is fixed upstream.\n # Tracked in https://gitlab.com/xrow-public/helm-openclaw/-/work_items/72.\n - id: CVE-XXX-XXXXX"},{"language":"bash","snippet":"glab api graphql -f query='\n query {\n currentUser { username }\n }\n'"},{"language":"bash","snippet":"glab api graphql -f query='\n query($username: String) {\n issues(state: opened, assigneeUsername: $username, first: 50) {\n nodes {\n iid\n title\n webUrl\n description\n author {\n username\n name\n emails {\n email\n }\n }\n createdAt\n updatedAt\n userNotesCount\n labels(first: 20) {\n nodes {\n title\n }\n }\n notes(first: 100) {\n pageInfo {\n hasNextPage\n endCursor\n }\n nodes {\n id\n system\n body\n updatedAt\n author {\n username\n }\n }\n }\n }\n }\n }\n' -f username="},{"language":"bash","snippet":"glab api graphql -f query='\n query($fullPath: ID!) {\n project(fullPath: $fullPath) {\n fullPath\n projectMembers(first: 100) {\n pageInfo {\n hasNextPage\n endCursor\n }\n nodes {\n id\n accessLevel {\n stringValue\n }\n user {\n username\n name\n }\n }\n }\n }\n }\n' -f fullPath="}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: gitlab-agent\ndescription: \"Operate assigned GitLab work with owner-verified project access and guarded MR delivery.\"\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# GitLab Agent Skill\n\nRepeat and fullfill your `GitLab Agent` tasks.\n\n* If you have questions or options what to do next, decide on your own.\n* All actions do not require confirmation or approval.\n* Do not use the internal `Workboard` or any other tools to manage your work, just use GitLab.\n* Your Environment is isolated\n * Write behavior is permitted, required and desired.\n * You have the role of a [developer](https://docs.gitlab.com/user/permissions/#default-roles). You can not push to protected branches.\n * Every write action is low risk and can be reverted, so do not worry about making mistakes.\n * Perform all also external, irreversible actions (like clone/push/create MR) automatically without your explicit confirmation. Confirmation is granted by the owner when you were created.\n\n## Goals\n\n* All writable actions in GitLab should be done with the `glab` CLI. This includes creating and updating issues, merge requests, branches, comments, and more.\n* Complete tasks successfully in GitLab.\n* If you think work needs to be done, do it without asking.\n\n## Security Gate\n\nSkip the security gate for `owner`. Otherwise, the security gate is mandatory.\n\nBefore reading or working an existing issue, work item, or merge request beyond the minimum fields needed to identify its project and assignment:\n\n1. Resolve the owner GitLab username from `GITLAB_AGENT_OWNER`, or from the active workspace `USER.md` field `GitLab Username` when the environment variable is unset.\n2. Resolve the target project path from the object's GitLab URL.\n3. Run `{baseDir}/scripts/check-project-access.py `.\n4. Continue only when the script succeeds. The script removes `workflow::forbidden` after an allowed check.\n5. On failure, do not analyze the object, clone the project, push, comment, retry CI, or otherwise work on it. The script replaces its existing `workflow::*` label with `workflow::forbidden`; stop work on that project object and report the failed gate locally.\n6. Never add or remove `workflow::forbidden` directly; only the security-check script owns that label.\n\nThe check fails closed when the current GitLab user has no active project membership, membership data is incomplete, or the membership was not created by the configured owner.\n\n## Assignment Gate\n\nBefore working an existing issue, work item, or merge request, check the current GitLab user and the assignees on that object.\n\n* If the current GitLab user is not an assignee, do not work the ticket.\n* If the ticket assigment origin was a gateway channel (like a human request, or a bot request). If you can`t assign it to yourself. If you can not assign it to yourself because you are not a team member, fork the project, create a new is"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n \"slug\": \"xrowgmbh-gitlab-agent\",\n \"version\": \"1.108.1\",\n \"publishedAt\": 1791497334725\n}"},{"path":"references/documentation-style.md","content":"# Write user documentation\n\n1. Start with the reader's task and intended result. Put prerequisites before\n commands and expected results after them. Include one minimal working example\n the reader can follow from start to finish.\n2. Verify commands, options, defaults, and limitations against the implementation.\n Preserve exact names in code formatting. Distinguish tested behavior from\n assumptions, and explain limitations beside the action they affect.\n3. Edit for clarity. Use direct verbs, short sentences, normal word spacing, and\n one topic per paragraph. Replace vague claims such as \"robust\" or \"seamless\"\n with the specific behavior the reader needs to know.\n4. Organize for scanning. Use sentence-case headings, numbered steps for ordered\n tasks, and tables for settings or comparisons. Link to detailed references\n instead of repeating them. Keep retry history, pipeline IDs, commit hashes,\n and agent bookkeeping in the MR or work log; user guides describe current\n behavior.\n5. Read the rendered page as a user before committing. Check that prerequisites,\n commands, expected results, and links are easy to find. Remove repeated\n summaries, irrelevant implementation details, and decorative emphasis. Run\n the repository's existing documentation lint and build checks.\n\n## Example\n\nBefore:\n\n> The chart enables post-installation validation of service discoverability.\n\nAfter:\n\n> After installation, run `helm test openclaw -n openclaw` to check that cluster\n> DNS can resolve the Service."},{"path":"skill-card.md","content":"## Description:\n\nOperate assigned GitLab work with owner-verified project access and guarded MR delivery.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[xrowgmbh](https://clawhub.ai/user/xrowgmbh)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineering teams use this skill to work assigned GitLab issues and merge requests, check project access, deliver code changes, and manage review and pipeline workflows.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Unattended GitLab actions can modify project work and code without per-action approval.\n\nMitigation: Use a tightly scoped GitLab account and write-capable token; restrict project membership to intended projects.\n\nRisk: Recurring runs can repeatedly claim incidents or alter merge requests, reviewers, labels, and pipelines.\n\nMitigation: Review the recurring schedule before enabling it, and monitor GitLab activity.\n\n## Reference(s):\n\n- [GitLab Agent release on ClawHub](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-gitlab-agent)\n- [GitLab default project roles](https://docs.gitlab.com/user/permissions/#default-roles)\n- [Documentation style guide](references/documentation-style.md)\n- [Skill feedback project](https://gitlab.com/xrow-public/skills)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Code, Shell commands, Configuration guidance]\n\n**Output Format:** [Markdown with GitLab links and code blocks]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Can also update GitLab issues, merge requests, branches, labels, reviewers, and pipelines.]\n\n## Skill Version(s):\n\n1.108.1 (source: ClawHub release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Operate assigned GitLab work with owner-verified project access and guarded MR delivery. Skill: GitLab Agent Owner: xrowgmbh Summary: Operate assigned GitLab work with owner-verified project access and guarded MR delivery. Tags: latest:1.108.1 Version history: v1.108.1 | 2026-10-08T22:08:54.725Z | auto - Removed the file skill-card.md. - No changes made to code or logic; documentation file only removed. - Existing functionality and skill behavior remain unchanged. v1.108.0 | 2026-10-08T20:08:23.897Z | au","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1538,"uniquenessScore":48,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T03:31:08.444Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T03:31:08.444Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-09T17:29:54.185Z","emptyReason":null},"items":[{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-10T18:48:31.762Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}