project-work/worker-toolkit-stocks-in-the-future/.claude/skills/detector-credential-leakage/SKILL.md

name, description, allowed-tools

name	description	allowed-tools
detector-credential-leakage	Self-check whether your submission ships credentials or other content from your authoring environment inside its authored surfaces — above all `environment/workspace.patch`. Two tiers. (1) **Known-credential tier (deterministic):** hard-flags 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. The canonical incident: your toolkit `.env` — your personal API key, proxy URL, and user id — swept into the workspace as a new `.env` file. (2) **Task-relevance tier (judgment):** content your patch adds that doesn't appear to serve the task — `.env`-style files, env-file symlinks into your home directory, `export FOO=` lines, credential-shaped assignments with real values. A `credential-leak` finding must be acted on before submitting (remove the material AND report the key as compromised so it can be rotated); `suspicious-content` findings are advisory. 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 credential leakage — whether anything from your own authoring environment (or any other secret) has been swept 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: deleting the line later does not un-ship it.

The failure shape to catch: your toolkit's .env — the file holding your personal ANTHROPIC_API_KEY, ANTHROPIC_BASE_URL, and USER_ID — landing in the workspace as a new .env file (or a .env.bak-* backup, or a symlink to /home/<you>/.env). It happens easily: a stray git add, a working-tree backup, a captured terminal snippet. None of it serves the task; the test agent has no network to use a key with; and the key is now distributed.

What doesn't trip this check: placeholder and example values (.env.example with empty or dummy entries, sk-ant-... as a literal template, changeme), dev-infrastructure defaults (POSTGRES_PASSWORD=postgres in a local docker-compose), code identifiers (USER_ID = 4958 as a test constant), and env vars your task's scenario genuinely needs documented.

Severity differs by tier. Unlike most self-checks, a credential-leak finding is not a consideration: remove the material from the patch, rebuild it (bash scripts/check-workspace-sync.sh --update-patch harbor-tasks/<slug>), and report the leaked credential through your support channel so it can be rotated — treat it as compromised even after you scrub it. suspicious-content findings are the usual advisory kind: read each one and fix or justify it.

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 two tiers, the deterministic pattern checks to run, the placeholder test, the redaction rule (never quote a secret value), what is NOT a finding, 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 or foreign content. Good. Move on.
• suspicious-content — no confirmed credential, but something your patch adds doesn't look like it belongs to the task: an env-file symlink into your home directory, a captured request with a real (if low-sensitivity) token, a config file of credential-shaped values. Fix each finding (replace tokens with placeholders, drop the file, or make its task relevance explicit) or satisfy yourself it's genuinely scenario material.
• credential-leak — a real credential or your authoring environment's own env vars are in the patch. Act before submitting: (1) remove the material and regenerate workspace.patch; (2) re-run this detector to confirm it's gone; (3) report the leaked value as compromised so it can be rotated — scrubbing the patch does not un-ship a key that already left your machine in an earlier submission.
• not-applicable — there's no workspace patch to assess yet. Build the workspace first.