Guidewire Core Workflow BSAFE

Model-agnostic agent-skills platform with a harness-free canonical layer, verified adapters, and the ccpi package manager. Explore at tonsofskills.com.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: guidewire-core-workflow-b
description: Automate the ClaimCenter FNOL→investigation→reserve→payment→settlement→close pipeline including the failure paths — duplicate FNOL from multi-source intake, reserve-must-precede-payment ordering, supervisor-authorization tiers, premature settlement, and reopen-vs-new-claim ambiguity. Use when building claim intake from caller portals, IVR, or partner systems; automating reserve-setting jobs; or integrating settlement events with finance. Trigger with "claimcenter automation", "FNOL", "claim reserve", "claim payment", "claim settlement", "claim reopen".
allowed-tools: Read, Write, Edit, Bash(curl:*), Bash(jq:*), Grep
version: 1.26.0
license: MIT
author: Jeremy Longshore <[email protected]>
compatibility: Designed for Claude Code
tags:
  - guidewire
  - claimcenter
  - fnol
  - reserves
  - payments
  - settlement
---

# Guidewire ClaimCenter Workflow

## Overview

Drive the ClaimCenter claims lifecycle through Cloud API and survive the failure modes that derail naive automation. This is the workflow used by FNOL portals, IVR claims intake, partner-of-record APIs, and reserve-setting jobs. Assumes `guidewire-install-auth` provides the bearer token and `guidewire-sdk-patterns` provides the retrying client with checksum round-trip.

Five production failures this skill prevents:

1. **Duplicate FNOL from multi-source intake** — the same loss event is reported by the caller, the claimant, and the broker; without dedup logic three claims land on the same loss with three reserves.
2. **Payment before reserve** — code creates a payment without first setting a reserve in the matching cost category; API returns `422 reserve-required`.
3. **Authorization-tier violation** — an integration with payment role `cc.payment.write` attempts a payment above its authorization limit; API returns `422 authorization-required` and the payment lands in pending-approval.
4. **Premature settlement** — claim closed before all open reserves are zeroed or all open activities resolved; reopens compound work and generate audit findings.
5. **Reopen vs. new claim confusion** — late-arriving evidence on a closed claim creates a new claim with a different number, breaking the loss-event continuity downstream finance and analytics depend on.

## Prerequisites

- A working auth + SDK layer per `guidewire-install-auth` and `guidewire-sdk-patterns`
- Cloud API roles `cc.claim.write`, `cc.reserve.write`, `cc.payment.write` assigned per least privilege; payment authorization tier matches the integration's expected payment range
- Knowledge of the carrier's loss-cause code list (`AUTO`, `PROPERTY`, `WORKERSCOMP`, etc.) and cost-category configuration (`body`, `parts`, `medical`, `legal`)
- A loss-dedup key strategy (typically: `policyNumber + lossDate + lossCause + reporterId`)

## Instructions

### 1. FNOL with deduplication

Before creating a claim, check whether one already exists for the same loss event. The dedup key combines policy, loss date, loss cause, and the reporting party.

```typescript
async function findExistingClaim(policyNumber: string, lossDate: string, lossCauseCode: string): Promise<Claim | null> {
  const url = `${BASE}/cc/rest/v1/claims?filter=policyNumber+eq+'${policyNumber}'+and+lossDate+eq+'${lossDate}'+and+lossCause.code+eq+'${lossCauseCode}'`;
  const res = await fetch(url, { headers: { Authorization: `Bearer ${await getToken()}` } });
  const body = await res.json();
  return body.data[0] ?? null;
}

const existing = await findExistingClaim(policyNumber, lossDate, lossCauseCode);
if (existing) {
  await addReporterToExistingClaim(existing.attributes.id, reporter); // additional reporter, same loss
  return { status: "deduplicated", claimNumber: existing.attributes.claimNumber };
}
const claim = await createClaim({ policyNumber, lossDate, lossCauseCode, reporter, description });
```

The dedup window is loss-cause-specific. For `AUTO`, same-day same-cause is almost certainly the same event. For `PROPERTY`, weather events can produce multiple legitimate same-cause same-day claims across distinct locations — extend the dedup key with the loss-location ZIP for that line.

### 2. Reserve setting before any payment

Reserves communicate the carrier's expected outflow per cost category. The Cloud API enforces "reserve before payment" — payments without a matching reserve return `422 reserve-required`.

```typescript
await retryable(async () => {
  const res = await fetch(`${BASE}/cc/rest/v1/claims/${claimId}/reserves`, {
    method: "POST",
    headers: { Authorization: `Bearer ${await getToken()}`, "Content-Type": "application/json", "Idempotency-Key": idempotencyKey },
    body: JSON.stringify({
      data: { attributes: {
        reserveAmount: { amount: 5000, currency: "usd" },
        costType: { code: "claimcost" },
        costCategory: { code: "body" },
        reserveLine: { exposure: { id: exposureId } },
      } },
    }),
  });
  if (!res.ok) throw await mapError(res, "POST", `/cc/rest/v1/claims/${claimId}/reserves`);
});
```

Reserve adjustments (raise/lower) use PATCH on the reserve resource; checksum round-trip applies. Lowering a reserve below cumulative payments returns `422` — fix payments first or use a reserve transfer.

### 3. Payments with authorization-tier handling

The integration's authorization tier is configured per Service Application in GCC. A payment that exceeds the tier does not error — it lands in `Status: PendingApproval` and waits for a supervisor:

```typescript
const payment = await fetch(`${BASE}/cc/rest/v1/claims/${claimId}/payments`, {
  method: "POST",
  headers: { Authorization: `Bearer ${await getToken()}`, "Content-Type": "application/json", "Idempotency-Key": idempotencyKey },
  body: JSON.stringify({ data: { attributes: paymentBody } }),
}).then(r => r.json());

if (payment.data.attributes.status.code === "PendingApproval") {
  await emitPaymentEscalationEvent({ claimId, paymentId: payment.data.attributes.i

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.