support-account

name

support-account

description

Record or update who the user is to a vendor, so support requests can be filed on their behalf without asking for the same details every time. Stores account numbers and customer identifiers that support desks legitimately ask for, which support plan the account is on and when that was last confirmed, the name and address to correspond under, and a pointer to where the credentials live — the vault item, the environment variable name, the login URL — never the secret itself. Handles several accounts per vendor with labels and a default. Use when the user says to remember their account details, save their customer number, note their support plan, record where a password is kept, or when a lookup or draft has stalled for want of an identifier.

support-account

Fill in the half of the picture the registry cannot know: which account, on which plan, under whose name.

Storage, resolution order and the full schema are in ${CLAUDE_PLUGIN_ROOT}/references/user-data-layout.md. Read it before writing anything. The one rule that matters: this file lives at ~/.claude-plugins/contact-support/accounts.json, outside the plugin, because anything inside the plugin directory is destroyed by the next update.

Inputs

• service — vendor slug. Need not have a registry entry yet; a profile can exist first.
• label (optional) — which account. Defaults to personal for the first one.
• Whatever detail the user offered. Often one field at a time, across sessions.

Procedure

1. Read what is already there

cat ~/.claude-plugins/contact-support/accounts.json 2>/dev/null

Absent: create it with {"version": 1, "services": {}} and, if the user has not set them, ask once for the defaults block — name, email, phone, timezone. Every subsequent service reuses it, so asking once here saves asking on every ticket. The timezone is not optional padding: it is what makes timestamps in a ticket readable and what decides when "business hours" starts for an SLA.

2. Find out what to collect

If a registry entry exists, its identifiers[] is the list, and required_for says which channels are blocked without each one. Ask only for those. where_to_find tells the user where to read each value off — quote it rather than making them hunt.

If no entry exists, collect the general shape: account number or customer ID, the account email, plan or tier, and the correspondence name. Then suggest support-add-service so the vendor's actual requirements can replace the guess.

3. Validate before storing

Check each value against the identifier's pattern. A mismatch is almost always a real mistake — pasting an API key where a Account SID belongs, a subaccount SID in the parent field, a truncated copy. Say what was expected and ask again rather than storing it.

example fields show shape only. If a user's value is identical to the example, they have pasted the placeholder.

4. Refuse to store secrets

An identifier marked secret: true is never stored as a value. Neither is anything that authenticates, whether or not the registry names it: tokens, API keys, passwords, recovery codes, private keys, session cookies.

If the user offers one, store the pointer instead and say what was stored:

"credentials": {
  "location": "1password",
  "ref": "op://Private/Twilio/credential",
  "login_url": "https://console.twilio.com/",
  "mfa": "TOTP in 1Password"
}

Say it once, plainly — "storing the location, not the token, so it stays out of transcripts and drafts" — and move on. Do not lecture, and do not raise it again on later edits.

The mfa field earns its place: it stops a browser-driven login being attempted blind and stalling at a prompt nobody is watching.

5. Stamp the plan

Write support_plan and plan_verified together, always. An undated plan claim is the field most likely to be silently wrong, and it is the field that sets both which channels are open and when escalation is justified.

If the user is unsure of the tier, record what they believe and set plan_verified to the date they said it, noting it as self-reported. Better an unconfirmed value with a date than a confident wrong one.

6. Second and subsequent accounts

Append to accounts[]; never overwrite. Once there are two, default is required — ask which one, because guessing sends the wrong Account SID and gets an authoritative answer about the wrong account.

Give labels the user will recognise later. personal and work beat account-1 and account-2.

7. Write and confirm

Write the file. Report what was stored, per field, and what is still missing that a channel needs. Never echo back a stored value that is longer than an obvious identifier — confirm the field is set rather than reprinting it into the transcript.

Guardrails

• Write only to ~/.claude-plugins/contact-support/accounts.json. Nothing in the plugin directory.
• Never write a secret value into this file, in any field, however the user phrases the request. The pointer is the deliverable.
• Never invent, complete or guess an identifier. A missing identifier is a question to ask.
• Do not copy identifiers into a repository, a commit, or any file outside ~/.claude-plugins/contact-support/.
• When editing, merge — do not rewrite the file from what is in context. Other services' profiles and other accounts under this service must survive.