| 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; help@twilio.com 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:
- Recommended channel — what it is, where, and one sentence on why this one.
- 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.
- 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.
- Identifiers the desk will ask for — which are on file, which are missing.
- 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.
- 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.
