Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →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.
Passed 15 of 23 test cases with the skill, and 8 of 23 without it.
and 8 more in the full report
7 fixed8 passed either way8 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
What latency target and metric summary statistic should be assigned to the Guidewire quote-to-bind workflow performance indicator?
| Checked | Without skill | With skill |
|---|---|---|
| Specifies quote-to-bind median latency target as less than or equal to 30 seconds | Missed | Passed |
The instructions your model reads when the skill loads.
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:
5xx pages someone; in three weeks the team mutes the channel; a real incident two weeks later goes unnoticed for an hour.integration_audit table from guidewire-security-and-rbac populated — incident triage depends on knowing what the integration tried to docorrelation_id propagated end-to-end through every Cloud API callBuild the operational layer in this order. Each step targets one of the five operational failures listed in Overview.
Track what users care about, not what is easy to measure. For a Guidewire integration, the SLIs that matter:
| SLI | Measurement | Target |
|---|---|---|
| Token-endpoint availability | success rate of /oauth/token over a rolling 5min window | ≥99.9% |
| Cloud API write success | 2xx rate on POST/PATCH calls, excluding 4xx caller errors | ≥99.5% |
| Bind success rate | bound / quoted ratio over rolling 1h, excluding referrals | ≥98% |
| FNOL intake p99 latency | end-to-end time from inbound event to claim.created log | ≤2s |
| Quote-to-bind median latency | median time from quote-call to bind-success | ≤30s |
5xx from upstream Cloud API counts against availability; 4xx from caller bugs (validation failures, scope mismatches) does not — those are caller errors, not integration outages. Distinguishing the two is the single biggest cause of either alert fatigue or missed incidents, depending on which way the bias goes.
test cases passed, vs 8 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.