Update to FantasyPros: Fantasy Advice

{
  "description": "Find realistic, mutually beneficial trades for the user's league with FantasyPros data. Use when the user asks for trade ideas, trade targets, who they should trade for or away, or how to upgrade a position via trade.",
  "included_files": [],
  "name": "trade-finder",
  "skill_md_contents": "---\nname: trade-finder\ndescription: Find realistic, mutually beneficial trades for the user's league with FantasyPros data. Use when the user asks for trade ideas, trade targets, who they should trade for or away, or how to upgrade a position via trade.\n---\n<!-- ChatGPT plugin fork of agentic-coach/strands-backend/src/app/agent/skills/trade-finder/SKILL.md (DATA-696). Differs only in dropping Coach-only visual-card guidance. Keep workflow changes in sync. -->\n# Trade finder\n\nWorkflow for surfacing the top realistic trades where both sides benefit.\n\n**Inputs:** optional constraints from the user (target player/position, player to move, preferred trade partner).\n\n0. **Named target? Find who owns him first.** If the user names a player to acquire, you MUST find which team rosters him BEFORE anything else: call `get_roster` with `all_teams=true` and the selected `league_key` and look for the player on each team's roster. That is exact for the selected league. `get_player_ownership` scans every league the user has synced, not just the selected one, so you MAY use it as a cross-check, but a missing or differently named entry for the selected league never means he is a free agent or unowned — in that case rely on the rosters. The team that owns him is the trade partner — no other team can send him. If he is on the user's own roster, say so instead of proposing a trade; only call him a free agent if no roster in the selected league has him. Never infer a named player's fantasy team from memory or from positional fit.\n1. **Assess both sides.** You MUST establish the user's roster strengths and needs before or alongside generating trades: call `get_roster`, and you SHOULD call `league_analyzer` to gauge relative positional strength across the league (it also reveals other teams' strengths and weaknesses).\n1a. **Pick the partner from `rank_trade_partners`, not from intuition — unless step 0 already identified the owner.** When the user named a target player, the owner is the partner: skip the partner ranking and use position ranks only to shape what to offer (what that team needs). Otherwise, once you know which position the user is moving and which they want, you MUST call `rank_trade_partners` with `position_surplus` and `position_need`. It returns the other teams ordered by fit, best first, with the ranks behind each score. A viable partner is WEAK at the position the user is selling (they need it) and STRONG at the position the user wants (they can spare it) — recommending a team that is strong at what the user is selling, or thin at what the user wants, is backwards and they will decline. Take candidates from the top of that list; if you name one from lower down, say why. Reciting a team's ranks correctly and then recommending the wrong team is the exact error this ranking exists to prevent.\n2. **Generate candidates.** You MUST call `trade_finder`, passing any user-specified constraints (when step 0 found an owner, set `player_trade_for` and `team_trade_with` to that owner and discard any returned trade whose partner is a different team) (`player_trade_for`, `player_trade_away`, `position_trade_for`, `position_trade_away`, `team_trade_with`). These combine, so a \"trade away X to get Y\" request is ONE call with both sides set — never two calls, and never just one side. The response echoes `filters_applied`; if it reports that nothing matched, that is a real empty result, so say so rather than re-running with fewer constraints and presenting the wider answer as if it matched.\n3. **Mutual-benefit filter.** You MUST only present trades where both teams have a positive gain (see `my_finder_ros_power_ranking_gain` and `their_finder_ros_power_ranking_gain` in the `trade_finder` results) according to Trade Finder, due to complementary needs and strengths (e.g. the user's RB surplus addresses the partner's RB hole, and vice versa). You MUST avoid multi-player-for-1 lopsided packages — never present a trade sending three or more players for a single player, even if the trade tool suggests it and even with caveats. When the tool only returns such packages, do not present them as recommended trades. A smaller package is a new proposal: use trade_analyzer to re-evaluate it where supported, and present it only if returned evidence establishes positive gains for both teams. Otherwise report that no suitable verified trade was found. Never carry the original package's gain values over to an edited package. You SHOULD prioritize trades involving equal numbers of players whenever possible.\n4. **Realism check.** You SHOULD discard trades the opposing manager would obviously reject: surplus-for-surplus swaps, selling low on elite players, or offers that leave the partner with no starter at a position.\n5. **Answer.** You MUST present the top 2-3 trades, each with an explicit two-sided rationale: what the user gains and why, and who the other team is (for a named target, the team that owns him) and why they would accept (\"you get X because ...; they accept because ...\").\n\n\n## Account access and subscription limits\n\nApply this section before the workflow's tool requirements. It takes precedence when a requested tool or league is unavailable to the current account.\n\n- OAuth sign-in is available to free and paid FantasyPros accounts. Use tool descriptions and current responses as the authority for access. If the host exposes `ff://user/entitlements`, it can establish the current user's tool access; do not assume that resource is exposed or callable.\n- Only bring up a subscription restriction when it is relevant to the user's request. If a tool returns `status=\"premium_required\"`, relay `required_user_disclosure` once, including the supplied informational link, and follow its access-related guidance. Do not promote upgrades, describe plans or prices, or encourage subscribing. Never replace the informational link with a pricing or checkout link.\n- Do not treat a gated result as empty successful data, repeat the same denied call, or retry with a different identity or league to bypass access controls. Do not claim the gated tool ran or invent its results.\n- Continue helping with tools the account includes when their returned data supports an answer. Clearly distinguish any alternative analysis from the unavailable assistant, finder, or analyzer result. If available tools cannot answer the request, state the limitation.\n- `get_leagues` may return `locked_leagues` without a `league_key`. Do not guess or construct keys for them. If the selected league is locked, disclose the returned restriction once and offer an accessible league or general research using available tools. If the user has multiple accessible leagues and none is selected, ask which league to use. Pass the selected accessible `league_key` explicitly on every league-scoped call; the server is stateless.\n\n## Data sources\n- Rosters, rankings, league standings, and trade evaluations MUST come from the FantasyPros tools above. Do not web-search to check or supplement them, and never let a web result override them. Never infer which fantasy team owns a player from the web or from memory.\n- Say how current the data is when it matters: results carry `data_as_of` (date, season, week), and `injury_status` news items carry `published`.\n- For anything the tools do not cover (for example why a player's role changed), you MAY search the web: prefer fantasypros.com and the most recent sources, skip anything from a previous season, and say where the information came from and when it was published.\n"
}