Agent skill · data analytics · jeremylongshore

guidewire-observability-and-incident-response

Operate a Guidewire Cloud API integration in production — define SLIs/SLOs for token availability, bind success rate, FNOL p99 latency; route alerts so the on-call gets paged for real outages and never for transient noise; triage 401 spikes, 409 storms, 429 saturation, scope drift, and Gosu OOM cascades from signal to recovery in 15 minutes or less. Use when designing a dashboard for a new integration, writing the on-call runbook, or running a post-incident review. Trigger with "guidewire observability", "guidewire slo", "guidewire on-call", "guidewire 401 spike", "guidewire 409 storm", "guidewire incident".

Why this skill is useful

Provides specific operational metrics and incident response procedures tailored for Guidewire Cloud integrations that the AI wouldn't reliably generate on its own.

What it needs

Requires datadog, grafana, newrelic, pagerduty, splunk account access. About 8k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.

What this skill does

Guidewire Observability and Incident Response Overview Run a production Guidewire Cloud API integration with the dashboards, alerts, and runbooks an on-call engineer can act on at 3am. This skill consolidates the operational layer: what to measure, what to alert on, how to triage the top five incident classes, and how to close the loop with a post-incident review that prevents recurrence rather than performing root-cause theater. Five operational failures this skill prevents: 1. Vanity dashboards — graphs of total request count, no per-endpoint p99, no SLI burn rate; on-call sees green during a real outage because the right thing was never measured. 2. Alert fatigue — every transient 5xx pages someone; in three weeks the team mutes the channel; a real incident two weeks later goes unnoticed for an hour. 3. No triage tree — on-call wakes up to "401 spike", does not know whether to rotate a secret, restart the integration, or call GCC; loses 20 minutes Googling. 4. Skipped post-incident review — the same root cause produces three incidents in a quarter because no one wrote down the action items from the first one. 5. Common-errors table living in nine Slack threads — operators cannot find the recovery for an error they have seen before, ask the same question in #ops, the answer takes 45 minutes. Prerequisites A working integration emitting structured logs and metrics to a backend (Datadog, Grafana+Prometheus, New Relic, Splunk, or equivalent) Access to a paging system (PagerDuty, Opsgenie, VictorOps) with on-call rotations defined The integrationaudit table from guidewire-security-and-rbac populated — incident triage depends on knowing what the integration tried to do correlationid propagated end-to-end through every Cloud API call Instructions Build the operational layer in this order. Each step targets one of the five operational failures listed in Overview. 1. Define SLIs that measure user-visible behavior Track what users care about, not what is easy to measure. …

How to use it

Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:

@skills jeremylongshore/guidewire-observability-and-incident-response

View the source on GitHub

Browse the @skills marketplace