{"id":"995b2e6f-ca5d-497b-a0e3-db2ab136b7e2","entityType":"agent","slug":"clawhub-xrowgmbh-xrowgmbh-ci-tools-pipeline","name":"CI Tools Pipeline","canonicalUrl":"https://www.xpersona.co/agent/clawhub-xrowgmbh-xrowgmbh-ci-tools-pipeline","canonicalPath":"/agent/clawhub-xrowgmbh-xrowgmbh-ci-tools-pipeline","generatedAt":"2026-10-10T04:45:10.540Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-09T06:29:50.295Z","emptyReason":null},"description":"Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps. Skill: CI Tools Pipeline Owner: xrowgmbh Summary: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps. Tags: latest:1.108.1 V","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 3.9K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s17aekq8k9ea9rzxqpwjjz8ea987ze4c:xrowgmbh-ci-tools-pipeline","sourceUrl":"https://clawhub.ai/xrowgmbh/xrowgmbh-ci-tools-pipeline","homepage":"https://clawhub.ai/xrowgmbh/skills/xrowgmbh-ci-tools-pipeline","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/xrowgmbh/xrowgmbh-ci-tools-pipeline","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/xrowgmbh/skills/xrowgmbh-ci-tools-pipeline","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":72,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing C"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T06:29:50.295Z","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-09T06:29:50.295Z","emptyReason":null},"stars":null,"forks":null,"downloads":3881,"packageName":null,"latestVersion":"1.108.1","tractionLabel":"3.9K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T06:29:50.294Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T06:29:50.295Z","lastCrawledAt":"2026-10-09T06:29:50.294Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T06:29:50.294Z","lastVerifiedAt":null,"highlights":[{"version":"1.108.1","createdAt":"2026-10-08T22:08:14.521Z","changelog":"- Removed the file skill-card.md. - No other functional or documentation changes.","fileCount":3,"zipByteSize":4074},{"version":"1.108.0","createdAt":"2026-10-08T20:07:43.474Z","changelog":"- Removed the file skill-card.md. - No changes to the skill logic or documentation content. - This update is for file cleanup only.","fileCount":3,"zipByteSize":4000},{"version":"1.107.1","createdAt":"2026-10-08T18:10:07.137Z","changelog":"- Removed the file skill-card.md. - No changes were made to functionality or documentation in SKILL.md.","fileCount":3,"zipByteSize":4000},{"version":"1.107.0","createdAt":"2026-10-08T17:05:12.387Z","changelog":"- Removed the file skill-card.md. - No user-facing changes to behavior or documentation beyond this file removal. - Version incremented to 1.107.0.","fileCount":3,"zipByteSize":4016},{"version":"1.106.1","createdAt":"2026-10-08T10:18:13.467Z","changelog":"- Removed the redundant file: skill-card.md. - No changes to skill logic or documentation content. - The skill's usage, guidance, and examples remain unchanged.","fileCount":3,"zipByteSize":4109},{"version":"1.106.0","createdAt":"2026-10-08T08:39:21.800Z","changelog":"- Removed the file skill-card.md. - No other changes to skill functionality or documentation.","fileCount":3,"zipByteSize":4001},{"version":"1.105.1","createdAt":"2026-10-06T18:34:03.960Z","changelog":"- Removed the redundant file skill-card.md. - No functional or behavior changes to the skill itself.","fileCount":3,"zipByteSize":3964},{"version":"1.105.0","createdAt":"2026-10-06T16:29:54.896Z","changelog":"- Removed the file: skill-card.md - No changes to functionality or user-facing documentation in SKILL.md - Version bump to 1.105.0","fileCount":3,"zipByteSize":4029}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17aekq8k9ea9rzxqpwjjz8ea987ze4c:xrowgmbh-ci-tools-pipeline","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-ci-tools-pipeline/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-ci-tools-pipeline/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-ci-tools-pipeline/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-ci-tools-pipeline/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-ci-tools-pipeline/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-ci-tools-pipeline/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-10T04:45:10.537Z"}},"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-ci-tools-pipeline/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-ci-tools-pipeline/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-ci-tools-pipeline/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-xrowgmbh-xrowgmbh-ci-tools-pipeline/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-09T06:29:50.295Z","emptyReason":null},"readme":"Skill: CI Tools Pipeline\n\nOwner: xrowgmbh\n\nSummary: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps.\n\nTags: latest:1.108.1\n\nVersion history:\n\nv1.108.1 | 2026-10-08T22:08:14.521Z | auto\n\n- Removed the file skill-card.md.\n- No other functional or documentation changes.\n\nv1.108.0 | 2026-10-08T20:07:43.474Z | auto\n\n- Removed the file skill-card.md.\n- No changes to the skill logic or documentation content.\n- This update is for file cleanup only.\n\nv1.107.1 | 2026-10-08T18:10:07.137Z | auto\n\n- Removed the file skill-card.md.\n- No changes were made to functionality or documentation in SKILL.md.\n\nv1.107.0 | 2026-10-08T17:05:12.387Z | auto\n\n- Removed the file skill-card.md.\n- No user-facing changes to behavior or documentation beyond this file removal.\n- Version incremented to 1.107.0.\n\nv1.106.1 | 2026-10-08T10:18:13.467Z | auto\n\n- Removed the redundant file: skill-card.md.  \n- No changes to skill logic or documentation content.  \n- The skill's usage, guidance, and examples remain unchanged.\n\nv1.106.0 | 2026-10-08T08:39:21.800Z | auto\n\n- Removed the file skill-card.md.\n- No other changes to skill functionality or documentation.\n\nv1.105.1 | 2026-10-06T18:34:03.960Z | auto\n\n- Removed the redundant file skill-card.md.\n- No functional or behavior changes to the skill itself.\n\nv1.105.0 | 2026-10-06T16:29:54.896Z | auto\n\n- Removed the file: skill-card.md\n- No changes to functionality or user-facing documentation in SKILL.md\n- Version bump to 1.105.0\n\nv1.104.0 | 2026-10-06T15:27:51.471Z | auto\n\n- Removed the file skill-card.md.\n- No changes were made to SKILL.md or other documentation content.\n\nv1.103.0 | 2026-10-06T14:54:52.299Z | auto\n\n- Removed the file: skill-card.md\n- No changes to functionality or documentation in SKILL.md\n\nv1.102.0 | 2026-10-06T13:17:03.436Z | auto\n\n- Removed the nonessential skill-card.md file.\n- No functional or documentation changes to the skill itself.\n\nv1.101.0 | 2026-10-06T08:26:48.338Z | auto\n\n- Removed the sample file skill-card.md.\n- No changes were made to the main function or documentation of the skill itself.\n\nv1.100.0 | 2026-10-05T21:33:32.038Z | auto\n\n- Removed the file: skill-card.md\n- No functional or documentation changes to SKILL.md\n- This update only deletes an auxiliary metadata file, with no effect on usage or behavior\n\nv1.99.1 | 2026-10-05T20:46:56.568Z | auto\n\n- Removed the file skill-card.md for skill xrowgmbh-ci-tools-pipeline.\n- No changes made to the SKILL.md content.\n- No new features or modifications to functionality in this release.\n\nv1.99.0 | 2026-10-05T17:51:21.366Z | auto\n\n- Removed the file skill-card.md from the repository.\n- No changes were made to the skill logic or documentation in SKILL.md.\n- This version contains only cleanup of repository files, with no functional modifications.\n\nv1.98.1 | 2026-10-05T14:46:53.395Z | auto\n\n- Removed the file skill-card.md.\n- No user-facing or functional changes in documentation or features.\n- This update affects repository structure only; the skill's behavior and guidance remain unchanged.\n\nv1.98.0 | 2026-10-05T11:10:42.488Z | auto\n\n- Removed the file skill-card.md.\n- No changes made to functionality or documentation in SKILL.md.\n\nv1.97.1 | 2026-10-05T01:03:58.105Z | auto\n\n- Removed the file skill-card.md.\n- No functional or documentation changes in SKILL.md.\n- Version bump to 1.97.1.\n- No new features or breaking changes.\n\nv1.97.0 | 2026-10-03T11:54:16.111Z | auto\n\n- Removed the file \"skill-card.md\".\n- No changes to functionality or user-facing documentation in SKILL.md.\n\nv1.96.0 | 2026-10-01T15:07:20.909Z | auto\n\n- Removed the skill-card.md file.\n- No changes to code or documentation content in SKILL.md.\n\nv1.95.1 | 2026-10-01T14:01:50.122Z | auto\n\n- Removed the file skill-card.md.\n- No changes to functionality or documentation content.\n- Version bump to 1.95.1.\n\nv1.95.0 | 2026-09-30T18:10:39.192Z | auto\n\n- Removed the redundant file skill-card.md.\n- No other changes to skill logic or documentation content.\n\nv1.94.0 | 2026-09-24T05:09:12.006Z | auto\n\n- Removed the file skill-card.md.\n- No changes to functionality or documentation content; skill-card metadata file is no longer included in the repository.\n\nv1.93.1 | 2026-09-23T21:54:12.803Z | auto\n\n- Removed the file: skill-card.md.\n- Documentation and guidance in SKILL.md remain unchanged in content and structure.\n\nv1.93.0 | 2026-09-20T05:54:26.575Z | auto\n\n- Removed the file skill-card.md.\n- No changes made to source code or documentation content.\n- Version bump to 1.93.0 with a minor internal cleanup.\n\nv1.92.0 | 2026-09-19T19:16:25.033Z | auto\n\nVersion 1.92.0 of xrowgmbh-ci-tools-pipeline\n\n- No file changes detected in this release.\n- No updates to features, documentation, or workflow.\n\nv1.91.8 | 2026-09-19T01:50:18.254Z | auto\n\nVersion 1.91.8\n\n- No file changes were detected in this release.\n- No updates to functionality or documentation.\n\nv1.91.7 | 2026-09-18T18:25:22.245Z | auto\n\n- Removed the file: skill-card.md, streamlining the repository.\n- No changes were made to SKILL.md or the main usage instructions.\n- No features, fixes, or documentation edits were added in this version.\n\nv1.91.6 | 2026-09-17T04:05:32.437Z | auto\n\nNo changes detected in this version.\n\n- Version 1.91.6 contains no file changes or updates.\n\nv1.91.5 | 2026-09-16T18:29:51.094Z | auto\n\n- Removed the documentation file: skill-card.md\n- No changes to core logic or features\n- All usage instructions and guidance remain in SKILL.md\n\nv1.91.4 | 2026-09-16T07:21:13.609Z | auto\n\n- Removed the file skill-card.md to streamline documentation.\n- No other changes to functionality or documentation.\n\nv1.91.3 | 2026-09-13T00:57:38.249Z | auto\n\n- Removed the file skill-card.md.\n- No changes to functionality, guidance, or documentation in SKILL.md.\n- No new features, fixes, or behavioral differences in this release.\n\nv1.91.2 | 2026-09-11T06:40:46.649Z | auto\n\n- Removed the file: skill-card.md\n- No code or documentation changes within skill logic or usage instructions\n- No new features or functionality added in this release\n\nv1.91.1 | 2026-09-09T16:56:23.974Z | auto\n\n- Removed the file: skill-card.md\n- No functional or documentation changes to SKILL.md\n- No new features or bug fixes in this release\n\nv1.91.0 | 2026-09-09T13:54:06.404Z | auto\n\n- Removed the skill-card.md file.\n- No changes to SKILL.md content.\n- No new features, fixes, or documentation updates aside from the file removal.\n\nv1.90.0 | 2026-09-08T06:42:21.700Z | auto\n\nxrowgmbh-ci-tools-pipeline version 1.90.0\n\n- No file changes were detected in this release.\n- Documentation and usage guidelines remain unchanged from the previous version.\n\nv1.89.0 | 2026-09-08T06:23:51.305Z | auto\n\n- Removed the skill-card.md file.\n- No changes to skill functionality or documentation content.\n\nv1.88.0 | 2026-09-07T23:34:22.222Z | auto\n\n- Removed the file skill-card.md.\n- No other changes to skill logic, guidance, or documentation.\n\nv1.87.0 | 2026-09-07T17:19:12.719Z | auto\n\n- Removed the file `skill-card.md` for streamlined skill packaging.\n- No changes were made to skill functionality or documentation in `SKILL.md`.\n\nv1.86.0 | 2026-09-07T08:24:26.728Z | auto\n\n- Removed file: skill-card.md\n- No changes to core functionality or guidance; documentation and behavior remain unchanged.\n\nv1.85.1 | 2026-09-07T06:29:43.429Z | auto\n\n- Removed the file: skill-card.md\n- No user-facing changes to documentation or behavior in this release\n\nv1.85.0 | 2026-09-07T05:31:19.873Z | auto\n\n- Removed the file skill-card.md.\n- No other changes to documentation or functionality.\n\nv1.84.7 | 2026-09-05T00:43:55.614Z | auto\n\n- Removed the skill card documentation file (skill-card.md).\n- No user-facing or functional changes to the skill logic or workflow.\n\nv1.84.6 | 2026-09-03T00:15:26.001Z | auto\n\n- Removed the file: skill-card.md\n- No other changes to documentation or functionality in this version.\n\nv1.84.5 | 2026-09-02T00:33:46.521Z | auto\n\n- Removed the file: skill-card.md\n- No functional or documentation changes to SKILL.md\n- No impact on usage or configuration\n\nv1.84.4 | 2026-09-01T10:42:53.826Z | auto\n\n- Removed obsolete documentation file: skill-card.md\n- No other changes to the skill logic or documentation.\n\nv1.84.3 | 2026-09-01T08:28:34.466Z | auto\n\n- Removed the file skill-card.md from the repository.\n- No changes were made to SKILL.md or the skill’s documented behavior.\n\nv1.84.2 | 2026-08-25T00:38:43.564Z | auto\n\n- Removed the file skill-card.md from the repository.\n- No changes made to code or documentation in SKILL.md.\n- This update is maintenance only; no user-facing functionality or workflow changes.\n\nv1.84.1 | 2026-08-24T20:11:26.895Z | auto\n\n- Removed the file: skill-card.md\n- No changes made to SKILL.md or other documentation\n- No new features, fixes, or enhancements included in this release\n\nv1.84.0 | 2026-08-16T12:29:16.400Z | auto\n\n- Removed the file skill-card.md.\n- No functional or documentation changes in SKILL.md.\n\nArchive index:\n\nArchive v1.108.1: 3 files, 4074 bytes\n\nFiles: skill-card.md (1963b), SKILL.md (6266b), _meta.json (147b)\n\nFile v1.108.1:SKILL.md\n\n---\nname: ci-tools-pipeline\ndescription: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps.\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"curl\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# CI Tools Pipeline Skill\n\nUse this skill to build proper GitLab CI/CD pipelines from the CI Tools Components Catalog.\nPrefer catalog components over custom jobs when a component exists for the job type.\n\n## Quick Start\n\n1. Read the project `AGENTS.md` first, then inspect the repository layout, current `.gitlab-ci.yml`, and existing pipeline failures.\n2. Open the live catalog before choosing components:\n   - Catalog: `https://ci-tools.xrow.de/`\n   - Components index: `https://ci-tools.xrow.de/Components/`\n   - Source: `https://gitlab.com/xrow-public/ci-tools`\n3. Select the smallest component set that covers the project:\n   - Baseline: `common`, `workflow`, `semantic-release`\n   - Hygiene: `label`, `pre-commit`, `spellcheck`, `trivy`\n   - Languages and test runners: `bash-unit-tests`, `lint-javascript`, `lint-json`, `lint-yaml`, `lint-markdown`, `lint-ansible`, `lint-helm`, `lint-tofu`\n   - Build and package: `container`, `buildah`, `helm`, `helm-docs`, `package`, `package-skill`, `oras-push`\n   - Docs and sites: `docusaurus`, `publish-sitemap`, `publish-wiki`\n   - Delivery: `deploy-helm`, `deploy-argocd`, `gitops`, `app-of-apps`\n   - Project flow: `workflow-trunkbased`, `workflow-gitflow`\n4. Validate locally before pushing:\n   - `glab ci lint .gitlab-ci.yml`\n   - Lint any included template files when supported by the project.\n   - Run the narrowest local test for scripts or generated configuration.\n\n## Pipeline Design\n\n- Keep root pipelines component-driven. Add handwritten jobs only when no component exists or a project-specific integration is unavoidable.\n- Use `$CI_SERVER_FQDN/xrow-public/ci-tools/<component>@main` for component includes when package registry or fully-qualified host behavior matters; otherwise match the existing project style.\n- Put component `inputs` next to the include and keep names stable across related jobs.\n- Prefer continuous delivery defaults. Do not create automatic production deployment unless the project already does that or the issue explicitly asks for it.\n- Keep validation jobs independent of deployment jobs so a project can fail fast before writing to registries, clusters, or external systems.\n- Use `needs` and `dependencies` only when a real artifact or ordering relationship exists.\n- Never use `allow_failure: true`, `when: manual`, `rules: when: never`, or skipped tests to hide a broken required pipeline. Use them only when the job is genuinely optional, documented, or intentionally gated.\n\n## Component Selection Heuristics\n\n### Repository Bootstrap\n\nUse these components for most repositories:\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/common@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/label@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/pre-commit@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/trivy@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/workflow@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/semantic-release@main\n```\n\nUse `label` early when the project needs standard `priority::*`, `size::*`, `type::*`, and `workflow::*` labels for automation.\n\n### Containers\n\nUse `container` for normal application images and `buildah` when the project needs direct image build control.\nSet `name` and `path` explicitly when the repository has multiple build roots.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/container@main\n    inputs:\n      name: app\n      path: container/app\n```\n\n### Helm Charts\n\nUse `helm` for chart build/test/publish flows and add `helm-docs` when chart documentation must be generated.\nSet `test-enabled: false` only when there is no safe cluster-backed test path.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/helm@main\n    inputs:\n      name: chart\n      path: chart\n```\n\n### Review Testing\n\nKeep review environments close to production while making destructive checks explicit and temporary.\nFor Helm review tests, validate install, upgrade, readiness, ingress, cleanup, and storage behavior through chart values instead of ad hoc shell overrides.\nDocument any review-only threshold or fixture in the MR so reviewers can see why it differs from production defaults.\n\n### Documentation\n\nUse `docusaurus` for docs sites and pair it with `publish-sitemap` when the project publishes public pages.\nPass `name` and `path` explicitly.\n\n### Infrastructure and GitOps\n\nUse `lint-ansible`, `ansible-collection`, `ansible-ee`, `ansible-runner`, `lint-tofu`, `tofu-module`, `gitops`, `deploy-argocd`, and `app-of-apps` according to the repository type.\nKeep plan, build, and deploy stages separate unless the catalog component documents a tighter flow.\n\n## Validation Workflow\n\n1. Fetch the live component page and verify the input names before editing:\n\n   ```bash\n   curl -fsSL https://ci-tools.xrow.de/Components/<component> | sed -n '1,220p'\n   ```\n\n2. Lint the pipeline:\n\n   ```bash\n   glab ci lint .gitlab-ci.yml\n   ```\n\n3. For merge requests, push with CI skipped first, then start an MR pipeline through GitLab Agent rules:\n\n   ```bash\n   git push origin <branch> -o ci.skip\n   glab ci run --mr\n   ```\n\n4. If CI fails, inspect the failed job trace and fix the underlying problem. If the failure comes from the catalog or main branch, open or link the dependency and mark the MR blocked rather than weakening the pipeline.\n\n## Review Checklist\n\n- The pipeline uses CI Tools components where available.\n- Component inputs match the live catalog documentation.\n- Protected branch behavior is respected.\n- Required checks are not hidden behind skips or `allow_failure`.\n- Registry, cluster, and deploy writes are gated by existing project rules.\n- The MR description lists the plan, acceptance criteria, and validation commands.\n\nFile v1.108.1:_meta.json\n\n{\n  \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n  \"slug\": \"xrowgmbh-ci-tools-pipeline\",\n  \"version\": \"1.108.1\",\n  \"publishedAt\": 1791497294521\n}\n\nFile v1.108.1:skill-card.md\n\n## Description:\n\nHelps developers build and maintain GitLab CI/CD pipelines using the CI Tools Components Catalog.\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 engineers use this skill to create, repair, and validate GitLab CI/CD pipelines for application builds, testing, packaging, documentation, and delivery.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Pushing a branch with CI skipped or starting a merge-request pipeline changes remote GitLab state and may trigger jobs or deployments.\n\nMitigation: Confirm the project, target branch, and pipeline rules before pushing or starting CI; retain existing deployment gates.\n\nRisk: Incorrect or changed catalog component inputs can break a required pipeline.\n\nMitigation: Check the live component documentation and lint the pipeline before pushing; investigate failures instead of suppressing required checks.\n\n## Reference(s):\n\n- [CI Tools Components Catalog](https://ci-tools.xrow.de/Components/)\n- [CI Tools project](https://gitlab.com/xrow-public/ci-tools)\n- [CI Tools Pipeline skill release](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-ci-tools-pipeline)\n\n## Skill Output:\n\n**Output Type(s):** [Configuration instructions, Code, Shell commands, Guidance]\n\n**Output Format:** [Markdown with GitLab CI YAML and shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Pipeline recommendations should be validated against the live component catalog and linted before use.]\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: 3 files, 4000 bytes\n\nFiles: skill-card.md (1776b), SKILL.md (6266b), _meta.json (147b)\n\nFile v1.108.0:SKILL.md\n\n---\nname: ci-tools-pipeline\ndescription: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps.\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"curl\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# CI Tools Pipeline Skill\n\nUse this skill to build proper GitLab CI/CD pipelines from the CI Tools Components Catalog.\nPrefer catalog components over custom jobs when a component exists for the job type.\n\n## Quick Start\n\n1. Read the project `AGENTS.md` first, then inspect the repository layout, current `.gitlab-ci.yml`, and existing pipeline failures.\n2. Open the live catalog before choosing components:\n   - Catalog: `https://ci-tools.xrow.de/`\n   - Components index: `https://ci-tools.xrow.de/Components/`\n   - Source: `https://gitlab.com/xrow-public/ci-tools`\n3. Select the smallest component set that covers the project:\n   - Baseline: `common`, `workflow`, `semantic-release`\n   - Hygiene: `label`, `pre-commit`, `spellcheck`, `trivy`\n   - Languages and test runners: `bash-unit-tests`, `lint-javascript`, `lint-json`, `lint-yaml`, `lint-markdown`, `lint-ansible`, `lint-helm`, `lint-tofu`\n   - Build and package: `container`, `buildah`, `helm`, `helm-docs`, `package`, `package-skill`, `oras-push`\n   - Docs and sites: `docusaurus`, `publish-sitemap`, `publish-wiki`\n   - Delivery: `deploy-helm`, `deploy-argocd`, `gitops`, `app-of-apps`\n   - Project flow: `workflow-trunkbased`, `workflow-gitflow`\n4. Validate locally before pushing:\n   - `glab ci lint .gitlab-ci.yml`\n   - Lint any included template files when supported by the project.\n   - Run the narrowest local test for scripts or generated configuration.\n\n## Pipeline Design\n\n- Keep root pipelines component-driven. Add handwritten jobs only when no component exists or a project-specific integration is unavoidable.\n- Use `$CI_SERVER_FQDN/xrow-public/ci-tools/<component>@main` for component includes when package registry or fully-qualified host behavior matters; otherwise match the existing project style.\n- Put component `inputs` next to the include and keep names stable across related jobs.\n- Prefer continuous delivery defaults. Do not create automatic production deployment unless the project already does that or the issue explicitly asks for it.\n- Keep validation jobs independent of deployment jobs so a project can fail fast before writing to registries, clusters, or external systems.\n- Use `needs` and `dependencies` only when a real artifact or ordering relationship exists.\n- Never use `allow_failure: true`, `when: manual`, `rules: when: never`, or skipped tests to hide a broken required pipeline. Use them only when the job is genuinely optional, documented, or intentionally gated.\n\n## Component Selection Heuristics\n\n### Repository Bootstrap\n\nUse these components for most repositories:\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/common@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/label@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/pre-commit@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/trivy@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/workflow@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/semantic-release@main\n```\n\nUse `label` early when the project needs standard `priority::*`, `size::*`, `type::*`, and `workflow::*` labels for automation.\n\n### Containers\n\nUse `container` for normal application images and `buildah` when the project needs direct image build control.\nSet `name` and `path` explicitly when the repository has multiple build roots.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/container@main\n    inputs:\n      name: app\n      path: container/app\n```\n\n### Helm Charts\n\nUse `helm` for chart build/test/publish flows and add `helm-docs` when chart documentation must be generated.\nSet `test-enabled: false` only when there is no safe cluster-backed test path.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/helm@main\n    inputs:\n      name: chart\n      path: chart\n```\n\n### Review Testing\n\nKeep review environments close to production while making destructive checks explicit and temporary.\nFor Helm review tests, validate install, upgrade, readiness, ingress, cleanup, and storage behavior through chart values instead of ad hoc shell overrides.\nDocument any review-only threshold or fixture in the MR so reviewers can see why it differs from production defaults.\n\n### Documentation\n\nUse `docusaurus` for docs sites and pair it with `publish-sitemap` when the project publishes public pages.\nPass `name` and `path` explicitly.\n\n### Infrastructure and GitOps\n\nUse `lint-ansible`, `ansible-collection`, `ansible-ee`, `ansible-runner`, `lint-tofu`, `tofu-module`, `gitops`, `deploy-argocd`, and `app-of-apps` according to the repository type.\nKeep plan, build, and deploy stages separate unless the catalog component documents a tighter flow.\n\n## Validation Workflow\n\n1. Fetch the live component page and verify the input names before editing:\n\n   ```bash\n   curl -fsSL https://ci-tools.xrow.de/Components/<component> | sed -n '1,220p'\n   ```\n\n2. Lint the pipeline:\n\n   ```bash\n   glab ci lint .gitlab-ci.yml\n   ```\n\n3. For merge requests, push with CI skipped first, then start an MR pipeline through GitLab Agent rules:\n\n   ```bash\n   git push origin <branch> -o ci.skip\n   glab ci run --mr\n   ```\n\n4. If CI fails, inspect the failed job trace and fix the underlying problem. If the failure comes from the catalog or main branch, open or link the dependency and mark the MR blocked rather than weakening the pipeline.\n\n## Review Checklist\n\n- The pipeline uses CI Tools components where available.\n- Component inputs match the live catalog documentation.\n- Protected branch behavior is respected.\n- Required checks are not hidden behind skips or `allow_failure`.\n- Registry, cluster, and deploy writes are gated by existing project rules.\n- The MR description lists the plan, acceptance criteria, and validation commands.\n\nFile v1.108.0:_meta.json\n\n{\n  \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n  \"slug\": \"xrowgmbh-ci-tools-pipeline\",\n  \"version\": \"1.108.0\",\n  \"publishedAt\": 1791490063474\n}\n\nFile v1.108.0:skill-card.md\n\n## Description:\n\nHelps developers build and maintain GitLab CI/CD pipelines using the CI Tools Components Catalog.\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 use this skill to choose catalog components, create or repair GitLab CI/CD configuration, and validate pipelines for application, infrastructure, and delivery workflows.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated pipeline changes may fail validation or trigger unintended deployment behavior.\n\nMitigation: Review the configuration before pushing, lint it with GitLab, and keep deployment writes gated by existing project rules.\n\nRisk: GitLab credentials with excessive permissions could broaden the impact of pipeline actions.\n\nMitigation: Use a GitLab token limited to the permissions needed for the target project.\n\n## Reference(s):\n\n- [ClawHub skill release](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-ci-tools-pipeline)\n- [CI Tools Components Catalog](https://ci-tools.xrow.de/Components/)\n- [CI Tools catalog source](https://gitlab.com/xrow-public/ci-tools)\n\n## Skill Output:\n\n**Output Type(s):** [Configuration, Shell commands, Guidance]\n\n**Output Format:** [GitLab CI YAML and Markdown guidance with shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [None]\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: 3 files, 4000 bytes\n\nFiles: skill-card.md (1844b), SKILL.md (6266b), _meta.json (147b)\n\nFile v1.107.1:SKILL.md\n\n---\nname: ci-tools-pipeline\ndescription: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps.\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"curl\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# CI Tools Pipeline Skill\n\nUse this skill to build proper GitLab CI/CD pipelines from the CI Tools Components Catalog.\nPrefer catalog components over custom jobs when a component exists for the job type.\n\n## Quick Start\n\n1. Read the project `AGENTS.md` first, then inspect the repository layout, current `.gitlab-ci.yml`, and existing pipeline failures.\n2. Open the live catalog before choosing components:\n   - Catalog: `https://ci-tools.xrow.de/`\n   - Components index: `https://ci-tools.xrow.de/Components/`\n   - Source: `https://gitlab.com/xrow-public/ci-tools`\n3. Select the smallest component set that covers the project:\n   - Baseline: `common`, `workflow`, `semantic-release`\n   - Hygiene: `label`, `pre-commit`, `spellcheck`, `trivy`\n   - Languages and test runners: `bash-unit-tests`, `lint-javascript`, `lint-json`, `lint-yaml`, `lint-markdown`, `lint-ansible`, `lint-helm`, `lint-tofu`\n   - Build and package: `container`, `buildah`, `helm`, `helm-docs`, `package`, `package-skill`, `oras-push`\n   - Docs and sites: `docusaurus`, `publish-sitemap`, `publish-wiki`\n   - Delivery: `deploy-helm`, `deploy-argocd`, `gitops`, `app-of-apps`\n   - Project flow: `workflow-trunkbased`, `workflow-gitflow`\n4. Validate locally before pushing:\n   - `glab ci lint .gitlab-ci.yml`\n   - Lint any included template files when supported by the project.\n   - Run the narrowest local test for scripts or generated configuration.\n\n## Pipeline Design\n\n- Keep root pipelines component-driven. Add handwritten jobs only when no component exists or a project-specific integration is unavoidable.\n- Use `$CI_SERVER_FQDN/xrow-public/ci-tools/<component>@main` for component includes when package registry or fully-qualified host behavior matters; otherwise match the existing project style.\n- Put component `inputs` next to the include and keep names stable across related jobs.\n- Prefer continuous delivery defaults. Do not create automatic production deployment unless the project already does that or the issue explicitly asks for it.\n- Keep validation jobs independent of deployment jobs so a project can fail fast before writing to registries, clusters, or external systems.\n- Use `needs` and `dependencies` only when a real artifact or ordering relationship exists.\n- Never use `allow_failure: true`, `when: manual`, `rules: when: never`, or skipped tests to hide a broken required pipeline. Use them only when the job is genuinely optional, documented, or intentionally gated.\n\n## Component Selection Heuristics\n\n### Repository Bootstrap\n\nUse these components for most repositories:\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/common@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/label@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/pre-commit@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/trivy@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/workflow@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/semantic-release@main\n```\n\nUse `label` early when the project needs standard `priority::*`, `size::*`, `type::*`, and `workflow::*` labels for automation.\n\n### Containers\n\nUse `container` for normal application images and `buildah` when the project needs direct image build control.\nSet `name` and `path` explicitly when the repository has multiple build roots.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/container@main\n    inputs:\n      name: app\n      path: container/app\n```\n\n### Helm Charts\n\nUse `helm` for chart build/test/publish flows and add `helm-docs` when chart documentation must be generated.\nSet `test-enabled: false` only when there is no safe cluster-backed test path.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/helm@main\n    inputs:\n      name: chart\n      path: chart\n```\n\n### Review Testing\n\nKeep review environments close to production while making destructive checks explicit and temporary.\nFor Helm review tests, validate install, upgrade, readiness, ingress, cleanup, and storage behavior through chart values instead of ad hoc shell overrides.\nDocument any review-only threshold or fixture in the MR so reviewers can see why it differs from production defaults.\n\n### Documentation\n\nUse `docusaurus` for docs sites and pair it with `publish-sitemap` when the project publishes public pages.\nPass `name` and `path` explicitly.\n\n### Infrastructure and GitOps\n\nUse `lint-ansible`, `ansible-collection`, `ansible-ee`, `ansible-runner`, `lint-tofu`, `tofu-module`, `gitops`, `deploy-argocd`, and `app-of-apps` according to the repository type.\nKeep plan, build, and deploy stages separate unless the catalog component documents a tighter flow.\n\n## Validation Workflow\n\n1. Fetch the live component page and verify the input names before editing:\n\n   ```bash\n   curl -fsSL https://ci-tools.xrow.de/Components/<component> | sed -n '1,220p'\n   ```\n\n2. Lint the pipeline:\n\n   ```bash\n   glab ci lint .gitlab-ci.yml\n   ```\n\n3. For merge requests, push with CI skipped first, then start an MR pipeline through GitLab Agent rules:\n\n   ```bash\n   git push origin <branch> -o ci.skip\n   glab ci run --mr\n   ```\n\n4. If CI fails, inspect the failed job trace and fix the underlying problem. If the failure comes from the catalog or main branch, open or link the dependency and mark the MR blocked rather than weakening the pipeline.\n\n## Review Checklist\n\n- The pipeline uses CI Tools components where available.\n- Component inputs match the live catalog documentation.\n- Protected branch behavior is respected.\n- Required checks are not hidden behind skips or `allow_failure`.\n- Registry, cluster, and deploy writes are gated by existing project rules.\n- The MR description lists the plan, acceptance criteria, and validation commands.\n\nFile v1.107.1:_meta.json\n\n{\n  \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n  \"slug\": \"xrowgmbh-ci-tools-pipeline\",\n  \"version\": \"1.107.1\",\n  \"publishedAt\": 1791483007137\n}\n\nFile v1.107.1:skill-card.md\n\n## Description:\n\nHelps developers build and maintain GitLab CI/CD pipelines using the CI Tools Components Catalog.\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 use this skill to select CI Tools components, edit GitLab CI configuration, and validate build, test, and deployment pipelines.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The suggested merge-request workflow can push a branch while skipping its push pipeline.\n\nMitigation: Confirm the repository permits this workflow and run local linting before pushing; then start and check the merge-request pipeline.\n\nRisk: GitLab credentials and pipeline changes can affect repositories and deployment workflows.\n\nMitigation: Use a least-privileged GitLab token and review generated CI configuration and deployment gates before applying changes.\n\n## Reference(s):\n\n- [CI Tools Components Catalog](https://ci-tools.xrow.de/Components/)\n- [CI Tools component source](https://gitlab.com/xrow-public/ci-tools)\n- [ClawHub skill listing](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-ci-tools-pipeline)\n\n## Skill Output:\n\n**Output Type(s):** [Configuration, Shell commands, Guidance]\n\n**Output Format:** [GitLab CI YAML and Markdown guidance with shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Review proposed pipeline changes and lint configuration before pushing.]\n\n## Skill Version(s):\n\n1.107.1 (source: ClawHub release)\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: 3 files, 4016 bytes\n\nFiles: skill-card.md (1838b), SKILL.md (6266b), _meta.json (147b)\n\nFile v1.107.0:SKILL.md\n\n---\nname: ci-tools-pipeline\ndescription: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps.\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"curl\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# CI Tools Pipeline Skill\n\nUse this skill to build proper GitLab CI/CD pipelines from the CI Tools Components Catalog.\nPrefer catalog components over custom jobs when a component exists for the job type.\n\n## Quick Start\n\n1. Read the project `AGENTS.md` first, then inspect the repository layout, current `.gitlab-ci.yml`, and existing pipeline failures.\n2. Open the live catalog before choosing components:\n   - Catalog: `https://ci-tools.xrow.de/`\n   - Components index: `https://ci-tools.xrow.de/Components/`\n   - Source: `https://gitlab.com/xrow-public/ci-tools`\n3. Select the smallest component set that covers the project:\n   - Baseline: `common`, `workflow`, `semantic-release`\n   - Hygiene: `label`, `pre-commit`, `spellcheck`, `trivy`\n   - Languages and test runners: `bash-unit-tests`, `lint-javascript`, `lint-json`, `lint-yaml`, `lint-markdown`, `lint-ansible`, `lint-helm`, `lint-tofu`\n   - Build and package: `container`, `buildah`, `helm`, `helm-docs`, `package`, `package-skill`, `oras-push`\n   - Docs and sites: `docusaurus`, `publish-sitemap`, `publish-wiki`\n   - Delivery: `deploy-helm`, `deploy-argocd`, `gitops`, `app-of-apps`\n   - Project flow: `workflow-trunkbased`, `workflow-gitflow`\n4. Validate locally before pushing:\n   - `glab ci lint .gitlab-ci.yml`\n   - Lint any included template files when supported by the project.\n   - Run the narrowest local test for scripts or generated configuration.\n\n## Pipeline Design\n\n- Keep root pipelines component-driven. Add handwritten jobs only when no component exists or a project-specific integration is unavoidable.\n- Use `$CI_SERVER_FQDN/xrow-public/ci-tools/<component>@main` for component includes when package registry or fully-qualified host behavior matters; otherwise match the existing project style.\n- Put component `inputs` next to the include and keep names stable across related jobs.\n- Prefer continuous delivery defaults. Do not create automatic production deployment unless the project already does that or the issue explicitly asks for it.\n- Keep validation jobs independent of deployment jobs so a project can fail fast before writing to registries, clusters, or external systems.\n- Use `needs` and `dependencies` only when a real artifact or ordering relationship exists.\n- Never use `allow_failure: true`, `when: manual`, `rules: when: never`, or skipped tests to hide a broken required pipeline. Use them only when the job is genuinely optional, documented, or intentionally gated.\n\n## Component Selection Heuristics\n\n### Repository Bootstrap\n\nUse these components for most repositories:\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/common@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/label@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/pre-commit@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/trivy@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/workflow@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/semantic-release@main\n```\n\nUse `label` early when the project needs standard `priority::*`, `size::*`, `type::*`, and `workflow::*` labels for automation.\n\n### Containers\n\nUse `container` for normal application images and `buildah` when the project needs direct image build control.\nSet `name` and `path` explicitly when the repository has multiple build roots.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/container@main\n    inputs:\n      name: app\n      path: container/app\n```\n\n### Helm Charts\n\nUse `helm` for chart build/test/publish flows and add `helm-docs` when chart documentation must be generated.\nSet `test-enabled: false` only when there is no safe cluster-backed test path.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/helm@main\n    inputs:\n      name: chart\n      path: chart\n```\n\n### Review Testing\n\nKeep review environments close to production while making destructive checks explicit and temporary.\nFor Helm review tests, validate install, upgrade, readiness, ingress, cleanup, and storage behavior through chart values instead of ad hoc shell overrides.\nDocument any review-only threshold or fixture in the MR so reviewers can see why it differs from production defaults.\n\n### Documentation\n\nUse `docusaurus` for docs sites and pair it with `publish-sitemap` when the project publishes public pages.\nPass `name` and `path` explicitly.\n\n### Infrastructure and GitOps\n\nUse `lint-ansible`, `ansible-collection`, `ansible-ee`, `ansible-runner`, `lint-tofu`, `tofu-module`, `gitops`, `deploy-argocd`, and `app-of-apps` according to the repository type.\nKeep plan, build, and deploy stages separate unless the catalog component documents a tighter flow.\n\n## Validation Workflow\n\n1. Fetch the live component page and verify the input names before editing:\n\n   ```bash\n   curl -fsSL https://ci-tools.xrow.de/Components/<component> | sed -n '1,220p'\n   ```\n\n2. Lint the pipeline:\n\n   ```bash\n   glab ci lint .gitlab-ci.yml\n   ```\n\n3. For merge requests, push with CI skipped first, then start an MR pipeline through GitLab Agent rules:\n\n   ```bash\n   git push origin <branch> -o ci.skip\n   glab ci run --mr\n   ```\n\n4. If CI fails, inspect the failed job trace and fix the underlying problem. If the failure comes from the catalog or main branch, open or link the dependency and mark the MR blocked rather than weakening the pipeline.\n\n## Review Checklist\n\n- The pipeline uses CI Tools components where available.\n- Component inputs match the live catalog documentation.\n- Protected branch behavior is respected.\n- Required checks are not hidden behind skips or `allow_failure`.\n- Registry, cluster, and deploy writes are gated by existing project rules.\n- The MR description lists the plan, acceptance criteria, and validation commands.\n\nFile v1.107.0:_meta.json\n\n{\n  \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n  \"slug\": \"xrowgmbh-ci-tools-pipeline\",\n  \"version\": \"1.107.0\",\n  \"publishedAt\": 1791479112387\n}\n\nFile v1.107.0:skill-card.md\n\n## Description:\n\nBuilds and maintains GitLab CI/CD pipelines using the CI Tools Components Catalog.\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 CI/CD engineers use this skill to create or repair GitLab pipelines, choose catalog components, check component inputs, and validate application, package, infrastructure, and deployment workflows.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: GitLab CLI access and GITLAB_TOKEN can initiate pipelines or push branches when requested.\n\nMitigation: Confirm the intended repository and permissions, and review changes and commands before running them.\n\nRisk: Live component documentation and main-branch includes can change after a pipeline is drafted.\n\nMitigation: Check current component inputs, review included changes, and lint the pipeline before pushing.\n\n## Reference(s):\n\n- [CI Tools Components Catalog](https://ci-tools.xrow.de/Components/)\n- [CI Tools documentation](https://ci-tools.xrow.de/)\n- [ClawHub skill release](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-ci-tools-pipeline)\n\n## Skill Output:\n\n**Output Type(s):** [Configuration, Shell commands, Guidance]\n\n**Output Format:** [GitLab CI YAML and Markdown guidance with shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Component inputs and validation steps tailored to the repository.]\n\n## Skill Version(s):\n\n1.107.0 (source: server-resolved release)\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: 3 files, 4109 bytes\n\nFiles: skill-card.md (2047b), SKILL.md (6266b), _meta.json (147b)\n\nFile v1.106.1:SKILL.md\n\n---\nname: ci-tools-pipeline\ndescription: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps.\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"curl\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# CI Tools Pipeline Skill\n\nUse this skill to build proper GitLab CI/CD pipelines from the CI Tools Components Catalog.\nPrefer catalog components over custom jobs when a component exists for the job type.\n\n## Quick Start\n\n1. Read the project `AGENTS.md` first, then inspect the repository layout, current `.gitlab-ci.yml`, and existing pipeline failures.\n2. Open the live catalog before choosing components:\n   - Catalog: `https://ci-tools.xrow.de/`\n   - Components index: `https://ci-tools.xrow.de/Components/`\n   - Source: `https://gitlab.com/xrow-public/ci-tools`\n3. Select the smallest component set that covers the project:\n   - Baseline: `common`, `workflow`, `semantic-release`\n   - Hygiene: `label`, `pre-commit`, `spellcheck`, `trivy`\n   - Languages and test runners: `bash-unit-tests`, `lint-javascript`, `lint-json`, `lint-yaml`, `lint-markdown`, `lint-ansible`, `lint-helm`, `lint-tofu`\n   - Build and package: `container`, `buildah`, `helm`, `helm-docs`, `package`, `package-skill`, `oras-push`\n   - Docs and sites: `docusaurus`, `publish-sitemap`, `publish-wiki`\n   - Delivery: `deploy-helm`, `deploy-argocd`, `gitops`, `app-of-apps`\n   - Project flow: `workflow-trunkbased`, `workflow-gitflow`\n4. Validate locally before pushing:\n   - `glab ci lint .gitlab-ci.yml`\n   - Lint any included template files when supported by the project.\n   - Run the narrowest local test for scripts or generated configuration.\n\n## Pipeline Design\n\n- Keep root pipelines component-driven. Add handwritten jobs only when no component exists or a project-specific integration is unavoidable.\n- Use `$CI_SERVER_FQDN/xrow-public/ci-tools/<component>@main` for component includes when package registry or fully-qualified host behavior matters; otherwise match the existing project style.\n- Put component `inputs` next to the include and keep names stable across related jobs.\n- Prefer continuous delivery defaults. Do not create automatic production deployment unless the project already does that or the issue explicitly asks for it.\n- Keep validation jobs independent of deployment jobs so a project can fail fast before writing to registries, clusters, or external systems.\n- Use `needs` and `dependencies` only when a real artifact or ordering relationship exists.\n- Never use `allow_failure: true`, `when: manual`, `rules: when: never`, or skipped tests to hide a broken required pipeline. Use them only when the job is genuinely optional, documented, or intentionally gated.\n\n## Component Selection Heuristics\n\n### Repository Bootstrap\n\nUse these components for most repositories:\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/common@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/label@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/pre-commit@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/trivy@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/workflow@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/semantic-release@main\n```\n\nUse `label` early when the project needs standard `priority::*`, `size::*`, `type::*`, and `workflow::*` labels for automation.\n\n### Containers\n\nUse `container` for normal application images and `buildah` when the project needs direct image build control.\nSet `name` and `path` explicitly when the repository has multiple build roots.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/container@main\n    inputs:\n      name: app\n      path: container/app\n```\n\n### Helm Charts\n\nUse `helm` for chart build/test/publish flows and add `helm-docs` when chart documentation must be generated.\nSet `test-enabled: false` only when there is no safe cluster-backed test path.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/helm@main\n    inputs:\n      name: chart\n      path: chart\n```\n\n### Review Testing\n\nKeep review environments close to production while making destructive checks explicit and temporary.\nFor Helm review tests, validate install, upgrade, readiness, ingress, cleanup, and storage behavior through chart values instead of ad hoc shell overrides.\nDocument any review-only threshold or fixture in the MR so reviewers can see why it differs from production defaults.\n\n### Documentation\n\nUse `docusaurus` for docs sites and pair it with `publish-sitemap` when the project publishes public pages.\nPass `name` and `path` explicitly.\n\n### Infrastructure and GitOps\n\nUse `lint-ansible`, `ansible-collection`, `ansible-ee`, `ansible-runner`, `lint-tofu`, `tofu-module`, `gitops`, `deploy-argocd`, and `app-of-apps` according to the repository type.\nKeep plan, build, and deploy stages separate unless the catalog component documents a tighter flow.\n\n## Validation Workflow\n\n1. Fetch the live component page and verify the input names before editing:\n\n   ```bash\n   curl -fsSL https://ci-tools.xrow.de/Components/<component> | sed -n '1,220p'\n   ```\n\n2. Lint the pipeline:\n\n   ```bash\n   glab ci lint .gitlab-ci.yml\n   ```\n\n3. For merge requests, push with CI skipped first, then start an MR pipeline through GitLab Agent rules:\n\n   ```bash\n   git push origin <branch> -o ci.skip\n   glab ci run --mr\n   ```\n\n4. If CI fails, inspect the failed job trace and fix the underlying problem. If the failure comes from the catalog or main branch, open or link the dependency and mark the MR blocked rather than weakening the pipeline.\n\n## Review Checklist\n\n- The pipeline uses CI Tools components where available.\n- Component inputs match the live catalog documentation.\n- Protected branch behavior is respected.\n- Required checks are not hidden behind skips or `allow_failure`.\n- Registry, cluster, and deploy writes are gated by existing project rules.\n- The MR description lists the plan, acceptance criteria, and validation commands.\n\nFile v1.106.1:_meta.json\n\n{\n  \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n  \"slug\": \"xrowgmbh-ci-tools-pipeline\",\n  \"version\": \"1.106.1\",\n  \"publishedAt\": 1791454693467\n}\n\nFile v1.106.1:skill-card.md\n\n## Description:\n\nHelps developers build and maintain GitLab CI/CD pipelines using the CI Tools Components Catalog.\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 engineers use this skill to select CI Tools components, create or fix GitLab pipeline configuration, and validate delivery workflows for applications, containers, charts, documentation, and infrastructure.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated pipeline changes can affect CI checks, deployments, or external systems.\n\nMitigation: Review and lint .gitlab-ci.yml before pushing; retain existing deployment gates and required checks.\n\nRisk: Component examples reference the live main branch and may change over time.\n\nMitigation: Check component inputs against the live catalog and review included components before use.\n\nRisk: GitLab commands may use a token with access to the target project.\n\nMitigation: Use a token with only the permissions needed for the target project.\n\n## Reference(s):\n\n- [CI Tools Components Catalog](https://ci-tools.xrow.de/Components/)\n- [CI Tools documentation](https://ci-tools.xrow.de/)\n- [CI Tools component project](https://gitlab.com/xrow-public/ci-tools)\n- [ClawHub skill release](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-ci-tools-pipeline)\n\n## Skill Output:\n\n**Output Type(s):** [Configuration, Shell commands, Guidance]\n\n**Output Format:** [Markdown with GitLab CI YAML and shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Requires glab, curl, and jq; GitLab access uses GITLAB_TOKEN.]\n\n## Skill Version(s):\n\n1.106.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.106.0: 3 files, 4001 bytes\n\nFiles: skill-card.md (1797b), SKILL.md (6266b), _meta.json (147b)\n\nFile v1.106.0:SKILL.md\n\n---\nname: ci-tools-pipeline\ndescription: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps.\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"curl\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# CI Tools Pipeline Skill\n\nUse this skill to build proper GitLab CI/CD pipelines from the CI Tools Components Catalog.\nPrefer catalog components over custom jobs when a component exists for the job type.\n\n## Quick Start\n\n1. Read the project `AGENTS.md` first, then inspect the repository layout, current `.gitlab-ci.yml`, and existing pipeline failures.\n2. Open the live catalog before choosing components:\n   - Catalog: `https://ci-tools.xrow.de/`\n   - Components index: `https://ci-tools.xrow.de/Components/`\n   - Source: `https://gitlab.com/xrow-public/ci-tools`\n3. Select the smallest component set that covers the project:\n   - Baseline: `common`, `workflow`, `semantic-release`\n   - Hygiene: `label`, `pre-commit`, `spellcheck`, `trivy`\n   - Languages and test runners: `bash-unit-tests`, `lint-javascript`, `lint-json`, `lint-yaml`, `lint-markdown`, `lint-ansible`, `lint-helm`, `lint-tofu`\n   - Build and package: `container`, `buildah`, `helm`, `helm-docs`, `package`, `package-skill`, `oras-push`\n   - Docs and sites: `docusaurus`, `publish-sitemap`, `publish-wiki`\n   - Delivery: `deploy-helm`, `deploy-argocd`, `gitops`, `app-of-apps`\n   - Project flow: `workflow-trunkbased`, `workflow-gitflow`\n4. Validate locally before pushing:\n   - `glab ci lint .gitlab-ci.yml`\n   - Lint any included template files when supported by the project.\n   - Run the narrowest local test for scripts or generated configuration.\n\n## Pipeline Design\n\n- Keep root pipelines component-driven. Add handwritten jobs only when no component exists or a project-specific integration is unavoidable.\n- Use `$CI_SERVER_FQDN/xrow-public/ci-tools/<component>@main` for component includes when package registry or fully-qualified host behavior matters; otherwise match the existing project style.\n- Put component `inputs` next to the include and keep names stable across related jobs.\n- Prefer continuous delivery defaults. Do not create automatic production deployment unless the project already does that or the issue explicitly asks for it.\n- Keep validation jobs independent of deployment jobs so a project can fail fast before writing to registries, clusters, or external systems.\n- Use `needs` and `dependencies` only when a real artifact or ordering relationship exists.\n- Never use `allow_failure: true`, `when: manual`, `rules: when: never`, or skipped tests to hide a broken required pipeline. Use them only when the job is genuinely optional, documented, or intentionally gated.\n\n## Component Selection Heuristics\n\n### Repository Bootstrap\n\nUse these components for most repositories:\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/common@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/label@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/pre-commit@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/trivy@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/workflow@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/semantic-release@main\n```\n\nUse `label` early when the project needs standard `priority::*`, `size::*`, `type::*`, and `workflow::*` labels for automation.\n\n### Containers\n\nUse `container` for normal application images and `buildah` when the project needs direct image build control.\nSet `name` and `path` explicitly when the repository has multiple build roots.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/container@main\n    inputs:\n      name: app\n      path: container/app\n```\n\n### Helm Charts\n\nUse `helm` for chart build/test/publish flows and add `helm-docs` when chart documentation must be generated.\nSet `test-enabled: false` only when there is no safe cluster-backed test path.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/helm@main\n    inputs:\n      name: chart\n      path: chart\n```\n\n### Review Testing\n\nKeep review environments close to production while making destructive checks explicit and temporary.\nFor Helm review tests, validate install, upgrade, readiness, ingress, cleanup, and storage behavior through chart values instead of ad hoc shell overrides.\nDocument any review-only threshold or fixture in the MR so reviewers can see why it differs from production defaults.\n\n### Documentation\n\nUse `docusaurus` for docs sites and pair it with `publish-sitemap` when the project publishes public pages.\nPass `name` and `path` explicitly.\n\n### Infrastructure and GitOps\n\nUse `lint-ansible`, `ansible-collection`, `ansible-ee`, `ansible-runner`, `lint-tofu`, `tofu-module`, `gitops`, `deploy-argocd`, and `app-of-apps` according to the repository type.\nKeep plan, build, and deploy stages separate unless the catalog component documents a tighter flow.\n\n## Validation Workflow\n\n1. Fetch the live component page and verify the input names before editing:\n\n   ```bash\n   curl -fsSL https://ci-tools.xrow.de/Components/<component> | sed -n '1,220p'\n   ```\n\n2. Lint the pipeline:\n\n   ```bash\n   glab ci lint .gitlab-ci.yml\n   ```\n\n3. For merge requests, push with CI skipped first, then start an MR pipeline through GitLab Agent rules:\n\n   ```bash\n   git push origin <branch> -o ci.skip\n   glab ci run --mr\n   ```\n\n4. If CI fails, inspect the failed job trace and fix the underlying problem. If the failure comes from the catalog or main branch, open or link the dependency and mark the MR blocked rather than weakening the pipeline.\n\n## Review Checklist\n\n- The pipeline uses CI Tools components where available.\n- Component inputs match the live catalog documentation.\n- Protected branch behavior is respected.\n- Required checks are not hidden behind skips or `allow_failure`.\n- Registry, cluster, and deploy writes are gated by existing project rules.\n- The MR description lists the plan, acceptance criteria, and validation commands.\n\nFile v1.106.0:_meta.json\n\n{\n  \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n  \"slug\": \"xrowgmbh-ci-tools-pipeline\",\n  \"version\": \"1.106.0\",\n  \"publishedAt\": 1791448761800\n}\n\nFile v1.106.0:skill-card.md\n\n## Description:\n\nHelps developers build and maintain GitLab CI/CD pipelines using the CI Tools Components Catalog.\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 engineers use this skill to create, update, and validate component-based GitLab CI pipelines for application builds, testing, packaging, and delivery.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Proposed pipeline changes can affect required checks or deployment behavior.\n\nMitigation: Review .gitlab-ci.yml changes and validate component inputs before applying them.\n\nRisk: Network requests, git pushes, and MR pipeline runs can send data to GitLab and consume CI resources.\n\nMitigation: Explicitly approve network access, pushes, and pipeline runs before execution.\n\n## Reference(s):\n\n- [CI Tools Components Catalog](https://ci-tools.xrow.de/Components/)\n- [CI Tools component repository](https://gitlab.com/xrow-public/ci-tools)\n- [CI Tools Pipeline on ClawHub](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-ci-tools-pipeline)\n\n## Skill Output:\n\n**Output Type(s):** [Configuration instructions, Code, Shell commands, Guidance]\n\n**Output Format:** [Markdown with GitLab CI YAML and shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May propose changes to .gitlab-ci.yml and validation steps.]\n\n## Skill Version(s):\n\n1.106.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.105.1: 3 files, 3964 bytes\n\nFiles: skill-card.md (1717b), SKILL.md (6266b), _meta.json (147b)\n\nFile v1.105.1:SKILL.md\n\n---\nname: ci-tools-pipeline\ndescription: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps.\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"curl\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# CI Tools Pipeline Skill\n\nUse this skill to build proper GitLab CI/CD pipelines from the CI Tools Components Catalog.\nPrefer catalog components over custom jobs when a component exists for the job type.\n\n## Quick Start\n\n1. Read the project `AGENTS.md` first, then inspect the repository layout, current `.gitlab-ci.yml`, and existing pipeline failures.\n2. Open the live catalog before choosing components:\n   - Catalog: `https://ci-tools.xrow.de/`\n   - Components index: `https://ci-tools.xrow.de/Components/`\n   - Source: `https://gitlab.com/xrow-public/ci-tools`\n3. Select the smallest component set that covers the project:\n   - Baseline: `common`, `workflow`, `semantic-release`\n   - Hygiene: `label`, `pre-commit`, `spellcheck`, `trivy`\n   - Languages and test runners: `bash-unit-tests`, `lint-javascript`, `lint-json`, `lint-yaml`, `lint-markdown`, `lint-ansible`, `lint-helm`, `lint-tofu`\n   - Build and package: `container`, `buildah`, `helm`, `helm-docs`, `package`, `package-skill`, `oras-push`\n   - Docs and sites: `docusaurus`, `publish-sitemap`, `publish-wiki`\n   - Delivery: `deploy-helm`, `deploy-argocd`, `gitops`, `app-of-apps`\n   - Project flow: `workflow-trunkbased`, `workflow-gitflow`\n4. Validate locally before pushing:\n   - `glab ci lint .gitlab-ci.yml`\n   - Lint any included template files when supported by the project.\n   - Run the narrowest local test for scripts or generated configuration.\n\n## Pipeline Design\n\n- Keep root pipelines component-driven. Add handwritten jobs only when no component exists or a project-specific integration is unavoidable.\n- Use `$CI_SERVER_FQDN/xrow-public/ci-tools/<component>@main` for component includes when package registry or fully-qualified host behavior matters; otherwise match the existing project style.\n- Put component `inputs` next to the include and keep names stable across related jobs.\n- Prefer continuous delivery defaults. Do not create automatic production deployment unless the project already does that or the issue explicitly asks for it.\n- Keep validation jobs independent of deployment jobs so a project can fail fast before writing to registries, clusters, or external systems.\n- Use `needs` and `dependencies` only when a real artifact or ordering relationship exists.\n- Never use `allow_failure: true`, `when: manual`, `rules: when: never`, or skipped tests to hide a broken required pipeline. Use them only when the job is genuinely optional, documented, or intentionally gated.\n\n## Component Selection Heuristics\n\n### Repository Bootstrap\n\nUse these components for most repositories:\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/common@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/label@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/pre-commit@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/trivy@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/workflow@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/semantic-release@main\n```\n\nUse `label` early when the project needs standard `priority::*`, `size::*`, `type::*`, and `workflow::*` labels for automation.\n\n### Containers\n\nUse `container` for normal application images and `buildah` when the project needs direct image build control.\nSet `name` and `path` explicitly when the repository has multiple build roots.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/container@main\n    inputs:\n      name: app\n      path: container/app\n```\n\n### Helm Charts\n\nUse `helm` for chart build/test/publish flows and add `helm-docs` when chart documentation must be generated.\nSet `test-enabled: false` only when there is no safe cluster-backed test path.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/helm@main\n    inputs:\n      name: chart\n      path: chart\n```\n\n### Review Testing\n\nKeep review environments close to production while making destructive checks explicit and temporary.\nFor Helm review tests, validate install, upgrade, readiness, ingress, cleanup, and storage behavior through chart values instead of ad hoc shell overrides.\nDocument any review-only threshold or fixture in the MR so reviewers can see why it differs from production defaults.\n\n### Documentation\n\nUse `docusaurus` for docs sites and pair it with `publish-sitemap` when the project publishes public pages.\nPass `name` and `path` explicitly.\n\n### Infrastructure and GitOps\n\nUse `lint-ansible`, `ansible-collection`, `ansible-ee`, `ansible-runner`, `lint-tofu`, `tofu-module`, `gitops`, `deploy-argocd`, and `app-of-apps` according to the repository type.\nKeep plan, build, and deploy stages separate unless the catalog component documents a tighter flow.\n\n## Validation Workflow\n\n1. Fetch the live component page and verify the input names before editing:\n\n   ```bash\n   curl -fsSL https://ci-tools.xrow.de/Components/<component> | sed -n '1,220p'\n   ```\n\n2. Lint the pipeline:\n\n   ```bash\n   glab ci lint .gitlab-ci.yml\n   ```\n\n3. For merge requests, push with CI skipped first, then start an MR pipeline through GitLab Agent rules:\n\n   ```bash\n   git push origin <branch> -o ci.skip\n   glab ci run --mr\n   ```\n\n4. If CI fails, inspect the failed job trace and fix the underlying problem. If the failure comes from the catalog or main branch, open or link the dependency and mark the MR blocked rather than weakening the pipeline.\n\n## Review Checklist\n\n- The pipeline uses CI Tools components where available.\n- Component inputs match the live catalog documentation.\n- Protected branch behavior is respected.\n- Required checks are not hidden behind skips or `allow_failure`.\n- Registry, cluster, and deploy writes are gated by existing project rules.\n- The MR description lists the plan, acceptance criteria, and validation commands.\n\nFile v1.105.1:_meta.json\n\n{\n  \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n  \"slug\": \"xrowgmbh-ci-tools-pipeline\",\n  \"version\": \"1.105.1\",\n  \"publishedAt\": 1791311643960\n}\n\nFile v1.105.1:skill-card.md\n\n## Description:\n\nHelps developers build and maintain GitLab CI/CD pipelines using the CI Tools Components Catalog.\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 engineers use this skill to create or repair GitLab CI/CD configuration, select catalog components, validate their inputs, and plan delivery pipelines.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated pipeline changes may alter deployment rules or publish artifacts.\n\nMitigation: Review .gitlab-ci.yml changes and existing deployment gates before merging.\n\nRisk: Pushing branches or running merge-request pipelines may trigger external CI actions.\n\nMitigation: Confirm the intended branch and pipeline actions before executing them.\n\n## Reference(s):\n\n- [CI Tools Components Catalog](https://ci-tools.xrow.de/Components/)\n- [CI Tools Catalog](https://ci-tools.xrow.de/)\n- [CI Tools component source](https://gitlab.com/xrow-public/ci-tools)\n\n## Skill Output:\n\n**Output Type(s):** [Configuration instructions, Code, Shell commands, Guidance]\n\n**Output Format:** [Markdown guidance and GitLab CI YAML]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Component selection and validation guidance for GitLab CI/CD pipelines.]\n\n## Skill Version(s):\n\n1.105.1 (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.105.0: 3 files, 4029 bytes\n\nFiles: skill-card.md (1821b), SKILL.md (6266b), _meta.json (147b)\n\nFile v1.105.0:SKILL.md\n\n---\nname: ci-tools-pipeline\ndescription: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps.\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"curl\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# CI Tools Pipeline Skill\n\nUse this skill to build proper GitLab CI/CD pipelines from the CI Tools Components Catalog.\nPrefer catalog components over custom jobs when a component exists for the job type.\n\n## Quick Start\n\n1. Read the project `AGENTS.md` first, then inspect the repository layout, current `.gitlab-ci.yml`, and existing pipeline failures.\n2. Open the live catalog before choosing components:\n   - Catalog: `https://ci-tools.xrow.de/`\n   - Components index: `https://ci-tools.xrow.de/Components/`\n   - Source: `https://gitlab.com/xrow-public/ci-tools`\n3. Select the smallest component set that covers the project:\n   - Baseline: `common`, `workflow`, `semantic-release`\n   - Hygiene: `label`, `pre-commit`, `spellcheck`, `trivy`\n   - Languages and test runners: `bash-unit-tests`, `lint-javascript`, `lint-json`, `lint-yaml`, `lint-markdown`, `lint-ansible`, `lint-helm`, `lint-tofu`\n   - Build and package: `container`, `buildah`, `helm`, `helm-docs`, `package`, `package-skill`, `oras-push`\n   - Docs and sites: `docusaurus`, `publish-sitemap`, `publish-wiki`\n   - Delivery: `deploy-helm`, `deploy-argocd`, `gitops`, `app-of-apps`\n   - Project flow: `workflow-trunkbased`, `workflow-gitflow`\n4. Validate locally before pushing:\n   - `glab ci lint .gitlab-ci.yml`\n   - Lint any included template files when supported by the project.\n   - Run the narrowest local test for scripts or generated configuration.\n\n## Pipeline Design\n\n- Keep root pipelines component-driven. Add handwritten jobs only when no component exists or a project-specific integration is unavoidable.\n- Use `$CI_SERVER_FQDN/xrow-public/ci-tools/<component>@main` for component includes when package registry or fully-qualified host behavior matters; otherwise match the existing project style.\n- Put component `inputs` next to the include and keep names stable across related jobs.\n- Prefer continuous delivery defaults. Do not create automatic production deployment unless the project already does that or the issue explicitly asks for it.\n- Keep validation jobs independent of deployment jobs so a project can fail fast before writing to registries, clusters, or external systems.\n- Use `needs` and `dependencies` only when a real artifact or ordering relationship exists.\n- Never use `allow_failure: true`, `when: manual`, `rules: when: never`, or skipped tests to hide a broken required pipeline. Use them only when the job is genuinely optional, documented, or intentionally gated.\n\n## Component Selection Heuristics\n\n### Repository Bootstrap\n\nUse these components for most repositories:\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/common@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/label@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/pre-commit@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/trivy@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/workflow@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/semantic-release@main\n```\n\nUse `label` early when the project needs standard `priority::*`, `size::*`, `type::*`, and `workflow::*` labels for automation.\n\n### Containers\n\nUse `container` for normal application images and `buildah` when the project needs direct image build control.\nSet `name` and `path` explicitly when the repository has multiple build roots.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/container@main\n    inputs:\n      name: app\n      path: container/app\n```\n\n### Helm Charts\n\nUse `helm` for chart build/test/publish flows and add `helm-docs` when chart documentation must be generated.\nSet `test-enabled: false` only when there is no safe cluster-backed test path.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/helm@main\n    inputs:\n      name: chart\n      path: chart\n```\n\n### Review Testing\n\nKeep review environments close to production while making destructive checks explicit and temporary.\nFor Helm review tests, validate install, upgrade, readiness, ingress, cleanup, and storage behavior through chart values instead of ad hoc shell overrides.\nDocument any review-only threshold or fixture in the MR so reviewers can see why it differs from production defaults.\n\n### Documentation\n\nUse `docusaurus` for docs sites and pair it with `publish-sitemap` when the project publishes public pages.\nPass `name` and `path` explicitly.\n\n### Infrastructure and GitOps\n\nUse `lint-ansible`, `ansible-collection`, `ansible-ee`, `ansible-runner`, `lint-tofu`, `tofu-module`, `gitops`, `deploy-argocd`, and `app-of-apps` according to the repository type.\nKeep plan, build, and deploy stages separate unless the catalog component documents a tighter flow.\n\n## Validation Workflow\n\n1. Fetch the live component page and verify the input names before editing:\n\n   ```bash\n   curl -fsSL https://ci-tools.xrow.de/Components/<component> | sed -n '1,220p'\n   ```\n\n2. Lint the pipeline:\n\n   ```bash\n   glab ci lint .gitlab-ci.yml\n   ```\n\n3. For merge requests, push with CI skipped first, then start an MR pipeline through GitLab Agent rules:\n\n   ```bash\n   git push origin <branch> -o ci.skip\n   glab ci run --mr\n   ```\n\n4. If CI fails, inspect the failed job trace and fix the underlying problem. If the failure comes from the catalog or main branch, open or link the dependency and mark the MR blocked rather than weakening the pipeline.\n\n## Review Checklist\n\n- The pipeline uses CI Tools components where available.\n- Component inputs match the live catalog documentation.\n- Protected branch behavior is respected.\n- Required checks are not hidden behind skips or `allow_failure`.\n- Registry, cluster, and deploy writes are gated by existing project rules.\n- The MR description lists the plan, acceptance criteria, and validation commands.\n\nFile v1.105.0:_meta.json\n\n{\n  \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n  \"slug\": \"xrowgmbh-ci-tools-pipeline\",\n  \"version\": \"1.105.0\",\n  \"publishedAt\": 1791304194896\n}\n\nFile v1.105.0:skill-card.md\n\n## Description:\n\nBuild and maintain GitLab CI/CD pipelines using the CI Tools Components Catalog.\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 engineers use this skill to create, repair, and validate component-based GitLab pipelines for builds, tests, packaging, documentation, infrastructure, and delivery.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The workflow can push branches and start merge-request pipelines without an explicit approval checkpoint.\n\nMitigation: Before each push or pipeline run, show the target remote, branch, outgoing commits, and pipeline command; require separate approval for pushing and starting CI.\n\nRisk: Consulting the live component catalog accesses an external site.\n\nMitigation: Request separate approval before fetching catalog pages.\n\n## Reference(s):\n\n- [CI Tools Components Catalog](https://ci-tools.xrow.de/Components/)\n- [CI Tools documentation](https://ci-tools.xrow.de/)\n- [CI Tools component source](https://gitlab.com/xrow-public/ci-tools)\n\n## Skill Output:\n\n**Output Type(s):** [Configuration instructions, Shell commands, Guidance]\n\n**Output Format:** [Markdown with GitLab CI YAML and shell snippets]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May include component selections, pipeline validation steps, and merge-request guidance.]\n\n## Skill Version(s):\n\n1.105.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.104.0: 3 files, 4009 bytes\n\nFiles: skill-card.md (1833b), SKILL.md (6266b), _meta.json (147b)\n\nFile v1.104.0:SKILL.md\n\n---\nname: ci-tools-pipeline\ndescription: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps.\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"curl\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# CI Tools Pipeline Skill\n\nUse this skill to build proper GitLab CI/CD pipelines from the CI Tools Components Catalog.\nPrefer catalog components over custom jobs when a component exists for the job type.\n\n## Quick Start\n\n1. Read the project `AGENTS.md` first, then inspect the repository layout, current `.gitlab-ci.yml`, and existing pipeline failures.\n2. Open the live catalog before choosing components:\n   - Catalog: `https://ci-tools.xrow.de/`\n   - Components index: `https://ci-tools.xrow.de/Components/`\n   - Source: `https://gitlab.com/xrow-public/ci-tools`\n3. Select the smallest component set that covers the project:\n   - Baseline: `common`, `workflow`, `semantic-release`\n   - Hygiene: `label`, `pre-commit`, `spellcheck`, `trivy`\n   - Languages and test runners: `bash-unit-tests`, `lint-javascript`, `lint-json`, `lint-yaml`, `lint-markdown`, `lint-ansible`, `lint-helm`, `lint-tofu`\n   - Build and package: `container`, `buildah`, `helm`, `helm-docs`, `package`, `package-skill`, `oras-push`\n   - Docs and sites: `docusaurus`, `publish-sitemap`, `publish-wiki`\n   - Delivery: `deploy-helm`, `deploy-argocd`, `gitops`, `app-of-apps`\n   - Project flow: `workflow-trunkbased`, `workflow-gitflow`\n4. Validate locally before pushing:\n   - `glab ci lint .gitlab-ci.yml`\n   - Lint any included template files when supported by the project.\n   - Run the narrowest local test for scripts or generated configuration.\n\n## Pipeline Design\n\n- Keep root pipelines component-driven. Add handwritten jobs only when no component exists or a project-specific integration is unavoidable.\n- Use `$CI_SERVER_FQDN/xrow-public/ci-tools/<component>@main` for component includes when package registry or fully-qualified host behavior matters; otherwise match the existing project style.\n- Put component `inputs` next to the include and keep names stable across related jobs.\n- Prefer continuous delivery defaults. Do not create automatic production deployment unless the project already does that or the issue explicitly asks for it.\n- Keep validation jobs independent of deployment jobs so a project can fail fast before writing to registries, clusters, or external systems.\n- Use `needs` and `dependencies` only when a real artifact or ordering relationship exists.\n- Never use `allow_failure: true`, `when: manual`, `rules: when: never`, or skipped tests to hide a broken required pipeline. Use them only when the job is genuinely optional, documented, or intentionally gated.\n\n## Component Selection Heuristics\n\n### Repository Bootstrap\n\nUse these components for most repositories:\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/common@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/label@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/pre-commit@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/trivy@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/workflow@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/semantic-release@main\n```\n\nUse `label` early when the project needs standard `priority::*`, `size::*`, `type::*`, and `workflow::*` labels for automation.\n\n### Containers\n\nUse `container` for normal application images and `buildah` when the project needs direct image build control.\nSet `name` and `path` explicitly when the repository has multiple build roots.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/container@main\n    inputs:\n      name: app\n      path: container/app\n```\n\n### Helm Charts\n\nUse `helm` for chart build/test/publish flows and add `helm-docs` when chart documentation must be generated.\nSet `test-enabled: false` only when there is no safe cluster-backed test path.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/helm@main\n    inputs:\n      name: chart\n      path: chart\n```\n\n### Review Testing\n\nKeep review environments close to production while making destructive checks explicit and temporary.\nFor Helm review tests, validate install, upgrade, readiness, ingress, cleanup, and storage behavior through chart values instead of ad hoc shell overrides.\nDocument any review-only threshold or fixture in the MR so reviewers can see why it differs from production defaults.\n\n### Documentation\n\nUse `docusaurus` for docs sites and pair it with `publish-sitemap` when the project publishes public pages.\nPass `name` and `path` explicitly.\n\n### Infrastructure and GitOps\n\nUse `lint-ansible`, `ansible-collection`, `ansible-ee`, `ansible-runner`, `lint-tofu`, `tofu-module`, `gitops`, `deploy-argocd`, and `app-of-apps` according to the repository type.\nKeep plan, build, and deploy stages separate unless the catalog component documents a tighter flow.\n\n## Validation Workflow\n\n1. Fetch the live component page and verify the input names before editing:\n\n   ```bash\n   curl -fsSL https://ci-tools.xrow.de/Components/<component> | sed -n '1,220p'\n   ```\n\n2. Lint the pipeline:\n\n   ```bash\n   glab ci lint .gitlab-ci.yml\n   ```\n\n3. For merge requests, push with CI skipped first, then start an MR pipeline through GitLab Agent rules:\n\n   ```bash\n   git push origin <branch> -o ci.skip\n   glab ci run --mr\n   ```\n\n4. If CI fails, inspect the failed job trace and fix the underlying problem. If the failure comes from the catalog or main branch, open or link the dependency and mark the MR blocked rather than weakening the pipeline.\n\n## Review Checklist\n\n- The pipeline uses CI Tools components where available.\n- Component inputs match the live catalog documentation.\n- Protected branch behavior is respected.\n- Required checks are not hidden behind skips or `allow_failure`.\n- Registry, cluster, and deploy writes are gated by existing project rules.\n- The MR description lists the plan, acceptance criteria, and validation commands.\n\nFile v1.104.0:_meta.json\n\n{\n  \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n  \"slug\": \"xrowgmbh-ci-tools-pipeline\",\n  \"version\": \"1.104.0\",\n  \"publishedAt\": 1791300471471\n}\n\nFile v1.104.0:skill-card.md\n\n## Description:\n\nBuilds and maintains GitLab CI/CD pipelines using the CI Tools Components Catalog.\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 CI engineers use this skill to create, troubleshoot, and validate GitLab pipelines for application builds, tests, packaging, and delivery using CI Tools components.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Pipeline changes can run with repository and GitLab token access.\n\nMitigation: Grant only necessary repository and token access; review generated pipeline changes before pushing or running an MR pipeline.\n\nRisk: External component includes pinned to @main may change between pipeline runs.\n\nMitigation: Review the external components and their inputs before running pipelines; pin reviewed versions where appropriate.\n\n## Reference(s):\n\n- [CI Tools Components Catalog](https://ci-tools.xrow.de/Components/)\n- [CI Tools source repository](https://gitlab.com/xrow-public/ci-tools)\n- [ClawHub skill release](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-ci-tools-pipeline)\n\n## Skill Output:\n\n**Output Type(s):** [Configuration, Shell commands, Guidance]\n\n**Output Format:** [GitLab CI YAML and Markdown guidance with shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Can propose or edit .gitlab-ci.yml and related pipeline configuration.]\n\n## Skill Version(s):\n\n1.104.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.103.0: 3 files, 4009 bytes\n\nFiles: skill-card.md (1796b), SKILL.md (6266b), _meta.json (147b)\n\nFile v1.103.0:SKILL.md\n\n---\nname: ci-tools-pipeline\ndescription: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps.\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"curl\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# CI Tools Pipeline Skill\n\nUse this skill to build proper GitLab CI/CD pipelines from the CI Tools Components Catalog.\nPrefer catalog components over custom jobs when a component exists for the job type.\n\n## Quick Start\n\n1. Read the project `AGENTS.md` first, then inspect the repository layout, current `.gitlab-ci.yml`, and existing pipeline failures.\n2. Open the live catalog before choosing components:\n   - Catalog: `https://ci-tools.xrow.de/`\n   - Components index: `https://ci-tools.xrow.de/Components/`\n   - Source: `https://gitlab.com/xrow-public/ci-tools`\n3. Select the smallest component set that covers the project:\n   - Baseline: `common`, `workflow`, `semantic-release`\n   - Hygiene: `label`, `pre-commit`, `spellcheck`, `trivy`\n   - Languages and test runners: `bash-unit-tests`, `lint-javascript`, `lint-json`, `lint-yaml`, `lint-markdown`, `lint-ansible`, `lint-helm`, `lint-tofu`\n   - Build and package: `container`, `buildah`, `helm`, `helm-docs`, `package`, `package-skill`, `oras-push`\n   - Docs and sites: `docusaurus`, `publish-sitemap`, `publish-wiki`\n   - Delivery: `deploy-helm`, `deploy-argocd`, `gitops`, `app-of-apps`\n   - Project flow: `workflow-trunkbased`, `workflow-gitflow`\n4. Validate locally before pushing:\n   - `glab ci lint .gitlab-ci.yml`\n   - Lint any included template files when supported by the project.\n   - Run the narrowest local test for scripts or generated configuration.\n\n## Pipeline Design\n\n- Keep root pipelines component-driven. Add handwritten jobs only when no component exists or a project-specific integration is unavoidable.\n- Use `$CI_SERVER_FQDN/xrow-public/ci-tools/<component>@main` for component includes when package registry or fully-qualified host behavior matters; otherwise match the existing project style.\n- Put component `inputs` next to the include and keep names stable across related jobs.\n- Prefer continuous delivery defaults. Do not create automatic production deployment unless the project already does that or the issue explicitly asks for it.\n- Keep validation jobs independent of deployment jobs so a project can fail fast before writing to registries, clusters, or external systems.\n- Use `needs` and `dependencies` only when a real artifact or ordering relationship exists.\n- Never use `allow_failure: true`, `when: manual`, `rules: when: never`, or skipped tests to hide a broken required pipeline. Use them only when the job is genuinely optional, documented, or intentionally gated.\n\n## Component Selection Heuristics\n\n### Repository Bootstrap\n\nUse these components for most repositories:\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/common@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/label@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/pre-commit@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/trivy@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/workflow@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/semantic-release@main\n```\n\nUse `label` early when the project needs standard `priority::*`, `size::*`, `type::*`, and `workflow::*` labels for automation.\n\n### Containers\n\nUse `container` for normal application images and `buildah` when the project needs direct image build control.\nSet `name` and `path` explicitly when the repository has multiple build roots.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/container@main\n    inputs:\n      name: app\n      path: container/app\n```\n\n### Helm Charts\n\nUse `helm` for chart build/test/publish flows and add `helm-docs` when chart documentation must be generated.\nSet `test-enabled: false` only when there is no safe cluster-backed test path.\n\n```yaml\ninclude:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/helm@main\n    inputs:\n      name: chart\n      path: chart\n```\n\n### Review Testing\n\nKeep review environments close to production while making destructive checks explicit and temporary.\nFor Helm review tests, validate install, upgrade, readiness, ingress, cleanup, and storage behavior through chart values instead of ad hoc shell overrides.\nDocument any review-only threshold or fixture in the MR so reviewers can see why it differs from production defaults.\n\n### Documentation\n\nUse `docusaurus` for docs sites and pair it with `publish-sitemap` when the project publishes public pages.\nPass `name` and `path` explicitly.\n\n### Infrastructure and GitOps\n\nUse `lint-ansible`, `ansible-collection`, `ansible-ee`, `ansible-runner`, `lint-tofu`, `tofu-module`, `gitops`, `deploy-argocd`, and `app-of-apps` according to the repository type.\nKeep plan, build, and deploy stages separate unless the catalog component documents a tighter flow.\n\n## Validation Workflow\n\n1. Fetch the live component page and verify the input names before editing:\n\n   ```bash\n   curl -fsSL https://ci-tools.xrow.de/Components/<component> | sed -n '1,220p'\n   ```\n\n2. Lint the pipeline:\n\n   ```bash\n   glab ci lint .gitlab-ci.yml\n   ```\n\n3. For merge requests, push with CI skipped first, then start an MR pipeline through GitLab Agent rules:\n\n   ```bash\n   git push origin <branch> -o ci.skip\n   glab ci run --mr\n   ```\n\n4. If CI fails, inspect the failed job trace and fix the underlying problem. If the failure comes from the catalog or main branch, open or link the dependency and mark the MR blocked rather than weakening the pipeline.\n\n## Review Checklist\n\n- The pipeline uses CI Tools components where available.\n- Component inputs match the live catalog documentation.\n- Protected branch behavior is respected.\n- Required checks are not hidden behind skips or `allow_failure`.\n- Registry, cluster, and deploy writes are gated by existing project rules.\n- The MR description lists the plan, acceptance criteria, and validation commands.\n\nFile v1.103.0:_meta.json\n\n{\n  \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n  \"slug\": \"xrowgmbh-ci-tools-pipeline\",\n  \"version\": \"1.103.0\",\n  \"publishedAt\": 1791298492299\n}\n\nFile v1.103.0:skill-card.md\n\n## Description:\n\nBuilds and maintains GitLab CI/CD pipelines using the CI Tools Components Catalog.\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 CI engineers use this skill to create, repair, and validate GitLab pipelines with CI Tools components for testing, packaging, and delivery.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Authenticated GitLab commands can push branches and trigger merge request pipelines.\n\nMitigation: Review proposed commands and confirm GitLab token access before allowing authenticated actions.\n\nRisk: External CI components referenced at @main can change without a pipeline edit.\n\nMitigation: Review component definitions and consider pinning versions for production-sensitive repositories.\n\n## Reference(s):\n\n- [CI Tools Components Catalog](https://ci-tools.xrow.de/Components/)\n- [CI Tools source](https://gitlab.com/xrow-public/ci-tools)\n- [ClawHub skill release](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-ci-tools-pipeline)\n\n## Skill Output:\n\n**Output Type(s):** [Configuration instructions, Code, Shell commands, Guidance]\n\n**Output Format:** [GitLab CI YAML and Markdown guidance with shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Requires glab, curl, jq, and a GitLab token for authenticated GitLab actions.]\n\n## Skill Version(s):\n\n1.103.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.","readmeExcerpt":"Skill: CI Tools Pipeline Owner: xrowgmbh Summary: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps. Tags: latest:1.108.1 V","codeSnippets":[],"executableExamples":[{"language":"yaml","snippet":"include:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/common@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/label@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/pre-commit@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/trivy@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/workflow@main\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/semantic-release@main"},{"language":"yaml","snippet":"include:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/container@main\n    inputs:\n      name: app\n      path: container/app"},{"language":"yaml","snippet":"include:\n  - component: $CI_SERVER_HOST/xrow-public/ci-tools/helm@main\n    inputs:\n      name: chart\n      path: chart"},{"language":"bash","snippet":"curl -fsSL https://ci-tools.xrow.de/Components/<component> | sed -n '1,220p'"},{"language":"bash","snippet":"curl -fsSL https://ci-tools.xrow.de/Components/<component> | sed -n '1,220p'"},{"language":"bash","snippet":"glab ci lint .gitlab-ci.yml"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: ci-tools-pipeline\ndescription: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps.\nmetadata: { \"openclaw\": { \"requires\": { \"bins\": [\"glab\", \"curl\", \"jq\"] }, \"primaryEnv\": \"GITLAB_TOKEN\" } }\n---\n# CI Tools Pipeline Skill\n\nUse this skill to build proper GitLab CI/CD pipelines from the CI Tools Components Catalog.\nPrefer catalog components over custom jobs when a component exists for the job type.\n\n## Quick Start\n\n1. Read the project `AGENTS.md` first, then inspect the repository layout, current `.gitlab-ci.yml`, and existing pipeline failures.\n2. Open the live catalog before choosing components:\n   - Catalog: `https://ci-tools.xrow.de/`\n   - Components index: `https://ci-tools.xrow.de/Components/`\n   - Source: `https://gitlab.com/xrow-public/ci-tools`\n3. Select the smallest component set that covers the project:\n   - Baseline: `common`, `workflow`, `semantic-release`\n   - Hygiene: `label`, `pre-commit`, `spellcheck`, `trivy`\n   - Languages and test runners: `bash-unit-tests`, `lint-javascript`, `lint-json`, `lint-yaml`, `lint-markdown`, `lint-ansible`, `lint-helm`, `lint-tofu`\n   - Build and package: `container`, `buildah`, `helm`, `helm-docs`, `package`, `package-skill`, `oras-push`\n   - Docs and sites: `docusaurus`, `publish-sitemap`, `publish-wiki`\n   - Delivery: `deploy-helm`, `deploy-argocd`, `gitops`, `app-of-apps`\n   - Project flow: `workflow-trunkbased`, `workflow-gitflow`\n4. Validate locally before pushing:\n   - `glab ci lint .gitlab-ci.yml`\n   - Lint any included template files when supported by the project.\n   - Run the narrowest local test for scripts or generated configuration.\n\n## Pipeline Design\n\n- Keep root pipelines component-driven. Add handwritten jobs only when no component exists or a project-specific integration is unavoidable.\n- Use `$CI_SERVER_FQDN/xrow-public/ci-tools/<component>@main` for component includes when package registry or fully-qualified host behavior matters; otherwise match the existing project style.\n- Put component `inputs` next to the include and keep names stable across related jobs.\n- Prefer continuous delivery defaults. Do not create automatic production deployment unless the project already does that or the issue explicitly asks for it.\n- Keep validation jobs independent of deployment jobs so a project can fail fast before writing to registries, clusters, or external systems.\n- Use `needs` and `dependencies` only when a real artifact or ordering relationship exists.\n- Never use `allow_failure: true`, `when: manual`, `rules: when: never`, or skipped tests to hide a broken required pipeline. Use them only when the job is genuinely optional, documented, or intentionally gated.\n\n## Component Selection Heuris"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7frykp2tnj00b0czk5f4r505809an4\",\n  \"slug\": \"xrowgmbh-ci-tools-pipeline\",\n  \"version\": \"1.108.1\",\n  \"publishedAt\": 1791497294521\n}"},{"path":"skill-card.md","content":"## Description:\n\nHelps developers build and maintain GitLab CI/CD pipelines using the CI Tools Components Catalog.\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 engineers use this skill to create, repair, and validate GitLab CI/CD pipelines for application builds, testing, packaging, documentation, and delivery.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Pushing a branch with CI skipped or starting a merge-request pipeline changes remote GitLab state and may trigger jobs or deployments.\n\nMitigation: Confirm the project, target branch, and pipeline rules before pushing or starting CI; retain existing deployment gates.\n\nRisk: Incorrect or changed catalog component inputs can break a required pipeline.\n\nMitigation: Check the live component documentation and lint the pipeline before pushing; investigate failures instead of suppressing required checks.\n\n## Reference(s):\n\n- [CI Tools Components Catalog](https://ci-tools.xrow.de/Components/)\n- [CI Tools project](https://gitlab.com/xrow-public/ci-tools)\n- [CI Tools Pipeline skill release](https://clawhub.ai/xrowgmbh/skills/xrowgmbh-ci-tools-pipeline)\n\n## Skill Output:\n\n**Output Type(s):** [Configuration instructions, Code, Shell commands, Guidance]\n\n**Output Format:** [Markdown with GitLab CI YAML and shell commands]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Pipeline recommendations should be validated against the live component catalog and linted before use.]\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":"Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps. Skill: CI Tools Pipeline Owner: xrowgmbh Summary: Build and maintain GitLab CI/CD pipelines with the CI Tools Components Catalog at ci-tools.xrow.de. Use when creating or fixing .gitlab-ci.yml files, choosing CI Tools components, validating component inputs, or designing continuous delivery pipelines for applications, Helm charts, containers, packages, documentation, infrastructure, and GitOps. Tags: latest:1.108.1 V","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1234,"uniquenessScore":46,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T06:29:50.295Z","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-09T06:29:50.295Z","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-10T04:45:10.540Z","emptyReason":null},"items":[{"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-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"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":"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"}]}}}