菜单
Platform structure discipline — environment strategy, account segmentation, landing zone, module composition. Cloud-agnostic.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 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 | 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).
