secret-management

Assign secrets to canonical storage lanes and generate environment files without exposing values.

25|1|Updated Feb 10, 2026
One-click install
npx skills add https://github.com/wisdom-in-a-nutshell/agents --skill secret-management-wisdom-in-a-nutshell
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: secret-management
Source: https://github.com/wisdom-in-a-nutshell/agents/tree/main/skills-source/owned/secret-management
Command: npx skills add https://github.com/wisdom-in-a-nutshell/agents --skill secret-management-wisdom-in-a-nutshell

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

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.

Frequently Asked Questions about secret-management

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide where a new secret should be stored?▼

Identify the secret's primary consumer first: a deployed app uses the runtime lane, one repo's local development uses the repo-local lane, cross-repo operator tooling uses the machine-local shared lane, and CI-only credentials use the GitHub Actions lane. Each secret gets exactly one primary owner lane.

How should I name secrets in a local canonical store?▼

Use the pattern repo--secret-name for repo-owned families and integration--secret-name for shared integrations, such as aipodcasting--mongodb-uri or cloudflare--api-token. Machine-local integrations match the folder name under ~/.secrets/<integration>/.

When should a secret go into GitHub Actions secrets?▼

Only for deliberate cloud-runner delivery or CI-only credentials, such as a cross-repo sync PAT. Workloads already running on a local machine should prefer local deployment automation, keeping the local store canonical rather than duplicating values in GitHub.

Can file-based credentials like .p8 keys use generated .env files?▼

No, file-based credentials such as App Store Connect .p8 keys should not be forced into KEY=value sync. Keep the value in the canonical store and materialize the required file locally at execution or bootstrap time instead.

Why should secrets not be stored in .zshrc or tracked config files?▼

Literal secret values in shell configs or tracked YAML risk leaking through version control and logs. Instead, generate a machine-local file under ~/.secrets/<integration>/env from the canonical store and source that generated file from shell bootstrap.