About this skill

Problem

Engineers often hard-code API keys, database passwords, or mail authorization codes in local projects, environment files, or shell history. pass keeps these secrets in a local ~/.password-store/ and encrypts them with GPG, reducing accidental commits and plaintext residue.

How It Works

Encrypted local storage: entries are stored under pass naming rules and decrypted only when a valid GPG key is available.
Core operations: pass ls lists entries, pass show reveals values, pass insert creates entries, pass rm deletes them, and pass find searches them.
Scripting: shell or local automation scripts can call pass show <name> to retrieve values instead of passing secrets as plaintext arguments.
Git backup: the encrypted store can be pushed to a private repository for multi-machine sync; the repository should not contain the GPG private key.

Boundaries

This is best for individual developer machines, scripts, and private collaboration, not for multi-team permissioning or online approval workflows. If the GPG key or passphrase is lost, the store is usually unrecoverable, so the key must be backed up separately. Never commit private keys or leave decrypted keys cached on shared machines.

Screenshots

Use Cases

Use `pass show` in local scripts to read LLM API keys without committing plaintext `.env` values.
Store database credentials with `pass insert` before running deployment or migration scripts.
Sync encrypted credentials across dev machines by pushing the `pass` store to a private Git repo.
Update mail authorization codes with `pass edit` during key rotation.

Best For

Backend engineers managing local dev keys who avoid committing API keys or leaving them in shell history.
Full-stack developers maintaining credentials across projects who need CLI lookup and updates.
Automation engineers writing shell scripts who need encrypted database passwords at runtime.
Remote developers syncing personal secrets who want private Git backup of the `pass` store.