Ops Credentials

OPS ► CREDENTIALS

CLI/API Reference

| Command | Output | | -------------------------------------- | ---------------------------------------------- | | bin/ops-credentials | Human table — configured + missing per service | | bin/ops-credentials --json | JSON array, one entry per credential | | bin/ops-credentials --service stripe | Filter to one integration |

The bin script is the source of truth. It scans these sources in order and reports the FIRST hit per credential:

1. Shell env ($STRIPE_SECRET_KEY, etc.)
2. $OPS_DATA_DIR/preferences.json (.revenue.stripe.secret_key, etc., including doppler:KEY references that get resolved live)
3. macOS Keychain (security find-generic-password -s -w)
4. Dashlane (dcli password --output json)

Values shorter than 12 chars print as •••; longer values print as first6•••last4.

Your task

When the user runs /ops:credentials:

1. Run bin/ops-credentials and present the output verbatim — it's already formatted for the user's terminal (compact mode for SSH/mobile, table layout otherwise).

1. Offer follow-ups via AskUserQuestion (max 4 options per Rule 1):

What would you like to do next?
  [Configure a missing service — pick one to set up now]
  [Re-audit a specific service]
  [Export to JSON]
  [Done]

1. On "Configure missing": list missing services 4-at-a-time via AskUserQuestion. For each pick, call the /ops:setup skill.

1. On "Re-audit specific": ask for the service name and run bin/ops-credentials --service .

1. On "Export to JSON": run bin/ops-credentials --json and write the result to /tmp/ops-credentials-audit-$(date +%s).json. Print the path.

Why this skill exists

Claude Code's plugin settings UI cannot introspect external credential stores. If a user has STRIPE_SECRET_KEY in macOS Keychain or klaviyo_api_key in Doppler, the settings panel shows those fields as empty (because the value isn't stored in Claude Code's user-config). The user can't tell at a glance which integrations they've already wired up.

/ops:credentials solves that — one command, one table, complete picture of which integrations are ready to use vs which still need /ops:setup.

Homey Pro (Home Automation)

| Field | Value | | ------------ | ----------------------------------------------------------------------------------------------------------- | | Service name | Homey Pro | | Category | Home Automation | | Keys | HOMEY_LOCAL_URL, HOMEY_LOCAL_TOKEN, HOMEY_CLOUD_TOKEN, HOMEY_ID | | Storage | $PREFS_PATH → .home_automation.homey_local_url, .homey_local_token, .homey_cloud_token, .homey_id | | Required | HOMEY_LOCAL_URL, HOMEY_LOCAL_TOKEN | | Optional | HOMEY_CLOUD_TOKEN (off-LAN fallback), HOMEY_ID (cloud API only) |

Rotation: Revoke the current token at https://my.homey.app/manager/tokens, generate a new one, then rerun /ops:setup --section home to save the replacement.

---

Privacy guarantees

• Never prints raw values. All output is masked.
• Never copies values to disk. Reads happen in-process; the JSON export contains only {service, label, configured, masked, source}, never the raw secret.
• Read-only. Does not write to keychain, Doppler, or preferences.

Mobile / SSH (Rule 7)

When $SSH_CONNECTION / $SSH_CLIENT / $SSH_TTY is set or $OPS_MOBILE=1, the bin script auto-switches to compact one-line-per-cred format. Skill output should pass it through unchanged.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Lifecycle-Innovations-Limited
• Source: Lifecycle-Innovations-Limited/claude-ops
• License: MIT
• Homepage: https://github.com/Lifecycle-Innovations-Limited/claude-ops/wiki

Install and usage instructions live in the source repository linked above.