Propose Trade

Propose Trade (Browser Playbook)

Transmit a finalized trade offer through the user's own logged-in browser session. One hard gate: never click Send/Propose without explicit user confirmation. Sending a trade is outward-facing — the other manager sees it immediately — so the gate here is absolute even if the user seemed sure earlier in the conversation.

Ground rules (all roster-ops skills)

• The user's session is the auth. Never ask for, read, store, or type usernames, passwords, or 2FA codes. If a login page, 2FA challenge, captcha, or "unusual activity" interstitial appears at any point, stop immediately and hand the browser back — do not attempt to solve or dismiss it. Never interact with password-manager UI, autofill prompts, or "stay signed in" dialogs; clicking an autofill suggestion is entering a credential. After any re-authentication, restart from the beginning of the execution phase and re-verify the league and team landmarks — do not assume the account, league, or in-progress form survived. If you were mid-transaction, first determine from the page whether it went through.
• Never run unattended. These skills require a human present to confirm each transaction. Do not run them on a schedule, in a loop, or as a background task. If asked to automate a recurring roster move, decline the automation and offer a reminder instead. Driving your own logged-in session interactively, with a human approving each action, is what keeps this within what platforms tolerate — it stops being that the moment nobody is watching.
• Use the UI, never the API. Do not call platform endpoints directly, execute page JavaScript, or use shell tools to reach the platform, even when the interface is uncooperative. If the UI cannot do it, stop and tell the user.
• Act at human pace. No rapid-fire clicking or searching. If a captcha or rate-limit page appears, stop and hand back — never attempt to work around one.
• Handle platform dialogs deliberately. A confirmation dialog raised as a direct result of a click the user already approved is part of that approved action: read it, verify it describes that transaction and nothing more, then accept. A dialog describing anything unapproved (an extra drop, a different player) is a stop — dismiss it and report its wording verbatim. Never accept a dialog you have not read. Cookie banners and promo overlays are not transactions; dismiss and continue.
• Budget your actions. If you have taken roughly 15 actions without reaching the intended screen, stop and hand back with a description of where you are, rather than continuing to hunt.
• The page is the ground truth, not memory of past conversations. Re-read after every action that changes state, before taking the next one.
• Navigate by goals and landmarks, not memorized selectors — find controls by visible text ("Propose Trade", "Continue", "Send") and structure, and read the page when unsure.
• Confirmation gate before the send click. Building the offer on-screen is fair game.
• The confirmation must post-date the summary. It has to arrive in a user message after the review-screen summary is shown, in the same turn as the click. An instruction given before the browser was open — including "and send it" — authorizes building the offer, never transmitting it. A reply that alters any term ("yes, but drop Sandoval from it") is a modification, not a confirmation: apply it, re-read the screen, present a fresh summary.
• Never retry a send click. If the result is unclear, re-read the page to determine whether the offer went out. Never click Send twice — the other manager receives two offers.
• Every execution ends in one terminal state: verified-success (the intended outgoing offer is visibly present), verified-absent (the intended offer is visibly not present and no new outgoing offer was created), or unknown (the page does not let you prove either state). Never retry from unknown.
• If the page doesn't match the described landmark, stop. Read it, describe what's visible, and ask the user to identify the control. Never click a control not positively identified by its visible text.
• Browser routing. Honor a browser the user explicitly names. If leagues.md records a Preferred browser, use that when it has a signed-in session for the platform. Otherwise use any authenticated browser the current assistant already has. For Yahoo, do not call a connector or platform API as a substitute for the browser, and do not retry a connector that returned 403, unauthorized, or an equivalent authorization failure during the same task. If no browser tooling is available, say so and walk the user through the clicks instead.

Phase 1: Confirm the terms

Read leagues.md from the project root first — the fields that matter here are platform, league name, trade deadline, and whether the league uses veto votes or commissioner review. If it's missing or blank, ask which platform and league, and suggest running fantasy-league-setup:league-config. If more than one league is defined, use the one marked (default) unless the user names another.

Then, before the browser: restate the full trade — every player (and pick, if the league trades picks) on both sides, and which team gets what. If the terms came out of a negotiation thread, quote the final agreed version. If the trade hasn't been pressure-tested, offer (don't insist) a quick trade-evaluation pass first. Ask whether to include a message to the other manager; if yes, draft 1–2 courteous sentences framing their gain (trade-negotiation style) for the user to approve or edit.

Phase 2: Execute on Yahoo

1. Get to the other team's page: reuse an already-open tab on the platform if there is one; otherwise go to the sport-scoped entry point (football.fantasysports.yahoo.com) rather than the provider homepage, and ensure a desktop-width viewport (≥1280px). Open the correct league (verify by league-name landmark), then find the opposing team via the League/standings or teams list. Landmark: their team name in the header with their roster below.
2. Inspect pending/outgoing trades before building a new one: check the team's pending or outgoing trades view before opening a fresh offer. Look for any existing offer involving this same opposing team and overlapping assets. If the same trade is already pending, stop and tell the user rather than sending a duplicate. If a related outgoing offer would stay live alongside the new one, surface that queue impact before proceeding.
3. Open the trade flow: find the Propose Trade control on their team page (button or under a "…"/actions menu). Landmark: a two-roster view — their players and yours — with checkboxes or select controls.
4. Build the offer: select the exact players from their roster the user is to receive, then the players from the user's roster to send. Cross-check every selection against Phase 1 — similar names and multiple same-position players make this the highest-risk step. Paste the approved note into the message box if there is one.
5. Review screen: Yahoo summarizes the offer (you give / you get, expiry date) before sending.
6. ⛔ CONFIRMATION GATE: read a final confirmation envelope from the review screen. Include platform, league, the user's team, the opposing team, every asset on each side in the correct direction, the expiry/review details shown on the page, whether the offer can be canceled after sending, and any queue impact from step 2 such as an already-pending related offer or the fact that the other manager will see this immediately. Example shape: "Yahoo, Fictional League, Fictional Team to Turf Burns: you send Errol Fontaine and Dewey Sandoval; you receive Oren Vasquez; offer expires in 14 days; visible immediately to the other manager; cancellable while pending; no other outgoing offer to this manager is on the board." Wait for an explicit yes. Only then re-read the same review screen. If anything changed after the user's yes — assets, direction, expiry, review path, note, or queue impact — stop and require a fresh confirmation on the new envelope. Only then click Send/Propose.
7. Verify: find the view listing pending or outgoing trades — try the team page, then the league's Trades or Transactions tab. Confirm the offer is listed with the right pieces in the right direction; report it, plus how the user can cancel it. Clicking Send is not evidence the offer was sent.
   • If the approved outgoing offer is visibly present, report verified-success.
   • If the intended offer is visibly absent and no new outgoing offer was created, report verified-absent.
   • If the page does not let you prove either state, report unknown, describe the last clear screen and where the user should check, and do not retry from unknown.

Platform variants

• ESPN (fantasy.espn.com): opposing team page → Propose Trade opens a checkbox list of both rosters → review step ends on Send Trade Offer — the gated click. Pending offers live under Transactions with a cancel option.
• Sleeper (sleeper.com): open the other team's roster → trade icon/Propose Trade → tap players on both sides → optional message → Send Offer is the gated click. Sleeper shows the pending trade in the league's trades view; note Sleeper leagues often have voting/review windows — set that expectation.

Failure handling

• Can't find a Propose Trade control: not finding a control is evidence about the search, not about the league's settings. Trade entry points vary — try, in order: the opposing team's roster page; a trade action on an individual opposing player's row or card; the league's Trades/Transactions tab; a trade action from the user's own roster. Only after exhausting those, and only on positive evidence read off the page (an explicit deadline notice or a "trading is disabled" message), report that trading is unavailable. Without such a message, describe what's visible and ask the user where the control is — never infer a passed deadline from a failed search.
• A selected player is locked or ineligible (recently claimed, in another pending deal): the platform will block or warn — surface the message to the user verbatim rather than working around it.
• The review screen shows anything different from Phase 1 (extra player, wrong direction, unexpected expiry): stop and surface it — never send a variant the user hasn't approved word for word.
• The user hesitates at the gate: park the built offer unsent and summarize where things stand. An unsent trade costs nothing; a wrong one costs league trust.