Try β€œClaude Code skills”, β€œMCP servers for Cursor” or β€œCodex” Β· Esc to close

A Vibe Coding Stack for a DevOps Engineer

By Kelvin Β· 02 October 2026 Β· Updated 02 Oct 2026 Β· 8 min read

devops claude-code mcp-servers agent-skills workflow

A Vibe Coding Stack for a DevOps Engineer
Photo by Brett Sayles on Pexels

A Vibe Coding Stack for a DevOps Engineer

A backend developer pointing a coding agent at a feature branch is one kind of risk. A DevOps engineer pointing the same agent at a Kubernetes cluster, a Terraform state file, or a production incident channel is a different kind entirely. The upside is real β€” an agent that can read a stack trace, open the right dashboard, and draft the fix without you tabbing between six tools β€” but the blast radius is bigger, and "it deleted a test file" turns into "it deleted a namespace."

This post puts together a stack for that job specifically: one agent, a skill pack that actually knows infrastructure, a guardrail layer that screens actions before they run, a way to watch what every agent session is doing, and three MCP servers that connect it to the tools a DevOps engineer actually lives in β€” errors, clusters, and tickets.

Open laptop showing code on a desk
Photo by Daniil Komov on Pexels

The base: an agent built for hooks and CI, not just chat

Claude Code is the obvious anchor here, not because it's the only capable terminal agent but because of what it's built to plug into. It reads a CLAUDE.md for project context, keeps automatic memory between sessions, and β€” more relevant for this stack β€” supports hooks that run your own shell commands before or after the agent acts, plus native GitHub Actions and GitLab CI/CD integration. That combination means you can insert real checks (a policy script, a dry-run plan, a Slack ping) at the exact moment an agent is about to do something, rather than hoping it stays within scope.

Install is a one-liner on macOS, Linux and WSL:

curl -fsSL https://claude.ai/install.sh | bash

Homebrew (brew install --cask claude-code) and WinGet are documented alternatives. From there, everything below β€” skills, plugins, MCP servers β€” layers on top of the same CLI.

Skills that actually know your infrastructure

A generic coding agent will happily write a Terraform resource block with the wrong provider version pinned, or a Dockerfile that ignores your base-image policy. What closes that gap is a skill pack written specifically for the DevOps side of full-stack work. Claude Skills (Fullstack Dev Skills) bundles 67 skills covering languages and frameworks alongside DevOps and security workflows, plus Jira integration for the ticket side of the job.

Inside Claude Code, it installs as a plugin:

/plugin marketplace add jeffallan/claude-skills
/plugin install fullstack-dev-skills@jeffallan

Agent Skills load on demand β€” the agent only pulls in the DevOps-specific instructions when a task actually calls for them, so you're not paying a context-window tax for skills you're not using on a given ticket.

Guardrails before anything ships

The riskiest part of handing an agent infrastructure access isn't a single bad command β€” it's a bad command running unreviewed because nobody was watching that session. ECC (Everything Claude Code) is worth layering in specifically for its AgentShield scanning and hooks, on top of a large bundled set of roughly 290 skills and 68 agents. The scanning piece matters most for this stack: it's a layer that screens agent actions rather than trusting the model's judgment alone.

npx [email protected] setup

Or, from inside Claude Code:

/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc

This is also where the hooks from the base Claude Code install earn their keep: a PreToolUse hook that blocks kubectl delete against a production context, or that requires a Terraform plan to be reviewed before apply, costs a few lines of shell and removes an entire class of "the agent did something destructive while I was in a meeting" incidents.

Watching the fleet, not just one session

Once you're running more than one agent session β€” one on an incident, one scaffolding a new service, one triaging a backlog of Dependabot PRs β€” you need visibility into what each one is actually doing, not just a terminal window you have to Alt-Tab to. Claude Code Agent Monitor is a self-hosted, real-time dashboard for Claude Code and Codex sessions: agents, tool calls, and running cost, all in one view.

Claude Code Agent Monitor πŸ€– AgentOpen source

Self-hosted real-time dashboard for Claude Code and Codex sessions, agents, tools and cost

β˜… 1.0k Β· +23 this week

git clone https://github.com/hoangsonww/Claude-Code-Agent-Monitor.git
cd Claude-Code-Agent-Monitor
npm run setup
npm run install-hooks
npm run dev

For a DevOps engineer specifically, the cost tracking matters as much as the activity feed β€” a runaway agent loop against a large repo can burn through a token budget fast, and a dashboard that surfaces that in real time is cheaper than finding out at the end of the month.

Network cables plugged into a server rack
Photo by Brett Sayles on Pexels

Reaching your actual infrastructure: MCP servers

Skills and hooks shape how the agent behaves; MCP servers decide what it can actually touch. For this stack, three servers cover the loop a DevOps engineer runs daily β€” see an error, check the cluster, track the fix β€” and each comes from a different part of the ecosystem:

ServerWhat it connects toCategory
Sentry MCPErrors, stack traces, issuesDev tools
Kubernetes MCP ServerPods, logs, any resource, HelmCloud infrastructure
Linear MCPIssues, projects, commentsProductivity
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/{organizationSlug}/{projectSlug}

Scoping it to a single project, as shown above, keeps the agent from browsing every error across every team by default.

Kubernetes MCP Server πŸ”Œ MCP serverOpen source

Native Go MCP server for Kubernetes and OpenShift: pods, logs, any resource, Helm and more

β˜… 2.1k Β· +20 this week

claude mcp add-json kubernetes-mcp-server \
  '{"command":"npx","args":["-y","kubernetes-mcp-server@latest","--read-only"],"env":{"KUBECONFIG":"'${HOME}'/.kube/mcp-viewer.kubeconfig"}}' \
  -s user

That --read-only flag and a dedicated viewer kubeconfig aren't decoration β€” they're the difference between an agent that can describe a crashing pod and one that can also delete it. Start read-only, and only widen scope for a specific session once you trust the workflow.

claude mcp add --transport http linear-server https://mcp.linear.app/mcp

After adding it, run /mcp inside Claude Code and complete the OAuth sign-in in your browser β€” this one authenticates per user rather than per API key, which matters if more than one engineer shares the same agent setup.

Putting it together: what a session actually looks like

With all five pieces installed, a realistic incident-response flow looks like this:

  1. An alert fires; you point Claude Code at the Sentry MCP server to pull the stack trace and recent error volume.
  2. The agent cross-references the error with the Kubernetes MCP server, read-only, to check pod status and recent logs in the affected namespace.
  3. A DevOps skill from the Fullstack Dev Skills pack drafts the fix β€” a config change, a rollback command, a patched Dockerfile.
  4. A hook (backed by ECC's scanning) intercepts anything that touches a production-tagged context and requires explicit confirmation before it runs.
  5. Once applied, the agent files or updates the incident ticket through the Linear MCP server, and the Agent Monitor dashboard shows the session's full tool-call history and cost for the post-incident review.

None of that requires the agent to have unrestricted access to anything β€” each piece narrows scope rather than widening it, which is the actual design goal for this role.

Not every week is an incident. A quieter, more common flow looks like this instead: a teammate opens a ticket in Linear asking for a new staging environment variable to be rolled out across three services. You hand the ticket description to Claude Code, it reads the Linear MCP server to pull the full context and acceptance criteria, uses a DevOps skill from the Fullstack Dev Skills pack to locate every place the variable needs to be added (Helm values, a Terraform variable block, a CI secret reference), and drafts the changes as a single PR rather than three separate ones. The Kubernetes MCP server, still read-only, confirms the current rollout state before anything is proposed. Nothing here touches a live cluster directly β€” the agent proposes, a human applies β€” which is the right default for anyone running this stack on a production account rather than a sandbox.

If you're not on Claude Code

The specific commands above are Claude Code's, but the shape of the stack isn't locked to one vendor. MCP is an open protocol, so the same Sentry, Kubernetes and Linear servers connect the same way to Cursor, OpenCode or any other app that speaks MCP β€” only the add-server command differs. Agent Skills are similarly portable: a skill written as a SKILL.md file works in any agent that supports the format, and the Fullstack Dev Skills pack and ECC both target that standard rather than a single app's proprietary plugin system. The one piece that's genuinely Claude-Code-specific here is the hooks configuration syntax; other agents that support hooks (several do, including Cursor) use their own config format for the same underlying idea β€” intercepting an action before it runs.

What it costs

Most of this stack is free or open-source; the main recurring cost is the agent plan itself.

ComponentPricing
Claude CodeIncluded in paid Claude plans (Pro, Max, Team); no free tier
Fullstack Dev SkillsFree, open-source plugin
ECCFreemium β€” core setup is free
Claude Code Agent MonitorFree, self-hosted
Sentry MCPFreemium, tied to your Sentry plan
Kubernetes MCP ServerFree, open-source
Linear MCPFreemium, tied to your Linear plan

Check current plan pricing on each vendor's own page before budgeting β€” see /deals for active student, startup and annual-billing discounts across the directory, including on Claude Code itself.

Where to go from here

This is a starting stack, not a fixed one. If your infrastructure runs on AWS or Cloudflare instead of a self-managed Kubernetes cluster, swap in the matching MCP server from /ecosystem β€” the pattern of "one error-tracking server, one infrastructure server, one ticketing server" holds regardless of which specific vendors you use. If you're new to any of the underlying concepts here, the glossary covers hooks, MCP, and Agent Skills in plain terms, and Claude Code's own skills, subagents and MCP server listings are worth browsing directly for anything more specific to your stack.

The takeaway: the risk in giving an agent DevOps access isn't the agent itself β€” it's unscoped access. Read-only kubeconfigs, project-scoped Sentry servers, and hooks that gate destructive commands turn "an agent with production access" into "an agent with exactly the access this task needs," which is the only version of that sentence worth shipping.

Mentioned in this post

Kubernetes MCP Server πŸ”Œ MCP serverOpen source

Native Go MCP server for Kubernetes and OpenShift: pods, logs, any resource, Helm and more

β˜… 2.1k Β· +20 this week

Claude Code Agent Monitor πŸ€– AgentOpen source

Self-hosted real-time dashboard for Claude Code and Codex sessions, agents, tools and cost

β˜… 1.0k Β· +23 this week

More from the blog

Building your vibe coding stack?

Browse 296 apps, skills, subagents and MCP servers, mapped to the apps they work with.

See the ecosystem map