agentsclimarketplace

Embed ci setup

Skill addxai/enterprise-harness-engineering/skills/embed-ci-setup

Quickly create a CI Pipeline for embedded repositories (SonarQube incremental C-language scanning). Triggers when the user says "add a Pipeline to this repo", "create CI configuration", "integrate SonarQube", "embedded project needs a Pipeline", or when a repo has no .gitlab-ci.yml and cannot merge MRs.From its SKILL.md

Install
npx -y skills add addxai/enterprise-harness-engineering --skill embed-ci-setup

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • reads credentialsReads from 1 credential source: `SONAR_USER_TOKEN`.
  • runs commandsInstructs the agent to run 3 commands, including `ls .gitlab-ci.yml 2>/dev/null` and 2 more.

SKILL.md

9.4 KB, ~2.3k tokens by cl100k_base, as published. Nobody here has run it

embed-ci-setup

Quickly create a GitLab CI Pipeline for embedded (C language) repositories with SonarQube incremental code scanning.

Description

Embedded team rule: Repositories without a Pipeline cannot merge MRs. This Skill helps embedded engineers create a standard CI Pipeline for their repository within minutes, including:

  • MR-triggered SonarQube incremental scanning (scans only .c / .h files changed in this MR)
  • Quality Gate check (shows a warning on failure, does not block the MR)
  • Dynamically generated sonar-project.properties (project key auto-generated from the repository path)

Applicable scenarios:

  • Embedded repository has no Pipeline and needs one quickly
  • Existing .gitlab-ci.yml repository needs SonarQube scanning added
  • All embedded projects primarily using C language

Not applicable:

  • Non-C language projects (Go, Python, Java, etc. should use the global SonarQube template)
  • CI workflows requiring compilation builds (this Skill only does source-code static scanning)

Rules

Rule 1 — Environment Constraints (must understand)

All embedded repositories run CI on the company's unified GitLab platform, with these constraints:

ConstraintDescription
CI entry pointManaged by your-org/ci-templates's entrypoint.yml, which auto-includes the business repository's .gitlab-ci.yml
Custom stages prohibitedDo not declare stages: in .gitlab-ci.yml; use GitLab default stages. Custom stages that do not include test will cause pipeline creation failures
include methodMust use include: project rather than include: local, because the CI entry point is in an external repository and local resolves to the wrong repository
Runner tagUse sonar-scanner
Docker imageMust specify image: harbor.example.com/tools/embed-quality:v1.2.0; runner uses Kubernetes executor
SonarQube tokenInjected via GitLab CI/CD Variable SONAR_USER_TOKEN; project admin must configure in advance
SonarQube serverhttps://sonarqube.example.com
No heredoc in YAMLDo not use <<EOF ... EOF within script: | blocks — it causes YAML parsing errors; use echo line by line instead

Rule 2 — Execution Flow

After receiving the user's request, execute the following steps:

Step 1: Check current repository status

# check if .gitlab-ci.yml exists
ls .gitlab-ci.yml 2>/dev/null

# check if ci/ directory exists
ls ci/sonar-analysis-embed.yml 2>/dev/null

# check if .gitignore has sonar-project.properties
grep "sonar-project.properties" .gitignore 2>/dev/null

Step 2: Decide action based on check results

.gitlab-ci.ymlci/sonar-analysis-embed.ymlAction
Does not existDoes not existCreate both files (Rule 3 + Rule 4)
ExistsDoes not existOnly create ci/sonar-analysis-embed.yml (Rule 4), add include to .gitlab-ci.yml (Rule 5)
ExistsExistsVerify configuration is correct; no action needed

Step 3: Update .gitignore

If .gitignore does not contain /sonar-project.properties, add it.

Step 4: Prompt user to check GitLab CI/CD Variables

Inform the user to confirm that SONAR_USER_TOKEN is configured in the project's GitLab Settings → CI/CD → Variables.

Rule 3 — Generate .gitlab-ci.yml (when no existing file)

When the repository has no .gitlab-ci.yml, generate the following content:

include:
  - project: $CI_PROJECT_PATH
    ref: $CI_COMMIT_REF_NAME
    file: ci/sonar-analysis-embed.yml

default:
  tags:
    - sonar-scanner

pass:
  stage: test
  script:
    - echo "CI pass"

Key points:

  • Do not declare stages:; use GitLab defaults
  • The pass job uses stage: test to ensure the pipeline has a runnable job in non-MR scenarios
  • include uses project: $CI_PROJECT_PATH + ref: $CI_COMMIT_REF_NAME

Rule 4 — Generate ci/sonar-analysis-embed.yml

Create the ci/ directory and generate the following file:

# ============================================================================
# SonarQube Incremental Analysis Job
# Triggered on Merge Request events, scans only changed C files (.c/.h)
#
# Requires: SONAR_USER_TOKEN configured in GitLab CI/CD Variables
# ============================================================================

sonar-analysis:
  stage: test
  tags:
    - sonar-scanner
  image: harbor.example.com/tools/embed-quality:v1.2.0
  variables:
    GIT_DEPTH: "0"
    GIT_STRATEGY: fetch
    SONAR_AUTH_TOKEN: "${SONAR_USER_TOKEN}"
  before_script:
    - git config --global --add safe.directory "${CI_PROJECT_DIR}"
  script:
    - |
      echo "======================================"
      echo "SonarQube Incremental Analysis"
      echo "  Source: ${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME}"
      echo "  Target: ${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}"
      echo "======================================"

      # Step 1: collect changed C files (.c/.h), exclude deleted files
      TARGET_BRANCH="origin/${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}"
      SOURCE_BRANCH="origin/${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME}"
      CHANGED_FILES=$(git diff --name-only --diff-filter=d "${TARGET_BRANCH}...${SOURCE_BRANCH}" -- '*.c' '*.h' | paste -sd ',' -)

      if [ -z "${CHANGED_FILES}" ]; then
        echo "No C files (.c/.h) changed in this MR, skipping SonarQube analysis."
        exit 0
      fi

      echo "Changed C files:"
      echo "${CHANGED_FILES}" | tr ',' '\n' | sed 's/^/  - /'

      # Step 2: generate project key from CI_PROJECT_PATH
      # e.g. rockchip_rk3576/buildroot -> rockchip_rk3576-buildroot
      PROJECT_KEY=$(echo "${CI_PROJECT_PATH}" | tr '/' '-')
      echo "Project Key: ${PROJECT_KEY}"

      # Step 3: generate sonar-project.properties
      PROPS="${CI_PROJECT_DIR}/sonar-project.properties"
      {
        echo "sonar.projectKey=${PROJECT_KEY}"
        echo "sonar.projectName=${PROJECT_KEY}"
        echo "sonar.projectVersion=1.0"
        echo "sonar.sources=."
        echo "sonar.sourceEncoding=UTF-8"
        echo "sonar.language=c"
        echo "sonar.inclusions=${CHANGED_FILES}"
        echo "sonar.scm.provider=git"
        echo "sonar.host.url=https://sonarqube.example.com"
      } > "${PROPS}"

      echo "======================================"
      echo "Generated sonar-project.properties:"
      cat "${CI_PROJECT_DIR}/sonar-project.properties"
      echo "======================================"

      # Step 4: run sonar-scanner with quality gate check
      sonar-scanner -Dsonar.token="${SONAR_AUTH_TOKEN}" -Dsonar.qualitygate.wait=true
  allow_failure: true
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Rule 5 — Add include to existing .gitlab-ci.yml

When the repository already has a .gitlab-ci.yml, add the include configuration at the top of the file.

Check items:

  1. If there is already an include: section, append one entry:
include:
  # ... existing includes ...
  - project: $CI_PROJECT_PATH
    ref: $CI_COMMIT_REF_NAME
    file: ci/sonar-analysis-embed.yml
  1. If there is no include: section, add at the very top of the file:
include:
  - project: $CI_PROJECT_PATH
    ref: $CI_COMMIT_REF_NAME
    file: ci/sonar-analysis-embed.yml
  1. Do not modify existing stages:, default:, other jobs, or any other configuration

Rule 6 — Notify User After Completion

After generating files, output the following information:

Files generated:
  - .gitlab-ci.yml (created / include updated)
  - ci/sonar-analysis-embed.yml
  - .gitignore (sonar-project.properties added)

Before use, please confirm:
  1. SONAR_USER_TOKEN is configured in GitLab project Settings → CI/CD → Variables
  2. Commit these files to the branch; SonarQube scan will auto-trigger when an MR is created
  3. Scan results can be viewed at https://sonarqube.example.com

Examples

Bad

User: "Add a Pipeline to this embedded repo"
AI: Declares stages: [build, test, deploy] in .gitlab-ci.yml, uses include: local to reference files,
    and uses heredoc in the script to generate sonar-project.properties
→ Pipeline creation fails: stages missing test (ci:init requires it), include: local resolves to wrong repo, heredoc causes YAML parse error
User: "This repo already has .gitlab-ci.yml, help me add SonarQube"
AI: Overwrote the user's original .gitlab-ci.yml, removing existing job configurations
→ The user's existing CI workflow is broken

Good

User: "Add a Pipeline to this embedded repo"
AI: Check finds no .gitlab-ci.yml → generates .gitlab-ci.yml (no stages declared, uses defaults)
    + ci/sonar-analysis-embed.yml (uses include: project, specifies image, echo writes properties)
    + .gitignore adds sonar-project.properties
    → Prompts user to check SONAR_USER_TOKEN configuration
User: "This repo already has .gitlab-ci.yml, help me add SonarQube"
AI: Check finds existing .gitlab-ci.yml, no ci/sonar-analysis-embed.yml
    → Only creates ci/sonar-analysis-embed.yml
    → Appends include at top of existing .gitlab-ci.yml without modifying other content
    → Prompts user to check SONAR_USER_TOKEN configuration

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most project setup skills give in ~2.3k tokens

Counted across 1,553 of the 3,091 authors here whose files we hold, read 2026-09-06

  • Write the configuration filein 36 of 1553
  • Create the directory structurein 35 of 1553, across 33 files
  • Verify the setupin 31 of 1553, across 28 files
  • Run the setup scriptin 30 of 1553, across 29 files
  • Pre-determine the required sample sizein 29 of 1553, across 12 files
  • Check if the configuration already existsin 29 of 1553
  • Document every testin 26 of 1553, across 10 files
  • Start with a hypothesisin 26 of 1553, across 11 files
  • Ask one question at a timein 22 of 1553
  • Test a single variable per testin 21 of 1553, across 9 files
  • Read product marketing context before asking questionsin 19 of 1553, across 8 files
  • Do not peek and stop earlyin 18 of 1553, across 7 files

Said here and by no other author read

  • Prompt user to check GitLab CI CD Variables
  • Generate gitlab ci yml
  • Generate ci sonar analysis embed yml
  • Add include to existing gitlab ci yml
  • Notify user after completion

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.