kevinzai/commander/ccc-devops

/ccc-devops — DevOps work, routed

CC Commander · ccc-devops · one router that loads the DevOps sub-skill, or short chain of them, the job needs.

Each sub-skill lives in its own directory beside this file. Read ${CLAUDE_SKILL_DIR}/<sub-skill>/SKILL.md (on Codex, the same path relative to this file) and follow it. Some sub-skills ship helper scripts under their own scripts/ directory; their SKILL.md names them. The user's selected model is preserved.

Codex: ask each picker as a plain-text question with the same options.

Sub-skills

Per-intent routing, "don't confuse with" pairs and campaign chains: references/routing.md.

When to use / when not to

• Use for pipelines, deploy strategy, containers, cloud architecture, Terraform, observability, network design, infrastructure hardening and incident runbooks.
• Use ccc-security for application-level security review, ccc-testing for test strategy, ccc-saas for application architecture.

What happens

1. Detect the toolchain. Run in one Bash call, silent on failure:

``bash ls .github/workflows .gitlab-ci.yml Dockerfile docker-compose.yml compose.yaml serverless.yml template.yaml cdk.json prometheus.yml 2>/dev/null ls *.tf terraform 2>/dev/null | head -5 git remote get-url origin 2>/dev/null ``

Report one line: 🏗️ Toolchain: <CI, containers, IaC, cloud detected | none detected>.

1. Confirm constraints. For infrastructure work, confirm the cloud provider, toolchain and environment (dev, staging, production) before proceeding. Ask only for what step 1 did not answer.

1. Route. An argument or a clear intent picks the sub-skill or chain from references/routing.md. Otherwise ask with AskUserQuestion (header "DevOps"), recommended first. Recommend CI/CD when step 1 found no pipeline; recommend Containers or cloud when a pipeline exists but no Dockerfile or IaC:

• 🟢 CI/CD pipeline — cicd-pipeline-generator + github-actions-security
• Deploy strategy — zero-downtime-deploy + senior-devops
• Containers or cloud infra — docker-development, terraform-patterns, the AWS sub-skills
• Something else — a follow-up picker with monitoring, security hardening, networking and runbooks

1. Load and run. Read ${CLAUDE_SKILL_DIR}/<sub-skill>/SKILL.md for each step of the chain and follow it.

1. Verify locally, without touching live infrastructure. Run whichever apply to the change, then git status --short:

``bash terraform fmt -check && terraform validate # Terraform terraform plan -out=tfplan # only with the user's credentials already configured; never apply docker build -t local-check . # Dockerfile command -v actionlint >/dev/null && actionlint # GitHub Actions promtool check config prometheus.yml # Prometheus, when promtool is installed ``

On failure, report the output and fix before continuing. When a tool is not installed, say so instead of claiming the check passed.

Done when

• Every validation command that applies to the change ran in this turn and its result is reported.
• git status --short lists only the files the task meant to touch.
• A plan (terraform plan, deploy strategy) is presented as a plan; nothing was applied.

Guardrails

• Never run terraform apply, kubectl apply, helm upgrade, a cloud CLI write (aws ... create|delete|put|update), a deploy, or a push that triggers one without authorization in this conversation; ask with a picker at that step.
• Never write secrets, keys or tokens into workflow files, Dockerfiles, Terraform or runbooks; use the platform's secret store or OIDC.
• Never widen IAM permissions, open security groups to 0.0.0.0/0, or disable branch protection to make something work.
• Never print environment dumps or secret-bearing output while diagnosing.

See also

• ccc-security — application security review
• ccc-testing — tests the pipeline runs
• ccc-saas — application architecture behind the infrastructure