# Task Group 008 Fewshot Attempt 02

> Solve private wealth advisory benchmark tasks that ask for structured JSON planning outputs using the advisory API, local request memo, and answer template. Use for Roth conversion/RMD summaries, ILIT Crummey funding cycles, GRAT versus CRAT comparisons, and combined estate liquidity action plans where source records may conflict.

- Skill: `prism-shadow/task-group-008-fewshot-attempt-02` (Agent Skill)
- Install (CLI): `npx skillmds@latest add prism-shadow/task-group-008-fewshot-attempt-02`
- Raw SKILL.md: https://api.skillmd.com/api/skills/prism-shadow/task-group-008-fewshot-attempt-02/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: prism-shadow (https://skillmd.com/u/prism-shadow)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/prism-shadow/task-group-008-fewshot-attempt-02

---


# Private Wealth Advisory JSON SOP

## Workflow

1. Read only the task prompt, request memo, and `answer_template.json` supplied for the current task. Extract `client_id`, planning horizon, engagement type, required top-level keys, enum values, and date/rounding requirements.
2. Query the API, starting with `/api/health`, `/api/clients/<client_id>`, `/api/source-documents?client_id=<client_id>`, and `/api/policies/tax`. Add `/api/rmd-factors` for Roth/RMD work, `/api/retirement-accounts?client_id=<client_id>` for retirement work, `/api/life-insurance?client_id=<client_id>` for ILIT work, and `/api/trust-candidates?client_id=<client_id>` for GRAT/CRAT work.
3. Build a normalized facts sheet before calculating: controlling profile facts, account facts, insurance facts, trust candidate facts, policy constants, and the output field map.
4. Calculate with full precision, then round final USD outputs to cents. Return JSON only, with JSON numbers and booleans, not strings.
5. Set `task_id` from the task split and number, such as `train_###` or `test_###`, and set `client_id` to the stable client identifier.

Prefer the JSON API endpoints over the portal page. Use `/api/clients?search=` only when the prompt does not provide a usable client ID.

## Source Resolution

Resolve conflicts by fact type, not by whichever endpoint was read first.

- Profile facts: prefer `SIGNED_PROFILE`, then `ATTORNEY_MEMO`, then `CUSTODIAN_EXPORT`, then `CRM_NOTE`, then `STALE_MARKETING_INTAKE`.
- Retirement balances and return assumptions: use `/api/retirement-accounts` and report `CUSTODIAN_EXPORT` for controlling account source when the template asks.
- Insurance facts: use `/api/life-insurance` for policy economics and dates. For template source fields, report the highest-precedence planning document that controls the policy/beneficiary facts, usually `SIGNED_PROFILE` unless attorney records are the only current authority.
- Trust candidate economics: use `/api/trust-candidates`. When the template asks for the asset source, these planning assets are usually attorney-driven; use `ATTORNEY_MEMO` unless a higher-precedence source explicitly controls the asset facts.
- Goals such as family transfer priority and philanthropic intent: prefer current signed profile facts over older CRM notes, even if the older source has a stronger stated preference.

Echo the chosen source type in the matching `source_resolution` field. Do not use stale CRM or marketing intake values when a signed profile or attorney memo supplies the same fact.

## Output Families

Choose the output family from `analysis_type` and the required keys in `answer_template.json`.

- `roth_conversion_rmd`: `recommendation`, `conversion_plan`, `rmd_projection`, `legacy_projection`, `source_resolution`.
- `ilit_crummey_implementation`: `recommendation`, `gift_plan`, `administration`, `estate_result`, `source_resolution`.
- `trust_comparison`: `recommendation`, `estate_context`, `grat`, `crat`, `source_resolution`.
- `estate_liquidity_action_plan`: `recommendation`, `estate_context`, `ilit`, `trust_transfer`, `action_set`, `source_resolution`.

For estate-context outputs, include the requested fields and, when useful for parity with this task family, `planning_year`, `exemption_used`, and `liquid_assets_available`.

## Roth Conversion And RMD Rules

Use the signed profile for `annual_non_ira_income`, `marginal_tax_rate`, `filing_status`, `age`, and `planning_year`. Use the custodian retirement account for balances, expected return, RMD start age, and recommended conversion years.

Core formulas:

- `first_rmd_year = planning_year + (rmd_start_age - age)`.
- `annual_conversion_amount = max(conversion_bracket_targets[filing_status] - annual_non_ira_income, 0)`.
- `conversion_years = recommended_conversion_years`.
- `conversion_years_positive = conversion_years` when the annual conversion amount is positive, otherwise `0`.
- `total_converted` is the sum of actual scheduled conversions. Cap a year's conversion at the remaining traditional balance if necessary.
- `total_conversion_tax = total_converted * marginal_tax_rate`.

Projection convention:

1. Baseline scenario starts with the traditional IRA balance and no conversions.
2. For each year from planning year through horizon, compute age for that year.
3. If age is at least RMD start age, calculate `rmd = opening_traditional_balance / rmd_factor[age]`, add `rmd * marginal_tax_rate` to the scenario RMD tax, and subtract the RMD from traditional balance.
4. Apply annual growth to the remaining traditional balance after any RMD.

Conversion scenario:

1. Start with traditional and Roth custodian balances.
2. At the start of each scheduled conversion year, move the annual conversion amount from traditional to Roth.
3. If an RMD is due in that same year, compute it from the post-conversion traditional balance, subtract it, and tax it.
4. Apply the account expected return to both ending traditional and Roth balances.

Then set:

- `baseline_rmd_tax_through_horizon` from the baseline scenario.
- `conversion_rmd_tax_through_horizon` from the conversion scenario, excluding conversion taxes.
- `rmd_tax_savings_through_horizon = baseline_rmd_tax_through_horizon - conversion_rmd_tax_through_horizon`.
- `projected_roth_balance_horizon` and `projected_traditional_balance_horizon` from the conversion scenario ending balances.
- `heir_tax_profile` to `MOSTLY_TAX_FREE` when traditional assets are essentially depleted, `MOSTLY_TAXABLE` when Roth assets are negligible, otherwise `MIXED_TAXABLE_AND_TAX_FREE`.

Recommendation defaults: positive bracket room with sufficient liquidity supports `STAGED_ROTH_CONVERSION`, `SUITABLE`, and `TAX_BRACKET_MANAGEMENT`. Use `LIQUIDITY_CONSTRAINT` when conversion tax cannot plausibly be paid from liquid assets; use `RMD_NEAR_TERM` only when the template facts make near-term RMD timing the main risk rather than bracket management.

## ILIT Crummey Rules

Use the policy annual gift exclusion for the planning year and the controlling beneficiary count.

- `annual_exclusion_capacity = annual_exclusion_per_beneficiary * beneficiary_count`.
- `premium_gap = max(annual_premium - annual_exclusion_capacity, 0)`.
- `notices_required = beneficiary_count`.
- `contribution_date = planned_contribution_date`.
- `notice_due_date = contribution_date + 7 calendar days`.
- `withdrawal_window_end = notice_due_date + 30 calendar days`.
- `earliest_premium_payment_date = withdrawal_window_end + 1 calendar day`.
- `dedicated_bank_account_required = true` for ILIT funding administration.
- `tax_liquidity_support = death_benefit * estate_tax_rate`.

Risk flags:

- No gap and no existing-policy transfer: `LOW_IF_FORMALITIES_MET`.
- Premium exceeds exclusion capacity: `EXCLUSION_SHORTFALL`.
- Existing policy transfer: `THREE_YEAR_LOOKBACK`.
- Both: `THREE_YEAR_LOOKBACK_AND_EXCLUSION_SHORTFALL`.

Recommendation mapping:

- Low risk: `FUND_WITH_CRUMMEY_NOTICES`, `SUITABLE_WITH_ADMINISTRATION`.
- Exclusion shortfall only: `USE_LIFETIME_EXEMPTION_FOR_SHORTFALL`; suitability is usually `BORDERLINE` unless liquidity and exemption facts are clearly comfortable.
- Three-year lookback only: `USE_NEW_POLICY_OR_ACCEPT_LOOKBACK`.
- Both lookback and shortfall: `DISCLOSE_LOOKBACK_AND_USE_EXEMPTION`.

For `projected_outside_estate_if_implemented`, use the death benefit for a properly implemented new ILIT policy. If the case is an existing-policy transfer and the chosen action accepts lookback risk, treat outside-estate status as conditional until the lookback clears.

## GRAT, CRAT, And Estate Context Rules

Use policy constants for estate exemption, estate tax rate, CRAT maximum term, and charitable deduction rate.

Estate context:

- Double the estate tax exemption for married/MFJ households; otherwise use one exemption.
- `taxable_estate = max(estate_value - exemption_used, 0)`.
- `estate_tax_exposure = taxable_estate * estate_tax_rate`.
- `liquidity_gap_before_planning = max(estate_tax_exposure - liquid_assets, 0)`.

GRAT:

- `term_years = grat_term_years`.
- `projected_remainder_to_heirs = asset_value * (1 + expected_growth_rate) ^ grat_term_years - asset_value * grat_annuity_rate * grat_term_years`.
- `estimated_estate_tax_reduction = projected_remainder_to_heirs * estate_tax_rate`.
- `mortality_inclusion_risk = TERM_SURVIVAL_REQUIRED`.

CRAT:

- `term_years = min(crat_term_years, max_crat_term_years)`.
- `projected_charitable_remainder = asset_value * (1 + expected_growth_rate) ^ term_years - asset_value * crat_payout_rate * term_years`.
- `estimated_income_tax_deduction = projected_charitable_remainder * charitable_deduction_rate`.
- `family_transfer_fit` is `LOW` when family transfer is the dominant goal, `HIGH` when philanthropy dominates, otherwise `MODERATE`.

Recommendation:

- Prefer `GRAT` with `CHILDREN_TRANSFER_PRIORITY` and `SECONDARY_CHARITABLE_TOOL` when family transfer priority dominates.
- Prefer `CRAT` with `PHILANTHROPIC_PRIORITY` and `SECONDARY_FAMILY_TRANSFER_TOOL` when philanthropy dominates.

## Combined Estate Liquidity Plans

Calculate estate context, ILIT, and trust transfer using the rules above. For family-transfer cases with viable ILIT administration and a strong GRAT result, use `COMBINE_ILIT_AND_GRAT` and sequence `ILIT_FIRST_THEN_GRAT`. For philanthropic cases, consider `CRAT_WITH_LIQUIDITY_REVIEW` and sequence `TRUST_DECISION_FIRST`. For ILIT cases with exemption or lookback issues, use `ILIT_WITH_EXEMPTION_REVIEW` and sequence `ILIT_FIRST_THEN_ATTORNEY_REVIEW`.

Build `action_set` from applicable enum actions and sort alphabetically:

- Include `ATTORNEY_DRAFT_REVIEW` for attorney coordination or trust implementation.
- Include `ILIT_CRUMMEY_NOTICE_CYCLE` when funding an ILIT with notices.
- Include `GRAT_FOR_APPRECIATING_SHARES` or `CRAT_FOR_CHARITABLE_REMAINDER` based on preferred trust strategy.
- Include `LIFETIME_EXEMPTION_ALLOCATION` when premium gap or lookback/shortfall facts require exemption use.

## Common Pitfalls

- Do not inspect hidden environment, evaluation, rubric, or test-answer files. Use only the task inputs and allowed API.
- Do not return explanatory prose or Markdown around the JSON.
- Do not turn numbers, booleans, or dates into the wrong JSON types.
- Do not include conversion taxes in RMD tax savings; `total_conversion_tax` is separate.
- Do not apply real-world RMD/conversion ordering if it conflicts with this task family; scheduled conversions are applied before same-year RMD calculations in the conversion scenario.
- Do not forget existing Roth balances when projecting Roth legacy values.
- Do not use single exemption for married/MFJ estate cases.
- Do not pay ILIT premiums before the withdrawal window closes.
- Do not leave `action_set` unsorted.
- Do not hardcode policy constants; fetch `/api/policies/tax` and `/api/rmd-factors` each run.