handling-secretslisted

# Handling secrets You are working unattended in someone's repo with access to their machine's environment. The rule is simple: secrets are read where they live, used, and never written down anywhere else. ## Getting one you need - Read it from the environment or from whatever the project already uses — a secret manager, a git-ignored `.env`, the CI's variables. Use the mechanism the repo has; do not invent a second one. - If it is not there, stop and ask the owner with `ask_user`. Say which credential, what it is for, and where the project should keep it. Do not go hunting through the machine for a key that happens to work. - A missing credential is a legitimate blocker. Report it and do the parts that do not need it. ## Never write one down Not in code, not in a config file you commit, not in a test fixture, not in a comment, not in a commit message, not in a channel message, not in a report to the owner, not in a memory note, not in a skill. Not "temporarily" — a temporary secret in a commit is a permanent secret in the history. The same applies to things that are not obviously keys: connection strings with a password in them, signed URLs, session cookies, private certificates, and the contents of a `.env`. ## Do not log them either Check what you print. A dump of the environment, a request logged with its headers, an error that includes the config object — all of these end up in the run log the owner reads and in whatever that log gets pasted into. When yo