القائمة
Use when handling credentials, IaC, or ephemeral cloud — make secrets un-committable, grant least privilege, tear down to zero, own only your scope.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when wiring a project's dev workflow (local stack, test tiers, gates, docs), or when naming make targets in a repo that has siblings — build a thin self-documenting Makefile facade over real scripts, name targets from the shared cross-repo vocabulary, and split env files by owner so targets consume them but never write them.
Use when you need to prove a feature actually delivers its intended outcome to a user or caller, not just that its code paths run — write executable acceptance tests against real, observable outcomes, derived from the spec before or independent of the implementation.
Use when adding any new capability to a working system — ship it behind a flag or optional collaborator that defaults to prior behavior.
Use when a spec, plan, or implementation must be independently reviewed before it is trusted, committed, or advanced to the next phase — dispatch a fresh reviewer per named lens whose job is to refute the artifact, not confirm it.
Use when building automation that edits, tests, or deploys itself — an agent that regenerates its own code, a self-updating pipeline, any loop that modifies the thing running it.
Use when about to call any integration, deployment, or hard guarantee "done" — prove it live end-to-end and capture the run as evidence.
| name | secrets-and-teardown-discipline |
| description | Use when handling credentials, IaC, or ephemeral cloud — make secrets un-committable, grant least privilege, tear down to zero, own only your scope. |
Make secrets — and identifying details — structurally impossible to commit, grant the narrowest privilege that works, always tear down ephemeral infrastructure and verify it reached zero, and provision only inside the lifecycle you own. Prevention is structural — not a reviewer remembering to look.
Reach for this whenever you touch any of:
.env-style config.Red-flag thoughts — if you catch yourself thinking any of these, STOP and apply this skill:
destroy ran without errors, so it's all gone.".env, .env.*, *.tfvars, *.tfstate*) and force-allow exactly one non-secret template back in (!.env.example). A secret should be physically unable to enter a commit, regardless of who is reviewing. Identifying details get the same structural treatment: a pre-commit check that derives the authoring machine's own identity at runtime and denies entries from a per-user registry that lives outside any repo — outside, because the list of your private names is itself a secret.gcloud secrets versions add, aws secretsmanager put-secret-value), a CI secret store, or a manual console step. The value lives only in the secret manager, never in the repo and never in IaC state.count/for_each flag) so they exist only when that feature is on. Use separate identities for separate phases — a build identity and a runtime identity — so neither inherits the other's reach. No broad Editor, no project-wide secretAccessor.force_destroy = true on buckets, deletion_protection = false on databases) so nothing blocks teardown. After every ephemeral cycle, run the destroy and then verify zero independently — e.g. terraform state list returns empty AND a provider-side query (gcloud asset search-all-resources, aws resourcegroupstaggingapi get-resources, or a billing/cost report) shows no surviving resources. For a fully throwaway environment, delete the enclosing project/account afterward to sweep up residue your IaC never tracked (staging buckets, default logs, leftover disks).project (or account/org) resource your IaC could later destroy. Externalize what you don't own, and say so plainly in the docs so the next person knows the boundary.Secrets that can be committed eventually are — by a tired teammate, an autoformatter, or an agent that globs *. A gitignore pattern blocks all of those at once; reviewer vigilance scales to zero. Real values in IaC state are just as exposed as values in code, because state is a plaintext file that gets copied, cached, and backed up. Broad IAM grants turn one compromised identity into total blast radius; resource-scoped grants cap the damage to exactly what that identity touches. And "destroy ran fine" is not "zero cost" — orphaned buckets, disks, and IP reservations bill silently for months. Verifying zero, and deleting the throwaway container, is the only way to actually stop the meter. Managing a lifecycle you don't own is how a stray destroy deletes someone else's project.
On the project this was distilled from — a hexagonal, human-in-the-loop AI agent shipped to a serverless cloud — the discipline showed up in three artifacts:
.gitignore carried .env and .env.* with a single !.env.example exception, so no contributor could commit a real key even by accident, while the template stayed in the repo.iam.tf deliberately kept cloudsql.client and secret access out of the always-on project-level roles: cloudsql.client was gated behind the enable_cloud_sql flag, while secret access was scoped to the specific secret resources — the DB-URL secret additionally flag-gated, and the ticketing-system-token secret always-on but still resource-scoped (never project-wide). The design goal, documented inline, was that the default serverless deployment should carry no standing privilege it never uses.24 destroyed, after which the project itself was deleted "to remove the CI staging bucket and guarantee zero cost" — destroy, then delete the enclosing project to sweep residue the IaC never tracked. (The artifact captured the destroy count and the project-delete sweep; the explicit verify-zero check in between is the step this skill recommends adding, not one that recording demonstrates.)You can apply all three without knowing anything about that project: ignore-by-pattern, scope-by-resource, destroy-then-verify-then-sweep.
tfvars file.secretAccessor or Editor when one resource-scoped binding would do.terraform destroy "done" without listing resources to confirm zero — leaving a staging bucket or reserved IP quietly billing.Most of this skill already ships as machinery: gitignore secret globs, detect-private-key, check-no-tracked-secrets.sh, and check-no-private-identifiers.sh (identity, not just credentials) in git-controls-starter — all fail-closed at commit time. What remains checkable: IaC linted for resource-scoped grants (no broad roles), and teardown certified by a verify-zero script — state list empty AND a provider-side query empty — that fails on any survivor instead of trusting a clean destroy log.