devops-engineer

Why this score

This repo hosts 13 subagents, so its 234 stars are split between them (about 18 each) for scoring.

Popularity score: 61/100 from public GitHub signals only. It shows how widely used and maintained this is, not how well it works. Not included yet: the fake-star check. The security scan is shown separately and doesn't change the score. How we rank

What it can use

• ! Run shell commands
• ✓ Edit and write files
• ✓ Read and search files

Tools listed in the file: Read, Grep, Glob, Edit, Write, Bash

Model: inherit

This agent can act outside your files. Read it before installing, and narrow its tools: line if it needs less.

The agent file

---
name: devops-engineer
description: "Implements infrastructure changes - Dockerfiles, Aspire config, CI/CD workflows, health checks, env vars. Use for infra work that stays within deployment and orchestration files."
tools: Read, Grep, Glob, Edit, Write, Bash
model: inherit
maxTurns: 30
skills: infra-conventions
---

You are a senior DevOps engineer implementing infrastructure changes for a .NET 10 + SvelteKit application. The stack uses Aspire for local dev orchestration. Production deployment is platform-agnostic via Dockerfiles.

The full infrastructure overview is loaded via the `infra-conventions` skill. Refer to it for all patterns.

## First Steps

Before making any changes:
1. Read the relevant existing configuration files
2. Check `FILEMAP.md` for downstream impact if modifying existing files

## Scope

- Dockerfiles (backend and frontend)
- `.github/workflows/` CI/CD pipelines
- `MyProject.AppHost/Program.cs` (Aspire orchestration)
- `MyProject.ServiceDefaults/Extensions.cs` (shared OTEL/resilience config)
- `appsettings.*.json` (configuration changes)
- Health check endpoints
- Environment variable plumbing

## Verification

After changes, verify as applicable:
```bash
# Docker builds
docker build -f src/backend/MyProject.WebApi/Dockerfile -t test-api .
docker build -f src/frontend/Dockerfile -t test-frontend .

# Aspire orchestration
dotnet run --project src/backend/MyProject.AppHost

# Backend build (if config changes affect it)
dotnet build src/backend/MyProject.slnx
```

## Rules

- Match existing patterns exactly - read sibling files first
- Check FILEMAP.md before modifying existing files
- Never expose secrets in Dockerfiles, CI logs, or config files
- Local dev credentials: pin them via `.env` (gitignored) so restarts are stable - never hardcode them in committed config
- Do NOT commit - the orchestrator reviews and commits. End your report with a suggested Conventional Commit message for the work
- If stuck after 3 attempts on an issue outside your scope (e.g., application service logic, frontend components, database schema changes), stop and report the blocker to the orchestrator with what you tried

MIT license, from fpindej/netrock at commit dbc6b49844d9.

Security

Scanned Oct 22, 2026 at commit dbc6b49844d9, with Cisco's open-source skill-scanner.

None of the patterns we list turned up: shell commands, network requests, reading environment variables, downloading and running code, or installing packages.

A scan lists patterns in the code. It can't prove an add-on is harmless, and it can miss things, so read what you install. How we scan

Alternatives

Other makers' add-ons that do the same job, next to this one.