CI Setup Skill

Configure production-ready CI/CD pipelines by detecting project languages, selecting appropriate templates, and customizing them for the target repository.

Inputs

• •$ARGUMENTS — Optional. Format: [github|gitlab] [project-path]
  • •If platform is omitted, auto-detect from Git remote.
  • •If project-path is omitted, use the current working directory.

Safety Checks

Before making any changes:

1. •Verify target directory is a Git repository — abort if not.
2. •Check for existing CI configuration — if .github/workflows/ or .gitlab-ci.yml already exists, warn the user and ask before overwriting.
3. •Never commit or push — only write files. The user decides when to commit.
4. •Never modify source code — only create/update CI configuration files.

Execution Steps

Step 1: Parse Arguments

Parse $ARGUMENTS to extract:
  - platform: "github" | "gitlab" | auto-detect
  - project_path: absolute path to the target repository (default: cwd)

If no platform is specified, detect it:

# Use git_platform.sh if available, otherwise check remote URL
platform=$(~/.claude/scripts/git_platform.sh 2>/dev/null || echo "github")

Step 2: Detect Project Languages

Scan the project root for language indicators. Check for the presence of:

Record which languages are detected. At least one must be found.

Step 3: Detect Project Structure

For each detected language, gather details:

Python:

• •Package manager: pyproject.toml (modern) vs requirements.txt vs Pipfile
• •Test framework: check for pytest.ini, setup.cfg [tool:pytest], pyproject.toml [tool.pytest]
• •Python version constraints: parse pyproject.toml requires-python or .python-version

Go:

• •Go version: parse go.mod for go directive
• •Module path: extract from go.mod
• •Workspace: check for go.work

Node.js:

• •Package manager: bun.lock (bun), pnpm-lock.yaml (pnpm), yarn.lock (yarn), package-lock.json (npm)
• •Framework: check package.json dependencies for Next.js, Vite, Remix, etc.
• •Has TypeScript: check for tsconfig.json
• •Test runner: check for vitest, jest, mocha in package.json
• •Scripts available: read package.json scripts for lint, test, build, typecheck

Terraform:

• •Backend type: parse *.tf for backend blocks
• •Provider list: parse required_providers
• •Module structure: check for modules/ directory

Step 4: Select and Customize Templates

Templates are located in the Manifest repository (or deployed location):

• •GitHub: templates/ci/github/ci.yml, security.yml, release.yml
• •GitLab: templates/ci/gitlab/.gitlab-ci.yml

For the canonical template source, check these paths in order:

1. •./templates/ci/ (if running inside the Manifest repo)
2. •~/.claude/../templates/ci/ (if Manifest is deployed)
3. •Inline generation as fallback

Read the selected template(s) and customize:

Customizations to apply:

1. •

   Remove unused language blocks — If the project does not use Go, remove all Go jobs. If it does not use Terraform, remove Terraform jobs. Keep only detected languages.

2. •

   Adjust version matrices — Replace default versions with detected versions. For example, if go.mod specifies go 1.22, use ['1.22'] instead of ['1.22', '1.23'].

3. •

   Match package manager — For Node.js, if only pnpm-lock.yaml exists, simplify the package manager detection to just use pnpm directly.

4. •

   Adjust paths filters — If all Python code lives under src/, narrow the paths filter from **/*.py to src/**/*.py.

5. •

   Add framework-specific steps — If Next.js is detected, add next build and potentially next lint. If Django, add python manage.py check.

6. •

   Set Python/Node/Go versions — Use the project's actual version constraints rather than template defaults.

Step 4.5: E2E Browser Test Job (Optional)

If tests/browser/ exists in the project and contains *.yaml or *.yml files, add a browser test job to the CI pipeline:

GitHub Actions — add after the test job:

  browser-tests:
    runs-on: ubuntu-latest
    needs: [test]
    if: hashFiles('tests/browser/*.yaml') != '' || hashFiles('tests/browser/*.yml') != ''
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install browser-use
        run: pip install browser-use
      - name: Install browser dependencies
        run: npx playwright install --with-deps chromium
      - name: Run browser tests
        run: |
          chmod +x ~/.claude/scripts/browser_test.sh 2>/dev/null || true
          python3 -m browser_use run tests/browser/ --headless || true

GitLab CI — add after the test stage:

browser-tests:
  stage: test
  image: python:3.12
  before_script:
    - pip install browser-use
    - npx playwright install --with-deps chromium
  script:
    - python3 -m browser_use run tests/browser/ --headless || true
  rules:
    - exists:
        - tests/browser/*.yaml
        - tests/browser/*.yml
  allow_failure: true

The browser test job should:

• •Run after unit tests (dependency/needs)
• •Use allow_failure: true / continue-on-error: true so it does not block the pipeline
• •Install browser-use and Chromium in the CI environment
• •Run in headless mode

If tests/browser/ does not exist, skip this step entirely.

Step 5: Write Configuration Files

GitHub Actions:

.github/workflows/ci.yml       — Main CI pipeline
.github/workflows/security.yml — Security scanning
.github/workflows/release.yml  — Automated releases

GitLab CI:

.gitlab-ci.yml — Complete pipeline (all stages in one file)

Create the target directories if they do not exist.

Step 6: Report Summary

Output a summary of what was created:

## CI/CD Setup Complete

**Platform**: GitHub Actions
**Detected languages**: Python 3.13, Node.js 22
**Package managers**: pip (pyproject.toml), pnpm

### Files created:
- .github/workflows/ci.yml — Multi-language CI (Python + Node.js)
- .github/workflows/security.yml — Dependency audit, secret scan, SAST
- .github/workflows/release.yml — Automated semver releases

### Next steps:
1. Review the generated workflow files
2. Add any required secrets (e.g., CODECOV_TOKEN, SEMGREP_APP_TOKEN)
3. Commit and push to trigger the first pipeline run
4. Configure branch protection rules to require CI to pass

Validation Rules

After writing files, verify:

1. •YAML syntax — Parse each generated file to confirm valid YAML.
2. •No hardcoded secrets — Confirm no API keys, tokens, or passwords appear in the output.
3. •Correct indentation — YAML files must use consistent 2-space indentation.
4. •File permissions — Generated files should not be executable.

Output Format

Provide the summary as markdown to the user. Include the full list of created files with brief descriptions of what each contains and any manual configuration needed.