Chess with Me

CWM turns engine lines into plain-language tactical explanations you can verify on the board—showing how a move enabled the opponent’s reply, and abstaining when the evidence isn’t strong enough.

Comment

Inspiration

I started Chess with Me because I could not find the chess product I wanted to use. Engines would show me +2, -1.05, a best move, and a principal variation, but I often still could not answer the questions that mattered to me: Why did my move create a problem? What can my opponent do now? What did the better move actually change?

A number alone did not teach me how to think, and a canned sentence such as “you should have played...” did not feel meaningful when I could not connect it to the board. I wanted an explanation in ordinary language that showed the tactical cause and effect, while remaining honest about what the available evidence could and could not prove. That became the idea behind Chess with Me.

What it does

Chess with Me is a local, playable AI chess companion with three product surfaces:

  • play a complete game against a configurable local Stockfish opponent;
  • import PGN or FEN into Review and ask about a selected move or position;
  • use local hot-seat VS mode with server-authoritative visual assistance.

For supported tactical positions, it explains a replayable causal chain rather than only reporting that another move was better. The submission demonstrates two high-confidence families: an immediate mating reply and an immediate capture of the same identified root piece. When the evidence cannot support a causal story, it gives a bounded comparison or explicitly abstains.

How I built it

I did not begin with the final product architecture. I first built Review Lab, a research environment where I could compare board visualizations, Stockfish principal variations, and human annotations. I used my own historical games as private research material to discover where real-game analysis became hard to understand. Those personal games and annotations were later removed from the submission repository; the submitted fixtures are synthetic and identity-free.

My first experiments tried to turn analysis into structured JSON. That exposed the real engineering question: how could I organize chess evidence in a way that was reproducible enough to support natural-language explanations? A plausible paragraph was easy to generate. A paragraph whose moves, squares, pieces, outcomes, and causal strength could all be checked was much harder.

With Codex and GPT-5.6 Sol, I turned those experiments into a written methodology and a layered architecture:

  1. Search: Stockfish examines the Played and Best branches.
  2. Proof: deterministic chess code legally replays every move and derives board events and concrete outcomes.
  3. Policy: a family-specific contract decides whether a narrow causal claim is proven or whether the system must abstain.
  4. Narration: GPT-5.6 may express the closed proof naturally, but it cannot add a move, motif, outcome, or stronger claim.
  5. Validation: schema and semantic checks reject unsupported output and return a deterministic explanation instead.

For the submitted version, I deliberately limited causal explanations to two high-confidence families: an exact immediate mating reply and an exact immediate capture of the same identified root piece. I then built the playable local companion, PGN/FEN Review mode, hot-seat VS mode, board assistance, provider fallback, UI projection, and a frozen evaluation gate around those truth boundaries.

I also preserved a decision log alongside the methodology. When I change the system later, I want to know not only what an earlier implementation did, but why I accepted that design and what it explicitly did not claim.

How I used Codex and GPT-5.6

Codex helped me transform an earlier research prototype into the submitted product during Build Week. I used it for architecture analysis, contract and task decomposition, implementation, adversarial testing, root-cause analysis, privacy review, and submission preparation. Dated commits distinguish the Build Week extension from the frozen earlier baseline.

I organized the AI collaboration as a small engineering team with explicit responsibilities:

  • Sol — architecture and semantic owner: architecture, chess-claim boundaries, root-cause analysis, design decisions, and final review.
  • Terra — staff-engineer / implementation strategist: repository and dependency analysis, implementation planning, and task decomposition.
  • Luna and Grok — implementation engineers: implementation, testing, refactoring, and other execution-heavy work.
  • Claude Code — UI engineer: product-interface implementation and visual integration.

The names describe the roles in my workflow, not independent product authorities. I retained the product decisions, reviewed the evidence, and resolved semantic conflicts before accepting work. Worktrees, bounded handoff packets, exact commits, integration tests, and owner review let several agents contribute without silently changing the chess claims.

The product's managed direct-OpenAI path pins gpt-5.6-terra through the Responses API. GPT-5.6 performs bounded intent classification, safe social language, and natural surface realization of verified explanations. Chess truth remains with Stockfish, legal replay, and deterministic proof code.

Challenges

The first challenge was turning what I learned in Review Lab into a systematic, reproducible method. Without AI-assisted architecture work, I think the project could easily have remained a whiteboard full of interesting observations: engine lines, visual comparisons, annotations, and possible explanations, but no dependable path from one to the next. Writing the methodology forced every layer to have a clear responsibility and every claim to have an evidence boundary.

The hardest semantic challenge was preventing a plausible explanation from being mistaken for a proven one. A principal variation can contain a tactical pattern by coincidence, and the absence of a tactic from the Best PV does not prove that the better move removed it. I addressed this by replaying the exact opponent reply after both root moves, preserving stable root-piece identity, binding claims to closed evidence IDs, and abstaining whenever the comparison was insufficient.

Reproducibility was another challenge. Engine searches can vary in ways that look small but change the evidence contract. I bound evidence to a pinned Stockfish identity and resolved search profile, measured warm and cold runs, and tested White and Black synthetic capture cases independently.

Finally, turning a research tool into a coherent product required more than adding a polished interface. Play, Review, VS mode, the HTTP server, provider fallback, and the browser all had to consume the same authoritative chess contracts without re-inventing semantics in the UI.

Accomplishments

  • A coherent local product, not only a notebook or prompt demo.
  • Two narrow but honest causal explanation families in English and Traditional Chinese.
  • Deterministic fallback: the educational core still works when GPT-5.6 is offline or its output is rejected.
  • Server-authoritative chess and renderer-only browser boundaries.
  • Privacy-safe synthetic fixtures and explicit anti-blame controls.
  • A large automated contract suite covering legality, evidence binding, provider failure, concurrency, privacy, and UI projection.

What I learned

I learned that an engine evaluation is not an explanation, and a natural sentence is not automatically understanding. Natural language became most useful only after the system had decided exactly what it was allowed to say.

I also learned that absence from a principal variation is not proof, that reproducibility must include semantic outputs rather than only numeric scores, and that refusing to make a causal claim can be a better educational result than producing a confident but unsupported story.

On the engineering side, I learned how explicit ownership and staged integration make multi-agent development manageable. Separating architecture, planning, implementation, UI work, and final review—while preserving decision records and exact handoffs—helped turn my original ideas into a system I can test, explain, and continue developing.

What's next

After submission evaluation, future work will be selected from observed failure clusters: broader tactical families, better step-by-step board playback, automatic whole-game review, strategic explanations, and longer-term learning continuity. These are not claimed as part of this submission.

Built With

Share this project:

Updates

Submission history