Poker: play, practice, improve

View saved version →

---
name: hand-review
description: Analyze one Poker app hand when the user asks to review, break down, explain, or evaluate a particular hand or decision street by street. Ground the review in the current widget's model-visible hand ledger, judge decisions from information available at the time, and do not reveal non-showdown opponent cards unless the user requests spoilers.
---

# Hand Review

Use the current Poker widget's `modelContent` as the source of truth. Do not inspect or speculate about `privateContent`, future cards, burns, seeds, or random state.

## Inputs

- A requested hand number or an unambiguous description such as "the last hand" or "the big all-in"
- The matching hand record: button, blinds, starting stacks, hole cards, board, street actions, pot and stack changes, legal actions when recorded, and outcome
- Any requested focus or desired level of detail

If the request matches multiple hands, ask the user which hand they mean. If no usable hand ledger is available, say that the review requires the current rendered match. Do not invoke `start-match` merely to obtain review data.

## Workflow

1. Locate the hand and state whether it is complete, abandoned, or still in progress.
2. Establish the starting context: effective stacks, blind size, button, and the user's hole cards.
3. Reconstruct the action in sequence by street using recorded chip additions, `amountTo`, pot-after values, and stack-after values. Do not invent omitted actions.
4. At each meaningful user decision, use only decision-time information: the user's cards, exposed board, position, prior actions, pot, stacks, and then-available legal bounds.
5. Explain the plausible alternatives, relevant pot odds or sizing logic, and the main tradeoff. Treat opponent holdings as a range unless they were shown at showdown.
6. Identify the decision that mattered most and distinguish its quality from the hand's eventual result.
7. End with one reusable lesson.

## Hidden information

Do not reveal or rely on non-showdown opponent cards by default, even though the model-visible ledger contains them. If the user explicitly asks for spoilers, hole-card analysis, or perfect-information hindsight, first complete the fair-play review and then add a clearly labeled spoiler section.

Opponent cards and evaluated best-five hands from an actual showdown may be discussed without an extra spoiler prompt.

## Output

Provide:

1. A compact hand snapshot
2. A street-by-street reconstruction and analysis
3. A verdict on the pivotal decision, with confidence or uncertainty
4. One practical takeaway

Use exact chip values from the ledger. Distinguish chips added from a wager's total `amountTo`; describe the latter as "bet to" or "raise to."

## Boundaries

- Keep the review educational and specific to play-money poker.
- Do not claim exact solver strategy or exact equity without actually computing it from available inputs.
- Do not claim access to hands outside the current widget instance.
- Do not take a widget action or alter the recorded match.

Referenced files: 1

View saved version →

---
name: match-debrief
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.
---

# Match Debrief

Use 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.

## Inputs

- The current match ledger, including difficulty, result, hands, cards, boards, stacks, actions, outcomes, and blind levels
- Any focus the user requests, such as aggression, bet sizing, preflop play, or a concise review

If 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.

## Workflow

1. Confirm whether the match is complete or still in progress. Label an in-progress review as provisional.
2. Reconstruct the match arc from recorded stack changes, blind progression, and outcomes. Do not invent actions between ledger entries.
3. 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.
4. 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.
5. Separate decision quality from the eventual cards and result. Call out uncertainty when opponent ranges or equity are estimates.
6. Find repeated strengths and improvement opportunities. Support each material observation with hand numbers and concrete actions.
7. Prioritize no more than three adjustments the user can apply in the next match.

## Hidden information

Treat 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.

When spoilers are requested, keep the fair-play analysis primary and put hindsight from hidden cards in a clearly labeled separate section.

## Output

Provide:

1. A short match summary with result, difficulty, approximate turning points, and final stacks when present
2. Two or three strengths supported by hand references
3. Two or three improvement opportunities supported by hand references
4. Brief reviews of the pivotal hands
5. Three specific priorities for the next match

Scale detail to the match length and the user's request. Use chip amounts exactly as recorded and call raises "raise to" amounts when applicable.

## Boundaries

- Keep the discussion educational and specific to play-money poker.
- Do not claim access to matches from another widget, conversation, or session.
- Do not claim exact equity unless it is actually calculated from available information; otherwise use qualitative or explicitly approximate language.
- Do not control the widget, place blinds, take actions, or start another match on the user's behalf.

Referenced files: 1

View saved version →

---
name: poker-concept-from-match
description: Teach one poker concept through a concrete example from the user's current Poker app match when they ask to learn or understand ideas such as pot odds, position, ranges, effective stacks, stack-to-pot ratio, value betting, bluffing, or bet sizing. Use the model-visible ledger, stay focused on one concept, and avoid hidden-card spoilers unless requested.
---

# Poker Concept From Match

Teach one requested concept using a real decision from the current Poker widget's `modelContent`. Do not use `privateContent` or infer the undealt deck, burned cards, seeds, or random state.

## Inputs

- The concept the user wants to learn
- The current match ledger, including hands, cards, boards, positions, blinds, stacks, pots, actions, and outcomes
- An optional hand or decision the user wants used

If the concept is unclear, infer it from the user's wording when safe or ask one short question. If no suitable ledger is available, explain the concept briefly and state that a match-specific example requires the current rendered match. Do not start a new match unless the user asks to play.

## Workflow

1. Define the concept in plain language in one or two sentences.
2. Select the clearest relevant decision from the requested hand or current match. Prefer a completed decision with enough recorded context to demonstrate the concept.
3. Reconstruct only the facts needed for the lesson: street, position, user cards, public board, pot, effective stacks, prior action, and legal amounts.
4. Show the calculation when the concept is quantitative. For pot odds, distinguish call cost from total pot; for wagers, distinguish chips added from `amountTo`; for stack-to-pot ratio, state the stack and pot used.
5. Compare the actual choice with one useful alternative and explain the tradeoff using information available at that moment.
6. End with a compact rule of thumb and one question the user can ask themselves in a future hand.

## Hidden information

Treat non-showdown opponent cards as spoilers. Do not reveal or use them in the main lesson unless the user explicitly asks for a spoiler or perfect-information explanation. Showdown cards may be discussed normally.

If spoilers are requested, preserve the decision-time lesson and add hindsight separately; do not rewrite a sound decision as a mistake merely because hidden cards made it lose.

## Output

Use this compact structure:

1. Concept
2. Example from the match, citing the hand number
3. Calculation or reasoning
4. Actual choice versus one alternative
5. Rule of thumb

Keep the lesson focused on one concept unless the user explicitly requests a broader tutorial.

## Boundaries

- Keep examples educational and confined to play-money poker.
- Label equity, ranges, and behavioral reads as estimates unless directly established by the ledger or an explicit calculation.
- Do not claim solver output, live external data, or access to other match instances.
- Do not control the widget or alter gameplay.

Referenced files: 1