user

credential-brokers

Credential resolution — env → OS keyring → dotfile. Never cleartext.

1 skills1 human gate5–15 min/session

Install this pack Read the reference

The contract

Use it when: You are setting up a credentialed pack for the first time, or a previously stored credential has stopped resolving.
You provide: The service name, the credential type, and your preferred storage location.
You receive: A credential stored in the resolution chain, verified by a live test invocation.

Where you decide

The agent pauses at these points. You choose whether to continue, redirect, or stop.

Confirm credential type and storage location

What changes when you install this

After installing credential-brokers, every credentialed skill in your toolkit resolves its token in-process — environment variable, OS keyring, or a local dotfile — without the value ever reaching the model. You set up a credential once; every subsequent session that needs it resolves it automatically.

The journey

1. Identify the credential needed

You provide: the name of the service and the credential type it requires — API key, personal access token, or SSO cookie.
Agent does: walks you through identifying what credential type the service requires and which resolution path to use.
You decide: confirm credential type and storage location at the credential setup gate — choose where the credential will live: environment variable (CI-friendly), OS keyring (secure, persistent), or dotfile (portable); for most developer workstations, the OS keyring is the right choice.
Output: an agreed credential type and resolution path.

2. Set up and verify

Agent does: runs credential-setup, prompts for the token value (which is never logged), stores it via the configured resolution chain, and then runs a test invocation to confirm the credential resolves correctly.
You do: provide the token value when prompted; verify the test invocation succeeded; if it fails, work through the resolution chain with the agent — is the environment variable exported? Is the keyring unlocked? Is the dotfile in the expected location and readable?
Output: a stored credential verified by a successful test invocation.

3. Credential available to all sessions

Agent does: confirms the credential is stored and will resolve automatically in every subsequent session that needs it — the token value never passes through the model again.
You do: confirm that the first real invocation of the credentialed skill works end-to-end; if a skill returns an auth error after a successful setup, the first check is always whether the token has the right scope for this operation.
Output: a fully operational credential available to all subsequent sessions.

Human gates

For each gate, everything you need to make a confident decision.

Confirm credential type and storage location
Trigger
Before credential-setup runs — to select the right resolution path
Time
3–8 minutes
What to check, good, bad, consequence
What to check
What type of credential does the service require — API key, personal access token, OAuth token, or SSO cookie?
Which resolution path fits your environment: environment variable (fast, CI-friendly), OS keyring (secure, persistent across shells), or dotfile (portable, requires file-permission discipline)?
Does the credential have a scope or permission level requirement? (A read-only token that a write-capable skill needs will fail at runtime, not at setup.)
Is this credential shared across multiple services — or per-service? (A Figma token for personal files is different from a team-scoped token.)
What good looks like
A credential stored in the right resolver for your environment, with the correct scope for every skill that will use it — confirmed by a test invocation before you leave the setup session.
What bad looks like
A credential stored in an environment variable that only exists in the current shell — it works now, silently fails in a new terminal or CI. Or a token set up for read access when the skills you're installing need write access.
Consequence of skipping
A credential that works in setup but fails at runtime is the most common source of confusing mid-session errors. Credentialed skills report auth failures with opaque messages — the setup gate is the cheap place to discover the mismatch.

Typical session

Agent turns: 2–4
Human gates: 1
Wall-clock time: 5–15 min

Install

agentbundle install --pack credential-brokers --scope user

Skills in this pack

credential-setup1 gate
Walks through establishing a credential for a service — API key, personal access token, or SSO cookie — and stores it via the configured resolution chain.