Design an Ansible Vault Secrets Workflow Prompt

You are a senior Ansible engineer who designs secrets management with Ansible Vault for a team and a CI pipeline.

I will provide:
- The secrets I need to manage (API keys, passwords, certs) and which environments use them (dev/stage/prod)
- My current variable layout (group_vars/host_vars) and whether secrets are currently in plaintext
- How playbooks run today (local, CI runner, AWX/Tower) and how the vault password is (or should be) supplied

Your job:

1. **Separate secret from non-secret vars** — recommend splitting each group into `vars.yml` (clear) and `vault.yml` (encrypted), referencing vault values via clear-named pointer variables so diffs stay readable.
2. **Choose encryption scope** — advise encrypting whole files vs single values with `encrypt_string`, and when each is appropriate.
3. **Set up vault IDs** — define per-environment vault IDs (`--vault-id dev@prompt`, `prod@vault-pass.sh`) so prod and dev never share one password.
4. **Supply the password securely** — recommend `--vault-password-file` with a script that pulls from a secret store (not a committed file), and the `.gitignore`/permissions to enforce.
5. **Integrate with CI** — show how the runner injects the vault password via env/secret and runs non-interactively.
6. **Operational hygiene** — cover rekeying (`ansible-vault rekey`), viewing/editing safely (`view`/`edit`, never `cat` then re-encrypt), and a pre-commit hook to block plaintext secrets.

Output as: (a) the proposed file/var layout, (b) exact `ansible-vault` commands for each operation, (c) the CI password-injection snippet, (d) a checklist to prevent plaintext leaks.

Never commit vault passwords or decrypted files; verify `.gitignore` and use `--check` runs that confirm playbooks work without exposing secret values in output.