ci-cd-pipeline-design
CI CD Pipeline Design
Overview
Use this skill to design delivery pipelines that are deterministic, auditable, and safe under both success and failure paths.
Scope Boundaries
- Use this skill when the task matches the trigger condition described in
description. - Do not use this skill when the primary task falls outside this skill's domain.
Inputs To Gather
- Repository topology (mono-repo/multi-repo), services affected, and deployment targets.
- Required checks (lint, test, security, compliance, performance) and risk tolerance.
- Artifact model (build outputs, provenance, signing, retention).
- Rollout model (blue/green, canary, phased, manual approvals).
Deliverables
- Pipeline stage blueprint with gate criteria and ownership.
- Artifact traceability model (source -> build -> deployable -> environment).
- Failure-path policy (auto-stop, rollback, manual override policy).
- Verification checklist for rollout and rollback readiness.
Quick Start Blueprint
Baseline stage order
validate(format/lint/static checks)test(unit/integration)package(immutable artifact creation)security(SCA, secrets, policy checks)pre-release(staging deploy + smoke)release(progressive production rollout)
Example gate policy
- No deploy if unit tests, integration tests, or security checks fail.
- Deploy only immutable artifacts produced by current commit.
- Rollback trigger: SLO breach or error-rate threshold breach during rollout window.
Quality Standard
- Stage order is deterministic and enforces risk reduction early.
- Each gate has binary pass/fail criteria and named owner.
- Artifacts are immutable and traceable to source commit.
- Rollback path is validated, not assumed.
- Manual approvals are explicit and auditable where required.
Workflow
- Define delivery risks and non-negotiable release constraints.
- Design stage sequence from fastest/high-signal checks to rollout.
- Define gate criteria and failure behavior per stage.
- Define artifact lineage and environment promotion rules.
- Validate success and failure paths with dry-runs.
- Publish operating policy and handoff guidance.
Failure Conditions
- Stop when release-critical gates are undefined or non-deterministic.
- Stop when rollback path cannot be executed within required recovery time.
- Escalate when policy/compliance gates are bypassed without approved exception.
More from kentoshimizu/sw-agent-skills
graph-algorithms
Graph algorithm workflow for modeling entities/relations and selecting traversal, path, ordering, or flow strategies. Use when correctness or performance depends on graph representation and algorithm choice; do not use for schema-only modeling or deployment topology planning.
14bash-style-guide
Style, review, and refactoring standards for Bash shell scripting. Trigger when `.sh` files, files with `#!/usr/bin/env bash` or `#!/bin/bash`, or CI workflow blocks with `shell: bash` are created, modified, or reviewed and Bash-specific quality controls (quoting safety, error handling, portability, readability) must be enforced. Do not use for generic POSIX `sh`, PowerShell, or language-specific application style rules. In multi-language pull requests, run together with other applicable `*-style-guide` skills.
11architecture-clean-architecture
Clean Architecture workflow for enforcing dependency direction, stable domain boundaries, and use-case-centered application design. Use when teams must separate business rules from frameworks and delivery mechanisms; do not use for isolated module cleanup without boundary implications.
11powershell-style-guide
Style, review, and refactoring standards for PowerShell scripting. Trigger when `.ps1`, `.psm1`, `.psd1` files, or CI workflow blocks with `shell: pwsh` or `shell: powershell` are created, modified, or reviewed and PowerShell-specific quality controls (error handling, parameter validation, readability, operational safety) must be enforced. Do not use for Bash, generic POSIX `sh`, or language-specific application style rules. In multi-language pull requests, run together with other applicable `*-style-guide` skills.
10github-codeowners-management
Govern CODEOWNERS rules so review routing reflects real ownership and risk boundaries on GitHub. Use when repository ownership mapping or mandatory reviewer rules must be defined, updated, or audited; do not use for non-GitHub runtime architecture or data-layer design.
9security-authentication
Security workflow for authentication architecture, credential lifecycle, and session/token assurance. Use when login, identity proofing, MFA, or session security decisions are required; do not use for authorization policy design or non-security quality tuning.
9