# Smol Example: ### ChatGPT Web: __ > Write an extremely detailed implementation doc for the streaming version and th apis . We are only looking at geometry rf engine right now . We need to be able to hand the doc you make off to an LLM to code the geometry enginer API up from the existing python code. Make it so . Extremely detailed. Markdown checkboxes for each discrete task `- [ ]` so the AI can mark them off with an X as they complete The codex-cli can start working on the output `TASKS_GEOENGINE.md`. # Implementing component 3 (of 4): ### ChatGPT Web: I pasted in all the `TASKS_*.md` the AI coder has produced so far, so the web planner has an idea of what was done. (If we didn't have access restrictions, the web version could just access the git repo). > Okay, here are the markdown taskfiles of what we've got done so far. We build geo engine and orchestrator . I need you to write a very detailed TASKS_IMNET.md file that deals with the imnet++ inet part and how it interacts with the other two systems as they exist . Write it as a markdown checklist - [ ] so the ai can cross items off as it writes them . Go . This produces TASKS_ORCHESTRATOR.md ### Codex CLI: > Check over TASKS_ORCHESTRATOR.md It was written without knowledg of the actual current implementation. Let me know if it looks good for ARCHITECTURE.md and if it is compatible with what has been done so far in TASKS_GEO_ENGINE.md We have only tried to make a gEO engine so far. no edits ,just check the TASKS_ORCHESTRATOR.md makes sense. ``` Overall verdict: it is mostly aligned with ARCHITECTURE.md and broadly compatible with the Geo engine work, but the 3 medium/high items above should be clarified before implementation so the orchs estrator doesn’t encode wrong assumptions. ``` This step is super important! I need to make sure the plan we thought of actually makes sense with what is happening on the ground. > Can the misaligned items be easily solved? Is there a moslty obvisous right answer to them ? If so tell me the gravious solutions, or show me my optiosn if there s a fork or hard choice __ ### Codex CLI: > @AGENTS.md You task is to implement the geometry engine defined in @TASKS_GEO_ENGINE.md . After completing each task, mark it off with an x (`- [x]`) so its markdown checkbox so there is an external record of what has been done. If plans change, then modify the task list appropriately. The overall high level architecture of the program is in @ARCHITECTURE.md . Go . This is where the magic happens! We have thought through our API and have developed a test plan, and a development plan. Now the AI can develop the code and test the API via the test suite to ensure its correct. --- Overall Advice: - Think about your inputs/outputs/dependencies beforehand. - When the AI screw ups hallucinates, or does something silly, you can make a note in AGENTS.md to do the right thing instead. - Force the AI to use as many deterministic static tools as possible: - Strict Type Checking (Use Rust instead of C, Typescript instead of Javascript, Python with Type Annotations instead of without) - Linters - Code Format Tools - Unit/Integration tests - Have the AI write as many tests as possible of what you want the program to do - If you want the AI to "one-shot" (i.e., autonomously code something complex for a while without supervision and get a good result), then you need to give it as much test input/output behaviour as possible, so it can keep checking against the "proper" results without your guidance.