support-revalidate

name

support-revalidate

description

Re-check registry entries that have passed their revalidation window and restamp them, so the plugin's contact details stay true instead of quietly rotting. Reaches every URL and reads the pages behind them, re-reads support plan tiers and response times, tests whether previously dead routes have come back, promotes or demotes each claim's confidence, moves newly broken routes into known_dead, and reports a diff of what changed. Use when a lookup reports an entry as stale, when a support address bounced or a link 404'd, when a vendor has reorganised its support, or on a schedule to sweep everything that is due.

support-revalidate

Support routes rot silently. A vendor moves its help centre, retires a forum, changes a plan tier, and nothing announces it — the entry keeps looking authoritative while being wrong. This skill is the maintenance pass that keeps the registry's confidence earned.

Inputs

• service (optional) — one slug. Omitted: sweep everything past its window.
• force (optional) — revalidate regardless of age. Use after a bounce or a 404 was observed.

Procedure

1. Find what is due

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

Deliberately not a reachability check — it reports schema errors and computes age, nothing more. Deciding whether a route still works needs judgement, and the reasons are in step 3.

Nothing due and no force: say so in one line, with the next due date, and stop. Revalidating a fresh entry is wasted effort.

2. Reach everything

Every URL in the entry — channels, status page, docs, and each known_dead target:

for u in <urls>; do
  echo "$u : $(curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}' -A 'Mozilla/5.0' --max-time 20 "$u")"
done

Include the dead ones. Vendors restore things, and a known_dead entry that has silently come back is costing the user a working route.

For email addresses there is no equivalent check. Do not attempt a probe message — an empty mail to a support desk creates a ticket someone has to close. Re-verify the address the way it was found: by confirming the vendor still publishes it. If it has vanished from the vendor's own pages, demote it to referenced and note the date it stopped being published rather than declaring it dead.

3. Interpret the results properly

The status code alone decides almost nothing.

Observed	What it might mean	What to do
200	Alive — or a client-rendered shell with no content	Read the page. If a fetcher gets only a <title>, note it as a gotcha and read it in a browser
301 / 302	Moved — or a live redirect fronting a dead resource	Follow the chain and check the destination. A vanity URL pointing at an expired invite returns 301 all day
403	Bot-walled — usually not gone	Try another fetch route or a browser before demoting. Do not write off a help centre on a 403
404	Gone	Find the replacement before moving it to known_dead. A dead end with no instead is half a finding
Connection failure	Host retired	known_dead, and look for where it went

And for anything that is or should be a link, compare the target against the text:

curl -s -A 'Mozilla/5.0' --max-time 30 "<url>" | grep -oiE 'mailto:[^"'"'"'>]{3,60}' | sort -u

A vendor can print one address and link another — Twilio prints [e-mail] and links [e-mail]. The href is operative. If a recorded address no longer matches the href on the page it came from, that is a change, not a formatting detail.

Where an article body cannot be read because the help centre is client-rendered, a Wayback snapshot of the predecessor host usually can be — see support-add-service step 3b. Carry the snapshot date into evidence.

4. Re-read what changes without moving

URLs can be stable while the facts behind them change, and these are the fields that quietly go wrong:

• Plan tiers, prices, and response times. The most volatile numbers in an entry, and the ones escalation timing depends on.
• Priority level names. Vendors rename severity tiers, and the wording routes the ticket.
• Which channels each tier unlocks. Chat and phone move between tiers.
• SLA remedy terms and claim deadlines. A changed claim window silently forfeits a remedy.
• Required form fields.

5. Update the entry

• Restamp verified per channel, only on the ones actually checked. A blanket restamp of unchecked channels is the failure this whole skill exists to prevent — it converts an honest stale entry into a dishonest fresh one.
• Promote or demote confidence based on what was reached this time, and rewrite evidence to describe this pass.
• Move newly broken routes to known_dead with today's date, the reason, and instead.
• Restore recovered routes to channels[], and leave a gotchas line recording that it was dead and came back — a route with that history deserves a shorter window.
• Update verification.last_verified, verified_by and method. Where a page could not be read, say so in method.
• Reconsider revalidate_after_days. Lots of churn this pass means a shorter window next time.

Write to ~/.claude-plugins/contact-support/services/<slug>.json for a user entry. For a shipped entry, edit it in place and say it needs committing, so the correction reaches everyone rather than one machine.

6. Report the diff

Four sections, and keep them short:

• Unchanged — a count, not a list.
• Changed — old value, new value, one line each.
• Newly dead — target, evidence, replacement.
• Recovered — target, and what it was replaced by in the meantime.

Then the new due date. If nothing changed, say that plainly — a clean pass is a real result and means the window can probably lengthen.

Guardrails

• Never restamp a claim you did not check. The date is the entire contract this file makes with its reader.
• Never send probe messages to support addresses, and never open a test ticket. Verification must not consume the vendor's time or the user's SLA.
• Never delete a known_dead item as noise. If it recovered, move it and record the history; the list only has value because nothing falls off it.
• Do not soften confidence distinctions to make an entry look better. referenced is an honest and useful state.
• Do not silently drop a channel that vanished. It becomes known_dead with a reason, or the next reader will assume nobody ever knew about it.