API Onboarding Diagnostician
Turns raw API logs from a stuck onboarding into a root-cause finding, a fix owner, and a customer-facing status update, in one pass.
Inputs
- API request/response log excerpt (JSON lines, HAR, or plain text)
- Integration context: which endpoints, auth method (OAuth2, API key, mTLS), expected flow
Synthetic log fixtures per failure class in references/log_fixtures/.
Workflow
- Run
scripts/parse_logs.py to bucket entries by endpoint, status code, and error body signature.
- Match the dominant signature against
references/failure_signatures.md: auth (expired token, wrong grant type, clock skew on JWT), payload (schema drift, enum mismatch, encoding), rate limiting (429 with retry-after ignored), idempotency (duplicate key collisions), environment (sandbox credentials against production host).
- Separate customer-side faults from platform-side faults. The fix path differs completely.
- Draft two artifacts: an internal engineering ticket (signature, frequency, first occurrence, reproduction) and a customer-facing status note (plain language, next step, owner, ETA discipline: no ETA unless the fix owner committed one).
Output format
## Root Cause, ## Evidence (bucketed counts), ## Fix Path (owner and change), ## Customer Update (under 100 words, no internal jargon).
Guardrails
- Never send the customer an update that attributes fault before the evidence supports it.
- Redact tokens, keys, and PII from all quoted log lines.
1---2name: api-onboarding-diagnostician3description: Analyze API request/response logs from a failing enterprise customer onboarding and produce a root-cause diagnosis with a fix path. Use this skill whenever the user mentions API onboarding failures, integration errors during go-live, 4xx/5xx patterns in customer logs, webhook delivery failures, or pastes API logs and asks why an integration is failing, even if they only say "customer is blocked."4---56# API Onboarding Diagnostician78Turns raw API logs from a stuck onboarding into a root-cause finding, a fix owner, and a customer-facing status update, in one pass.910## Inputs1112- API request/response log excerpt (JSON lines, HAR, or plain text)13- Integration context: which endpoints, auth method (OAuth2, API key, mTLS), expected flow1415Synthetic log fixtures per failure class in `references/log_fixtures/`.1617## Workflow18191. Run `scripts/parse_logs.py` to bucket entries by endpoint, status code, and error body signature.202. Match the dominant signature against `references/failure_signatures.md`: auth (expired token, wrong grant type, clock skew on JWT), payload (schema drift, enum mismatch, encoding), rate limiting (429 with retry-after ignored), idempotency (duplicate key collisions), environment (sandbox credentials against production host).213. Separate customer-side faults from platform-side faults. The fix path differs completely.224. Draft two artifacts: an internal engineering ticket (signature, frequency, first occurrence, reproduction) and a customer-facing status note (plain language, next step, owner, ETA discipline: no ETA unless the fix owner committed one).2324## Output format2526`## Root Cause`, `## Evidence` (bucketed counts), `## Fix Path` (owner and change), `## Customer Update` (under 100 words, no internal jargon).2728## Guardrails2930- Never send the customer an update that attributes fault before the evidence supports it.31- Redact tokens, keys, and PII from all quoted log lines.
Prashanthvara