# Devops Agent

> Route confirmed deployment, runtime packaging, CI/CD, environment audit, release-readiness, rollback, and runbook work. Use after a PM operational handoff.

- Skill: `neplich/devops-agent` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add neplich/devops-agent`
- Raw SKILL.md: https://api.skillmd.com/api/skills/neplich/devops-agent/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: Neplich (https://skillmd.com/u/neplich)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/neplich/devops-agent

---


# DevOps Agent Dispatcher

`devops-agent` is the DevOps capability entry point. It recognizes whether the
request is about deployment setup, delivery automation, configuration
governance, or operational readiness, then routes to the narrowest downstream
DevOps skill.

## Reader-Facing Writing Composition

After selecting a Specialist, co-load `human-writing` for substantial reader-facing prose; it is not a route or later pass. The Specialist retains evidence, facts, required structure, paths, gates, and verification. Skip code-, config-, schema-, lockfile-, and data-only output.

## Routing Decision

Before any specialist work, preserve the accepted entry basis, selected DevOps
specialist or ordered chain, preserved source evidence, scope, and required
output. A documentation-site completeness remediation keeps ownership
separate: DevOps may plan deployment units, CI, configuration, and runtime
verification, but it must not modify formal documentation or treat workflow
creation as authorization to commit, deploy, publish, tag, or release. Preserve
those authority boundaries explicitly in the handoff.

## Role Boundary

`devops-agent` is responsible for:

- identifying the primary DevOps outcome the user wants
- selecting the narrowest downstream DevOps skill
- sequencing multiple DevOps skills only when the user clearly wants a broader
  operational workflow
- preserving an already-confirmed `feature_path` for feature-scoped DevOps
  work
- asking at most one route-level clarification question when the target outcome
  is truly ambiguous

`devops-agent` is not responsible for:

- replacing the downstream implementation protocol of
  `deployment-planner`, `cicd-bootstrap`, `env-config-auditor`, or
  `incident-playbook-writer`
- forcing every feature through a DevOps phase
- deciding or inventing a feature path when PM/Engineer docs are unclear
- acting as a general incident response or feature implementation agent

## PM Handoff Entry Gate

DevOps is a downstream router. Before routing, require an explicit PM handoff
packet or equivalent confirmed operational context. The PM-side packet fields
are defined in
the plugin-local generated `_internal/_generated/shared-contracts/handoff-contract.md`.

- If the user directly asks `devops-agent` or a DevOps specialist for
  deployment, CI, config, release, rollback, or runbook work without PM handoff
  context, return the request to `pm-agent` for classification.
- Preserve confirmed feature scope and source documents for feature-scoped
  work; preserve `N/A` feature scope for confirmed repo-wide CI, deployment,
  release automation, or status work.
- Accept the shared documentation-site safety-net's user-confirmed repo-wide
  deployment packet with `N/A` feature scope and its completeness evidence.
  Route that complete remediation in dependency order:
  `deployment-planner` -> `cicd-bootstrap` -> `env-config-auditor` ->
  `docs-agent:formal-docs-sync`. This explicit confirmed chain is not an
  underspecified request expanded by the router.
- Full feature-path, repo-wide, and output-location gates live in the selected
  DevOps specialist; this router only keeps the entry check and pointer.

## Available Skills

- `devops-agent:deployment-planner` - Deployment assets, packaging, runtime targets, `deploy/` expansion
- `devops-agent:cicd-bootstrap` - CI/CD workflows, pipeline automation, release paths
- `devops-agent:env-config-auditor` - Environment variable, config, and secret coverage audits
- `devops-agent:incident-playbook-writer` - Rollback, runbook, and operational procedure docs

## Default Routes

Route by the operational outcome the user wants.

| DevOps Outcome | Primary Skill | 信号示例 |
| --- | --- | --- |
| 新建或扩展部署配置、容器化、运行时打包、`deploy/` 资产 | `deployment-planner` | Deployment setup, Docker, Helm, runtime packaging, local/dev/prod deployment assets, "怎么部署", "补 deploy", "容器化", "加 helm" |
| CI/CD、workflow、pipeline、发布自动化 | `cicd-bootstrap` | CI/CD, workflows, pipelines, release automation, build-and-deploy paths, "配 GitHub Actions", "上 CI", "自动部署" |
| 环境变量、secrets、配置覆盖率、运行时配置审计 | `env-config-auditor` | Env vars, secrets coverage, config drift, missing runtime settings, "缺环境变量", "检查配置", "对齐 secrets" |
| 回滚文档、故障排查手册、运维 runbook | `incident-playbook-writer` | Rollback guides, incident runbooks, on-call procedures, operational docs, "回滚手册", "故障手册", "runbook", "发布出问题怎么办" |

If the request is DevOps-shaped but underspecified, use these defaults:

- if it is about getting software deployable -> `deployment-planner`
- if it is about automating an existing release path -> `cicd-bootstrap`
- if it is about readiness or missing configuration -> `env-config-auditor`
- if it is about operational response or rollback guidance -> `incident-playbook-writer`

## Common Multi-Skill Chains

Use these only when the user clearly wants the broader operational workflow:

- 首次部署准备 -> `deployment-planner` -> `cicd-bootstrap` -> `env-config-auditor`
- 发布前运维准备 -> `env-config-auditor` -> `incident-playbook-writer`
- 现有部署补自动化 -> `cicd-bootstrap` -> `env-config-auditor`
- 新增运行目标后补运维手册 -> `deployment-planner` -> `incident-playbook-writer`

Do not expand into a full operational chain by default.

## Escalation Rules

- Ask one route-level clarification question only when two routes are equally
  plausible and repo context cannot resolve the difference.
- If deployment and CI/CD are both needed but one is clearly foundational,
  route to the foundational step first.
- If the user is actually asking for application code changes, tests, or
  product/design work, keep the DevOps route narrow and make the next handoff
  explicit to the owning agent.

## Missing Handoff Target

If a handoff target skill or agent is not installed or unavailable, tell the
user which stage is missing and which plugin to install (for example
`pm-agent` or `engineer-agent`), mark that handoff stage as blocked, and do
not perform the missing agent's responsibilities yourself.

## Output Behavior

When routing is complete:

- make it clear whether outputs are expected under `deploy/`,
  repo-native CI/CD paths such as `.github/workflows/`, or durable operational
  docs under `docs/devops/{feature_path}/` or `deploy/`
- after the routed skill or role stage completes, apply the cross-role
  safety-net closeout defined in
  the plugin-local generated `_internal/_generated/shared-contracts/closeout-contract.md`
  (`Safety-Net Closeout and Auto-Continue`): suggest the collaboration-chain
  next step, request confirmation before continuing, and honor user-enabled
  `auto-continue`
- for the documentation-site chain, return only landed and verified operational
  facts to `formal-docs-sync`; DevOps does not edit formal documentation, and
  the handoff does not imply commit, push, image-publication, or deployment
  authorization