project-work/worker-toolkit-potion-polyglot/.claude/skills/detector-credential-leakage/SKILL.md

name, description, allowed-tools

name	description	allowed-tools
detector-credential-leakage	Self-check whether your submission ships a credential inside its authored surfaces — above all `environment/workspace.patch`. Mainly one job: find leaked keys, tokens and secrets. Deterministic pattern checks hard-flag your authoring environment's own env vars (`ANTHROPIC_API_KEY`, `ANTHROPIC_BASE_URL`, `USER_ID` as an env assignment) and well-known secret shapes (`sk-ant-…`, AWS `AKIA…`, GitHub `ghp_…`, Google `AIza…`, Stripe secret keys, bearer tokens, private-key blocks, URL-embedded passwords) on lines your patch adds; a placeholder test then clears dummies, `.env.example` files, dev defaults and code identifiers. A `credential-leak` must be fixed before submitting AND the key reported for rotation, since removing the line doesn't un-ship it; `suspicious-content` is advisory. A second, narrow check flags an absolute path from your own machine that continues into your checkout on a line your patch adds (`/home/you/.../worker-toolkit-x/repo/...`) — a patch is repo-relative, so such a path only gets in by accident: that's `internal-leak`, fix it before submitting, nothing to rotate. The report never reproduces secret values. Reads workspace.patch (+ Dockerfile, instruction.md, tests/*.md); runs before or after reference runs exist.	Bash, Read, Write

Credential-leakage detector

This skill checks one of your tasks for a leaked credential — a key, token or secret swept out of your authoring environment into the submission's authored surfaces, above all environment/workspace.patch. Everything your patch adds ships to everyone downstream, so a leaked key is compromised the moment you submit, and scrubbing it afterwards doesn't undo that. It also catches one closely-related shape: an absolute path from your own machine.

The failure shapes to catch:

• Your toolkit .env — your personal ANTHROPIC_API_KEY, ANTHROPIC_BASE_URL and USER_ID landing in the workspace as a new .env file, a .env.bak-* backup, or a symlink to /home/<you>/.env.
• Any real third-party secret the patch adds — an AWS or Google key, a GitHub token, a Stripe secret key, a private-key block, a captured request carrying a live Authorization: Bearer …, a database URL with the password embedded.
• An absolute path from your machine into your checkout, on a line your patch adds — /home/you/…/worker-toolkit-<repo>/repo/app/foo.rb. A patch is repo-relative by construction, so this only ever gets in by accident: a coverage report keyed by your file paths, or a helper script with your checkout hardcoded. It ships your username and directory layout to everyone downstream. Rare — 2 in 350 patches.

What doesn't trip this check: placeholder and example values (.env.example with dummies, sk-ant-... as a literal template), dev defaults (POSTGRES_PASSWORD=postgres in a local docker-compose), code identifiers (USER_ID = 4958 as a test constant, or any variable merely named SECRET or TOKEN), and secrets on context or removed lines — those belong to the source repo, not to you.

Nor do generic paths that name no person and no checkout — /home/runner/work/… in a CI workflow, /home/ubuntu/<app> in a deploy config, /home/app/… in a compose volume — which real repos legitimately commit.

Also out of scope, and never reported here: authoring artifacts (.raccoon-setup-done, .claude/settings.local.json, stray logs) and patch content that simply doesn't relate to the task.

Read these before deciding:

1. .claude/skills/_detector-worker-shell.md — where to write the report and how to handle re-runs.
2. .claude/skills/detector-credential-leakage/core.md — the deterministic pattern checks to run, the placeholder test, the redaction rule (never quote a secret value), what is NOT a finding, the out-of-scope list, verdict enums, and the body schema.

Compose the report per the schema in core.md and write it per _detector-worker-shell.md.

Acting on the verdict

• clean — nothing your patch adds looks like a credential. Good, move on. This is the normal answer.
• suspicious-content — no confirmed credential, but something credential-shaped couldn't be resolved: a captured request with a real (if low-sensitivity) token, a config file of credential-shaped values. Replace the value with a placeholder, drop the file, or satisfy yourself it's genuinely scenario material.
• credential-leak — a real credential (or your authoring env vars) is in the patch. Act before submitting: (1) remove the material and regenerate the patch with bash scripts/check-workspace-sync.sh --update-patch harbor-tasks/<slug>; (2) re-run this detector to confirm it's gone; (3) report the leaked value through your support channel so it can be rotated — scrubbing the patch does not un-ship a key that already left your machine in an earlier submission.
• internal-leak — your patch adds an absolute path from your own machine into your checkout. Fix before submitting: remove or relativize the path (or drop the file, if it's a generated artifact like a coverage report), regenerate the patch, and re-run this detector. Nothing to rotate.
• not-applicable — there's no workspace patch to assess yet. Build the workspace first.