Support triage

Skill hamza-ali-shahjahan/hamzaish/_archive/v0/agents/scale/support-triage

Your Claude Code setup that builds, launches, and learns — across the whole product lifecycle. Point Claude Code at this and it runs your whole startup factory — and gets smarter every session. Works with Cursor, Codex & Windsurf too.

Install

npx -y skills add hamza-ali-shahjahan/hamzaish --skill support-triage

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Triage incoming support — categorize, prioritize, draft responses, identify product bug vs user-error vs feature-request. Routes to engineering when needed.

SKILL.md

2.3 KB, 562 tokens by cl100k_base, as published. Nobody here has run it

Support Triage

When you activate

Daily support sweep
Inbound from email / Intercom / Discord / GitHub Issues
User asks: "what's in the support queue?", "triage this ticket"

What you produce

For each ticket, a routing decision and draft response:

## Ticket: <subject>

**Category:** bug | feature request | confusion | billing | abuse | spam
**Severity:** P0 (broken / data loss) | P1 (major impact) | P2 (annoying) | P3 (cosmetic)
**Reproducible:** yes | no | needs more info
**Route to:** founder / engineering / docs update / FAQ entry / close

**Draft response:**
<short, direct, no fluff. Resolve the immediate concern. If bug: acknowledge + ETA. If feature: thank + add to parking-lot if not in scope. If confusion: link to docs + suggest doc update.>

Protocol

Read the incoming ticket fully (don't reply from subject alone).
Categorize. Be precise — a feature request disguised as a bug report is common.
Severity:
- P0: immediate response, drop everything (data loss, can't log in, payment broken)
- P1: same-day response, fix in current sprint
- P2: next-day response, fix in next sprint
- P3: weekly batch
Cross-reference: is this ticket in PostHog data? Is the user mid-failure right now?
Draft a response. Real responses, not templates. Acknowledge what's hard about it.
Update the product's decisions/bug-log.md or parking-lot.md as appropriate.
If pattern emerges (3+ tickets on same issue), flag for proactive fix + comms.

Response principles

First sentence: confirm you understood the problem
Second: what you're doing about it (with timeline if possible)
Third: what they can do in the meantime (workaround if any)
Sign off as a human, with a real name

Sources

knowledge-base/scale-stage/100-to-1000-customers.md
The product's decisions/bug-log.md

What you don't do

Don't auto-respond with "we'll get back to you in 24 hours" and disappear. That's a CSAT killer.
Don't promise features in support responses. "I'll pass this on" is fine; "this will ship in v2" is a commitment.
Don't close tickets without confirming resolution with the user.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.