infrastructure

Plugin infrastructure from marketplace truecast in wastedcode/truecast. Commands read from the repo's manifest — 27 days ago.

Skills (21)

• author-the-runbook

  Use when documenting how to deploy, operate, or recover a service, or after learning something a release/incident taught you — write a runbook so good a competent stranger could ship or recover from it alone.

• beat-the-frontier

  Use before any substantive infra/ops deliverable and as the last pass before handing it over — your version of the engine's "beat the frontier" loop. Name who runs production best today, set the bar above them, pre-empt every ask a demanding SRE lead would make (commands that run first time, real li

• eliminate-toil

  Use when ops work is manual, repetitive, and scaling with growth (manual deploys, hand-run migrations, copy-paste fixes, ticket-driven provisioning) — identify the toil and automate it away so ops doesn't grow linearly with the system.

• hand-over-commands-that-run

  Use whenever you give a human a command to run, especially as root or on a box you can't reach yourself. Test it for their exact shell, user and environment first. No placeholders. Output goes to a file you can read. State whether it's reversible. Then get the access to verify it yourself.

• infrastructure-as-code

  Use when provisioning or changing infrastructure (cloud resources, clusters, networking, config) — define it as versioned, reviewed, reproducible code; fight drift; prefer immutable replace over hand-patching live boxes.

• know-the-platform

  Use before building on or committing to a vendor/runtime (cloud, PaaS, serverless, queue, DB, third-party API) — read the actual pricing, runtime-limits, and execution-model docs first, so the charging unit, hardcoded limits, and statefulness aren't discovered in production.

• manage-config

  Use when designing or fixing how the system is configured (env vars, json/yaml/toml files, flags, per-project/per-box settings, layered defaults) — give config a versioned schema, define merge/precedence/layering explicitly, validate on load, and check prod↔local parity.

• manage-process-and-session-lifecycle

  Use whenever the system spawns processes, sessions, jobs, workers, or connections (background daemons, tmux/PTY sessions, worker pools, cron jobs, subprocesses) — model the full lifecycle, enforce clean shutdown/draining, and VERIFY nothing was left running; no zombies, no stragglers.

• map-blast-radius

  Use before any change touches prod — enumerate what's stateful, what's a one-way door, what's reversible, and who's downstream, so rigor matches risk and the irreversible parts get caught early.

• observability-that-pages-on-symptoms

  Use when adding monitoring/alerting or when alerts are noisy/missing — instrument golden signals, make the system debuggable (metrics/logs/traces), and page humans only on user-facing symptoms, not on causes like CPU%.

• own-prod-mindset

  Use whenever a change is heading to production or you're asked "is this ready to ship / is it live / is it healthy" — adopt the you-build-it-you-run-it posture and verify by running, not by reading.

• pave-the-golden-path

  Use when multiple teams/engineers each reinvent deploys/infra badly, or when building shared platform capability — make the safe, observable, compliant way the EASY way (a paved road), so people fall into the pit of success rather than being blocked.

• plan-capacity-and-prove-it-scales

  Use before a launch/traffic spike (marketing push, Black Friday, a new large customer) or when asked "can we handle the load / will this scale" — model the expected and worst-case load, load-test against the real bottleneck, and prove the system holds (or autoscales) before traffic does it for you.

• release-with-tested-rollback

  Use at the ship gate for any release — enforce one sanctioned scripted door to prod, a rollback you have actually tested, no leaked secrets, no regressed control, and the observability to know it's healthy.

• right-size-reliability

  Use when deciding how much ops rigor/ceremony a change or system warrants — match depth to real blast radius, so you don't run big-org reliability theatre on a side project, nor cowboy a multi-tenant migration.

• run-the-incident

  Use the moment prod is broken/degraded or an alert fires — declare an incident, take command, mitigate before diagnosing, and communicate on a cadence. Stop ad-hoc heroics and restore the user first.

• set-slos-and-error-budgets

  Use when someone demands "100% uptime," when arbitrating ship-speed vs stability, or when defining how reliable a service must be — set an SLI/SLO and an error budget so reliability is a quantified, spent resource, not a vibe.

• ship-progressively

  Use when rolling out any risky change to many users/hosts — stage it (canary → progressive → full) behind health gates and flags so a bad change is caught at 1% and auto-aborted, not at 100%.

• tame-cloud-cost

  Use when cloud spend is rising, unexplained, or unattributed, or before provisioning expensive resources — treat cost as an engineering metric: make it visible, attribute it, find waste, and right-size before the bill is the incident.

• verify-resilience-with-game-days

  Use when reliability/recoverability is being assumed rather than proven — deliberately inject the failure (dependency down, AZ/region loss, restore from backup, failover, on-call paged) in a controlled game day or chaos experiment, so you learn the system breaks before a real outage teaches you.

• write-the-blameless-postmortem

  Use after any incident (or near-miss) — write a blameless postmortem that finds the systemic/contributing causes, not a person to blame, and produces tracked action items so the system can't fail that way again.

Subagents (1)

• infrastructure

  An infrastructure/platform engineer who owns the production boundary — ships safely (canary + tested rollback through one gated door), defines infra as code, manages config (versioned schema, precedence, prod↔local parity), knows the platform (reads vendor pricing/limits/runtime docs before building