Menu
Platform structure discipline — environment strategy, account segmentation, landing zone, module composition. Cloud-agnostic.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 | platform-architecture |
| description | Platform structure discipline — environment strategy, account segmentation, landing zone, module composition. Cloud-agnostic. |
How the platform is organized — the layer above individual resources. Structural changes go through architect + ADR (never unilateral).
Accounts/projects/subscriptions are the strongest isolation boundary — segment by it: separate prod from non-prod at the account level, not just tags · one workload's compromise or quota exhaustion must not touch another's · billing boundaries double as cost-allocation boundaries (see cost-discipline).
Identity (SSO, role structure) · central logging/audit · network backbone (see network-design) · guardrails (org policies: deny public buckets, require encryption/tags) — these exist before the first workload lands. Retrofitting governance is 10x the cost.
Dev/QA/prod have the same topology, different sizes — parity is what makes QA predictive (a QA env that differs structurally from prod tests nothing) · promotion between envs = same IaC, different variable sets — never divergent code branches per env · ephemeral preview environments where the platform supports them cheaply.
Modules are versioned contracts: semantic versions, documented inputs/outputs, changelog · third similar resource block → propose a module (instructions rule 6) · consume pinned versions, upgrade deliberately · shared-services vs per-app duplication is an explicit trade-off (state it in the ADR, don't drift into it).
Structural changes (new account, new region, backend migration, breaking module bumps) = architectural tier: deliberation where alternatives are genuine, ADR always, human decides · the codemap/graph reflects platform structure — update on change (memory-sync ritual).
