Use secrets safely
Use /hq-secrets and schema-driven injection so credentials run your work without ever being pasted into chat or committed.

Referenced secret
Secrets are declared and referenced, never typed into chat or stored in a repo.

Declare the keys
A repo lists the secret names it requires in a `.env.schema` file, so HQ knows what to fetch without seeing the values in code.
Add the needed key names to `.env.schema` and keep real values out of the repo entirely.
Run with injection
`hq run` reads the schema, batch-fetches the secrets, and injects them as environment values that are never printed; `hq secrets exec` does the same for a one-off command.
Run repo work through `hq run`, or use `hq secrets exec` for a single command that needs one key.


Collect human secrets by link
For a human-supplied credential, the /hq-secrets skill generates a link so the person enters the secret themselves.
Generate a link with /hq-secrets and send it, rather than asking the person to paste the value into the conversation.
Keep the chapter executable.
Runs schema-driven secrets via `hq run`, one-offs via `hq secrets exec`, and generates links for human-supplied credentials.
Injects a single named secret for one command without printing it.
What goes wrong, and the fix.
Pasting an API key directly into the chat to get work done.
Never paste a key; generate a /hq-secrets link or reference it through the schema.
Committing a real .env file with live values.
Use .env.schema plus the vault and keep real values out of the repo.
Reaching for another company's credentials when the active ones fail.
Respect cross-company isolation and use only the active company's secrets.
What to keep in mind.
Never inline
A secret never goes in chat, a prompt, or a commit; it is referenced through the schema or a /hq-secrets link.
Schema-driven
Declare keys in .env.schema and let `hq run` batch-fetch and inject them so real values stay in the vault.
