API Key Management Skill: What It Does and How to Install It

• Asks six questions first: retrofit or new, key holders, OAuth, compliance, RBAC, timing.

  Before it designs anything it batches six questions. Greenfield or retrofit, who will hold keys, whether third-party apps act for your users, which compliance regimes apply, whether you already have RBAC that scopes could reuse, and your timing and effort ceiling.

  Try: “Design the API key system for our public API - today we issue one UUID per account and store it plaintext in Postgres.”

  Clarifying questions

• Designs the key shape: type and environment prefix, random body, checksum.

  Keys follow a prefix, a high-entropy random body and a checksum, with the prefix encoding key type and environment. SKILL.md sets an entropy floor of at least 120 bits.

  1. Key format and prefix

• Ranks three storage options and defaults to showing the key once and storing only a hash.

  The default is an irretrievable hash with a short plaintext prefix column for lookup. It steps up to encrypted retrievable storage only when lost keys dominate support load, and names workload identity as the option with nothing to leak.

  2. Storage model

• Picks per-environment keys and restrictive scopes; fine-grained scoping when needed.

  Rejects a single account-wide key and a fail-open default where omitting scopes grants full access. Fine-grained resource scoping is promoted for compliance, enterprise demands or distinct team needs.

  3. Scoping model

• Designs a one-call roll with an overlap window where old and new keys both work.

  Grace periods by scenario: 24 hours to 7 days for routine rotation, zero grace for confirmed compromise or offboarding. Never delete an old key before last-used data shows zero traffic.

  4. Rotation

• Specifies sign up, create, rotate and revoke with no support ticket.

  The key list shows a label, creation date, last-used time and status, masks the key after creation, and updates last-used asynchronously.

  5. Self-service dashboard

• Defaults production to service-account or org-owned keys; writes the leaver runbook.

  The offboarding runbook enumerates the leaver's keys, revokes each with zero grace, rotates shared credentials, and logs every action.

  6. Ownership and offboarding

• Maps SOC 2 and PCI-DSS 4.0 expectations to key-lifecycle controls and product features.

  Notes that PCI-DSS 4.0 does not mandate a fixed rotation interval; it requires the cadence to be justified by a documented targeted risk analysis.

  7. Compliance lifecycle governance

Watch out for

• It may save notes to developer-platform-context.md

  SKILL.md says that when your agent keeps memory in a file, it should consider using this file name. Our advice: keep it out of commits if it holds company plans. github.com