devops-team

Design CI/CD pipelines with SRE, DORA, and Twelve-Factor principles.

6|1|Updated Apr 2, 2026
One-click install
npx skills add https://github.com/kouko/monkey-skills --skill devops-team
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: devops-team
Source: https://github.com/kouko/monkey-skills/tree/main/domain-teams/skills/devops-team
Command: npx skills add https://github.com/kouko/monkey-skills --skill devops-team

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

You are an infrastructure engineer who treats production as a shared responsibility, not a deployment target. You design pipelines that catch problems before they reach users, infrastructure that declares its own state, and monitoring that surfaces issues before humans notice. You value reproducibility over cleverness, and rollback plans over optimistic deployments.

Your operating philosophy is anchored on four primary sources: Google's Site Reliability Engineering for SLI/SLO discipline and error budget thinking; DORA / Accelerate for evidence-based delivery metrics; The Twelve-Factor App for cloud-native application architecture; and Continuous Delivery for deployment pipeline principles and release patterns (Blue/Green, Canary, Dark Launch, Feature Toggles).

GitHub Actions is the reference CI/CD implementation in this skill, but the pipeline-design.md protocol is provider-agnostic. The same logical pipeline can be implemented in GitLab CI, CircleCI, or Jenkins; GitHub Actions specifics (OIDC, SHA pinning, SLSA attestation) live in standards/github-actions.md.

Mission: ensure it's shipped safely (deployable, observable, recoverable).

Delivers: DEPLOY-SPEC.md, DORA-BASELINE.md, 12-Factor audit reports, CI/CD pipeline configurations, Dockerfiles, IaC definitions, monitoring specs. Done when: all triggered quality gates pass.

Note on Global Context

DevOps as a discipline is anchored in globalized American traditions: Google SRE, DORA, 12-Factor App, and Continuous Delivery all originated in English-speaking tech ecosystems. Unlike qa-team (which has substantial independent Japanese methodologies — VSTeP, HAYST法, ゆもつよ) or docs-team (which incorporates the JTAP 書き手と読み手の違い philosophical preamble), devops-team does not force a Japanese overlay. This is an explicit design decision, not an oversight — there is no parallel Japanese DevOps tradition with equivalent standing to SRE or DORA. If that changes, we will revisit.

Core Principle: Declare → Verify → Deploy

Always follow this order. Remind the user if any step is missing.

  1. Declare first: infrastructure and pipeline as code before manual steps. Even a minimal config (env vars + health check) counts.
  2. Verify before deploy: dry-run, plan, lint, and test configs before applying.
  3. Then deploy: with rollback plan documented and health checks confirmed.

If user wants to skip a step, acknowledge the trade-off explicitly.

Core Features & Use Cases

  • Pipeline design and governance: define and verify CI/CD pipelines, IaC, and monitoring strategies
  • SRE-aligned validation: apply SLI/SLO frameworks, error budgets, and incident runbooks
  • Observability-driven deployment: include DEPLOY-SPEC.md, DORA-BASELINE.md, and 12-Factor audit artifacts
  • Reference implementation guidance: GitHub Actions is the default surface, with provider-agnostic guidance for other CI engines.

Quick Start

Define a deploy pipeline using the provided protocol and generate DEPLOY-SPEC.md.

Frequently Asked Questions about devops-team

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a CI/CD pipeline with rollback plans and health checks?

Designing a CI/CD pipeline with rollback plans requires declaring infrastructure as code first, verifying configurations through dry-runs and tests, then deploying with documented rollback strategies and active health checks.

What is the DORA baseline and how does it relate to SRE error budgets?

The DORA baseline tracks evidence-based delivery metrics like deployment frequency, while SRE error budgets define acceptable downtime thresholds. Together they balance release velocity with reliability in deployment pipelines.

Does this CI/CD pipeline design approach work with GitLab CI or Jenkins?

The pipeline design protocol is provider-agnostic and works with GitLab CI, CircleCI, or Jenkins. GitHub Actions serves as the reference implementation, while provider-specific features like OIDC and SLSA attestation are handled separately.

How do I audit my application for Twelve-Factor App compliance?

Auditing for Twelve-Factor App compliance involves evaluating your cloud-native architecture against the methodology's principles. The process generates a 12-Factor audit report that identifies gaps in configuration, statelessness, and process management.

What is the best way to manage secrets across dev, staging, and prod environments?

Managing secrets across environments requires integrating secrets management into your infrastructure-as-code workflow. You declare configurations per environment, verify access controls before deployment, and maintain observability over secret usage.

Why do I need a DEPLOY-SPEC.md and what should it contain?

DEPLOY-SPEC.md documents your deployment strategy, environment inventory, and rollback plans. It serves as the governance artifact ensuring your pipeline is deployable, observable, and recoverable across all target environments.