Maintainer-focused tool for managing CI/CD infrastructure, CTest suites, release packaging, and security automation for iccDEV.

Install

mkdir -p .claude/skills/maintainer-ci-ctest && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/16591" && unzip -o skill.zip -d .claude/skills/maintainer-ci-ctest && rm skill.zip

Installs to .claude/skills/maintainer-ci-ctest

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Maintainer workflow for scoping and updating iccDEV CI, CTest, CPack, sanitizer, workflow, and release-gate infrastructure.
123 charsno explicit “when” trigger
Advanced

Key capabilities

  • Scope and update iccDEV CI infrastructure
  • Scope and update CTest infrastructure
  • Scope and update CPack and release packaging
  • Scope and update sanitizer helper policy
  • Scope and update CodeQL/workflow governance
  • Scope and update security automation

How it works

The skill provides a workflow for iccDEV maintainers to scope and update CI, CTest, CPack, sanitizer, workflow, and release-gate infrastructure.

Inputs & outputs

You give it
Maintainer-owned infrastructure change request
You get back
Updated CI, CTest, CPack, sanitizer, workflow, or release-gate infrastructure

When to use maintainer-ci-ctest

  • Add or update CTest profile validations
  • Configure CI workflow gates
  • Update sanitizer policy and scripts
  • Manage release packaging and CPack settings

About this skill

Maintainer CI and CTest Workflow

Use this skill only for iccDEV maintainer-owned infrastructure changes: .github/**, Dockerfile*, CTest registration, CPack and release packaging, sanitizer helper policy, CodeQL/workflow governance, vcpkg release verification, and security automation.

General contributor requests should be redirected to issue or PR descriptions unless an iccDEV maintainer explicitly approved the infrastructure change.

Scope Decision

Choose the smallest maintainer-owned surface that proves the behavior:

ChangePrimary locationRequired docs
Add profile inputTesting/CreateAllProfiles.*docs/ctest.md if counts change
Add profile validationTesting/RunTests.*docs/ctest.md if CTest coverage changes
Add focused Linux regression.github/scripts/*.sh.github/ci/regression/README.md or docs/ctest.md
Register CTest suiteBuild/Cmake/Testing/CMakeLists.txtdocs/ctest.md
Change workflow gate.github/workflows/*.ymldocs/regression-workflow-governance.md
Change maintainer DockerfileDockerfile*docs/build.md and docs/regression-workflow-governance.md
Change sanitizer policyBuild/Cmake/CMakeLists.txt, .github/scripts/sanitize-*.github/instructions/*
Change CPack/release packagingBuild/Cmake/**, release workflowsdocs/build.md or release docs
Change vcpkg release verificationports/iccdev/**, vcpkg workflowsvcpkg skill/docs

Keep contributor code changes separate from maintainer infrastructure commits when practical.

CTest Rules

  • check must exist on every platform.
  • check and workflow CTest execution must use --no-tests=error.
  • Do not add hard-coded CTest suite totals to workflows, docs, or maintainer instructions; keep suite lists descriptive and let CTest discovery report the current total.
  • Adding checks inside iccdev-tool-coverage-baseline.sh does not change that count; validate the direct script and ctest -R '^iccdev\.tool-coverage$'.
  • Windows full builds include focused executable regressions, batch-backed suites, dump/profile smoke coverage, shared-export coverage, and PAWG report coverage.
  • The comprehensive build matrix must retain MSVC, ClangCL, and MinGW UCRT64 coverage, plus a separate MSVC full CTest gate with warnings treated as errors. Unix must likewise retain the full strict CTest gate.
  • Use rg "Total Tests:|currently register|ci[-]tool[-]tests[.]yml" docs .github before PR handoff to catch stale count and workflow-name references.
  • Generated-profile count changes must update every explicit assertion source, including Build/Cmake/Testing/CMakeLists.txt, generated-profile workflows, and packaged WASM regression scripts.
  • Do not duplicate generated-profile totals in this skill; use the assertion sources as the current truth.
  • Windows batch CTest runs must use the disposable Testing copy under the build tree and must not dirty the source Testing/ directory.
  • Windows executable tests must receive runtime DLL directories through Build/Cmake/Testing/WindowsRuntimePaths.cmake; do not rely on a developer or runner shell PATH for vcpkg or MinGW runtime DLLs.
  • MinGW builds still need UCRT64 bin on the invoking shell PATH because GCC subprocesses such as cc1plus.exe depend on MSYS2 runtime DLLs during build.

Workflow Rules

  • Follow .github/instructions/workflow-governance.instructions.md.
  • Treat ci-pr-action full as the explicit long-cycle maintainer gate. It runs Unix GCC/Clang Release and Debug builds, exact GCC 15.2 strict Release LTO in the regression container, GCC 15.2 ASAN+UBSAN tool tests, Windows, and Docker.
  • ci_scope=auto is the default. It selects the full matrix for source, build, test, and container changes; workflow-only changes run the preflight and workflow-security gates.
  • Use ci_scope=fast-lane for the exact GCC 15.2 Release LTO and ASAN+UBSAN Release tool lanes. Fast lane defaults to the latest CTest with Windows and Docker disabled; add them only when the change needs those surfaces.
  • On ci-qa-pr-docker-testing, Docker PR verification is advisory. Let the orchestrator continue when that lane fails, mark the run for bump-sha-pins, update pinned action or container SHAs, and rerun Docker before claiming container verification.
  • Do not use || true around profile generation, CTest discovery, regression execution, sanitizer checks, or packaging verification.
  • Use least-privilege permissions and credential cleanup.
  • Sanitize all GITHUB_STEP_SUMMARY and GITHUB_OUTPUT writes.
  • Check out the base ref's .github/scripts sparsely and source its sanitizer helpers for every workflow that executes PR-controlled source.
  • Include github.event_name in concurrency keys for workflows that accept both PR and manual-dispatch events, so a manual lane cannot cancel its PR counterpart.
  • Trigger shared-concurrency workflows sequentially to avoid canceling your own run. Use ci-pr-action for normal maintainer validation and ci-regression-checks through that orchestrator for ASAN/UBSAN CTest coverage.

Local Validation

file <changed-files>
git diff --check
cmake -S Build/Cmake -B build -DENABLE_TOOLS=ON -DENABLE_TESTS=ON -DENABLE_WXWIDGETS=OFF
cmake --build build --parallel "$(nproc)"
ctest --test-dir build -N --no-tests=error
ctest --test-dir build --output-on-failure --no-tests=error

For tool coverage script changes:

ICCDEV_TOOLS_DIR=$PWD/build/Tools \
ICCDEV_TESTING_DIR=$PWD/Testing \
ICCDEV_TEST_OUTDIR=/tmp/iccdev-tool-output \
  .github/scripts/iccdev-tool-coverage-baseline.sh --asan --quick
ctest --test-dir build -R '^iccdev\.tool-coverage$' --output-on-failure

For workflow YAML:

python3 -c "import yaml; [yaml.safe_load(open(p)) for p in ['.github/workflows/<workflow>.yml']]; print('YAML parse OK')"
actionlint -no-color .github/workflows/<workflow>.yml

For CPack, install/export, vcpkg, or release packaging changes, run the nearest packaging smoke test and inspect logs for missing files, duplicate install manifest entries, CRT mismatch warnings, and skipped smoke coverage.

For Dockerfile* changes:

docker build -t iccdev-container-check -f <Dockerfile> .
docker run --rm iccdev-container-check <smoke-command>

For Dockerfile.ci-regression, also run a no-cache build and smoke clang, clang++, gcc, g++, cmake, afl-fuzz, and /usr/bin/time. If the image is published, pass the published branch or SHA tag to ci-iccdev-tool-tests.yml.

GitHub Validation

After pushing, trigger only the workflows affected by the change:

gh workflow run "ci-pr-action" --repo InternationalColorConsortium/iccDEV --ref <branch> -f ci_scope=full
gh workflow run "ci-pr-action" --repo InternationalColorConsortium/iccDEV --ref <branch> \
  -f ci_scope=fast-lane -f pr_number=<open-pr-number>
gh workflow run "ci-risk-analysis" --repo InternationalColorConsortium/iccDEV --ref <branch> \
  -f analysis_target="Specific git ref" -f git_ref=<full-sha> -f severity_threshold=HIGH -f fail_on_findings=true

Wait for shared-concurrency workflows one at a time. Capture run IDs, head SHA, job conclusions, artifact names, and key sentinel lines such as Total Tests, 100% tests passed, generated-profile counts, and sanitizer summaries.

Handoff

Report:

  • Branch and commit SHA.
  • Maintainer-owned scope touched and why.
  • Expected counts changed or confirmed unchanged.
  • Local commands and outcomes.
  • GitHub run IDs, conclusions, artifacts, and any annotations.
  • For registry QA runs, report summary.md, results.tsv, and findings.txt as authoritative evidence. Note whether per-run logs were bounded by registry_qa_log_tail_lines; use 0 only when full raw logs are needed. Developer reports must preserve downloaded profile payloads so reviewers can inspect and rerun failing inputs without a second download step.
  • Remaining Windows, packaging, or release validation that requires hosted runners.

References

  • ../../../docs/ctest.md
  • ../../../docs/regression-workflow-governance.md
  • ../../../docs/documentation-maintenance.md
  • ../../instructions/workflow-governance.instructions.md
  • ../../instructions/testing.instructions.md
  • ../../instructions/build-system.instructions.md
  • ../../prompts/maintainer-ci-ctest.prompt.md

When not to use it

  • For general contributor requests
  • When not making maintainer-owned infrastructure changes
  • When not explicitly approved by an iccDEV maintainer

Limitations

  • Use this skill only for iccDEV maintainer-owned infrastructure changes:
  • General contributor requests should be redirected to issue or PR descriptions unless an iccDEV maintainer explicitly approved the infrastructure change.
  • Do not add hard-coded CTest suite totals to workflows, docs, or maintainer instructions

How it compares

This skill offers a specialized workflow for maintainer-owned infrastructure changes, ensuring adherence to specific rules and validation steps, unlike general CI/CD pipeline management.

Compared to similar skills

maintainer-ci-ctest side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
maintainer-ci-ctest (this skill)01moReviewAdvanced
deployment-pipeline-design62moReviewAdvanced
cloudflare-deploy36moReviewIntermediate
artifactory-module-architecture43moNo flagsIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

deployment-pipeline-design

wshobson

Design multi-stage CI/CD pipelines with approval gates, security checks, and deployment orchestration. Use when architecting deployment workflows, setting up continuous delivery, or implementing GitOps practices.

670

cloudflare-deploy

davila7

Deploy applications and infrastructure to Cloudflare using Workers, Pages, and related platform services. Use when the user asks to deploy, host, publish, or set up a project on Cloudflare.

342

artifactory-module-architecture

TencentBlueKing

Artifactory 制品库模块架构指南,涵盖制品上传下载、存储后端适配、制品元数据、清理策略、权限控制。当用户开发制品库功能、处理制品存储、配置清理策略或实现制品管理时使用。

419

deployment-engineer

sickn33

Expert deployment engineer specializing in modern CI/CD pipelines, GitOps workflows, and advanced deployment automation. Masters GitHub Actions, ArgoCD/Flux, progressive delivery, container security, and platform engineering. Handles zero-downtime deployments, security scanning, and developer experience optimization. Use PROACTIVELY for CI/CD design, GitOps implementation, or deployment automation.

418

genkit-infra-expert

jeremylongshore

Execute use when deploying Genkit applications to production with Terraform. Trigger with phrases like "deploy genkit terraform", "provision genkit infrastructure", "firebase functions terraform", "cloud run deployment", or "genkit production infrastructure". Provisions Firebase Functions, Cloud Run services, GKE clusters, monitoring dashboards, and CI/CD for AI workflows.

15

managing-deployment-rollbacks

jeremylongshore

Deploy use when you need to work with deployment and CI/CD. This skill provides deployment automation and orchestration with comprehensive guidance and automation. Trigger with phrases like "deploy application", "create pipeline", or "automate deployment".

11

Search skills

Search the agent skills registry