support-lookup

name

support-lookup

description

Find out how to reach a named vendor's support team, using this plugin's verified registry rather than a web search. Resolves the service, merges the user's overrides over the shipped entry, filters the channels by what the account's support plan can use and what an agent can actually drive, and reports the recommended route with the response time to expect, the identifiers the desk will demand, the checks worth doing first, and the plausible-looking routes that are known dead. Use when the user asks how to contact a vendor, what a company's support email or ticket URL is, whether a service has phone support, how long support should take to reply, or where to report abuse — and always as the first step before drafting or sending anything.

support-lookup

Answer "how do I reach these people" from the registry, not from memory. A support address recalled from training data is a guess with a plausible shape; [e-mail] is the canonical example — it looks exactly right and does not exist.

Inputs

• service — what the user called the vendor. Match loosely.
• issue (optional) — what the problem is. Without it, channel filtering cannot be done properly; ask for a one-line description if the user has not given one.
• account (optional) — which of the user's accounts, when there are several.

Procedure

1. Resolve the service

Search shipped and user entries for a slug, name or alias match, case-insensitively:

ls "${CLAUDE_PLUGIN_ROOT}/data/services/" ~/.claude-plugins/contact-support/services/ 2>/dev/null
grep -ril "<term>" "${CLAUDE_PLUGIN_ROOT}/data/services/" ~/.claude-plugins/contact-support/services/ 2>/dev/null

No match: say so in one line and offer support-add-service, which researches and writes an entry. Do not improvise contact details from memory as a stopgap — an unverified answer delivered confidently is the failure mode this plugin exists to prevent. If the user wants a quick unverified answer anyway, label every claim as unverified and check the URLs before repeating them.

Then check separate_desks[]. If the issue concerns a product listed there, this is the wrong entry and the misroute is the most expensive mistake available — say so before anything else.

2. Merge

Read ${CLAUDE_PLUGIN_ROOT}/references/user-data-layout.md and apply the resolution order. The user's overlay wins; accumulated lists concatenate; the older last_verified governs.

3. Check the age

"${CLAUDE_PLUGIN_ROOT}/scripts/check_registry.py"

Past revalidate_after_days, say so in one line — "verified 2026-02-01, 180 days ago, past its 90-day window" — and offer support-revalidate. Still report what the entry says. A stale entry with a stated age is useful; the same entry presented as current is not.

4. Load the account context

Read ~/.claude-plugins/contact-support/accounts.json for this slug. Take support_plan, identifiers and entitlements.

Missing profile, or missing an identifier that a channel lists in required_for: name exactly what is missing and offer support-account. Do not fabricate a placeholder identifier — a ticket with a wrong Account SID gets a confident answer about someone else's account.

If plan_verified is absent or old, treat the plan as unconfirmed and say so. Every response-time figure below depends on it.

5. Select the channel

Read ${CLAUDE_PLUGIN_ROOT}/references/channel-selection.md and work its steps: classify the issue, filter by plans, filter by agent_reachable, drop anything whose not_for matches.

Do not skip to the first listed channel. Entry order is a default for an unclassified issue, and most issues are classifiable.

6. Report

Six things, in this order:

1. Recommended channel — what it is, where, and one sentence on why this one.
2. Who does it — the agent unaided, the agent driving the user's browser, or the user alone. Say this plainly; it sets the expectation for the rest of the interaction.
3. Response time to expect, tied to the plan, marked guaranteed or estimated. An estimate stated as a guarantee is worse than saying nothing, because escalation gets timed against it.
4. Identifiers the desk will ask for — which are on file, which are missing.
5. Before you contact — the entry's checks, filtered to the ones this issue makes relevant. If one of them would plainly resolve the issue without a ticket, say that first and stop. Not opening a ticket is a good outcome.
6. Alternatives and dead ends — the runner-up channel with the condition for switching, plus any known_dead route the user might otherwise reach for.

End by naming the next step: support-request to draft, or the specific check to run first.

Guardrails

• Never state a support address, URL or phone number that is not in the merged entry. If it is not there, it is not verified, and saying so is the answer.
• Never present a referenced or inferred channel as confirmed. Carry the distinction into the reply where it changes what the user should expect.
• Never recommend a public channel for an issue that cannot be described without identifiers.
• Do not read credentials unless the user has asked where a credential lives. Nothing here needs it, and there is no reason for a secret's location to pass through this report.