name: repo-sync-secret-guard category: devops description: Git sync and pre-commit guardrails for Hermes/CEO repos, with emphasis on secret detection that avoids false positives in public research artifacts.

Repo Sync & Secret Guard

Use this skill when maintaining Git-backed Hermes/CEO repositories that are auto-synced, committed by cron, or protected by pre-commit secret scanning.

When to use

• Fixing a cron-driven git auto-sync job.
• Adding or refining a pre-commit hook.
• Preventing accidental secret leaks in repo-managed runtime assets.
• Reviewing whether a file should be tracked, ignored, or treated as a public research artifact.

Core principles

1. Prefer high-confidence secret detection over broad keyword blocking.
2. Do not block on generic strings like api_key, token, or secret alone.
3. Block on concrete token formats or a sensitive key name paired with a real-looking secret value.
4. Do not blindly exclude research source artifacts.
5. Files under content/research/**/sources/** may be noisy, but they are often important evidence and should remain in policy.
6. If they contain secret-like strings, handle them with pattern quality, not path-based blanket exemptions.
7. Cron sync must be silent on no-op and explicit on failure.
8. No changes: exit 0 and print a quiet/success marker if needed.
9. Hook failure or commit failure: surface the exact offending path and pattern class.
10. Treat auto-sync as a pipeline, not a single command.
11. Stash, pull/rebase, restore stash, stage, secret-guard, commit, push.
12. Verify the actual failing step before editing the script.

Recommended workflow

1. Inspect the failing job output and reproduce locally.
2. Run the sync script with tracing if necessary to identify the exact failing command.
3. Test the commit path separately from the push path.
4. If pre-commit is the blocker, tighten the hook before changing the cron job.
5. Re-run the sync end-to-end and confirm the exit code is zero.

Secret-detection policy

Prefer blocking on

• Explicit credential file names: .env, auth.json, credentials.json, google_client_secret.json, token.pickle, lark_schema.json, dashboard.txt.
• Strong token formats: sk-..., ghp_..., gho_..., github_pat_..., AIza..., ya29...., xox..., hf_..., pat_....
• Sensitive keys only when coupled with a real secret-like value: base_token, access_token, client_secret, refresh_token, private_key, api_secret.

Avoid

• Blocking on generic words without a token-shaped value.
• Blanket path exemptions for research source directories.
• Treating public HTML snippets, scraped pages, or docs as credentials solely because they include substrings like api_key in embedded public scripts.

Pitfalls

• Pre-commit rules that are too broad will break cron-based sync jobs by turning a harmless commit into exit code 1.
• If a public source file triggers the hook, narrow the regex; do not hide the file path globally.
• If git-auto-sync fails, confirm whether the blocker is:
• hook rejection
• dirty index after stash/pop
• push rejection
• unrelated pathspec/restore mistakes

Verification

• Run the sync script manually once after any hook change.
• Confirm:
• commit succeeds
• push succeeds
• second run with no changes is silent or no-op
• If the repo contains public research sources, sample one or two known noisy files and ensure they do not false-positive unless they truly contain secret-shaped values.

Linked notes

• See references/pre-commit-secret-scan.md for the refined pattern policy and the false-positive case that motivated it.