What this prompt does
This prompt turns a vague "we should use a vault" intention into a concrete, end-to-end secret management plan for your [infrastructure_type]. It asks the model to stand up a secret store with [vault_tool], organize your [secret_types] into categories, and attach an automatic rotation schedule ([rotation_schedule]) to each one. It then layers on access policies driven by your [access_model], application integration patterns, audit logging, and the operational pieces teams usually forget.
The structure works because it forces you to write the parts everyone skips. Anyone can install a vault; the value is in the emergency revocation procedure, the runbook for rotation failures, and secret-sprawl detection that scans [code_repos] for hardcoded credentials. By also requesting a migration plan from [current_approach] and pre-commit hooks, the prompt covers the full lifecycle: getting secrets in, keeping them rotated, and stopping the next leak before it ships. It also asks for CI/CD pipeline integration so secrets are injected at deploy time rather than baked into images, and a disaster-recovery section for the vault itself, since a vault is a single point of failure once everything depends on it. That breadth is what separates a real secret-management program from a half-finished tool install.
When to use it
- You are still passing secrets as plaintext environment variables and want a real vault-backed setup.
- You are adopting
[vault_tool]and need a structured rollout instead of ad-hoc onboarding. - An audit or compliance review requires documented rotation, access policies, and access logging.
- You suspect hardcoded secrets are scattered across
[code_repos]and need a scan-and-remediate plan. - You need to define an emergency revocation path before an incident forces you to invent one.
- You are wiring secret injection into CI/CD and want it done without leaking values into logs.
Example output
Expect a structured implementation plan rather than a single script: a vault setup section, a table mapping each secret category to its rotation interval, policy definitions tied to [access_model], an integration section comparing SDK, sidecar, and env-injection approaches, plus standalone runbooks for emergency revocation and rotation failures. Migration steps from [current_approach] and pre-commit hook configuration usually arrive as their own callouts.
Pro tips
- Be specific in
[secret_types]; database credentials, TLS certificates, and OAuth secrets rotate very differently, and listing them separately yields sharper rotation logic. - Set realistic intervals in
[rotation_schedule]per type rather than one blanket number, since certificates and DB passwords have different blast radii. - Name your real
[code_repos]scope so the sprawl-detection step produces actionable scan commands instead of generic advice. - Match
[access_model]to how your services actually authenticate; "service identity + role-based" produces tighter policies than a loose human-centric model. - Treat the rotation-failure runbook as the most important output and test it, because a rotation that silently fails is worse than no rotation.
- Iterate by feeding the generated pre-commit hooks back and asking it to harden them against your specific secret patterns.
