@gonzih/skills-devops 1.1.0 → 1.2.0

package/package.json

@@ -1 +1 @@
-{"name":"@gonzih/skills-devops","version":"1.1.0","description":"DevOps skills for Claude Code","type":"module","scripts":{"postinstall":"node install.js"},"files":["skills/","install.js","README.md"],"keywords":["claude","mcp","skills","devops"],"license":"MIT"}
+{"name":"@gonzih/skills-devops","version":"1.2.0","description":"DevOps skills for Claude Code","type":"module","scripts":{"postinstall":"node install.js"},"files":["skills/","install.js","README.md"],"keywords":["claude","mcp","skills","devops"],"license":"MIT"}

package/skills/alert-triage/SKILL.md

@@ -20,6 +20,12 @@ Analyze a set of incoming monitoring alerts, determine severity and urgency, ide
 4. Identify the root cause alert and downstream effects
 5. Output a triage summary: what to act on now, what to monitor, what to silence
 
+## Live Data Sources
+- **Prometheus alerting rule examples**: `https://github.com/samber/awesome-prometheus-alerts` — community-maintained library of Prometheus alerting rules by category (infra, databases, Kubernetes, etc.)
+- **AWS status page API**: `https://health.aws.amazon.com/health/status` — current AWS service health; programmatic access via AWS Health API (`aws health describe-events`)
+- **GCP status page API**: `https://status.cloud.google.com/incidents.json` — machine-readable GCP incident feed
+- **Azure status API**: `https://azure.status.microsoft/api/v2/status.json` — Azure service health JSON feed
+
 ## Example
 User: "I have 47 alerts firing: disk full on db-01, high latency on api-gateway, 5xx spike on checkout"
 → Identifies disk-full on db-01 as root cause driving the cascade, recommends clearing disk space first, provides ordered action plan.

package/skills/ci-cd-troubleshooter/SKILL.md

@@ -29,6 +29,11 @@ When the pipeline deploys infrastructure with Pulumi, check for:
   - **Config missing**: stack config not committed or secret not set — run `pulumi config set <key>`
   - **Passphrase prompt**: `PULUMI_CONFIG_PASSPHRASE` env var missing for self-managed backends
 
+## Live Data Sources
+- **GitHub Actions API**: `https://api.github.com/repos/{owner}/{repo}/actions/runs` — fetch recent workflow run status, logs, and failure reasons
+- **Docker Hub vulnerability feeds**: `https://hub.docker.com/v2/repositories/{namespace}/{repo}/tags` — check image tag availability; cross-reference CVEs via Docker Scout or Snyk
+- **npm audit patterns**: Run `npm audit --json` for dependency vulnerability data; common failure patterns include `EAUDITNOPJSON`, peer conflict errors, and lock file drift
+
 ## Example
 User: "My GitHub Actions deploy job is failing with 'Error: Unable to locate executable file: docker'"
 → Diagnose missing Docker setup step, suggest `docker/setup-buildx-action`, apply to workflow YAML.

package/skills/incident-commander/SKILL.md

@@ -27,6 +27,11 @@ When the incident involves infrastructure managed by Pulumi:
 2. Re-deploy the previous version: check out the corresponding commit and run `pulumi up`, or use `pulumi up --target-replace <urn>` for surgical replacement of a single resource
 3. Use `pulumi refresh` after rollback to confirm state matches real infrastructure
 
+## Live Data Sources
+- **AWS Service Health Dashboard API**: `https://health.aws.amazon.com/health/status` — real-time AWS service events; use `aws health describe-events --filter eventTypeCategories=issue` for programmatic querying
+- **GCP status API**: `https://status.cloud.google.com/incidents.json` — current and historical GCP incidents in JSON format
+- **PagerDuty webhook patterns**: Inbound webhooks deliver `incident.trigger`, `incident.acknowledge`, `incident.resolve` payloads — use these to auto-populate incident timelines and sync state
+
 ## Example
 User: "Production database is down, started 14:32 UTC, ~10k users affected"
 → Declares SEV1, drafts initial stakeholder update, starts timeline, prompts for on-call contacts, and guides through mitigation steps to resolution and postmortem.

package/skills/runbook-writer/SKILL.md

@@ -26,6 +26,11 @@ When the runbook covers an infrastructure change managed by Pulumi, include:
 - Link to the stack in Pulumi Cloud (e.g. `https://app.pulumi.com/<org>/<project>/<stack>`)
 - Rollback step using `pulumi stack history` to identify the previous deployment and re-run it
 
+## Live Data Sources
+- **AWS Runbook templates**: `https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html` — official AWS Systems Manager Automation runbook library
+- **PagerDuty runbook community**: `https://community.pagerduty.com` — real-world runbook examples shared by practitioners
+- **SRE Workbook public patterns**: `https://sre.google/workbook/table-of-contents/` — Google SRE Workbook chapters on on-call and operational procedures
+
 ## Example
 User: "Write a runbook for restarting the payment-service in Kubernetes"
 → Produces a runbook covering health checks, drain, rolling restart, verification, and rollback with `kubectl` commands.