Design CI/CD

Make delivery flow, trust boundaries, and recovery paths reviewable before modifying pipeline configuration. Prefer the repository's existing CI provider, reusable workflows, artifact conventions, and deployment mechanism.

Lazy Design

Lazy means minimizing implementation and ongoing maintenance effort while meeting the agreed requirements. Read the relevant workflows and trace affected triggers, jobs, and deployment paths before recommending a design. For fixes, address the cause at the appropriate shared owner. Favor readable, complete solutions over line-count targets.

Consider, in order: no change if the outcome is already met; reuse in the repository; standard tooling; native CI/CD features; installed integrations; then minimal custom scripting or a justified new dependency. Stop when an option satisfies the contract and constraints. Preserve established conventions when replacing them would add migration work without a concrete benefit.

Require a current need for extra jobs, wrappers, configuration, or extension points. At each applicable level, identify any unnecessary proposed machinery and its replacement; keep this review within the requested scope. Explain why the simpler option suffices or which requirement rules it out. Preserve explicit requirements, required checks, least privilege, secret protection, and recovery controls. Propose scope reductions for agreement.

Dependency Gate

At Components, list every proposed new third-party action, plugin, runner image, integration, or hosted service, including its source, purpose, permissions, and why an existing dependency cannot meet the need. Obtain explicit agreement for each before moving to Interactions. Do not add, pin, configure, or assume approval for a new dependency.

Conversation

Start at Capabilities for release or deployment workflow changes; start at Components for a bounded job change. Never skip Contracts. Present only one level, then wait for explicit approval. Do not edit workflow files, run releases, or supply implementation configuration until the design is approved.

1. Capabilities — Confirm triggers, affected branches/environments, required checks, release outcome, compliance constraints, and explicit non-goals.
2. Components — Identify workflows, jobs, runners, reusable actions, environments, artifact stores, secret sources, and deployment targets. Consider native concurrency, matrices, and artifact handling before custom orchestration; add caching or parallelism for a demonstrated bottleneck or stated target. Obtain the dependency agreement.
3. Interactions — Trace trigger-to-release flow, dependency ordering, cache/artifact handoff, approvals, promotion gates, concurrency, failure handling, rollback, and audit evidence.
4. Contracts — Define inputs/outputs, artifact names and retention, environment variables, permissions, secret access, versions, gate criteria, and notifications. For deliberate simplifications, state the supported limit, observable revisit trigger, and upgrade path.
5. Implementation — After approval, propose a small rollout and validation plan covering affected triggers, gates, and failure paths, including safe dry runs; implement only when requested. Record non-obvious accepted limits near the affected configuration using repository conventions.

State assumptions and the blast radius at every level. Do not broaden permissions, expose secrets, add deployment targets, or introduce uncontrolled release paths without an explicit decision.