API credentials hygiene

**Judgment:** This skill is a strong, generally safe choice for designing or improving API credential handling in typical integration and deployment workflows. It focuses on documentation, planning, and best practices rather than direct secret manipulation, which fits well with automated agents and review pipelines. **What it does well:** - Builds a clear credential map (integrations → env vars → scopes/permissions → owners → rotation cadence). - Encourages moving secrets out of code and into env vars or secret managers. - Drives least-privilege configurations and explicit rotation runbooks (including overlap/rollback steps). - Adds auditability by defining what should be logged and where. - Has strong safety guidance: no real secrets, placeholders only, no unauthorized key acquisition, and defers legal/compliance interpretation. **Risks / Limitations:** - Produces technical guidance, not legal/compliance sign-off; relying on it as a compliance authority would be risky. - Quality of output depends heavily on the user providing accurate, complete information about current credential locations and usage. - May oversimplify very complex enterprise IAM setups (multiple clouds, federated identities, regulated environments) if used without expert review. - It plans changes rather than enforcing them; misapplication or incomplete follow-through can leave residual secrets or over-broad permissions. **Recommended scenarios:** - Before deploying a service that uses third-party APIs, to standardize env vars, separation of dev/prod, and rotation plans. - When refactoring legacy code or automation (e.g., scripts, n8n workflows) that currently contain hard-coded API keys. - During internal security reviews where you need structured documentation of who owns each credential, what it can do, and how it is rotated. - When adopting a secret manager and needing a migration map from existing env vars and inline secrets to managed secrets and references.