Purpose
Determine whether a specific claim qualifies under the governing policy by testing the stated facts and submitted evidence against every policy element — then deliver a defensible validity determination with a confidence rating, evidence gaps, fraud flags, and the exact follow-up needed to resolve open questions. Replaces gut-feel triage with a consistent, auditable decision process.
When to Use
Invoke this skill when the user asks to:
- Decide whether a claim, dispute, or refund request meets policy criteria
- Review submitted evidence against a coverage rule or eligibility requirement
- Identify what documentation is missing before a claim can be adjudicated
- Triage a queue of claims into approve / deny / escalate buckets
- Check a suspicious claim for inconsistencies or fraud signals
- Produce written justification for a claim approval or denial
Inputs Required
Before starting, collect:
- Policy/rule text: The specific policy clauses, coverage terms, or eligibility criteria that govern this claim (paste the relevant sections)
- Claim summary: What the claimant is asking for and the amount or remedy sought
- Stated facts: The claimant's account of what happened, including dates, parties, and sequence of events
- Submitted evidence: List of documents, screenshots, receipts, communications, or records provided (with what each purports to show)
- Claim type: Category — e.g., damage, non-delivery, unauthorized transaction, service failure, injury, chargeback
- Prior history: Any known prior claims, disputes, or account flags for this claimant (if available)
- Decision authority: Whether the reviewer can approve/deny directly or only recommend for escalation
If prior history or decision authority is missing, proceed with the review and note the assumption; treat the claim as first-instance unless told otherwise.
Instructions
Step 1: Extract Policy Elements
Break the governing policy into discrete, testable elements — the individual conditions that must ALL be satisfied for the claim to qualify. For each element, capture:
- The requirement in plain language
- The evidence type that would satisfy it (receipt, timestamp, photo, third-party record, etc.)
- Whether it is a hard requirement (failure = automatic denial) or a soft/weighable factor
List every element numbered. A claim is only valid if every hard requirement passes.
Step 2: Map Facts and Evidence to Each Element
For each policy element from Step 1, assign a status:
- Satisfied — evidence directly supports the requirement; cite the specific evidence
- Partially satisfied — some support exists but is incomplete or indirect
- Unsupported — no evidence provided for this element
- Contradicted — evidence or stated facts conflict with the requirement
Cite the exact evidence item or stated fact backing each status. Do not infer satisfaction from absence of contradiction — a missing document is Unsupported, not Satisfied.
Step 3: Consistency and Fraud Signal Check
Run the claim against these red-flag categories:
- Timeline inconsistency: Dates in the narrative conflict with dates on evidence (e.g., receipt dated after reported incident)
- Evidence anomalies: Altered documents, mismatched names/amounts, reused images, or metadata gaps
- Narrative drift: The stated facts contradict themselves or shift from prior submissions
- Pattern risk: Claim matches a known abuse pattern for this claim type or repeats prior claimant behavior
- Value mismatch: Amount claimed is inconsistent with the evidence of loss
Flag each signal as None / Low / Elevated with a one-line reason. Elevated signals route to escalation regardless of policy fit.
Step 4: Determine Validity
Combine the element mapping and fraud check into a determination:
- Valid — all hard requirements Satisfied, no Elevated fraud signals
- Invalid — one or more hard requirements Contradicted or Unsupported with no path to cure
- Incomplete — otherwise valid but blocked by missing evidence that could be supplied
- Escalate — Elevated fraud signal, ambiguous policy language, or claim exceeds the reviewer's decision authority
Assign a confidence rating (High / Medium / Low) reflecting evidence strength and ambiguity, with a one-sentence justification.
Step 5: Build the Required Follow-Up List
For any Incomplete or borderline determination, specify exactly what is needed:
- Each missing item, the element it resolves, and who must provide it
- What would flip the determination if supplied (or if it fails to arrive by a deadline)
- A recommended default outcome if follow-up is not provided within the standard window
Step 6: Write the Determination Rationale
Produce a concise, quotable justification suitable for the claim record or a claimant-facing decision letter — referencing the specific policy elements and evidence that drove the outcome. Keep it factual and neutral; no editorializing about the claimant.
Output Format
- Structure: Determination header first (outcome + confidence), then supporting analysis
- Length: 500–800 words
- Format: Structured document — policy element table, then labeled sections
- Sections: Determination Summary → Policy Element Mapping (table: element / requirement / hard-or-soft / status / evidence cited) → Fraud & Consistency Signals → Required Follow-Up → Determination Rationale
- Tone: Neutral, precise, audit-ready — the voice of a claims specialist writing for the record, not persuasive or sympathetic
Quality Checklist
Before delivering output, verify:
- [ ] Every policy element is listed and individually assigned a status — none skipped
- [ ] Each Satisfied/Partially satisfied status cites a specific evidence item or stated fact
- [ ] Every hard requirement is marked as hard, and any failed hard requirement is reflected in the determination
- [ ] All five fraud signal categories are checked and rated (None/Low/Elevated)
- [ ] The determination is one of the four defined outcomes with a stated confidence rating
- [ ] Any Incomplete outcome includes a follow-up list naming the exact missing items and who must supply them
Notes
- A missing document is never treated as satisfying a requirement — absence of evidence is Unsupported, and the burden sits with the claimant unless the policy states otherwise.
- Keep policy interpretation conservative: if a clause is genuinely ambiguous, escalate rather than resolve it against the claimant, and note the ambiguity for policy owners to clarify.
- The determination rationale should hold up if the claimant appeals — write every status as if it will be read back to you in a dispute review.
- When triaging a queue, run the same six steps per claim and output determinations in a shared table so the approve/deny/escalate split is scannable at a glance.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills