A local ChatPRD coding harness, with an explanation of its own code
A How I AI episode sent me into an experiment with a local coding harness for ChatPRD. I worked with Codex on the architecture and implementation, then asked it to turn the code into an explainer and presentation so I could see how the pieces fit together.
Build a local coding harness around existing tools with Codex
After reading our How I AI episode about Mozilla’s agent workflow, I asked Codex what a similar setup could look like for ChatPRD. The discussion moved toward a local coding harness: an application that gives a coding agent a defined task, the relevant tools, and a place to save its work. I also used Factory’s CLI as a reference while thinking through the interface.
Codex inspected the skills and command-line tools we already used, then built a terminal interface around a Claude Agent SDK worker. The harness could assemble a task brief, run readiness checks, collect available evidence, and save the worker prompt and outputs together. Investigation and code-editing modes had different permissions. I wanted the setup for a task to be repeatable, including which tools the agent should reach for first.
This got to a local implementation with checks and a browsable record of runs. Some integrations still needed configuration. The useful experiment was packaging our existing development workflow so I would not have to explain the same tools, context, and expectations at the start of every task.
Turn generated code into an HTML explainer with Codex
Once the local coding harness existed, I asked Codex to make an HTML page explaining how the code worked, what the application added, and how someone could build something similar. It read the implementation and produced a code map and an explanation of the run loop. I pushed it to make the page more visual, with architecture diagrams and ChatPRD styling.
I also asked it to identify the interesting prompts in the code. The explainer traced the prompt builder, the generated worker prompt, the worker’s tool permissions, and the saved outputs. That gave me specific places to look when I wanted to understand how the agent was being instructed.
Codex then made a separate ten-slide HTML presentation with keyboard navigation and a link back to the explainer. Having the agent turn its implementation into something I could inspect and explain removed a separate documentation pass. My feedback went into the explanation and the diagrams while the code was still fresh.
# Explain this application
Adapted from my workflow; this is not the original transcript.
Read the implementation of the application I identify. Create a standalone HTML explainer for its owner that answers:
- What does it do, and when would I use it?
- What happens from the initial input to the final result?
- Which files own the important parts?
- Where do agent prompts come from, which tools can the agent use, and where are outputs saved?
- Which parts are implemented, and which still need configuration or development?
Use diagrams for the architecture and main execution path. Link explanations to the relevant source files. Distinguish observed behavior from intended behavior. Use the application’s existing visual style where available.
Check that the page opens, its navigation works, and its diagrams and explanations match the code. Keep example data free of secrets and private customer information.