Add an explicit, top-of-file policy forbidding any secret, password, token, API key, or SSH key from being committed to the repository in any form (source, comments, examples, docs, commit messages). Covers: environment-variable/vault sourcing, placeholder usage in examples, pre-commit self-check, and the mandatory history-purge procedure (git filter-repo --replace-text + force-push + credential rotation) if a secret is ever introduced. 🤖 Generated with [Crush](https://github.com/charmassociates/crush) Assisted-by: GLM-5 via Crush <crush@charm.land>
3.0 KiB
3.0 KiB
Agent Guidelines
Secrets and Credentials Policy
NEVER commit secrets, passwords, tokens, API keys, SSH keys, or any credential to this repository — in source, in comments, in examples, in documentation, or in commit messages. No exceptions.
Rules:
- No secrets in code. Credentials must come from environment variables, a vault, or Ansible Vault — never from a hardcoded literal.
- No real secrets in examples/docs. Use placeholders like
$AWX_PASSWORD,***REMOVED***, or<your-token-here>. - Check before committing. If a change introduces anything that looks like
a secret (password assignment,
b64encode,AUTH =, API key, private key block), stop and refactor it to read from the environment first. - If a secret is ever introduced, it must be purged from the entire git
history (not just the working tree) with
git filter-repo --replace-text, followed by a force-push. Rotating the exposed credential is mandatory. .gitignoremust keep secret-bearing paths ignored (e.g..env, private keys). Add new entries as needed.
Git Commit and Push Policy
ALWAYS commit and push automatically. NEVER wait to be asked.
After completing each logical unit of work, immediately:
- Stage the relevant files
- Commit with a well-formed message (see below)
- Push to
origin/main
Do NOT batch multiple unrelated changes into one commit. Do NOT leave work uncommitted at the end of a task.
Commit Rules
- Commit atomically: Each logical change is its own commit.
- Use conventional commit format:
feat(scope): description— New featurefix(scope): description— Bug fixdocs: description— Documentation changesrefactor(scope): description— Code refactoringtest(scope): description— Test additions/changeschore: description— Maintenance tasks
- Write verbose, beautifully formatted messages:
- Title line (50 chars max)
- Blank line
- Body explaining WHAT and WHY (not how)
- Reference related files/issues
- Include footer with attribution
- Push after every commit — do not accumulate local commits.
Example Commit
feat(security-hardening): implement SCAP-STIG compliance logic
Refactor apply script to implement comprehensive security hardening:
- Add GRUB bootloader permission hardening (root:root, mode 0400)
- Disable and remove autofs service per STIG requirements
- Deploy modprobe configurations for kernel module blacklisting
- Create STIG-compliant network protocol blacklist
This ensures servers meet DoD security requirements for production
deployment.
🤖 Generated with [Crush](https://github.com/charmassociates/crush)
Assisted-by: GLM-5 via Crush <crush@charm.land>
Important
- NEVER wait to be asked to commit and push.
- Commit immediately after each logical unit of work.
- Push after every commit.
- Prefer many small, focused commits over fewer large ones.
- Never commit secrets — see the Secrets and Credentials Policy above.