/cicd-integration

name: cicd-integration
description: "Generate CI pipeline files and check scripts (GitHub Actions, GitLab, CircleCI, Bitbucket) that automate design system checks: token validation, hardcoded values, a11y scans, visual regression, bundle size. Trigger: set up CI, quality gates, automate these checks. Not for running an audit."
allowed-tools: Read, Write, Grep, Glob, Bash(cat:*), Bash(find:*), Bash(head:*), Bash(ls:*), Bash(sort:*), Bash(tail:*), Bash(wc:*), Bash(git diff:*), Bash(npx terrazzo:*), Bash(npx stylelint:*)
references:
  - ../../knowledge-notes/component-governance.md
  - ../../knowledge-notes/token-architecture.md
  - ../../knowledge-notes/design-to-code-contract.md
  - ../../knowledge-notes/output-discipline.md

CI/CD Integration

A skill for generating pipeline configurations that automate the quality checks Design System Ops skills perform manually. This bridges the gap between "here are the problems the audit found" and "these problems can never recur because the pipeline catches them."

**Output type:** File creation. This skill produces pipeline configuration files (YAML), scripts, and documentation. It does not execute pipelines — it generates the configuration that teams add to their repository.

---

Before you begin: verify references

Confirm that every path in this skill's frontmatter `references:` exists relative to this SKILL.md. If any is missing, stop: the install is incomplete, usually because a flattening installer (for example `npx skills install`) dropped the repo-root `knowledge-notes/` directory. Tell the user to reinstall by a method in `1-INSTALL.md` and run `verify-install.sh` from the install root. Proceed without the references only if the user explicitly says to, and then say in the output that it was produced without the pack's reference material.

Why this exists

Every audit skill in Design System Ops finds problems. Some of those problems should never have reached a human reviewer because they are mechanically detectable: a hardcoded hex value in a component file, a token alias that references a non-existent token, a component export missing from the barrel file, an accessibility violation that an automated scanner would catch.

CI/CD Integration converts audit findings into automated pipeline checks. The goal is not to replace the audit skills — those handle nuance, context, and cross-skill synthesis that pipelines cannot. The goal is to automate the mechanical subset so that audits focus on the problems only humans can evaluate.

---

Configuration

If `.ds-ops-config.yml` exists, follow the configuration-and-recurring knowledge note (`../../knowledge-notes/configuration-and-recurring.md`). This skill reads:

cicd:
  platform: "github-actions"         # github-actions, gitlab-ci, circleci, bitbucket
  package_manager: "npm"              # npm, yarn, pnpm
  node_version: "22"                  # Node.js version (22 or 24; both LTS)
  test_framework: "jest"              # jest, vitest, playwright
  component_library_path: "packages/components"
  token_path: "packages/tokens"
  monorepo: true                      # Whether the project uses a monorepo structure
  triggers:
    - "push to main"
    - "pull request to main"

If no configuration exists, ask for: 1. CI/CD platform (default: GitHub Actions) 2. Package manager (default: npm) 3. Whether the project is a monorepo 4. Paths to token files and component files

---

Step 0: Assess what to automate

Before generating any pipeline configuration, determine which checks are worth automating. Not everything should be in CI.

Automation decision matrix

| Check type | Automate in CI? | Why | |---|---|---| | Token naming violations | Yes | Mechanical — regex patterns, no judgment needed | | Token circular references | Yes | Graph traversal — computers are better at this | | Hardcoded colour values | Yes | grep/AST — exact match detection | | Component prop type checking | Yes | TypeScript/Flow already does this | | Accessibility (automated subset) | Yes | axe-core catches the machine-detectable subset of WCAG issues; keyboard and screen reader checks stay manual | | Visual regression | Yes | Pixel comparison catches unintended changes | | Component export completeness | Yes | AST/barrel file check | | Bundle size tracking | Yes | Byte comparison — pure measurement | | Token coverage gaps | Partial | Can check primitive→semantic mapping exists, cannot judge if mappings are correct | | Component API consistency | Partial | Can lint prop naming patterns, cannot judge API design quality | | Documentation completeness | Partial | Can check if docs exist, cannot judge if they are good | | Cross-component pattern compliance | No | Requires too much context and judgment | | Naming convention quality | No | Conventions need human validation first, then automation | | Usage guideline adherence | No | Requires consuming-app context that CI rarely has |

Rule of thumb

If the skill's finding includes a specific, unambiguous rule (e.g., "tokens must use kebab-case", "no hex values outside token files"), it can be automated. If the finding requires judgment (e.g., "this token naming could be clearer"), it cannot.

---

Step 1: Map audit findings to pipeline checks

For each audit finding category, determine the automated check:

Token checks

| Finding category | Pipeline check | Tool | |---|---|---| | Naming violations | Lint token names against convention regex | Custom script or Style Dictionary validator | | Circular references | Build-time alias resolution check | Style Dictionary build (fails on circular refs) | | Orphaned tokens | Cross-reference token definitions with usage in component files | Custom script: grep token names across component source. Warn only — it can't see tokens consumed outside the repo (product apps, native platforms, Figma), so an "orphan" may be in use | | Missing semantic tier | Check that every component token reference resolves thr