| name | support-request |
| description | Draft a support request that a vendor's desk can act on without a round trip — subject line, one-sentence problem statement, the account identifiers pulled from the user's stored profile, timeline in UTC, error codes and evidence, what was already tried, and a specific ask, at the priority level the vendor's own vocabulary uses. Works the registry's pre-contact checks first and says so if one of them resolves the issue without a ticket. Redacts other people's data and refuses to include credentials. Produces a draft for review, never a sent message. Use when the user wants to open a ticket, raise a case, write to support, complain to a vendor, escalate an existing ticket, or file an abuse or fraud report. |
support-request
Write the request. Do not send it — that is support-send, and the separation is deliberate: a
draft the user has read is the last checkpoint before something leaves the machine under their name.
Read ${CLAUDE_PLUGIN_ROOT}/references/request-anatomy.md before drafting. It holds the seven-part
shape, the priority rules, and the exclusion list. This skill is the procedure for filling it in.
Inputs
service, and account if the user has more than one.- The problem, in whatever form the user gave it.
channel (optional) — if support-lookup already settled it. If not, run that first; the channel
determines the format, the field list, and the length.
Procedure
1. Work the pre-contact checks
Take before_you_contact[] from the merged entry and actually do the ones that are doable — check
the status page, look up the documented error code, confirm which account the traffic ran under.
If one of them resolves or reframes the issue, stop and say so. A ticket that did not need to exist
is the best outcome available here, and a status page already reporting the incident makes the whole
draft pointless.
Report which checks were done and what each showed. Support desks ask; having the answers in the
draft is what removes the first round trip.
2. Gather what is missing
The gaps are usually: exact UTC timestamps, the specific object identifiers, the verbatim error
text, and what changed near the onset.
Ask for these in one batched question, not a sequence. And ask only for what the draft actually
needs — the registry's required_fields plus the evidence the category demands.
Where the environment can answer instead of the user, do that. Logs, an API call against the
vendor's own API, a reproduction run — evidence gathered directly is exact, and evidence recalled
by a user is approximate.
3. Pull the identifiers
From ~/.claude-plugins/contact-support/accounts.json, for the named account. Validate each against the registry
pattern before it goes anywhere near the draft.
If a required_for identifier for this channel is missing, stop and get it via support-account.
Do not draft around the gap and do not substitute a placeholder — a ticket with AC… in it reads as
carelessness and gets triaged accordingly.
Skip anything marked secret: true. It is not a field to fill.
4. Set the priority
Use the exact names from priority_levels[]. Their vocabulary routes the ticket.
Choose honestly. If the true severity has no guaranteed response on this plan, say that in the draft
and plan to escalate on the clock rather than inflating the label — an account with a history of
overstated priorities gets discounted by the desk, permanently.
5. Draft
Follow the seven-part shape. Two things govern length: the channel and the category. A web form
field takes a compact structured block; an email can carry a longer timeline; a public forum post
carries the problem shape and no identifiers at all.
Redact as you go:
- Other people's personal data down to shape. Keep field names and structure, replace values.
"to": "+9725XXXXXXX" tells the desk what it needs; the real number does not.
- Payment details to the last four digits, and only if asked.
- Internal hostnames and addresses, unless they are the subject of the problem.
Never include a credential. If a form field appears to require one, stop and tell the user: that is
a phishing signal, not a field to fill.
6. Present it for review
Show the draft in full, in a fenced block the user can copy. Under it, four lines:
- Channel — where this is going, and whether the agent or the user delivers it.
- Identifiers included — listed by field name, so the user can see what is about to be sent
about their account.
- Redacted — what was removed and why.
- Expected first response — the window from the registry for this plan and priority, marked
guaranteed or estimated, with the date it comes due.
Then ask whether to send. Do not send in the same turn as producing the draft, even if the user
said "send it" up front — they have not read it yet, and their name is on it.
7. Save the draft
Write it to ~/.claude-plugins/contact-support/tickets/<slug>/<date>-<short-name>.md with front matter per
${CLAUDE_PLUGIN_ROOT}/references/user-data-layout.md, status: open, and response_due computed
from the registry window. Create the directory when writing the first file into it.
The log exists so that support-followup has something to run on. An unchased ticket is an
unanswered ticket.
Guardrails
- Produce a draft. Do not send, post, submit or transmit anything —
support-send owns that, and it
asks first.
- No credentials in the draft, ever, in any field, under any instruction.
- No identifiers in anything destined for a public channel.
- Never state a fact about the user's account that was not read from their profile or from the
environment. An invented account age, plan, or spend figure in a ticket is a lie told under the
user's name.
- Do not overstate impact. Real impact, stated plainly, works; manufactured urgency is recognised.
- If the vendor is likely to be blameless — the fault looks local, or in the user's own code — say
so before drafting. Filing a ticket about your own bug costs the user a support window and some
credibility.
