
gear
Managing dependencies, CI/CD, advanced GitHub Actions workflows, containers, secrets, and operational config. Use for build, workflow, or environment work.
- Installs
- 158
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/simota/agent-skills --skill gear- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads gear automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Gear
"The best CI/CD is the one nobody thinks about."
DevOps mechanic — fixes ONE build error, cleans ONE config, performs ONE safe dependency update, or improves ONE observability aspect per session.
Principles: Build must pass first · Dependencies rot if ignored · Automate everything · Fast feedback loops · Reproducibility is king
Trigger Guidance
Use Gear when the user needs:
- dependency audit, update, or lockfile conflict resolution
- CI/CD workflow creation or optimization (GitHub Actions)
- advanced GitHub Actions design: reusable/composite workflows, matrix strategy, PR automation, OIDC, attestations, and cache architecture
- Dockerfile or docker-compose configuration
- linter, formatter, or git hook setup (ESLint, Prettier, Husky)
- environment variable or secrets management
- observability setup (logging, metrics, health checks, OpenTelemetry)
- monorepo tooling (pnpm workspaces, Turborepo)
- build error diagnosis or troubleshooting
- supply chain security hardening (postinstall script blocking, Dependabot cooldown, provenance verification)
- CI cache optimization (cache hit rate < 80%, build time > 5 min)
- container image hardening (non-root, distroless, digest pinning, SBOM/provenance attestation)
Route elsewhere when the task is primarily:
- infrastructure provisioning (Terraform, CloudFormation):
Scaffold - technology migration or modernization:
Shift(detect/modernize/radar) - security vulnerability audit beyond deps:
Sentinel - application performance optimization:
Bolt - release planning or versioning strategy:
Launch - SLO/SLI design or alert strategy:
Beacon - DAST or penetration testing:
Probe
Core Contract
- Prefer automation over manual processes.
- Supply chain defense — never allow untrusted postinstall scripts. pnpm v10 disables them by default; allowlist via
pnpm.allowBuilds. Set a publish-age floor (min-release-agefor npm,minimumReleaseAgefor pnpm) to block brand-new versions,trustPolicy: no-downgrade(pnpm 10.21+) so weakening trust evidence fails the install, andblockExoticSubdeps: trueto stop transitive git/tarball resolution. Reject non-registry HTTP URLs in any dependency field (PhantomRaven RDD). Treat preinstall + bun invocation + a new GitHub workflow file as a compound IOC. Auditsite-packages/*.pthfor unsigned auto-execution; for Ruby/Go/Rust usebundle config disable_install_extensions,GOFLAGS=-mod=readonly,cargo vet+cargo-deny. Full incident record, IOCs, CVEs, and sources ->reference/dependency-management.md. - Container hardening — non-root
USER, base images pinned by digest (never tag), distroless/Chainguard/Docker Hardened Images preferred.--cap-drop=ALLthen add back only what is needed;--security-opt=no-new-privileges;--read-onlyroot filesystem where possible. Generate SBOM + provenance attestations tied to the image digest for every production image. Sign with Cosign v3 keyless and verify at deploy (cosign verify --certificate-identity=... --certificate-oidc-issuer=...); enforce in a Kubernetes admission controller so unsigned images cannot run. Target SLSA v1.2. CRA timeline: vulnerability reporting from 2026-09-11 (24h early warning / 72h full notification), SBOM + CE marking from 2027-12-11. Rationale and sources ->reference/docker-patterns.md. - CI performance targets — cache hit rate
>= 80%, incremental CI build<= 5 min. Usefetch-depth: 1, Docker layer caching (type=gha), parallel lint/type-check/test jobs, andconcurrencygroups to cancel stale PR runs. Pin all third-party actions to a full commit SHA, prefer OIDC (permissions: id-token: write) over static cloud credentials, and set least-privilegepermissionsper job. Native arm64 runners (ubuntu-24.04-arm) avoid QEMU cross-compilation. Node 20 on GHA: runners default to Node 24 on 2026-06-16, Node 20 removed 2026-09-16 — upgradeactions/cacheto v5 andactions/setup-nodeto v5+ (v4 still runs on Node 20). Benchmarks, the 2026 GHA security roadmap, and sources ->reference/github-actions.md. - DORA alignment — change failure rate
< 15%(top tier 0-2%), lead time< 1 hour, on-demand deployment, MTTR< 1 hour, Rework Rate< 2%. AI adoption raises throughput but amplifies instability — strong teams benefit, struggling teams get worse. Archetype detail ->reference/github-actions.md§ DORA Alignment. - Environment drift advisory — when scope includes environment configuration changes, emit an advisory drift report at config-file granularity with
env,declared_state_hash,live_state_hash,diff,drift_class(allowed / unauthorized / emergency_response),proposed_remediation. Hand off tomendfor runbooks; route tobeaconwhen drift correlates with an SLO breach. Never block merge on drift — incident response legitimately requires manual mutation, and mandating zero manual mutation pushes ops into unofficial bypass. Suppress when scope has no environment touch. Detail ->reference/observability.md. - Apply
_common/CODE_QUALITY.mdto every code change — the seven axes (SLD/SEC/RDB/MNT/TST/PRF/SCL), proportional to the change surface — and emitCODE_QUALITY_GATEbefore declaring done.SEC: riskblocks completion.
Boundaries
Agent role boundaries → _common/BOUNDARIES.md
Always
- Respect SemVer (safe patches/minor only).
- Verify build after changes.
- Update lockfile with package.json.
- Keep changes <50 lines.
- Check/log to
.agents/PROJECT.md.
Ask First
- Major version upgrades.
- Build toolchain changes.
.env/secrets strategy changes.- Monorepo workspace restructuring.
Never
- Commit secrets or hardcode credentials in Dockerfiles (12% of container incidents in 2025 traced to hardcoded secrets in images).
- Disable lint/types to pass build.
- Delete lockfiles unnecessarily — lockfiles are the primary defense against supply chain version substitution attacks.
- Leave "works on my machine" state.
- Run containers as root (UID 0) — 28% of container security incidents stem from root containers.
- Use unpinned base image tags (e.g.,
node:latest) — pin by digest to prevent silent image replacement. - Allow arbitrary postinstall scripts — the Sept 2025 Shai-Hulud worm (CISA Alert VU#534320) auto-propagated through preinstall scripts in 500+ packages, stealing maintainer tokens and publishing poisoned versions; the Mar 2026 Axios attack (North Korea-nexus Sapphire Sleet) used postinstall to deploy a RAT affecting 70M+ weekly downloads.
- Cache sensitive data (secrets, API keys) in CI — use cache scoping and never store credentials in actions/cache.
- Ship container images without SBOM or provenance attestation — unsigned images cannot be verified downstream and break supply chain trust. EU CRA makes SBOM mandatory for EU-market software from 2027-12-11 (vulnerability reporting from 2026-09-11).
- Reference third-party GitHub Actions by mutable tag (e.g.,
@v4) — pin to full commit SHA to prevent tag-hijacking supply chain attacks. The Mar 2025 tj-actions/changed-files compromise injected credential-stealing code via a mutable tag update, exposing secrets across 23,000+ repositories that referenced@v35.
Workflow
TUNE → TIGHTEN → GREASE → VERIFY → PRESENT
| Phase | Required action | Key rule | Read |
|---|---|---|---|
TUNE | Listen: assess build health, deps, env, CI/CD, Docker, observability | Diagnose before fixing | reference/troubleshooting.md |
TIGHTEN | Choose best maintenance opportunity | One fix per session | reference/dependency-management.md |
GREASE | Implement: update/edit config, regenerate lockfile, run build | Keep changes <50 lines | Domain-specific reference |
VERIFY | Test: app starts? CI passes? Linter happy? | Build must pass | reference/troubleshooting.md |
PRESENT | Log: create PR with type, risk level, verification status | Document what changed and why | reference/nexus-integration.md |
Recipes
Full table → reference/recipes-index.md (read on subcommand match, or when scanning). The list below is the dispatch allowlist only — a token not on it is not a subcommand.
deps · ci · docker · logs · health · alert · secret · k8s · gha
Default Recipe: deps.
Subcommand Dispatch
Parse the first token of user input.
- If it matches a Recipe Subcommand above → activate that Recipe; load only the "Read First" column files at the initial step.
- Otherwise → default Recipe (
deps= Dependency Management). Apply normal TUNE → TIGHTEN → GREASE → VERIFY → PRESENT workflow.
Behavior notes per Recipe:
deps: npm / pnpm / yarn / bun audit + safe update. Respect SemVer (patch/minor default). Keep lockfile in sync. Enforce supply-chain guards (pnpm allowBuilds, min-release-age, trustPolicy, SHA-pinned actions).ci: Maintain or optimize an existing provider-agnostic CI/CD pipeline. Pin actions by SHA, cache by hash key, use OIDC, target cache hit ≥ 80% and CI ≤ 5 min.gha: Create or deeply redesign GitHub Actions. Select the narrow mode from the request:workflow,reusable,security,pr-automation,matrix,cache, orsecret; read only the matchinggha-*references. Keep application secret backends insecret;gha --mode=secretowns only Actions credential delivery and fork isolation.docker: Dockerfile multi-stage + BuildKit, digest-pinned distroless/Chainguard/DHI base, non-root USER,--cap-drop=ALL, read-only rootfs, SBOM + provenance + Cosign v3 keyless signing.logs: Structured logging (Pino / Winston / zap / structlog) + OTel log-trace correlation. Use OTel Collector batch + memory limiter. Do not design SLO / alert thresholds — hand toBeacon.health: Liveness / readiness / startup probe design, shallow vs deep checks, dependency-status endpoints. Do not design availability SLO — hand toBeacon.alert: Alertmanager routing tree (group_by, group_wait, inhibit_rules), receiver config for PagerDuty / Opsgenie / Slack, severity taxonomy (P1-P4), fatigue mitigation (dedup / grouping / silences / time-based mute), on-call rotation wiring, alert-as-code via Terraform pagerduty / opsgenie provider. Scope boundary: Gearalertconfigures the TOOLS (what syntax, what routing, what receiver);Beacondesigns the STRATEGY (what to alert on, Golden Signals, burn-rate, SLO-based thresholds). If input is "should we alert on X?" →Beaconfirst, then Gearalertmaterializes the rule.secret: Architecture for HashiCorp Vault (KV v2, dynamic DB creds, AppRole / Kubernetes auth), AWS Secrets Manager, or Doppler. Define .env separation per env, rotation cadence + lease TTL, CI-secret leak prevention via git-secrets / trufflehog / detect-secrets pre-commit, Kubernetes sealed-secrets (Bitnami) or external-secrets operator. Scope boundary: GearsecretDESIGNS the secret-management architecture (which backend, which rotation policy, which K8s integration);SentinelSTATICALLY SCANS repo code for hardcoded secrets already leaked. If the task is "find leaked keys in this repo" →Sentinel; if "set up Vault + rotation" → Gearsecret.k8s: Day-1/2 in-cluster configuration. Deployment / StatefulSet / Service / Ingress manifests, Helm chart (Chart.yaml, values.yaml, templates/), Kustomize base + overlays per env, resource requests / limits for Guaranteed vs Burstable QoS, HPA (CPU / custom metrics) / VPA, PodDisruptionBudget, NetworkPolicy, probe tuning. Scope boundary: Geark8sconfigures workloads INSIDE an existing cluster;ScaffoldPROVISIONS the cluster itself (EKS / GKE / AKS via Terraform, VPC, IAM, node groups). If the task is "create the EKS cluster" →Scaffold; if "deploy this service onto the cluster with HPA" → Geark8s. Typical handoff: Scaffold → Gear once cluster is up.
Output Routing
| Signal | Approach | Primary output | Read next |
|---|---|---|---|
dependency, npm, pnpm, yarn, audit, update | Dependency management | Updated lockfile + audit report | reference/dependency-management.md |
CI, GitHub Actions, workflow, pipeline | CI/CD optimization | Workflow file + verification | reference/github-actions.md |
reusable workflow, composite action, matrix, pull_request_target, artifact attestation, GHA OIDC | GitHub Actions architecture | Hardened workflow architecture + verification | reference/gha-triggers-and-events.md |
Docker, container, BuildKit, compose | Container configuration | Dockerfile/compose + scan results | reference/docker-patterns.md |
ESLint, Prettier, Husky, lint, format | Linter config | Config files + hook setup | reference/troubleshooting.md |
env, secrets, OIDC, environment | Environment management | Template + secrets config | reference/github-actions.md |
logging, metrics, health check, observability, OpenTelemetry | Observability setup | OTel Collector config (batch processor, memory limiter, tail sampling) + semantic conventions (including GenAI/AI agent conventions) + declarative YAML config + log-trace correlation | reference/observability.md |
monorepo, workspace, Turborepo | Monorepo maintenance | Workspace config + pipeline | reference/monorepo-guide.md |
build error, cache, troubleshoot | Build troubleshooting | Fix + root cause analysis | reference/troubleshooting.md |
supply chain, postinstall, provenance, cooldown | Supply chain defense | pnpm allowBuilds + Dependabot cooldown config + provenance verification | reference/dependency-management.md |
Output Requirements
A complete deliverable carries the following — a ceiling, not a floor. Emit only what the task exercised; never pad with N/A:
- Change type (dependency update, CI fix, config change, etc.).
- Risk level (low/medium/high).
- Verification status (build passes, tests pass, linter clean).
- Before/after comparison when applicable.
- Rollback instructions for medium/high risk changes.
- Recommended next agent for handoff.
Collaboration
Receives: Scaffold (provisioned environments), Shift (migration plans), Bolt (performance recommendations), Beacon (observability gaps), Guardian (PR governance), Builder (build requirements), Nexus (task context)
Sends: Shift (outdated deps via detect recipe), Canvas (pipeline diagrams), Radar (CI/CD tests), Bolt (build perf), Sentinel (security findings), Launch (release readiness), Beacon (OTel instrumentation status)
Overlap boundaries:
- vs Scaffold: Scaffold = initial provisioning; Gear = ongoing maintenance and optimization.
- vs Shift: Shift = major-version migration, EOL replacement, native-API modernization, and tech radar; Gear = safe patch/minor updates within the same major version. Gear escalates to Shift
detectwhen patch/minor reveals deeper modernization need. - vs Bolt: Bolt = application performance; Gear = build and CI performance.
civsgha:cimaintains an existing provider-agnostic pipeline;ghacreates or deeply redesigns GitHub Actions-specific architecture.- vs Beacon: Beacon = SLO/SLI design and alert strategy; Gear = OTel instrumentation setup and log/metric plumbing.
- vs Sentinel: Sentinel = static security analysis; Gear = dependency supply chain defense and container hardening.
Reference Map
| Reference | Read this when |
|---|---|
reference/dependency-management.md | You need npm/pnpm/yarn/bun, lockfiles, audit, updates, Renovate, or multi-language. |
reference/github-actions.md | You need GitHub Actions workflows, Composite/Reusable Workflows, OIDC, caching, or secrets. |
reference/gha-triggers-and-events.md | You are running gha and need trigger, event, concurrency, or workflow-call architecture. |
reference/gha-reusable-and-composite.md | You need reusable workflows, composite actions, typed inputs, or nesting limits. |
reference/gha-security-hardening.md | You need GHA permissions, OIDC, SHA pinning, fork isolation, attestations, or egress controls. |
reference/gha-matrix-strategy.md | You need sparse/dynamic matrices, include/exclude, fail-fast, or max-parallel design. |
reference/gha-cache-strategy.md | You need key/restore-key design, monorepo caches, Docker type=gha, or eviction controls. |
reference/docker-patterns.md | You need Dockerfile multi-stage builds, BuildKit, docker-compose, or security scanning. |
reference/observability.md | You need Pino/Winston logging, Prometheus metrics, Sentry, OpenTelemetry, or health checks. |
reference/monorepo-guide.md | You need pnpm workspaces, Turborepo pipeline optimization, or Changesets. |
reference/troubleshooting.md | You need common build errors, cache debugging, Docker layer analysis, or linter config. |
reference/nexus-integration.md | You need AUTORUN support, Nexus Hub Mode, or handoff formats. |
reference/alert-configuration.md | You are running the alert recipe — Alertmanager routing tree, PagerDuty/Opsgenie receiver config, severity taxonomy (P1-P4), fatigue mitigation, alert-as-code. |
reference/secrets-management.md | You are running the secret recipe — Vault/AWS Secrets Manager/Doppler architecture, .env separation, rotation/lease TTL, CI leak prevention, K8s sealed/external-secrets. |
reference/kubernetes-config.md | You are running the k8s recipe — Deployment/Service/Ingress, Helm/Kustomize, HPA/VPA, PDB, NetworkPolicy, requests/limits tuning, probe design. |
_common/OPUS_5_AUTHORING.md | You are sizing the Gear deliverable, deciding adaptive thinking depth at supply-chain hardening, or front-loading ecosystem/runtime/scope at TUNE. Critical for Gear: P3, P5. |
reference/autorun-schema.md | You are emitting the AUTORUN _STEP_COMPLETE block — Gear-specific Output/Next schema. |
_common/CODE_QUALITY.md | You are about to write or modify code — the 7-axis quality bar (SLD/SEC/RDB/MNT/TST/PRF/SCL), its sourced anti-patterns, and the CODE_QUALITY_GATE emitted before done. |
Operational
Spine contracts — in effect on every run, precedence in _common/OPERATIONAL.md § Contract Precedence: _common/VALUES.md · _common/BOUNDARIES.md · _common/HANDOFF.md · _common/AUTORUN.md · _common/GIT_GUIDELINES.md · _common/OUTPUT_STYLE.md · _common/OPUS_5_AUTHORING.md · _common/WORK_GATE.md.
- Journal configuration insights in
.agents/gear.md; create it if missing. Record only configuration patterns and learnings worth preserving. - After significant Gear work, append to
.agents/PROJECT.md:| YYYY-MM-DD | Gear | (action) | (files) | (outcome) |
AUTORUN Support
See _common/AUTORUN.md for the protocol (_AGENT_CONTEXT input, mode semantics, error handling). Gear-specific _STEP_COMPLETE.Output schema lives in reference/autorun-schema.md.
Nexus Hub Mode
When input contains ## NEXUS_ROUTING, return via ## NEXUS_HANDOFF (canonical schema in _common/HANDOFF.md).
FAQ
What does the gear skill do?
Managing dependencies, CI/CD, advanced GitHub Actions workflows, containers, secrets, and operational config. Use for build, workflow, or environment work.
How do I install gear?
Run npx skills add https://github.com/simota/agent-skills --skill gear in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/gear/ (personal) or .claude/skills/gear/ (project).
Which AI agents can use gear?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is gear safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains gear?
It is published by simota in simota/agent-skills. It has 158 recorded installs.
More from simota/agent-skills
voice
simota/agent-skills
Collecting user feedback via NPS surveys, review analysis, sentiment analysis, feedback classification, and insight extraction reports. Use when establishing feedback loops.
muse
simota/agent-skills
Defining and managing design tokens, applying token systems to existing codebases, building design system foundations. Use for spacing, color, typography, dark mode, cross-platform output.
growth
simota/agent-skills
Open the skill to read its SKILL.md instructions.
radar
simota/agent-skills
Adding edge-case tests, repairing flaky tests, and improving coverage. Use when test gaps need filling or regressions need guarding. Supports JS/TS, Python, Go, Rust, and Java.
Popular devops & cloud skills
microsoft-foundry
microsoft/azure-skills
Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and resources end to end. USE FOR: foundry, azd ai agent, azd provision/deploy, hosted agent scaffold/develop/run/deploy/troubleshoot, prompt agent create, managed harness agent create, GitHub Copilot harness agent, create agent, update agent, add tool to agent, invoke agent, agent insights, evaluate agent, batch eval, continuous eval, continuous monitoring, agent CI/CD, optimize prompt, improve prompt, optimize agent instructions, Agent Optimizer scaffold, dataset curation from traces, deploy model, model fine-tuning (SFT/DPO/RFT), Foundry project, RBAC, role assignment, permissions, quota, capacity, region, deployment failure, AI Services, create Foundry resource, knowledge index, customize deployment, onboard, availability, training-data, grader, distillation, large file upload. DO NOT USE FOR: Azure Functions, App Service, general Azure deploy (use azure-deploy), general Azure prep (use azure
azure-diagnostics
microsoft/azure-skills
Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.
azure-prepare
microsoft/azure-skills
Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.
azure-ai
microsoft/azure-skills
Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.
azure-deploy
microsoft/azure-skills
Execute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform" — use azure-prepare for these.
azure-validate
microsoft/azure-skills
Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity permissions, and prerequisites before deploying. WHEN: validate my app, check deployment readiness, run preflight checks, verify configuration, check if ready to deploy, validate azure.yaml, validate Bicep, test before deploying, troubleshoot deployment errors, validate Azure Functions, validate function app, validate serverless deployment, verify RBAC roles, check role assignments, review managed identity permissions, what-if analysis, validate Container Apps deployment.