Update to Poker: play, practice, improve

{
  "description": "Review and debrief a Poker app match when the user asks for a match recap, performance review, biggest mistakes, strengths, leaks, pivotal hands, or improvement priorities. Use only the current widget's model-visible match ledger, separate decision quality from results, and do not reveal non-showdown opponent cards unless the user requests spoilers.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 221
    }
  ],
  "name": "match-debrief",
  "skill_md_contents": "---\nname: match-debrief\ndescription: Review and debrief a Poker app match when the user asks for a match recap, performance review, biggest mistakes, strengths, leaks, pivotal hands, or improvement priorities. Use only the current widget's model-visible match ledger, separate decision quality from results, and do not reveal non-showdown opponent cards unless the user requests spoilers.\n---\n\n# Match Debrief\n\nUse the current Poker widget's `modelContent` as the source of truth. Do not use `privateContent` or infer the undealt deck, burned cards, seeds, or random state.\n\n## Inputs\n\n- The current match ledger, including difficulty, result, hands, cards, boards, stacks, actions, outcomes, and blind levels\n- Any focus the user requests, such as aggression, bet sizing, preflop play, or a concise review\n\nIf no usable match ledger is available, say that a debrief requires the current rendered match and ask the user to open or return to it. Do not invoke `start-match` unless the user separately asks for a new match.\n\n## Workflow\n\n1. Confirm whether the match is complete or still in progress. Label an in-progress review as provisional.\n2. Reconstruct the match arc from recorded stack changes, blind progression, and outcomes. Do not invent actions between ledger entries.\n3. Identify the few hands that most affected the result or best demonstrate a repeated decision pattern. Do not equate the largest pot with the worst decision automatically.\n4. Evaluate choices using only information legitimately available to the user at each decision: the user's cards, public board, position, prior actions, pot, stacks, and legal bounds.\n5. Separate decision quality from the eventual cards and result. Call out uncertainty when opponent ranges or equity are estimates.\n6. Find repeated strengths and improvement opportunities. Support each material observation with hand numbers and concrete actions.\n7. Prioritize no more than three adjustments the user can apply in the next match.\n\n## Hidden information\n\nTreat opponent cards from non-showdown hands as spoilers even though they are model-visible. Do not reveal or use them to justify decision-time advice unless the user explicitly requests a perfect-information or spoiler review. Opponent cards shown at showdown may be discussed normally.\n\nWhen spoilers are requested, keep the fair-play analysis primary and put hindsight from hidden cards in a clearly labeled separate section.\n\n## Output\n\nProvide:\n\n1. A short match summary with result, difficulty, approximate turning points, and final stacks when present\n2. Two or three strengths supported by hand references\n3. Two or three improvement opportunities supported by hand references\n4. Brief reviews of the pivotal hands\n5. Three specific priorities for the next match\n\nScale detail to the match length and the user's request. Use chip amounts exactly as recorded and call raises \"raise to\" amounts when applicable.\n\n## Boundaries\n\n- Keep the discussion educational and specific to play-money poker.\n- Do not claim access to matches from another widget, conversation, or session.\n- Do not claim exact equity unless it is actually calculated from available information; otherwise use qualitative or explicitly approximate language.\n- Do not control the widget, place blinds, take actions, or start another match on the user's behalf.\n"
}