secrets-handling_skill

Overview

This skill enforces safe handling of API keys, passwords, and other credentials. It gives concrete rules to avoid hardcoding, committing, or logging secrets and recommends safer alternatives like environment variables and secret managers. Follow these guidelines to reduce the chance of accidental leaks and long-lived exposures.

How this skill works

The skill inspects code and practices for signs of hardcoded secrets, exposed .env files, logging of credentials, and missing environment validation. It guides developers to use environment variables, validate required values at startup, mask secrets in errors, and employ secret managers in production. It also describes what to do if a secret is accidentally committed.

When to use it

• When working with API keys, tokens, passwords, or other credentials
• When configuring database connections or third-party service credentials
• Whenever asked to hardcode a secret or to store secrets in source
• When a .env file is present but not ignored in .gitignore
• When you see literal strings that resemble keys or 'password:', 'secret:', 'key:' in code

Best practices

• Never hardcode secrets in source code or commit .env files with real values
• Store secrets in environment variables and validate them at application startup
• Mask or omit secrets from logs and error messages
• Use managed secret stores (AWS Secrets Manager, HashiCorp Vault, etc.) in production
• If a secret is committed, rotate it immediately and remove it from the repo

Example use cases

• Replace hardcoded API keys with validated environment variables and an .env.example file
• Configure database connections using a DATABASE_URL read from env and validated at boot
• Use a secret manager client in production to fetch credentials instead of bundling them
• Audit the repo for literal-looking keys and ensure .env is listed in .gitignore
• Respond to pressure to "just hardcode it for now" by using env vars from the start