How to use the Dep DevOps Engineer agent skill

What is an agent skill?

An agent skill is a folder containing a SKILL.md file. The file holds instructions and a description, and an agent that has the skill installed can load those instructions when a request matches the skill's purpose. The skill itself does not run code. It changes how the agent approaches the task.

The dep skill is listed under the name dep and its description is: handles containerization, CI/CD pipelines, and deployment setup.

What the skill makes the agent do

Dep covers the path between code that works locally and code running in production. It works on a finished artifact and makes it shippable. It does not write application logic and does not review code quality. The source says it is meant to work on code that has already been tested.

• Containerization: a Dockerfile using a pinned base image (not latest), multi-stage builds where appropriate, a non-root user in the final stage, a .dockerignore, a HEALTHCHECK instruction and documented ports.
• Local development: a docker-compose.yml with dependent services such as a database, cache or queue, with pinned image versions.
• CI/CD: a pipeline config for the target platform with lint, test, build, security-scan and deploy stages, where deploy runs only on specific branches such as main or release.
• Environment setup: a .env.example with comments, a secrets management strategy, and notes on build-time versus runtime variables.
• Verification and recovery: a post-deploy checklist (health endpoint, migrations, login flow, error monitoring, logs) and a rollback procedure.

Install the skill

Download the ZIP from the skill's page on this directory, then choose one of two routes. For a personal install, unzip it into ~/.claude/skills/. For a single project, unzip it into the project's .claude/skills/ folder so it applies only to that repository.

In the Claude apps you can instead upload the skill under Settings → Capabilities → Skills.

• Personal install: unzip into ~/.claude/skills/
• Project install: unzip into .claude/skills/ inside your repository
• Claude apps: Settings → Capabilities → Skills, then upload

How to trigger the skill with natural requests

You do not need a special command. Describe the deployment task in plain language and name your repository and target platform where you can. The source notes that the skill asks for a stated provider and will always ask when the target is ambiguous.

Works well for requests such as the examples below. Give the agent the repository, the test state and the hosting target.

• Set up a Dockerfile for this Node app, pin the base image and run as non-root.
• Write a GitHub Actions pipeline with lint, test, build, security scan and a deploy step that only runs on main.
• Create a .env.example for this project and tell me which variables are secrets.
• Draft a deployment checklist and rollback plan for our staging release to Cloud Run.

What you should provide

The skill works best on a repository that already has a passing test suite and a stated cloud or hosting provider. Without these the output may be incomplete. Infrastructure-as-code (Terraform, Pulumi or CloudFormation) is only generated when you have specified a cloud provider.

Some requirements sit outside the skill. Docker or another container tool is needed if you want to build or test the generated files. A CI platform account such as GitHub or GitLab is needed for pipelines to run there. A target provider is needed for infrastructure code.

• A repository with a passing test suite
• A stated target platform or cloud provider
• Docker or a container tool, if you want to build or test the files
• A CI platform account, if pipelines will run on GitHub or GitLab
• A target provider, if you want infrastructure as code

Safety notes: scripts and network

The skill's files are instructions only. According to the listing it runs no scripts and uses no network. It does not deploy anything itself. Generating deployment files does not authorise provisioning, paid resources, publication or production deployment.

Generated configs can contain mistakes. Review every file and run the verification steps yourself before anything reaches production. Keep real secrets out of the conversation and out of the repository. Any credentials you paste into the chat or place in the repo are your responsibility.

• Review every generated Dockerfile and pipeline before use
• Use reviewed action and image versions and least-privilege CI permissions
• Store secrets in a protected store such as GitHub Secrets or a secrets manager, never in committed env files
• Do not promise a fast rollback without measuring it; database reversal may need a separately verified restore

Tips for better output

Name the target platform and region up front. Say whether the app has a database, cache or queue, since the docker-compose file depends on it. If you have a recent test report, mention it, because the skill expects tested input.

Ask for one piece at a time when you are unsure. A pipeline-only or Dockerfile-only request is a supported subset of the full package.

• State the platform (for example Vercel, Railway, AWS ECS, GCP Cloud Run or self-hosted)
• List the backing services the app depends on
• Ask for a single file first and review it before requesting the full package