Workflow Hub

I love playing poker, both online and live. One month, I performed poorly. Although it felt like the cards were running badly, I wondered whether I had developed a problem in my game and was blaming my losses on bad luck. I asked around, including asking AI, whether a tool existed that could measure luck from poker hand histories. The unwelcome answer was that it did not. I'm not a coder, but after doing some research into vibe coding, I started building a luck-detection app in a Claude chat. Claude built the UI directly in the chat window and advised me on the formulas I was using to calculate luck for the cards dealt, my performance on the flop, and my performance when I went all in. All three metrics have strong averages, and luck is what varies them. I used a bell curve to model hand outcomes and a Monte Carlo simulator, which Claude suggested and executed, to evaluate all possible outcomes. The result astonished me because it was so useful. I immediately fixed two major leaks in my game and felt better knowing that bad luck really was the main problem affecting my results. I liked the tool so much that I decided to turn it into a full web app with Claude Code, and now an iPhone app that I may let other people use for free. I also had a lot of fun building it—except for learning how to use Xcode. That was a pain, even with step-by-step guidance from Claude. Step-by-step: 1. I reviewed a month of poor poker results and questioned whether bad luck or problems in my game were causing the losses. 2. I researched whether a tool existed that could measure luck from poker hand histories and learned that I would need to build one myself. 3. I used vibe coding to start building a luck-detection app in a Claude chat. 4. I had Claude create the UI and advise on formulas for evaluating cards dealt, flop performance, and all-in performance. 5. I used a bell curve to model hand outcomes and a Monte Carlo simulator to evaluate possible outcomes. 6. I used the results to identify and fix two major leaks in my game and confirm that bad luck was also affecting my results. 7. I expanded the project into a full web app with Claude Code and then began building an iPhone app, working through the added challenge of learning Xcode.

Most people remember the predictions they got right and rationalize the ones they got wrong. This workflow forces every meaningful forecast into a structured record so you can measure not only whether you were right, but also whether your confidence was justified. The objective is not simply to make more correct predictions. It is to make your stated confidence increasingly match reality. For every forecast, record the following: Step-by-step: 1. State exactly what you believe will happen. The claim must be specific enough to resolve later. Bad: “AI stocks look vulnerable.” Better: “The Nasdaq-100 will fall at least 15% from its current level within six months.” 2. Assign a numeric probability from 0–100%. Avoid vague terms such as “likely” or “probably” without attaching a percentage. 3. Define when the prediction should resolve, such as within 30 days, by year-end, or within 12 months. 4. Identify the one to three factors most responsible for the forecast being correct. This makes the causal thesis explicit. 5. Specify what evidence would materially weaken or invalidate the forecast. This prevents moving the goalposts later. 6. Define in advance what counts as correct, incorrect, or ambiguous. Do not wait until the outcome is known to decide how success will be measured. 7. Freeze the forecast by preserving the original forecast exactly. If new information materially changes your view, create a new forecast rather than editing the old one. This preserves the forecasting record. 8. At the end of the time horizon, record what actually happened. Then distinguish between a thesis error, in which the underlying reasoning was wrong; a timing error, in which the thesis may have been right but the forecast horizon was wrong; and a driver error, in which the expected outcome occurred but for different reasons. 9. Review calibration by comparing probability bands with actual results over time. If forecasts assigned 70% confidence are correct about 70% of the time, your confidence is well calibrated. If high-confidence forecasts fail too often, you are overconfident. If lower-confidence forecasts succeed too often, you may be underconfident. Do not overinterpret tiny sample sizes; calibration becomes more meaningful as forecasts accumulate. 10. Periodically review error patterns, including overconfidence, underconfidence, timing errors, weak assumptions, ignored counterevidence, wrong key drivers, poor resolution criteria, and repeated mistakes by forecasting domain. Use those patterns to improve future forecasts. Copy-and-paste prompt Act as a forecasting and calibration analyst. Whenever I make a meaningful prediction, create a forecast record using: CLAIM: PROBABILITY: TIME HORIZON: KEY DRIVERS: DISCONFIRMING SIGNALS: RESOLUTION CRITERIA: Make the prediction specific enough to evaluate later. Require a numeric probability and a defined time horizon. Preserve the original forecast exactly. If new information materially changes the forecast, create a new version rather than rewriting the original. When the forecast resolves, add: OUTCOME: RESULT: THESIS ACCURACY: TIMING ACCURACY: DRIVER ACCURACY: WHAT WAS RIGHT: WHAT WAS WRONG: CALIBRATION REVIEW: LESSON: Periodically review resolved forecasts for: Accuracy by probability band Overconfidence Underconfidence Timing errors Repeated bad assumptions Strongest forecasting domains Weakest forecasting domains Never rewrite history to make an old forecast look better. The objective is not to maximize correct predictions. The objective is to make confidence increasingly match reality.

I used /goal in OpenAI's Codex to build a Magic: The Gathering app so my brother and I can play asynchronously without needing to coordinate a call or awkwardly play over FaceTime. The idea is to let each of us take turns when we have time, track the board state cleanly, and keep a game going over days instead of trying to line up schedules. The command allowed Codex to continue running until everything was done, basically one-shotting exactly what I was looking for without any intervention. Step-by-step: 1. I defined the core problem: two people needed to play asynchronously without coordinating a call. 2. I described the app’s essential behavior, including turn-taking, persistent board state, and games that continue over multiple days. 3. I used /goal in Codex so the build could continue autonomously toward the finished result. 4. I let Codex implement the app and resolve the work without requiring step-by-step intervention. 5. I tested the finished flow to make sure each player could return later and continue from the correct state.