support-request

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.