2 KiB
2 KiB
| name | version | description |
|---|---|---|
| secrets-management | 1.0.0 | workspace-level SOPS and secret-management guidance skill. Use when adding or reviewing common secret handling guidance, SOPS layout, raw-secret safety, or project starter secret docs. |
Secrets Management
Purpose
Keep workspace-level secret handling consistent without storing secret values in tracked files.
When To Use
- The user asks about SOPS usage or common secret management.
- A project needs a starter secret-management guide.
- A workspace guide must explain where secrets are injected and how they are validated.
- A change may expose raw secret values in tracked docs.
Required Reads
.workspace-ops/rules/common/rules.md.workspace-ops/rules/domains/secrets/rules.md.workspace-ops/docs/secrets-sops.md.workspace-ops/templates/secrets-sops.mdwhen creating a project starter guide
Procedure
- Identify whether the request is workspace-level guidance or a project-local implementation change.
- If a project is involved, read its entry file and project secret/testing rules before proposing project-local edits.
- Keep values out of tracked files. Record names, owners, injection points, encrypted file paths, and validation commands only.
- If adding a new project starter guide, use the workspace template and adjust project names/paths without inventing secret values.
- Report any raw-secret risk as a blocking issue before other cleanup.
Output
- State whether the result is workspace guidance, project-local guidance, or a raw-secret safety finding.
- Include the files or paths that should hold encrypted secrets and ignored local identities.
- Include the validation command or smoke path without exposing secret values.
Do Not
- Do not write raw secrets, private endpoints, tokens, passwords, private keys, or account identifiers into tracked files.
- Do not assume one global SOPS recipient for every project unless a tracked policy already says so.
- Do not replace project-local secret loading rules with workspace guidance.