Menu
Infrastructure composition patterns — immutable infra, GitOps, golden images, cattle-not-pets, day-2 thinking. Tool-agnostic.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Context engineering — memory navigation, textual graph traversal, progressive disclosure, recovery. Load when assembling context for a task or when lost.
Implementation-side security discipline — headers, dependencies, secrets, authz. Load for hardening work (sec-ops domain).
Commit conventions, branching, anchors in messages, and the git safety rules. Load for any git operation beyond status/diff.
Anti-generic-AI design discipline — bans, tells, and the slop test. Load for ANY new UI surface or visual redesign. Inspired by Impeccable (Apache 2.0).
Motion & animation discipline — purpose, performance, reduced-motion. Load when work involves animation, transitions or scroll effects.
Microcopy discipline — buttons, errors, empty/loading/success states, alt text. Voice and tone come from the project's memory, not from this skill.
| name | infra-patterns |
| description | Infrastructure composition patterns — immutable infra, GitOps, golden images, cattle-not-pets, day-2 thinking. Tool-agnostic. |
The structural patterns layer for infra — counterpart to back's design-patterns. Tooling from memory-long §stack.
Replace, don't patch: config changes produce new instances/images, deployed by replacement — SSH-ing into a server to fix it creates a snowflake nobody can rebuild · golden images built by pipeline (versioned, scanned, minimal) · if you must mutate (legacy), record it as DEBT-* with a path to immutability.
Anything you'd grieve is a liability: no named, hand-raised servers · every resource rebuildable from code + data restore (the real test: "could we recreate this from the repo?" — if no, it's not IaC yet, it's documentation) · singletons that can't be replaced get an ADR explaining why.
Desired state lives in git; the runtime converges toward it · drift is a signal, not noise: detected drift either becomes code (someone had a reason) or gets reverted (nobody did) — never ignored · manual console changes in prod = incident-grade event, not convenience. Deep dive: gitops skill (ops/dev owns the practice).
Layers with clear ownership: foundation (network/identity/logging — changes rarely, guarded hard) → platform (clusters, shared services) → workload (per-app, changes often) · blast-radius-ordered state: don't put fast-changing workload resources in the same state/stack as the foundation (see state-discipline) · environments composed from the same modules with different inputs — never forked copies.
Provisioning is day 0; the pattern must answer day 2: how does it upgrade? · how is it observed? (see observability principles) · how does it scale? · how is it decommissioned cleanly (orphaned dependencies = cost + attack surface)? A pattern without upgrade + teardown stories is half-designed.
New patterns prove rebuildability (fresh env from scratch in CI when feasible) · pattern changes propagate via module version bumps, tracked per environment · report names which layer the change belongs to and its blast radius.
