Triggered by ~1h lost on 2026-06-12 when the IX WHM access method was forgotten and password auth no longer worked. CLAUDE.md Key rules now mandates vaulting via the vault skill + thorough documentation for any credential surfaced in a session. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1.7 KiB
1.7 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| feedback-vault-every-credential | ANY credential surfaced in a session must be vaulted via the vault skill AND thoroughly documented — immediately |
|
When ANY credential appears in a session — the user pastes one, you create/rotate one, or you
discover one in a log/config — immediately store it in the SOPS vault via the vault skill
and document it thoroughly (what it is, what it's for, how it's used: auth method, endpoint,
gotchas). This is a standing job requirement, not a per-task ask — it is literally why the vault
exists.
Why: Mike (2026-06-12) was "highly irritated" after ~an hour was wasted because the IX WHM access method had been lost/forgotten and I fell back to a password method that no longer works. The original rule ("recognize any credential in-session, vault it, document what it's for and how it's used") had drifted out of the always-loaded instructions.
How to apply:
- Use the
vaultskill (vault-helper.sh new/set,vault.sh get/get-field) — the canonical path. Do NOT improvise rawsops/vault.shwith hand-built paths. (Exception: the helper only writes undercredentials:; a top-level metadatanotesedit still needssops --set— but the secret itself always goes through the skill.) - Document in the entry's
notes: purpose + exact usage (e.g. header vs basic-auth, endpoint, "force curl -4", what does NOT work and why). Future me reads this instead of re-deriving. - Finish the job: store ->
verifyencrypted -> publish (sync/commit). Never paste the secret into chat/commit/coord. - Now reinforced in CORE
.claude/CLAUDE.md"Key rules". See ix-whm-dns-api-access for the concrete case that triggered this.