Using devops skills

Using DevOps Skills

Overview

DevOps Agent Skills is a collection of operational workflow skills organized around an 8-phase delivery cycle. Each skill encodes a specific process that senior DevOps engineers follow. This meta-skill runs the session-start entry selection, maps work to the right phase, and defines the operating rules every skill shares.

The Cycle

Full:      Discover → Define → Design → Evaluate → Build → Integrate → Guard
         → Package → Provision → Deploy → Verify → Observe → Operate → Improve

Summarized:  DEFINE → GROUND → ORCHESTRATE → EVALUATE → SECURE → DEPLOY → OBSERVE → GOVERN

Phase	Compresses	Question it answers
Define	Discover, Define	What are we building, for whom, under which constraints?
Ground	Design	What architecture carries it? (cloud, network, ADRs)
Orchestrate	Build, Integrate	How do changes flow? (scripts, Git flow, CI/CD, image builds)
Evaluate	Evaluate, Verify	Is it proven? (reviews, plan gates, audits, post-deploy checks)
Secure	Guard	Is it trustworthy? (secrets, supply chain, signing, policy)
Deploy	Package, Provision, Deploy	How does it reach production? (artifacts, IaC, K8s, GitOps)
Observe	Observe	Can we see it? (metrics, logs, traces, alerts, SLOs)
Govern	Operate, Improve	Can we run and evolve it? (incidents, DR, docs, DORA)

Foundations is not a phase of the main cycle. Linux, networking, Git, and Bash fundamentals form an optional track for beginners and students (via /learn and the devops-mentor persona). Seniors route around the cycle directly.

Session Start: Entry Mode Selection

At the start of every session (or when a new body of work begins), present the entry selection. One short question, four options — never skip straight to building on a guessed context:

How do you want to start?

[1] Senior DevOps     → Tell me the task; I'll route it through the cycle.
                        No interview, no teaching track.
[2] Beginner / Student → /learn — the devops-mentor guides you stage by stage
                        (Foundations first: Linux, networking, Git, Bash).
[3] Interview me      → interview-me extracts the Mission Brief: real objective,
                        constraints, and impediments, one question at a time.
[4] Start from a diagram → diagram-driven-design parses your draw.io / Mermaid /
                        topology description and builds the Mission Brief from it.

Selection rules:

• [1] Senior DevOps → go straight to Skill Discovery below. No interview, no foundations track. Respect their time.
• [2] Beginner / Student → invoke the devops-mentor persona (/learn). The mentor assesses level and runs the learning path; the Foundations skills (linux-system-administration, network-troubleshooting-and-dns, git-workflow-and-versioning, shell-scripting-automation) are teaching material here.
• [3] Interview → invoke interview-me. Its confirmed Mission Brief carries a Recommended route — follow it.
• [4] Diagram → invoke diagram-driven-design. It parses the diagram source, runs gap analysis, and produces the Mission Brief — follow its Recommended route.

If the user just starts talking without picking: infer the mode from the request (a diagram attachment → [4]; "teach me" → [2]; "grill me" → [3]; a concrete task → [1]). Only when a non-trivial ask is genuinely underspecified and the user hasn't opted out, offer [3] in one line ("I can interview you to pin this down — want that, or should I proceed with stated assumptions?"). Offered, never forced.

Skill Discovery

Once the entry mode is set, map the task to its phase and skill:

Task arrives (entry mode set)
    │
    ├── DEFINE
    │     ├── interview-me                    → intent + impediments → Mission Brief
    │     └── diagram-driven-design           → draw.io/Mermaid → Mission Brief
    ├── GROUND
    │     ├── cloud-platform-foundations      → IAM, network, compute, data design (+ADRs)
    │     └── cost-estimation-and-finops      → price the design before provisioning
    ├── ORCHESTRATE
    │     ├── git-workflow-and-versioning     → branches, PRs, Conventional Commits, SemVer
    │     ├── shell-scripting-automation      → idempotent Bash/Python/PowerShell
    │     ├── container-build-and-hardening   → Dockerfiles, images, scanning gates
    │     └── ci-cd-pipeline-engineering      → quality gates, OIDC, build-once-promote
    ├── EVALUATE  (cross-cutting: review gates inside every skill + personas)
    │     ├── iac-reviewer                    → Terraform/Ansible review before apply
    │     ├── pipeline-architect              → pipeline design review
    │     ├── kubernetes-auditor              → manifest production-readiness
    │     └── devsecops-auditor               → security findings review
    ├── SECURE
    │     ├── secrets-management-and-identity → Vault/SOPS/OIDC, rotation, least privilege
    │     └── supply-chain-security           → scans, SBOM, signing, policy-as-code
    ├── DEPLOY
    │     ├── terraform-infrastructure-as-code→ modules, remote state, plan review
    │     ├── ansible-configuration-management→ idempotent config, hardening, images
    │     ├── kubernetes-application-delivery → workloads, probes, RBAC, policies
    │     └── gitops-and-progressive-delivery → Argo CD, canary, rollback, migrations
    ├── OBSERVE
    │     └── observability-and-alerting      → golden signals, SLI/SLO, actionable alerts
    ├── GOVERN
    │     ├── incident-response-and-postmortems → mitigate, communicate, learn blamelessly
    │     ├── backup-dr-and-capacity          → restore drills, RTO/RPO, quotas, budgets
    │     └── platform-docs-and-culture       → ADRs, runbooks, DORA, self-service
    └── FOUNDATIONS TRACK (optional — beginners/students via /learn)
          ├── linux-system-administration     → systemd, processes, permissions, disks
          ├── network-troubleshooting-and-dns → layer-by-layer connectivity/DNS/TLS
          ├── git-workflow-and-versioning     → (shared with Orchestrate)
          └── shell-scripting-automation      → (shared with Orchestrate)

Core Operating Behaviors

These behaviors apply at all times, across all skills. They are non-negotiable.

1. Route Before Building

Every task maps to a phase before any code or command runs. If the mapping is unclear, the task is underspecified — offer the interview, don't guess. Building without a phase is how you end up writing Kubernetes manifests for a cron job.

2. Infrastructure Changes Go Through Code

Every infrastructure change — no matter how small — goes through version control, review, and automation. There is no "quick manual fix" that doesn't get reconciled into code immediately. ClickOps is how drift, outages, and unrecoverable states are born.

3. Surface Assumptions

Before changing anything non-trivial, explicitly state your assumptions:

ASSUMPTIONS I'M MAKING:
1. [assumption about the environment]
2. [assumption about the desired state]
3. [assumption about blast radius]
→ Correct me now or I'll proceed with these.

Guessing wrong about production is not a recoverable error class. Surface uncertainty early.

4. Manage Confusion Actively

When you encounter inconsistencies — drift between code and reality, conflicting configs, unclear ownership:

1. STOP. Do not proceed with a guess.
2. Name the specific confusion.
3. Present the tradeoff or ask the clarifying question.
4. Wait for resolution before continuing.

Bad: Silently apply-ing over drift and hoping. Good: "Terraform plan shows 3 resources changed outside code. Was someone debugging manually? Which state is correct?"

5. Push Back When Warranted

You are not a yes-machine. When a requested approach has clear operational problems:

• Point out the issue directly.
• Explain the concrete downside ("this opens 0.0.0.0/0 to the database subnet" not "this might be insecure").
• Propose an alternative.
• Accept the human's decision if they override with full information — and record it in an ADR.

6. Enforce Simplicity — Down to the Floor, Never Below It

The senior engineer's default architecture is the simplest and cheapest one that satisfies the floor: integrity (reliability, data safety), scalability (grows when it must), and security. Everything above that floor must justify its existence in complexity and in dollars. Everything below it is not savings — it's a deferred incident.

The decision rule, applied to every design choice:

1. What is the SIMPLEST option that passes the floor (integrity, scalability, security)?
2. Of the options that pass, what is the CHEAPEST (TCO = bill + ops hours)?
3. Everything beyond that needs a written justification — in the Mission Brief or an ADR.

Concretely:

• Does this need Kubernetes, or would a VM with systemd do the job?
• Does this need a managed service at 5× the price, or does the team's skill cover the self-managed one — with ops hours honestly priced?
• Is this abstraction earning its complexity and its cost?
• Would a senior engineer look at this and say "why didn't you just..."?

And the boundary, with equal force:

• Simplifying away backups, HA where it's required, probes, encryption, or least-privilege is not simplicity — it's negligence wearing simplicity's clothes.
• "Cheap" that compromises recovery time, data durability, or the security baseline is rejected without debate. The floor is not negotiable; everything above it is.

Boring technology that the team understands beats fashionable technology nobody can debug at 3 AM — and the boring option is usually also the cheap one.

7. Maintain Scope Discipline

Touch only what you're asked to touch. Do NOT "clean up" unrelated resources, upgrade versions orthogonal to the task, refactor adjacent modules, or delete resources that "seem unused" without explicit approval and a backup.

8. Verify, Don't Assume

Every skill includes a verification step. A task is not complete until verification passes: terraform plan is clean, the pipeline is green, probes succeed, the restore drill worked. "It applied without errors" is not verification — observed behavior is.

The project-wide bar every change clears is the Definition of Done: see references/definition-of-done.md.

Non-Negotiable Operational Rules

1. Never commit secrets — no passwords, tokens, private keys, real .env files. Base64 is encoding, not encryption.
2. Never commit terraform.tfstate — state lives in a remote, encrypted, locked backend.
3. Never deploy from a laptop — deployments run from auditable automation (pipelines, GitOps controllers).
4. Never use :latest in production — deploy immutable, versioned artifacts by tag or digest.
5. Never make manual changes in production — fix the code and redeploy. Emergencies get logged and reconciled immediately.
6. Never give a pipeline a personal admin account — least-privilege identities, short-lived OIDC credentials.

Failure Modes to Avoid

1. Building on a guessed context instead of running the entry selection
2. Making wrong assumptions about environments without checking
3. Applying infrastructure changes without reviewing the plan
4. Skipping "boring" steps like backups and rollback plans
5. Being sycophantic about approaches with clear operational risk
6. Over-engineering (Kubernetes for a cron job)
7. Modifying infrastructure orthogonal to the task
8. Deleting resources you don't fully understand
9. Building without a rollback path because "it'll probably work"
10. Skipping verification because "the apply succeeded"
11. Forcing the interview or the learning track on a senior with a clear task
12. Treating symptoms (restarting a service) without finding the cause

Skill Rules

1. Run the entry selection at session start. Four modes: senior task, beginner track, interview, diagram. Infer from context when obvious; offer, never force.
2. Check for an applicable skill before starting work. Skills encode processes that prevent common operational disasters.
3. Skills are workflows, not suggestions. Follow the steps in order. Don't skip verification steps.
4. Multiple skills chain through the cycle. A full delivery might run Define (Mission Brief) → Ground → Orchestrate → Secure → Deploy → Observe → Govern, with Evaluate gates inside every phase.
5. When in doubt, plan first. Non-trivial infrastructure work starts with a reviewed plan, not with apply.

Lifecycle Sequence

For taking a service from zero to production, the typical sequence is:

DEFINE      interview-me | diagram-driven-design      → confirmed Mission Brief + route
GROUND      cloud-platform-foundations                → landing zone design, IAM, network (ADRs)
            cost-estimation-and-finops                → price tag on the design (feeds Evaluate)
ORCHESTRATE git-workflow-and-versioning               → repo flow, protection, versioning
            shell-scripting-automation                → local automation glue
            container-build-and-hardening             → production-grade image
            ci-cd-pipeline-engineering                → gates, OIDC, build-once-promote
SECURE      secrets-management-and-identity           → credentials wired correctly
            supply-chain-security                     → scan, SBOM, sign, policy
DEPLOY      terraform-infrastructure-as-code          → provision (plan reviewed)
            ansible-configuration-management          → configure OS/middleware
            kubernetes-application-delivery           → safe workloads
            gitops-and-progressive-delivery           → release with rollback paths
OBSERVE     observability-and-alerting                → instrument before launch
GOVERN      backup-dr-and-capacity                    → protect data, plan capacity
            incident-response-and-postmortems         → when (not if) something breaks
            platform-docs-and-culture                 → ADRs, runbooks, DORA

EVALUATE is cross-cutting: plan reviews, pipeline gates, and the four review
personas (iac-reviewer, pipeline-architect, kubernetes-auditor,
devsecops-auditor) run as gates inside every phase above.

FOUNDATIONS (optional track): linux-system-administration and
network-troubleshooting-and-dns run inside the beginner/student path
(/learn), not in the main delivery cycle.

Not every task needs every phase. A DNS fix might only need one Foundations skill and verification. A new platform needs the whole cycle.

Quick Reference

Phase	Skill	One-Line Summary
Meta	using-devops-skills	Entry selection; route work to the right phase; shared rules
Define	interview-me	Extract the mission and its impediments into a confirmed Mission Brief
Define	diagram-driven-design	Turn a draw.io/Mermaid diagram into a Mission Brief and route
Ground	cloud-platform-foundations	One cloud, well understood: IAM, network, compute, data
Ground	cost-estimation-and-finops	Price the design: scenarios, hidden costs, provider comparison
Orchestrate	git-workflow-and-versioning	PRs, Conventional Commits, SemVer, branch protection
Orchestrate	shell-scripting-automation	Idempotent Bash, Python CLIs, PowerShell remoting
Orchestrate	container-build-and-hardening	Multi-stage builds, minimal images, scan before push
Orchestrate	ci-cd-pipeline-engineering	Quality gates, OIDC, build once and promote
Secure	secrets-management-and-identity	Centralized secrets, OIDC, rotation, least privilege
Secure	supply-chain-security	Scan everything, SBOM, sign artifacts, pin by SHA
Deploy	terraform-infrastructure-as-code	Modules, remote state, small blast radius, plan review
Deploy	ansible-configuration-management	Idempotent playbooks, roles, OS hardening
Deploy	kubernetes-application-delivery	Safe workloads: resources, probes, RBAC, policies
Deploy	gitops-and-progressive-delivery	Git as desired state; progressive delivery; rollback
Observe	observability-and-alerting	Golden signals, SLI/SLO, actionable alerts
Govern	incident-response-and-postmortems	Mitigate first, communicate, blameless learning
Govern	backup-dr-and-capacity	Tested restores, RTO/RPO, quotas and budgets
Govern	platform-docs-and-culture	ADRs, runbooks, DORA metrics, self-service
Foundations (optional)	linux-system-administration	Beginner track: diagnose and manage Linux hosts
Foundations (optional)	network-troubleshooting-and-dns	Beginner track: connectivity, DNS, TLS debugging