This repository publishes Codex skills and helper scripts. It is prepared for source sharing, not for storing runtime credentials, browser state, or local machine secrets.

• Real API keys, access tokens, cookies, session exports, browser profiles, local databases, or raw private-key material.
• .env files or machine-local overrides containing non-placeholder credentials.
• Built-in .system/ skills or danger-* skills unless they have been intentionally exported and separately reviewed.

• Keep credentials in environment variables or a local secret manager.
• Keep third-party material inside third-party/ with explicit origin and license review.
• Keep maintainer-specific sensitive scan inputs in a local private policy file such as $CODEX_HOME/private/publish-policy.json, not in committed docs or shared shell snippets.
• Prefer redacted examples such as your_token_here instead of live values.
• Keep the first sanitization and publication pass local-first. Do not hand unpublished branches, local private policy files, or internal-only skill trees to Codex cloud or GitHub-side Codex flows from this repo workflow.
• Treat the publish repo as a mirror of local source skills. Managed skill bundle edits should originate in the local source tree and be synced out, not authored directly in the public mirror.

If you find a leaked secret or sensitive local path:

1. Do not paste the raw value into a public issue.
2. Rotate or revoke the credential first if it is real.
3. Contact the maintainer privately with redacted evidence and affected file paths.

Run the staged export scan before public release:

python3 owned/skills-github-publisher/scripts/preflight_scan.py --root . --strict --strict-provenance --local-policy-file "$CODEX_HOME/private/publish-policy.json"

After creating the GitHub repository, enable Secret Scanning and Push Protection before the first public push.

If you later enable Codex on GitHub for this repository, limit the first use to review on already public pull requests rather than broader cloud-side editing. If a trusted maintainer later wants a follow-up task to write back to the current PR branch, make that request explicit and keep the patch scope narrow.