Life insurance recommender

Life Insurance Recommender (Singapore)

This skill turns "should I buy this insurance policy" into a structured pipeline: understand the person → check their reasoning → decode the actual candidate policies → score them against that specific person's needs → hand them a report they can click through.

Why the pipeline is ordered this way

Insurance mis-selling usually isn't about bad math — it's about a mismatch between why someone wants coverage and what triggers a payout. A death benefit doesn't help someone who is critically ill but alive; a 20-year term doesn't leave a legacy if the insured outlives it. Getting the beneficiary purpose right in Stage 1-2, before looking at any product, is what makes the Stage 4 scoring meaningful rather than generic. Do not skip ahead to product comparison before the needs record is settled.

The five stages

Each stage has its own prompt file with the full instructions — read the relevant one when you reach that stage rather than trying to hold all of it in your head at once.

Stage	Prompt file	What it produces
1. Interview	prompts/01_interview.md	A structured needs record: purpose, amount, duration per need, plus profile and budget
2. Needs analysis	prompts/02_needs_analysis.md	A checked/finalized needs record — either confirming the user's own plan is consistent, or making an explicit recommendation
3. Policy sourcing	prompts/03_policy_sourcing.md	A real, priced candidate set recorded into policy_bank/policies.md - sourced live from compareFIRST.sg (phase 2), or from a user-uploaded document
4. Policy decoding & scoring	prompts/04_policy_assessment.md	4a: filter the bank by category/budget and get user confirmation on which filtered policies to evaluate. 4b: per confirmed policy - suitability score /10, categorized summary, drawbacks/catches
5. Report generation	prompts/05_report_generation.md	A single self-contained HTML file: list view + click-through detail, saved to outputs and presented to the user

Run them in order for a full "help me figure out what to buy" request. If the user already has a finalized needs record from an earlier conversation, or already knows exactly which policies to compare, it's fine to start from whichever stage is actually needed — e.g. "score this PRUVital Cover PDF against my existing coverage plan" can jump straight to Stage 4 if Stage 1-2 output already exists in the conversation.

Supporting frameworks

Two reference documents underpin Stages 1-2 and 4, and one template underpins Stage 5. Read these when the relevant stage calls for them — they're deliberately kept out of this file to keep it short.

• frameworks/coverage_taxonomy.md — the shared vocabulary: beneficiary purposes (SELF_INCOME / DEPENDENT_INCOME / LEGACY_ESTATE / DEBT_LIABILITY), product categories (TERM_LIFE, WHOLE_LIFE, CRITICAL_ILLNESS, etc.), rider mechanics, and the tag set used when decoding a policy. Stage 1, 2, and 4 all lean on this.
• frameworks/scoring_rubric.md — the v0 suitability scorecard (5 sub-scores summing to /10) used in Stage 4. Explicitly a first pass — say so to the user and expect to refine weights once real premium quotes exist.
• frameworks/report_template.html — a working HTML/CSS/JS template (list + modal popup) for Stage 5. Copy and fill in placeholders rather than building a report layout from scratch.

Policy bank

policy_bank/policies.md is the registry of policy variants available to filter and score against — base policy name, provider, category (TERM_LIFE/WHOLE_LIFE), add-on/variant description (SA multiplier, coverage-term option, rider, etc.), coverage/premium term, sum assured, premium, path to the source document, source, and date last updated. Rows sourced live from compareFIRST.sg carry a real quote for the specific profile/coverage searched; older rows predating that workflow may still carry a flat S$1,500/year placeholder — the registry's own notes section flags which is which. The actual product summary documents live in policy_bank/pdfs/. See prompts/03_policy_sourcing.md for how to source new policies (live search or user upload).

Current known limitations (say so if relevant, don't paper over them)

• Some older policy-bank rows still carry flat placeholder premiums from before live sourcing existed, and haven't had their add-on ranges broken out into separate rows yet — sum-assured- adequacy and cost-efficiency scores for those specific rows are rougher than for freshly-sourced ones.
• Stage 3's live sourcing depends on the claude-in-chrome browser tool being connected, since compareFIRST's results render via JavaScript/AJAX that a plain fetch can't see — if that tool isn't available, sourcing falls back to whatever the user uploads manually.
• compareFIRST's dropdown brackets (coverage term, sum assured, etc.) rarely match a user's exact numbers — Stage 3 always picks the closest bracket and says so, rather than pretending it's exact.
• The scoring rubric is v0 — a reasonable first cut, not a validated instrument.