Imported from zhaneul/yev-math (AGENTS.md). Install upstream with npx skills add zhaneul/yev-math. Copyright stays with the author.

Project Agents Agreement

This document outlines the workflow and agreements for the project, specifically regarding the iterative derivation, critique, and response process for solving mathematical and game-theoretic problems.

Workflow Structure

The project follows a staged approach to problem-solving, where each step is documented in a dedicated Markdown file. The files are named sequentially to track the evolution of the solution.

File Naming Convention

Files are prefixed with a step number, followed by the type of document:

• {N}_derivation.md: The initial or revised derivation of the solution. This should be a self-contained document explaining the problem, the mathematical model, and the solution.
• {N}_critique.md: A critique of the corresponding derivation. This document should identify potential flaws, missing assumptions, edge cases, or errors in logic.
• {N}_response.md: A response to the critique, addressing the points raised and outlining how the solution will be improved or why the critique is invalid.
• {N+1}_derivation.md: The updated derivation incorporating the feedback from the previous cycle.

Example Sequence:

1. 1_derivation.md
2. 1_critique.md
3. 1_response.md
4. 2_derivation.md ... and so on.

Document Standards

Derivation Files

• Self-Sufficiency: Each derivation file must be sufficient on its own. It should fully describe the problem, parameters, and solution logic without requiring the reader to reference the codebase or previous versions (unless for historical context).
• Clarity: Use standard mathematical notation (LaTeX/MathJax style) and clear prose.
• Completeness: Include all relevant parameters, game rules, and step-by-step logic.

Critique Files

• Objectivity: Critiques should focus on logical consistency, mathematical accuracy, and completeness of the model.
• Verification: Where possible, suggest methods to verify the claims (e.g., code simulations, edge case checks).
• Constructiveness: Aim to improve the solution. If an error is found, suggest the correct direction.

Response Files

• Directness: Address each point of the critique explicitly.
• Actionable: State clearly what changes will be made to the next derivation or the codebase.

Code and Verification

• Code Synchronization: The codebase (e.g., solve_poker.py) should reflect the logic presented in the most recent valid derivation.
• Reproducibility: The repository should include all necessary configuration (e.g., pyproject.toml, uv.lock) to allow anyone to run the solver and verify the results.
• Git Commits: Major steps (e.g., completing a derivation-critique-response cycle) should be committed with clear messages (e.g., "Step 1", "Step 2").

Current Status

• Step 2: Revised derivation completed (2_derivation.md).
• Next: Awaiting 2_critique.md.