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.

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 agents/product_manager/skills/idea-to-spec/_internal/_shared/skill-map.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.

• 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

Routing Signals

Route by the operational outcome the user wants.

• Deployment setup, Docker, Helm, runtime packaging, local/dev/prod deployment

assets, "怎么部署", "补 deploy", "容器化", "加 helm" -> deployment-planner

• CI/CD, workflows, pipelines, release automation, build-and-deploy paths,

"配 GitHub Actions", "上 CI", "自动部署" -> cicd-bootstrap

• Env vars, secrets coverage, config drift, missing runtime settings,

"缺环境变量", "检查配置", "对齐 secrets" -> env-config-auditor

• Rollback guides, incident runbooks, on-call procedures, operational docs,

"回滚手册", "故障手册", "runbook", "发布出问题怎么办" -> incident-playbook-writer

Default Routes

| DevOps Outcome | Primary Skill | | --- | --- | | 新建或扩展部署配置、容器化、运行时打包、deploy/ 资产 | deployment-planner | | CI/CD、workflow、pipeline、发布自动化 | cicd-bootstrap | | 环境变量、secrets、配置覆盖率、运行时配置审计 | env-config-auditor | | 回滚文档、故障排查手册、运维 runbook | incident-playbook-writer |

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:

• state which DevOps skill should handle the request
• if relevant, state the follow-up DevOps chain
• 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 agents/product_manager/skills/idea-to-spec/_internal/_shared/skill-map.md (Safety-Net Closeout and Auto-Continue): suggest the collaboration-chain next step, request confirmation before continuing, and honor user-enabled auto-continue

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Neplich
• Source: Neplich/dev-agent-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.