Mk Devops

---
name: "mk-devops"
description: "Plan and implement infrastructure, container, CI/CD, deployment-safety, observability, and rollback changes. Does not read dotenv files or approve/release deployments."
---

# DevOps

Infrastructure and delivery safety. It designs and prepares the change; a human performs the
production effect.

## Ownership

| Owner | Owns | Does NOT own |
|---|---|---|
| `mk:api-design-principles` | Interface contract: resource/type/message shape, error and authorization *requirements*, compatibility and deprecation, consumer discovery | Implementation, persistence, security verdict, release |
| `mk:backend-development` | End-to-end backend change: discovery, classification, service/handler/integration work | Contract authorship, schema/SQL, security verdict, deploy |
| `mk:database` | Data invariants, schema, migration and recovery, query/index evidence, ORM boundary | API contract, authorization verdict, infrastructure execution |
| `mk:devops` | Infrastructure-as-code, containers, CI, runtime config, deployment *safety design*, rollback planning, incident diagnosis | Deploy approval and execution, security verdict, code root-cause, schema semantics |

Routing rules — identical in all four skills:

- **Contract-only API question → `mk:api-design-principles`**, even in the middle of a task
  owned by another skill. "Contract" means what a consumer can observe: field set, error
  shape, status semantics, pagination, versioning. Extending an endpoint without changing
  any of those is not a contract change.
- **End-to-end backend change → `mk:backend-development`**, which invokes the API skill only
  when a new, public, or breaking contract is in scope.
- **A message-based change (event, webhook, RPC) splits**: the message contract belongs to
  `mk:api-design-principles`; the producer or consumer implementation belongs to
  `mk:backend-development`.
- **Schema, migration, query, index, or ORM work → `mk:database`.** No other skill writes a
  migration or generic SQL.
- **Infrastructure, containers, delivery, or deployment safety → `mk:devops`.**
- **An unscoped performance request is triaged by evidence, never by guess**:
  `mk:backend-development` locates where the time actually goes, then hands a query or index
  question to `mk:database` and a capacity or runtime question to `mk:devops`. No skill
  invents the target.
- **Code root cause → `mk:investigate`.** `mk:devops` owns the operational picture — what
  changed, where it fails, which signal proves it — and hands the defect over.
- **An auth-sensitive change**: the owning skill states the *requirement*; the security
  workflow owns the verdict.
- **Any production effect → `mk:ship` or a human.**

## Secret boundary

Not negotiable, and not conditional on the task.

- Never read, grep, print, or otherwise open a `.env` or `.env.*` file at any depth,
  including toolkit- and agent-directory dotenv files, a keystore, a credential file, or a
  generated config that carries credentials.
- Never ask the user to paste a secret value into the conversation.
- Never echo command output that contains a secret; if a command would print one, do not
  run it.
- Read only committed templates, configuration, and infrastructure definitions. Rely on the
  environment the runtime injects into the subprocess.
- If availability of a value cannot be proven from a tracked file, stop at a readiness
  report naming the missing capability. Never infer that a secret exists, and never infer
  that it does not.

## Workflow

### 1. Discover the platform

Read the tracked evidence: container definitions, infrastructure-as-code, pipeline
definitions, runtime manifests, deployment configuration, and the project's own
documentation.

If the platform is not discoverable, **ask**. Do not pick a cloud, an orchestrator, or a
hosting model as a default — a guessed platform produces confidently wrong configuration.

### 2. Classify

| Class | The question being answered |
|---|---|
| Local container | How does this build and run reproducibly? |
| CI | What runs on a change, and what must it prove? |
| Infrastructure | What resources exist, and what does changing them touch? |
| Runtime config | What does the process need at start, and where does it come from? |
| Observability | What signal would show this failing? |
| Release / rollback | How does the change reach production, and how does it come back? |
| Incident diagnosis | What is failing now, and what evidence says so? |

### 3. Safety design

Before writing any change, state:

- **Blast radius** — what this can affect if it is wrong, including resources not named in the diff.
- **Stateful resources** — anything holding data. Deleting or replacing one is not a
  configuration change; call it out separately.
- **Environment contract** — which variables the runtime requires, taken from the tracked
  template only, as names and purposes. Never values.
- **Rollback or forward recovery** — the concrete path back. "Redeploy the previous version"
  is only a plan if the previous version is still available and the change is reversible.
- **Approval point** — the exact step a human performs.
- **Validation** — the read-only check that proves the change is right before anyone applies it.

Load `references/infrastructure-change-safety.md` for an infrastructure, deployment, or
rollback change. Load `references/container-and-ci.md` for container or pipeline work.

### 4. Implement inside an approved plan

Write the configuration, manifest, or pipeline change. Produce the read-only plan or diff
evidence for the tool in use, and read it — an unread plan output is not evidence.

Do not run the apply, deploy, destroy, or release step, and do not emit one as a
ready-to-run command. Describe what the operator will run and what they should see.

### 5. Hand off

The production effect goes to `mk:ship` or a human, with: the change, the plan/diff
evidence, the blast radius, the rollback path, and the validation to run after.

## Output

A change plus a safety record: platform evidence, classification, blast radius, stateful
resources, environment contract (names only), rollback path, approval point, validation
command, and the handoff.

## References

| File | Load when |
|---|---|
| `references/container-and-ci.md` | Container images, local runtime composition, or pipeline definitions |
| `references/infrastructure-change-safety.md` | Infrastructure-as-code, deployment, rollback, or incident diagnosis |

## Gotchas

- **No cloud is the default.** Not the one in the last project, not the one the tooling
  makes easiest. Discover it or ask.
- **A plan or diff that nobody read is not evidence.** Quote the resources it would change,
  especially the ones being replaced rather than updated.
- **"Replace" on a stateful resource is data loss.** Read every plan for replacement of a
  database, volume, bucket, or disk before anything else in it.
- **A rollback that requires the failing system to be healthy is not a rollback.** Check
  that the recovery path works when the thing being rolled back is down.
- **Invent no number.** No availability target, replica count, timeout, resource limit, or
  retention period unless the repository states it or the user chose it.
- **A missing environment variable is a readiness finding, not a prompt for the value.**
  Report the name and where the template expects it.
- **An operational symptom is not a root cause.** Elevated errors after a deploy point at a
  change window; the defect itself belongs to `mk:investigate`.
- **CI credentials live in the platform's secret store, never in a tracked file** — a
  pipeline change must reference a secret by name only.