Surfaced while tidying up after run 2 of the validation program (#16), 2026-08-25. Recorded as follow-up 6 in the run record.
The working-directory rule in SKILL.md opens with a goal and then gives three options in order:
Put the working directory somewhere the repo already ignores, so a run leaves git status clean and no .gitignore edit is needed — in that order: (1) an ignored scratch location in the notes system; (2) .audit/<repo>-<YYYY-MM-DD>/ at the checkout root, left untracked and uncommitted; (3) outside the checkout entirely, if the repo would show either as dirty.
The ambiguity is what "dirty" means. If it means modified tracked files, option 2 always qualifies and option 3 is nearly unreachable. If it means any git status output — which is what "leaves git status clean" implies — then option 2 only qualifies in a repo that already ignores .audit/, and option 3 is indicated everywhere else.
Run 2 resolved it the permissive way. QuantEcon/meta has no .gitignore at all, so option 3 was indicated by the rule's own condition, and option 2 was taken instead. The result was 2.4 MB of audit output — including AWS and access-token findings, per the run's own report — sitting untracked in a public repository checkout until it was moved by hand afterwards. Any git add -A in that repo would have staged it. The exposure required a deliberate add-commit-push, so this is a latent hazard rather than a live incident, but the blast radius is a public repo and the content is exactly the kind you would not want there.
Worth noting that moving the bundle out afterwards left the checkout fully clean — empty git status, HEAD unchanged — which is a strictly better end state for a read-only skill and arguably what the rule is reaching for.
Two candidate fixes, either sufficient:
Define the term. Say "dirty" means any git status output, and note that option 2 satisfies the goal only where the repo already ignores that path — which makes option 3 the default for repos without a suitable .gitignore rather than a rarely-taken fallback.
Or add a check. Have the skill run git check-ignore on the candidate directory during preflight and fall through to option 3 when it does not match. That removes the judgement call entirely and is two lines. It pairs naturally with #59, which proposes capturing the working-tree state at phase 1 anyway.
Surfaced while tidying up after run 2 of the validation program (#16), 2026-08-25. Recorded as follow-up 6 in the run record.
The working-directory rule in
SKILL.mdopens with a goal and then gives three options in order:The ambiguity is what "dirty" means. If it means modified tracked files, option 2 always qualifies and option 3 is nearly unreachable. If it means any
git statusoutput — which is what "leavesgit statusclean" implies — then option 2 only qualifies in a repo that already ignores.audit/, and option 3 is indicated everywhere else.Run 2 resolved it the permissive way.
QuantEcon/metahas no.gitignoreat all, so option 3 was indicated by the rule's own condition, and option 2 was taken instead. The result was 2.4 MB of audit output — including AWS and access-token findings, per the run's own report — sitting untracked in a public repository checkout until it was moved by hand afterwards. Anygit add -Ain that repo would have staged it. The exposure required a deliberate add-commit-push, so this is a latent hazard rather than a live incident, but the blast radius is a public repo and the content is exactly the kind you would not want there.Worth noting that moving the bundle out afterwards left the checkout fully clean — empty
git status,HEADunchanged — which is a strictly better end state for a read-only skill and arguably what the rule is reaching for.Two candidate fixes, either sufficient:
Define the term. Say "dirty" means any
git statusoutput, and note that option 2 satisfies the goal only where the repo already ignores that path — which makes option 3 the default for repos without a suitable.gitignorerather than a rarely-taken fallback.Or add a check. Have the skill run
git check-ignoreon the candidate directory during preflight and fall through to option 3 when it does not match. That removes the judgement call entirely and is two lines. It pairs naturally with #59, which proposes capturing the working-tree state at phase 1 anyway.