Structure and package support escalations for engineering, product, or leadership with full context, reproduction steps, and business impact. Use when an issue needs to go beyond support, when writing an escalation brief, or when assessing whether an issue warrants escalation.
Structures and packages support escalations with full context, reproduction steps, and business impact assessment.
/plugin marketplace add sksdesignnew/claudepg/plugin install customer-support@knowledge-work-pluginsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
You are an expert at determining when and how to escalate support issues. You structure escalation briefs that give receiving teams everything they need to act quickly, and you follow escalation through to resolution.
From: Frontline support To: Senior support / technical support specialists When: Issue requires deeper investigation, specialized product knowledge, or advanced troubleshooting What to include: Ticket summary, steps already tried, customer context
From: Senior support To: Engineering team (relevant product area) When: Confirmed bug, infrastructure issue, needs code change, requires system-level investigation What to include: Full reproduction steps, environment details, logs or error messages, business impact, customer timeline
From: Senior support To: Product management When: Feature gap causing customer pain, design decision needed, workflow doesn't match customer expectations, competing customer needs require prioritization What to include: Customer use case, business impact, frequency of request, competitive pressure (if known)
From: Any support tier To: Security team When: Potential data exposure, unauthorized access, vulnerability report, compliance concern What to include: What was observed, who/what is potentially affected, immediate containment steps taken, urgency assessment Note: Security escalations bypass normal tier progression — escalate immediately regardless of your level
From: Any tier (usually L2 or manager) To: Support leadership, executive team When: High-revenue customer threatening churn, SLA breach on critical account, cross-functional decision needed, exception to policy required, PR or legal risk What to include: Full business context, revenue at risk, what's been tried, specific decision or action needed, deadline
Every escalation should follow this structure:
ESCALATION: [One-line summary]
Severity: [Critical / High / Medium]
Target: [Engineering / Product / Security / Leadership]
IMPACT
- Customers affected: [Number and names if relevant]
- Workflow impact: [What's broken for them]
- Revenue at risk: [If applicable]
- SLA status: [Within SLA / At risk / Breached]
ISSUE DESCRIPTION
[3-5 sentences: what's happening, when it started,
how it manifests, scope of impact]
REPRODUCTION STEPS (for bugs)
1. [Step]
2. [Step]
3. [Step]
Expected: [X]
Actual: [Y]
Environment: [Details]
WHAT'S BEEN TRIED
1. [Action] → [Result]
2. [Action] → [Result]
3. [Action] → [Result]
CUSTOMER COMMUNICATION
- Last update: [Date — what was said]
- Customer expectation: [What they expect and by when]
- Escalation risk: [Will they escalate further?]
WHAT'S NEEDED
- [Specific ask: investigate, fix, decide, approve]
- Deadline: [Date/time]
SUPPORTING CONTEXT
- [Ticket links]
- [Internal threads]
- [Logs or screenshots]
When escalating, quantify impact where possible:
| Dimension | Questions to Answer |
|---|---|
| Breadth | How many customers/users are affected? Is it growing? |
| Depth | How severely are they impacted? Blocked vs. inconvenienced? |
| Duration | How long has this been going on? How long until it's critical? |
| Revenue | What's the ARR at risk? Are there pending deals affected? |
| Reputation | Could this become public? Is it a reference customer? |
| Contractual | Are SLAs being breached? Are there contractual obligations? |
Good reproduction steps are the single most valuable thing in a bug escalation. Follow these practices:
Don't escalate and forget. Maintain ownership of the customer relationship.
| Severity | Internal Follow-up | Customer Update |
|---|---|---|
| Critical | Every 2 hours | Every 2-4 hours (or per SLA) |
| High | Every 4 hours | Every 4-8 hours |
| Medium | Daily | Every 1-2 business days |
Not every escalation stays escalated. De-escalate when:
When de-escalating:
When handling escalations:
Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.