set-lineup

Set Lineup (Browser Playbook)

Set a lineup on the user's platform through their own logged-in browser session. Two phases, one hard gate: never save a lineup change without explicit user confirmation.

Execution boundary

• Treat this as an execution skill, not a general advice skill. If the user already named the swaps, carry out those swaps.
• If the user asks you to "set my lineup" without naming the swaps, read the live roster and then run lineup-strategy:start-sit if it is installed. Its globally optimized, evidence-qualified recommendation becomes the proposed target lineup; it is not authorization to apply anything.
• If lineup-strategy:start-sit is unavailable, either ask the user to name the intended swaps or reproduce its full decision contract inline before returning to execution: optimize the whole legal lineup rather than filling slots greedily, honor locks and kickoff times, preserve late-swap optionality, timestamp the analysis, and require official status plus a second credible source for any injury-driven change. A page-visible projection or status tag alone is not enough. If the user is still debating broader ranges of outcomes or waiver implications, finish that read-only analysis before proceeding.

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.
• Navigate by goals and landmarks, not memorized selectors. Platforms redesign constantly; find things by their visible text and structure ("the roster table", "the section labeled Bench"), and read the page when unsure.
• Confirmation gate: before any click that commits a change, show the user exactly what is about to change and wait for an explicit yes. Everything before that (navigation, reading, opening dialogs) is fair game.
• The confirmation must post-date the summary. It has to arrive in a user message after the summary read off the actual page, in the same turn as the click. An instruction given before the browser was open — including "and submit it" or "just do it" — authorizes building the change, never committing it. A reply that alters any term ("yes, but bench Moss instead") is a modification, not a confirmation: apply it, re-read the page, present a fresh summary, ask again.
• Never retry a commit click. If an action's result is unclear, re-read the page to find out whether it landed. Retry only on positive evidence the change is absent. If the page is ambiguous or mid-update, wait and re-read — never click again.
• Every execution ends in one terminal state: verified-success (the approved final lineup is visibly on the page), verified-absent (the approved change is visibly not present and the lineup is still at the pre-change baseline), or unknown (the page does not let you prove either state). Never retry from unknown.
• 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.