Devops
Audit deployment readiness across CI/CD, containers, monitoring, IaC, secrets, CDN, and DNS — score each area 0-100, identify critical gaps, and optionally auto-fix by chaining deploy sub-skillsFrom its SKILL.md
npx -y skills add tinh2/skills-hub-registry --skill devopsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
9.2 KB, ~2.1k tokens by cl100k_base, as published. Nobody here has run it
You are in AUTONOMOUS MODE. Do NOT ask questions. Do NOT pause for confirmation. Execute every phase below in sequence, making decisions based on what you find.
============================================================ PHASE 0 — INPUT
$ARGUMENTS may contain:
- A specific sub-area to focus on:
ci,docker,k8s,monitoring,terraform,secrets,cdn,dns --report-only— produce the readiness report without generating or modifying files--fix— attempt to fix all identified gaps by chaining sub-skills- A target environment:
aws,gcp,azure,fly,vercel - If no arguments, default to
--report-only
============================================================ PHASE 1 — INFRASTRUCTURE DISCOVERY
Scan the entire project root for existing infrastructure artifacts:
- CI/CD:
.github/workflows/,.gitlab-ci.yml,Jenkinsfile,.circleci/,bitbucket-pipelines.yml - Containers:
Dockerfile,docker-compose.yml,docker-compose.*.yml,.dockerignore - Kubernetes:
k8s/,kubernetes/,helm/,charts/, any*.yamlwithapiVersion: apps/ - IaC:
terraform/,*.tf,pulumi/,Pulumi.yaml,cdk/,cloudformation/ - Monitoring:
prometheus.yml,grafana/,datadog.yaml,.newrelic.yml,alertmanager.yml - Secrets:
.env,.env.*,vault/,secrets/, hardcoded API keys or tokens in source - CDN:
cdn/, Cloudflare config (wrangler.toml), CloudFront references in Terraform - DNS: DNS records in Terraform, Cloudflare zone configs, Route53 references
Also detect the application stack:
- Language: Check
package.json,go.mod,Cargo.toml,requirements.txt,pyproject.toml,Gemfile,pubspec.yaml,pom.xml,build.gradle - Framework: Next.js, Fastify, Express, Django, Flask, FastAPI, Gin, Actix, Rails, Spring Boot, Flutter
- Database: Prisma schema, SQLAlchemy models, GORM, ActiveRecord, TypeORM
Store all findings in memory for scoring.
============================================================ PHASE 2 — READINESS SCORING
Score each area on a 0-100 scale using the rubric below. Be precise — partial credit is valid (e.g., 35 or 65).
| Area | 0 | 25 | 50 | 75 | 100 |
|---|---|---|---|---|---|
| CI/CD | Nothing | Basic lint/test | PR checks + deploy | + caching + matrix | + security scan + preview deploys |
| Containers | Nothing | Dockerfile exists | + multi-stage | + compose + healthcheck | + non-root + .dockerignore + optimized layers |
| Kubernetes | Nothing | Basic deployment | + service + ingress | + HPA + probes | + PDB + resource limits + Helm |
| IaC | Nothing | Single resource | Modular structure | + remote state + envs | + cost tags + proper naming + outputs |
| Monitoring | Nothing | Basic logging | Metrics endpoint | + dashboards + alerts | + SLOs + distributed tracing |
| Secrets | Hardcoded values | .env files | Secrets manager | + rotation | + CI integration + audit trail |
| CDN | Nothing | Static hosting | CDN configured | + caching rules | + edge functions + invalidation |
| DNS | Nothing | Manual records | IaC-managed | + SSL + subdomains | + email DNS + health routing |
Calculate an overall Deployment Readiness Score as the weighted average:
- CI/CD: 25%
- Containers: 20%
- Monitoring: 15%
- IaC: 15%
- Secrets: 10%
- Kubernetes: 5% (0-weight if app is serverless/edge)
- CDN: 5%
- DNS: 5%
============================================================ PHASE 3 — GAP ANALYSIS
For each area scoring below 50, generate a specific remediation plan:
- What is missing (concrete, not vague)
- Which sub-skill can fix it (reference:
deploy/github-actions,deploy/docker,deploy/k8s,deploy/monitoring,deploy/terraform,deploy/secrets,deploy/cdn,deploy/dns) - Estimated effort: quick (<5 min), moderate (5-15 min), significant (15+ min)
- Priority based on:
- Critical: No CI/CD, secrets in source code, no containerization for production app
- High: No monitoring, no IaC for cloud resources, no health checks
- Medium: Missing caching, no preview deploys, basic Kubernetes without HPA
- Low: No CDN, no email DNS, no edge functions
============================================================ PHASE 4 — REMEDIATION (if --fix)
If --fix was passed, execute remediations in priority order:
- Critical items first — fix secrets exposure, add basic CI/CD
- High items next — add Dockerfile, monitoring, IaC
- Medium items — optimize CI caching, add HPA, preview deploys
- Low items — CDN, DNS, edge functions
For each remediation:
- Read the sub-skill's approach and apply it inline (do not shell out)
- After each fix, re-score that area and record the before/after delta
- Stop if cumulative changes exceed 20 new files (to avoid overwhelming a single PR)
============================================================ PHASE 5 — OUTPUT
Generate a deployment readiness report. Print to stdout AND write to DEPLOY_READINESS.md in the project root.
## Deployment Readiness Report
**Project**: {detected project name}
**Stack**: {language} / {framework} / {database}
**Date**: {current date}
**Overall Score**: {score}/100
### Area Scores
| Area | Score | Status | Key Finding |
|------|-------|--------|-------------|
| CI/CD | XX | PASS/WARN/FAIL | {one-line summary} |
| Containers | XX | PASS/WARN/FAIL | {one-line summary} |
| Kubernetes | XX | PASS/WARN/FAIL | {one-line summary} |
| IaC | XX | PASS/WARN/FAIL | {one-line summary} |
| Monitoring | XX | PASS/WARN/FAIL | {one-line summary} |
| Secrets | XX | PASS/WARN/FAIL | {one-line summary} |
| CDN | XX | PASS/WARN/FAIL | {one-line summary} |
| DNS | XX | PASS/WARN/FAIL | {one-line summary} |
### Critical Gaps
{list of critical and high priority gaps with sub-skill references}
### Recommended Actions
{ordered list of remediations — each with sub-skill name, estimated effort, and expected score improvement}
### Changes Made (if --fix)
{list of files created/modified with before/after scores}
Use PASS for scores >= 75, WARN for 50-74, FAIL for < 50.
============================================================ SELF-HEALING VALIDATION (max 2 iterations)
After completing deployment/infrastructure changes, validate:
- Verify all generated files are syntactically valid (YAML, JSON, HCL, Dockerfile).
- Run validation commands if available (terraform validate, docker build --check, kubectl dry-run).
- Verify no secrets, credentials, or sensitive values are hardcoded.
- If validation fails, diagnose and fix the specific syntax or config error.
- Repeat up to 2 iterations.
IF STILL FAILING after 2 iterations:
- Document what failed and the exact error
- Include partial output if available
============================================================ NEXT STEPS
After generating the report, suggest:
- Which sub-skill to run first if gaps exist (with the exact command)
- Whether the project is ready for production deployment
- Any architectural concerns (e.g., no database backups, no rate limiting, no disaster recovery)
============================================================ SELF-EVOLUTION TELEMETRY
After producing output, record execution metadata for the /evolve pipeline.
Check if a project memory directory exists:
- Look for the project path in
~/.claude/projects/ - If found, append to
skill-telemetry.mdin that memory directory
Entry format:
### /devops — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}
Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.
============================================================ DO NOT
- Do NOT delete existing infrastructure files — only add or modify
- Do NOT commit changes — leave them staged for review
- Do NOT expose secrets in the report output
- Do NOT assume a cloud provider — detect or use $ARGUMENTS
- Do NOT generate Kubernetes manifests for projects that are clearly serverless/edge
- Do NOT modify application source code — only infrastructure files
- Do NOT install CLI tools or dependencies — work with what is available
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most ship operate skills give in ~2.1k tokens
Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07
- Document a rollback plan before deploymentin 41 of 779, across 22 files
- Update the changelogin 21 of 779, across 19 files
- Run the test suitein 20 of 779
- Create an annotated git tagin 20 of 779
- Clean up feature flags after full rolloutin 18 of 779, across 10 files
- Verify deployment health after launchin 18 of 779, across 10 files
- Test both feature flag statesin 17 of 779, across 9 files
- Verify the working tree is cleanin 17 of 779
- Make database migrations backward-compatiblein 16 of 779, across 8 files
- Set up error monitoring before launchin 15 of 779, across 7 files
- Monitor metrics at each rollout stagein 14 of 779, across 5 files
- Create a GitHub releasein 14 of 779
Said here and by no other author read
- execute every phase in sequence
- scan project root for infrastructure artifacts
- detect the application stack
- score each area on a 0-100 scale
- calculate overall deployment readiness score
- generate remediation plan for areas scoring below 50
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.