Security hygiene check

Event: immediately before creating a project commit, including amendments and merge commits. Check after final edits and staging, including skill refinements. This gate is independent of self-improvement enablement and applies even when committing or pushing is already authorized.

1. Read the disclosure policy. Maintain agents/scratch/security-policy.md (or the configured project scratch equivalent) as a Git-versioned natural-language allowlist: what information may be disclosed, for what purpose, and under which conditions. Describe semantic permissions, not exempt files, paths, globs, or scanner rules; every file remains inspectable. Record the user's approved scope and rationale without sensitive values. Existing occurrence is not consent. A missing policy grants no exceptions; conflicting or ambiguous permissions require clarification.
2. Inspect the candidate. Review the exact proposed tree and commit metadata, not just the working-tree diff. Search for personal identifying data (PID/PII), private project associations, local user paths, credentials, tokens, private keys, authenticated URLs, and confidential content. Include tracked scratch, generated artifacts, and newly added files; .gitignore does not protect tracked content. Use available local secret scanning plus contextual review; do not upload content to an external scanner. Distinguish intentional public attribution and clearly synthetic examples from plausible leaks. State inaccessible or unscanned coverage rather than claiming it clean.
3. Pause on uncovered findings. Apply recorded permissions only when the finding and its context clearly satisfy them; do not ask again for covered disclosures. For uncovered findings, report locations, data categories, and exposure scope without reproducing sensitive values. Ask: “These items may disclose personal or sensitive information. Would you like them removed or redacted, excluded from the commit, or retained as intentional?” Explain that this skill requires a decision before committing. Wait for an explicit disposition covering each finding; silence and earlier blanket commit/push authorization are not approval. Do not silently delete, unstage, or retain flagged content. If sensitive material is already committed, identify that exposure separately; removal from the new tree does not erase history, and rotation or history rewriting requires separate authorization.
4. Resolve and recheck. Apply the user's selected disposition. Record reusable disclosure permissions in the policy at the scope the user approved; distinguish one-time exceptions from standing permissions and never broaden them by inference. Verify the final candidate before allowing the authorized commit. Recheck if its contents or metadata change; one-time approval covers only the reviewed findings; standing policy applies only within its recorded conditions. Preserve unrelated work. Record only sanitized decisions and unresolved coverage in existing scratch notes when useful; never persist secret values. An incomplete check remains unresolved, not a pass.

Host wiring: applicable AGENTS.md must require this check before every project commit, apply the project disclosure policy, and link this skill. Installation must carry that instruction to the chosen scope. This is an agent-followed gate, not an installed Git hook; commits made outside a compliant agent are not intercepted.

Illustrative standing permission: “Public contributor names and their chosen commit attribution emails may appear in Git metadata; this does not permit contact details in logs or datasets.” Record this only if approved for the project.