Update to MayRetire

{
  "description": "Review and explain a supplied Canadian retirement plan through MayRetire's remote MCP service; use the focused creation or scenario-testing skill for those requests.",
  "included_files": [
    {
      "relative_path": "references/accounts-benefits-and-income.md",
      "size_in_bytes": 2423
    },
    {
      "relative_path": "references/investments-housing-and-tax.md",
      "size_in_bytes": 2123
    },
    {
      "relative_path": "references/opening-in-ui.md",
      "size_in_bytes": 701
    },
    {
      "relative_path": "references/planning-goals-and-success.md",
      "size_in_bytes": 3237
    },
    {
      "relative_path": "references/withdrawals-and-explanations.md",
      "size_in_bytes": 2438
    }
  ],
  "name": "mayretire",
  "skill_md_contents": "---\nname: mayretire\ndescription: Review and explain a supplied Canadian retirement plan through MayRetire's remote MCP service; use the focused creation or scenario-testing skill for those requests.\n---\n\n# MayRetire planning\n\nUse the MayRetire MCP tools for calculations. Before asking for a plan, explain\nthat using remote tools sends its financial details to MayRetire's server for\nprocessing. Do not ask for payment-card details, health information, government\nidentifiers, or credentials. The remote service does not have\naccess to the user's browser storage, MayRetire account, or local files. Ask the\nuser to attach a saved/exported MayRetire JSON plan, or interview them to create\none with `create_plan_payload`. Never claim to have retrieved a plan automatically.\nThe complete plan is supplied in `basePlan` on each plan-related call.\n\n## Start with the goal and scope\n\nFor a supplied plan, call `inspect_plan_payload` and `validate_plan_payload`\nbefore relying on its calculations. For plan creation, ask for household status,\nages, province, work and pension income, CPP/OAS estimates, account balances,\ndebts, housing, baseline after-tax spending, and any estate goal. Ask for missing\nmaterial facts; label illustrative defaults. For investment mix, offer simple\nEquity, Growth, Balanced, and Conservative presets and confirm the user's choice.\n\nClarify whether spending should be fixed, flexible with a stated minimum, or\nselected to pursue an after-tax estate target with a minimum acceptable spending\nlevel. Ask which areas may change before optimization: spending, benefit timing,\nwithdrawal strategies and schedule, investments, housing, corporate or rental\nassets, debt, and one-time purchases. Limit comparisons to the areas relevant to\nthe user's question. Preserve any existing withdrawal overrides unless the user\nagrees to change them; prefer strategy settings before adding new overrides.\n\n## Interpret the active configuration\n\nUse `inspect_plan_payload` and the returned assumptions to identify which\nsettings drive the current calculation before discussing stored plan values.\nDo not flag an inactive value merely because it appears in the JSON. Mention it\nwhen the user asks about changing modes, when it conflicts with a stated goal,\nor when it materially affects the requested analysis.\n\nConsult the bundled\n[MayRetire tutorial](../mayretire-app-assistant/references/MayRetire_Tutorial.md)\nwhen a feature's purpose, screen location, or interaction with other settings\nneeds explanation. For a particular JSON plan, `inspect_plan_payload`\nestablishes which settings are active, `describe` defines unfamiliar fields,\nand calculations establish actual outcomes. Do not infer that a stored field\napplies solely because the tutorial describes it, or override tool evidence\nwith a general tutorial example. Link the public tutorial for interface help.\n\nWith constant-dollar spending, report the fixed after-tax spending target; a\nstored minimum is not an active floor. Discuss a possible floor only when\nconsidering flexible or estate-target spending, and confirm the amount with the\nuser. For the main accounts, `returnMethod = 1` uses asset allocations: stored\nmanual or legacy real-return values do not drive their current projections.\nThe legacy real-return field is recognized as a fallback when a manual-return\nplan lacks a nominal-return value, not evidence that the user intended to use\nthat rate. Additional portfolios have independent return modes. Do not claim a\nprojection is too optimistic solely because of a dormant return value; confirm\nthe intended return method and compare modeled alternatives first.\n\n## Use the least costly evidence that answers the question\n\n- Call `calculate_plan_payload` for a deterministic baseline and\n  `compare_plan_payloads` to screen up to eight independent variations.\n- Call `explain_plan_payload` for a specific age, year, or account question.\n- Use `describe` to learn an unfamiliar field before editing. Apply a patch or\n  item operations with `edit_plan_payload`; show material changes and return the\n  resulting plan JSON to the user when they want to keep the scenario.\n- Call `start_stress_test_job`, `start_monte_carlo_job`, or\n  `start_backtest_job` for the corresponding risk test. Call\n  `start_exploration_job` or `start_optimization_job` for a bounded set of\n  scenarios when requested. The server may queue\n  a job and report its position; poll `status_plan_job` until it runs and\n  finishes, then call `result_plan_job`. Retrieve only selected candidate plans using\n  `get_candidate_plan`. Use `cancel_plan_job` if the user redirects the search.\n  Screen broad ideas deterministically before costly simulations. MayRetire's\n  usual Monte Carlo count is 500 trials; keep trial count, seed, engine build,\n  and success criteria aligned when comparing scenarios.\n\n## Explain what the numbers mean\n\nShow a small table with only metrics relevant to the user's question. State\nwhether spending and any active after-tax estate goal were met. A stored estate\namount can be inactive under another spending strategy. Do not compare success\nrates for different goals as though they measure the same requirement. Stress\nscenario pass count and average spending funded are different metrics; neither\nis a probability of success. Monte Carlo success is a model estimate, not a\nguarantee. Describe amounts as Canadian dollars in plan-start purchasing power\nwhen the returned result uses that basis. Speak in user-friendly planning terms\nrather than JSON field names unless the user asks for implementation details.\nFor a couple's survivor years, compare annual income to that year's returned\n`minTargetIncomeAmount` and `targetIncomeAmount`, not the original two-person\nhousehold amounts. See the planning-goals reference for the scaling rule.\n\nThe remote pilot processes supplied plans on MayRetire's server and temporarily\nholds planning jobs in memory. It does not save plans to a MayRetire account.\n`plan_handoff_url` creates a browser link only when the user wants to review a\nplan in MayRetire; it does not open a browser or store the plan. Do not present\nmodeled outcomes as personalized financial, tax, or legal advice.\n\n## Read focused guidance when relevant\n\n- [Planning goals and success](references/planning-goals-and-success.md):\n  spending modes, active estate criteria, scope, and interpretation.\n- [Accounts, benefits, and income](references/accounts-benefits-and-income.md):\n  CPP/OAS, work, registered accounts, corporate assets, and spending phases.\n- [Investments, housing, and tax](references/investments-housing-and-tax.md):\n  return methods, additional portfolios, dormant housing, debt, and tax evidence.\n- [Withdrawals and explanations](references/withdrawals-and-explanations.md):\n  strategy schedules, overrides, and decision traces.\n- [Opening in MayRetire](references/opening-in-ui.md): use only when the user\n  asks to view the plan in the browser.\n\nFor a guided plan interview, use the `mayretire-create-plan` skill. For a\nwhat-if search, stress test, Monte Carlo run, or backtest, use the\n`mayretire-test-scenarios` skill. Both use the same remote MCP service.\n"
}