# Fewshot Attempt 02

> Skill: Roth Conversion RMD Analysis for Wealth Advisory

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

---

# Skill: Roth Conversion RMD Analysis for Wealth Advisory

## Overview
Generate a structured JSON comparison of Roth conversion versus RMD baseline for a private-wealth advisory client. The procedure queries an advisory API, resolves conflicting multi-source records, projects taxes and balances through a planning-horizon year, and produces a recommendation.

## API Usage
1. Obtain the advisory API base URL from the environment (commonly exposed as `API_BASE` after the shared environment starts).
2. Query all relevant endpoints for the given `client_id`:
   - Client profile and demographics
   - Account holdings and custodian exports
   - Tax-policy constants (brackets, rates, thresholds)
   - RMD factors / uniform lifetime table
   - Any source documents, life-insurance records, or trust candidates
3. Conflicts are expected because records were imported from different systems. Keep every source value and its provenance tag for resolution.

## Source Resolution Rules
Apply these hierarchies **before** using any data in calculations.

- **Profile / demographic data** (highest priority first):
  1. `SIGNED_PROFILE`
  2. `ATTORNEY_MEMO`
  3. `CUSTODIAN_EXPORT`
  4. `CRM_NOTE`
  5. `STALE_MARKETING_INTAKE`
- **Account / balance data** (highest priority first):
  1. `CUSTODIAN_EXPORT`
  2. `SIGNED_PROFILE`
  3. `CRM_NOTE`

Report the winning source tags in:
- `source_resolution.controlling_profile_source`
- `source_resolution.controlling_account_source`

## Analysis Steps

### 1. Anchor dates and horizon
- `client_id` and the **planning horizon year** come from the advisor request memo.
- Determine the client’s birth year / age from the resolved profile.
- Compute the **first RMD year** using the resolved tax-policy constants (e.g., SECURE 2.0 rules: age 73 for birth years 1951–1959, age 75 for 1960+).

### 2. Baseline scenario (no conversion)
- Project the resolved traditional retirement-account balance forward year by year through the horizon.
- Starting in the first RMD year, apply the applicable RMD factor each year to determine the required distribution.
- Tax each distribution using the resolved ordinary-income brackets.
- Accumulate the taxes → `baseline_rmd_tax_through_horizon`.

### 3. Conversion scenario
- If the memo explicitly states **"no conversion is requested"** (or the client is clearly unsuitable), set all conversion amounts to `0` and skip to step 5, but still keep any baseline plan years in `conversion_plan` with zeroed amounts.
- Otherwise, build a **staged conversion plan**:
  - `first_conversion_year` is normally the current / next year.
  - `conversion_years` is the count of years over which conversions are spread.
  - `conversion_years_positive` equals `conversion_years` when conversion is positive; in no-conversion cases it may match the planned window but amounts must be `0`.
  - `annual_conversion_amount` = `total_converted / conversion_years`, rounded to cents.
  - `total_conversion_tax` = sum of tax on each year’s converted amount, rounded to cents.
- After removing converted amounts, reproject the remaining traditional balance and its yearly RMDs.
- Accumulate post-conversion RMD taxes → `conversion_rmd_tax_through_horizon`.

### 4. Savings and legacy projection
- `rmd_tax_savings_through_horizon` = `baseline_rmd_tax_through_horizon - conversion_rmd_tax_through_horizon`.
  - Allow a one-cent tolerance because intermediate year-by-year rounding can propagate.
- Project the Roth balance at horizon by growing the converted amounts.
- Project the remaining traditional balance at horizon.
- Set `heir_tax_profile`:
  - `MOSTLY_TAXABLE` when the Roth balance is negligible (e.g., no conversion occurred).
  - `MIXED_TAXABLE_AND_TAX_FREE` when both Roth and traditional balances are materially positive.
  - `MOSTLY_TAX_FREE` when the traditional balance is negligible.

### 5. Recommendation
- `primary_action`:
  - `NO_CONVERSION` when the memo explicitly says no conversion is requested, or when analysis shows conversion is unsuitable.
  - `STAGED_ROTH_CONVERSION` otherwise.
- `suitability`:
  - `SUITABLE` for staged conversions.
  - `DEFER` for no-conversion recommendations.
- `risk_flag` (choose the best fit):
  - `TAX_BRACKET_MANAGEMENT` — default for most staged conversions where the main concern is staying within favorable brackets.
  - `LIQUIDITY_CONSTRAINT` — when the conversion period is long or the client has liquidity concerns.
  - `RMD_NEAR_TERM` — when the reason to defer is unfavorable RMD timing (e.g., conversion would start after RMDs have already begun and the analysis recommends no conversion).

## Output Format
- Return **only** a single JSON object. No markdown fences, no explanatory prose outside the JSON.
- Required top-level keys (order does not matter):
  - `task_id`, `client_id`, `analysis_type`, `recommendation`, `conversion_plan`, `rmd_projection`, `legacy_projection`, `source_resolution`
- `task_id`: use the task identifier supplied by the harness (e.g., `train_001`, `test_001`).
- `client_id`: from the memo.
- `analysis_type`: always `"roth_conversion_rmd"`.
- All monetary values must be JSON **numbers** (not strings), rounded to exactly two decimal places (cents).
- All years must be JSON integer numbers.
- Enum strings must match the template exactly (all caps with underscores).

## Calculation Checks
- `annual_conversion_amount × conversion_years` should equal `total_converted` (within rounding).
- `baseline_rmd_tax_through_horizon - conversion_rmd_tax_through_horizon` should equal `rmd_tax_savings_through_horizon` (within rounding).
- In a no-conversion case:
  - `total_converted = 0`
  - `total_conversion_tax = 0`
  - `rmd_tax_savings_through_horizon = 0`
  - `baseline_rmd_tax_through_horizon` should equal `conversion_rmd_tax_through_horizon`
  - `annual_conversion_amount = 0`
- Ensure `conversion_years_positive` is consistent with the sign of `annual_conversion_amount`.

## Pitfalls
- **Conflicting sources:** Never blindly use the first record returned. Always apply the source-resolution hierarchy.
- **Numeric types:** Outputting `"1234.56"` (a string) instead of `1234.56` (a number) will fail validation.
- **Horizon year:** It comes from the memo, not from a hard-coded default.
- **RMD age rules:** Use the API’s tax-policy constants if available; do not hard-code outdated RMD ages.
- **No-conversion edge case:** Even when the recommendation is `NO_CONVERSION`, the `conversion_plan` object may still contain a `first_conversion_year` and `conversion_years` describing the theoretical window, but all monetary fields must be zero.
- **One-cent rounding drift:** When summing year-by-year taxes, carry cents each year or round only the final total; if you round every year independently, a 1-cent discrepancy in `rmd_tax_savings_through_horizon` is possible and acceptable.