---
name: loom-ci-cd-and-automation
description: "Use when changing pipeline or automation behavior itself: CI gates, build/deploy workflows, release automation, preview/staging/prod environments, credentials, artifacts, or pipeline-specific failure recovery."
disable-model-invocation: true
---

# loom-ci-cd-and-automation

CI/CD and automation is a playbook for executable quality gates and release paths.

It specifies pipeline behavior, implements it in scoped tickets, records observed
pipeline results, and audits risky automation changes.

## Loom Routing

Common routes use these Loom skills for durable records or follow-up workflow:
`loom-specs`, `loom-plans`, `loom-tickets`, `loom-evidence`, `loom-audit`,
`loom-research`, and `loom-retrospective`.

Ensure the `using-loom` skill is loaded before applying this workflow.

When routing to any named Loom skill, follow that skill's procedure and guidance
completely. This playbook adds workflow pressure; it does not shorten the target
skill's requirements.

## Use This Playbook When

Use this playbook when:

- setting up or changing CI checks
- adding lint, type check, test, build, security, bundle, or E2E gates
- configuring preview, staging, production, rollback, or release automation
- debugging CI failures
- changing deployment credentials, environments, or secrets handling
- adding automation that agents or humans will rely on for closure claims

## Route

Use this route:

```text
contract -> pipeline -> implement -> observe -> harden -> recover
```

## Contract

Use `loom-specs` when pipeline behavior is durable.

Specify:

- triggers
- required checks
- environments
- secret boundaries
- artifact retention
- branch or tag behavior
- failure behavior
- manual approval points
- rollback or retry behavior
- what evidence a passing run provides

Use `loom-plans` when the automation change spans several tickets or migration
stages.

## Pipeline Shape

Common gates:

- install with locked dependencies
- formatting or lint
- type check
- unit tests
- integration tests
- build
- E2E tests when critical flows require them
- security or dependency audit
- bundle or performance budget
- artifact upload on failure
- preview deploy
- staging verification

Gate order should fail early on cheap deterministic checks and preserve artifacts
for expensive failures.

## Implement

Use tickets for scoped changes.

Implementation guidelines:

- keep secrets in CI secret stores
- avoid logging credentials or tokens
- use least-privilege tokens
- pin versions when reproducibility matters
- cache dependencies without hiding stale lockfile failures
- keep generated artifacts out of Git unless the project expects them
- document local equivalents of CI checks when developers need them

## Observe

Record evidence for meaningful pipeline behavior:

- successful run URL and checked jobs
- failed run and diagnostic excerpt
- artifact paths
- local reproduction command and output
- before/after behavior for a pipeline fix
- skipped or unavailable checks

Before preserving CI logs or artifacts as evidence, check for secrets and
sensitive values. Redact or omit sensitive values before saving excerpts. If an
artifact may contain sensitive data, link only to an access-controlled location
and record the limitation instead of copying it into Loom.

Use `loom-evidence` when a ticket or audit will rely on pipeline output.

## Harden

Use `loom-audit` when automation changes affect releases, secrets, production,
security gates, or deployment permissions.

Audit questions:

- can a bad change bypass required checks?
- are secrets exposed in logs or artifacts?
- do permissions exceed need?
- are deployment triggers correct?
- are rollback and failure modes observable?
- do artifacts contain sensitive data?

## Recover

When CI fails, use `loom-debugging-and-error-recovery`:

- preserve the failure output
- reproduce locally when possible
- fix root cause
- update evidence
- add prevention if the failure revealed a recurring trap

## Done Means

The CI/CD pass is done when:

- pipeline behavior is specified or scoped
- automation changes are implemented in bounded tickets
- passing and failing behavior was observed where relevant
- secrets and permissions were checked
- evidence supports the claimed gate
- risky automation changes received audit
