Claude Skill

ci-cd

Use when setting up or modifying CI/CD pipelines, quality gates, test runners, or deployment pipeline configuration through workflow files. Not for triggering a deployment.

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download outlinedriven-outline-driven-development-.devin_skills_ci-cd-b0e8ce8.zip · 5 KB

outlinedriven/outline-driven-development 54 10 forks Apache-2.0 Updated 2d ago

Part of outlinedriven/outline-driven-development — 145 skills

Install

skills CLI npx skills add https://github.com/OutlineDriven/outline-driven-development/tree/main/.devin/skills/ci-cd

Claude Code

claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install outlinedriven-outline-driven-development@llmmart

Git git clone https://github.com/OutlineDriven/outline-driven-development.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole outlinedriven/outline-driven-development collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

CI/CD and deployment configuration

Contract

Field	Bound contract
Trigger	Setting up or modifying CI/CD pipelines, quality gates, test runners, deployment strategy, or configuring a deployment pipeline through workflow files.
Authority	Reversible local: writes only CI workflow and deployment configuration files in the local repository; rollback is version control. No remote mutation.
Side effect	Writes CI workflow and deployment configuration files locally; no deployment, publishing, credential, or remote mutation.
Done	Blocking gates in a fixed order, secret references via provider environment variables, a deployment stage with a rollback mechanism, and local schema validation are present.

Inputs

The target repository and its CI provider (e.g., GitHub Actions). Required; detected from existing configuration or supplied by the user.
The quality gates the project requires. Required; defaults to the fixed gate order below.
The project ecosystem commands that realize each gate (lint, type-check, test, build, integration, security audit, bundle size). Required.
The deployment target and its rollback strategy. Required when a deployment stage is in scope.
Any required deployment secrets, environment names, or build commands. Supplied by the user; this skill does not invent credentials.
An existing pipeline to modify. Optional; supply when modifying rather than creating.

Procedure

Bound scope: confirm the work is authoring or modifying CI workflow and deployment configuration files in the repository. Do not run deployments, publish artifacts, configure branch protection, place secrets in a remote manager, or mutate remote systems. Enumerate the exact files this skill will create or edit and show the set to the user before mutation. Write only those files. Done when: scope is bounded to local config file authoring and the file set is enumerated.
Identify the CI provider and target ecosystem. Detect from existing configuration; if none exists, ask the user for the target platform and pipeline shape before creating any file. Done when: the provider and ecosystem are identified from existing config or supplied by the user.
Establish the fixed gate order that every PR and push to main must pass, in this sequence: lint, type check, unit tests, build, integration tests, E2E (optional), security audit, bundle size. The order is fixed across ecosystems; only the commands change (Node: pnpm exec biome check ., pnpm exec tsc --noEmit, pnpm exec vitest run, pnpm run build; Python: uv run ruff check ., uv run ruff format --check ., uv run pyright, uv run pytest, uvx pip-audit; Rust: cargo clippy, cargo test, cargo build, cargo audit). Do not add stages the user did not request. Done when: the fixed gate order is established with ecosystem-specific commands.
Make every gate blocking. No gate may be skipped. If lint fails, fix lint; if a test fails, fix the code. Do not disable the rule or skip the test. Done when: every gate is configured as blocking with no skip path.
Reference secrets via environment variables expected from the provider. Never store secrets in code or in workflow configuration files. The user places secrets in the provider's secret store out of band; this skill only writes the variable references. Done when: secrets are referenced as masked env vars in the workflow file, not stored in any committed file.
Author the deployment stage with a rollback mechanism. Configure the deployment pipeline stages (build, test, deploy) using the user-supplied platform, environment, and commands. Include a defined rollback step. Do not add stages the user did not request. Done when: the deployment stage has a rollback mechanism and only user-requested stages.
Validate the authored files locally. Run the project's local check set (lint, build, test) against the pipeline definition. If the platform provides a local validation command for the workflow file (e.g., actionlint for GitHub Actions), run it. Do not trigger a deployment. Done when: every local check and platform validation command is run with pass or fail recorded.
When a CI run has already failed, route the failure back to the agent that owns the change: copy the failing job name, the error text, and the repo state at failure, so the root cause is fixed rather than re-run. Skip this step when setting up a new pipeline that has no failure yet. Done when: the failure is routed to the owning agent with job name, error text, and repo state, or the step is skipped for a new pipeline.
Verify all gates are present, the pipeline runs on every PR and push to main, secrets are referenced via env vars, deployment has a rollback mechanism, and local schema validation passes. Done when: every done-predicate element is verified present.

Failure and recovery

Unsupported CI provider: stop and report; do not guess a provider-specific schema.
Missing required ecosystem commands: stop and ask the user; do not invent commands.
Gate failure: fix the code or configuration that caused the failure. Never disable the gate, skip the test, or re-run a flaky test; fix the flakiness.
Secret leak in a config or code file: remove the secret from the file, rotate it, and re-reference it as an env var before proceeding.
Missing rollback: do not mark deployment configuration done; add the rollback mechanism first.
Validation fails: report the failing check with its file and line; do not mark the pipeline verified. Leave the edited files in place for the user to correct, or revert them to their prior state on user request.
Partial result: keep all completed gate configuration, but do not commit a pipeline that is missing a blocking gate, a secret boundary, or a rollback. The blocked result is a report listing exactly which done-predicate element is missing and what was tried.
Rollback: the edited CI or workflow files are version-controlled; restore them from VCS to the pre-edit state.

Output

CI workflow and deployment configuration files in the repository implementing the fixed gate order, blocking gates, secret references via environment variables, a deployment rollback mechanism, and local schema validation, plus a report listing files written and per-check pass or fail status. No deployment triggered.

Files (outline-driven-development)

agents

openai.yaml 198 B

interface:
  display_name: "CI Cd"
  short_description: "Use when setting up or modifying CI/CD pipelines, quality gates, test runners, or deployment pipeline configuration through workflow files."

references

automation-and-environments.md 900 B

# Automation and environments

## Environment management

```
.env.example       → Committed (template for developers)
.env                → NOT committed (local development)
.env.test           → Committed (test environment, no real secrets)
CI secrets          → Stored in GitHub Secrets / vault
Production secrets  → Stored in deployment platform / vault
```

Never give CI production secrets. Use separate secrets for CI testing.

## Automation beyond CI

### Dependabot / Renovate

```yaml
# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    open-pull-requests-limit: 5
```

### PR checks

- Required reviews: At least 1 approval before merge
- Required status checks: CI must pass before merge
- Branch protection: No force-pushes to main
- Auto-merge: If all checks pass and approved, merge automatically

ci-failure-feedback-loop.md 365 B

# Feeding CI failures back to agents

When CI fails, use this feedback loop with the agent:

```
CI fails
    │
    ▼
Copy the failure output
    │
    ▼
Feed it to the agent:
"The CI pipeline failed with this error:
[paste specific error]
Fix the issue and verify locally before pushing again."
    │
    ▼
Agent fixes → pushes → CI runs again
```

deployment-strategies.md 1.9 KB

# Deployment strategies

**Grounded: 2026-08-26**

## Preview deployments

Every PR gets a preview deployment for manual testing:

```yaml
# Deploy preview on PR (Vercel/Netlify/etc.)
deploy-preview:
  runs-on: ubuntu-latest
  if: github.event_name == 'pull_request'
  steps:
    - uses: actions/checkout@v7
    - name: Deploy preview
      run: npx vercel --token=${{ secrets.VERCEL_TOKEN }}
```

## Feature flags

Feature flags decouple deployment from release. Put incomplete or risky features behind flags to:

- Ship code without enabling it. Merge to main early, enable when ready.
- Roll back without redeploying. Disable the flag instead of reverting code.
- Canary new features. Enable for 1% of users, then 10%, then 100%.
- Run A/B tests. Compare behavior with and without the feature.

```typescript
// Simple feature flag pattern
if (featureFlags.isEnabled('new-checkout-flow', { userId })) {
  return renderNewCheckout();
}
return renderLegacyCheckout();
```

**Flag lifecycle:** Create → Enable for testing → Canary → Full rollout → Remove the flag and dead code. Flags that live forever become technical debt. Set a cleanup date when you create them.

## Staged rollouts

```
PR merged to main
    │
    ▼
  Staging deployment (auto)
    │ Manual verification
    ▼
  Production deployment (manual trigger or auto after staging)
    │
    ▼
  Monitor for errors (15-minute window)
    │
    ├── Errors detected → Rollback
    └── Clean → Done
```

## Rollback plan

Every deployment should be reversible:

```yaml
# Manual rollback workflow
name: Rollback
on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Version to rollback to'
        required: true

jobs:
  rollback:
    runs-on: ubuntu-latest
    steps:
      - name: Rollback deployment
        run: |
          # Deploy the specified previous version
          npx vercel rollback ${{ inputs.version }}
```

github-actions.md 2.4 KB

# GitHub Actions configuration

**Grounded: 2026-08-26**

## Basic CI pipeline

```yaml
# .github/workflows/ci.yml
name: CI

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - uses: actions/setup-node@v7
        with:
          node-version: '24'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Type check
        run: npx tsc --noEmit

      - name: Test
        run: npm test -- --coverage

      - name: Build
        run: npm run build

      - name: Security audit
        run: npm audit --audit-level=high
```

## With database integration tests

```yaml
  integration:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_DB: testdb
          POSTGRES_USER: ci_user
          POSTGRES_PASSWORD: ${{ secrets.CI_DB_PASSWORD }}
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: '24'
          cache: 'npm'
      - run: npm ci
      - name: Run migrations
        run: npx prisma migrate deploy
        env:
          DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
      - name: Integration tests
        run: npm run test:integration
        env:
          DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb
```

> **Note:** Even for CI-only test databases, use GitHub Secrets for credentials rather than hardcoding values; hardcoded test credentials get reused in other contexts.

## E2E tests

```yaml
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: '24'
          cache: 'npm'
      - run: npm ci
      - name: Install Playwright
        run: npx playwright install --with-deps chromium
      - name: Build
        run: npm run build
      - name: Run E2E tests
        run: npx playwright test
      - uses: actions/upload-artifact@v7
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/
```

SKILL.md 6.4 KB

---
name: ci-cd
description: 'Use when setting up or modifying CI/CD pipelines, quality gates, test runners, or deployment pipeline configuration through workflow files. Not for triggering a deployment.'
---

# CI/CD and deployment configuration

## Contract

| Field | Bound contract |
|---|---|
| Trigger | Setting up or modifying CI/CD pipelines, quality gates, test runners, deployment strategy, or configuring a deployment pipeline through workflow files. |
| Authority | Reversible local: writes only CI workflow and deployment configuration files in the local repository; rollback is version control. No remote mutation. |
| Side effect | Writes CI workflow and deployment configuration files locally; no deployment, publishing, credential, or remote mutation. |
| Done | Blocking gates in a fixed order, secret references via provider environment variables, a deployment stage with a rollback mechanism, and local schema validation are present. |

## Inputs

- The target repository and its CI provider (e.g., GitHub Actions). Required; detected from existing configuration or supplied by the user.
- The quality gates the project requires. Required; defaults to the fixed gate order below.
- The project ecosystem commands that realize each gate (lint, type-check, test, build, integration, security audit, bundle size). Required.
- The deployment target and its rollback strategy. Required when a deployment stage is in scope.
- Any required deployment secrets, environment names, or build commands. Supplied by the user; this skill does not invent credentials.
- An existing pipeline to modify. Optional; supply when modifying rather than creating.

## Procedure

1. Bound scope: confirm the work is authoring or modifying CI workflow and deployment configuration files in the repository. Do not run deployments, publish artifacts, configure branch protection, place secrets in a remote manager, or mutate remote systems. Enumerate the exact files this skill will create or edit and show the set to the user before mutation. Write only those files. Done when: scope is bounded to local config file authoring and the file set is enumerated.
2. Identify the CI provider and target ecosystem. Detect from existing configuration; if none exists, ask the user for the target platform and pipeline shape before creating any file. Done when: the provider and ecosystem are identified from existing config or supplied by the user.
3. Establish the fixed gate order that every PR and push to main must pass, in this sequence: lint, type check, unit tests, build, integration tests, E2E (optional), security audit, bundle size. The order is fixed across ecosystems; only the commands change (Node: `pnpm exec biome check .`, `pnpm exec tsc --noEmit`, `pnpm exec vitest run`, `pnpm run build`; Python: `uv run ruff check .`, `uv run ruff format --check .`, `uv run pyright`, `uv run pytest`, `uvx pip-audit`; Rust: `cargo clippy`, `cargo test`, `cargo build`, `cargo audit`). Do not add stages the user did not request. Done when: the fixed gate order is established with ecosystem-specific commands.
4. Make every gate blocking. No gate may be skipped. If lint fails, fix lint; if a test fails, fix the code. Do not disable the rule or skip the test. Done when: every gate is configured as blocking with no skip path.
5. Reference secrets via environment variables expected from the provider. Never store secrets in code or in workflow configuration files. The user places secrets in the provider's secret store out of band; this skill only writes the variable references. Done when: secrets are referenced as masked env vars in the workflow file, not stored in any committed file.
6. Author the deployment stage with a rollback mechanism. Configure the deployment pipeline stages (build, test, deploy) using the user-supplied platform, environment, and commands. Include a defined rollback step. Do not add stages the user did not request. Done when: the deployment stage has a rollback mechanism and only user-requested stages.
7. Validate the authored files locally. Run the project's local check set (lint, build, test) against the pipeline definition. If the platform provides a local validation command for the workflow file (e.g., `actionlint` for GitHub Actions), run it. Do not trigger a deployment. Done when: every local check and platform validation command is run with pass or fail recorded.
8. When a CI run has already failed, route the failure back to the agent that owns the change: copy the failing job name, the error text, and the repo state at failure, so the root cause is fixed rather than re-run. Skip this step when setting up a new pipeline that has no failure yet. Done when: the failure is routed to the owning agent with job name, error text, and repo state, or the step is skipped for a new pipeline.
9. Verify all gates are present, the pipeline runs on every PR and push to main, secrets are referenced via env vars, deployment has a rollback mechanism, and local schema validation passes. Done when: every done-predicate element is verified present.

## Failure and recovery

- Unsupported CI provider: stop and report; do not guess a provider-specific schema.
- Missing required ecosystem commands: stop and ask the user; do not invent commands.
- Gate failure: fix the code or configuration that caused the failure. Never disable the gate, skip the test, or re-run a flaky test; fix the flakiness.
- Secret leak in a config or code file: remove the secret from the file, rotate it, and re-reference it as an env var before proceeding.
- Missing rollback: do not mark deployment configuration done; add the rollback mechanism first.
- Validation fails: report the failing check with its file and line; do not mark the pipeline verified. Leave the edited files in place for the user to correct, or revert them to their prior state on user request.
- Partial result: keep all completed gate configuration, but do not commit a pipeline that is missing a blocking gate, a secret boundary, or a rollback. The blocked result is a report listing exactly which done-predicate element is missing and what was tried.
- Rollback: the edited CI or workflow files are version-controlled; restore them from VCS to the pre-edit state.

## Output

CI workflow and deployment configuration files in the repository implementing the fixed gate order, blocking gates, secret references via environment variables, a deployment rollback mechanism, and local schema validation, plus a report listing files written and per-check pass or fail status. No deployment triggered.