What problem does it solve? Secrets often end up scattered across repos, shell configs, GitHub Actions, and cloud providers with no clear owner, leading to duplication, leaks, and drift. This Skill decides which lane owns each secret and defines the exact files, names, and validation steps to apply. ## Core Features & Use Cases - Lane-Based Ownership: Routes each secret to one of four lanes: runtime (deployed apps), repo-local development, machine-local shared tooling, or GitHub Actions CI. - Canonical Local Store: Keeps values in a machine-local store under ~/Documents/DobbySecrets/scopes/<scope>/<secret-name> and generates .env and ~/.secrets/<integration>/env files from it. - Naming and Guardrails: Enforces repo--name and integration--name naming families and blocks anti-patterns like secrets in .zshrc, tracked YAML, or unnecessary GitHub Actions entries. - Use Case: When adding a new API key for a Mac Mini service, use this Skill to store it canonically, map it into the repo's secret_env_map.env, regenerate the runtime .env, and validate with local-secrets --plain status without printing the value. ## Quick Start Use the secret-management skill to decide where this new API key belongs, what it should be named, and which files and workflows need updating.