Codex How To v0.3: engineering loop + review-first Living Wiki

[Phelan164]

I built and maintain Codex How To, an independent engineering-first curriculum and reusable workflow package for OpenAI Codex.

The central idea is that generated code is an intermediate result. A task should move through:

scope → reproduce → implement → test → review → evidence

The repository now includes:

• 14 progressive modules, from safety and AGENTS.md through skills, MCP, subagents, orchestration, context efficiency, and Living Wiki maintenance;
• 9 installable skills for the engineering loop, frontend, backend, DevOps, testing, code review, security review, bounded orchestration, and knowledge maintenance;
• a review-first Living Wiki with registered sources, explicit uncertainty, deterministic linting, and reviewed promotion;
• a dependency-free playground with seeded defects; and
• a three-way protocol for comparing no-skill, full-skill, and lean-skill runs without claiming a universal productivity multiplier.

The fastest way to evaluate the engineering workflow is the five-minute demo. It asks Codex to reproduce an uncovered input-boundary defect, add a failing regression, implement the smallest fix, run the checks, inspect the diff, and report evidence.

The two flagship skills are now indexed in the open agent skills catalog. A tested Codex installation is:

npx skills add Phelan164/codex-howto --skill engineering-loop -g -a codex -y

For knowledge maintenance, install maintain-codex-wiki from the same catalog and start with a read-only query against the Living Wiki before adding a database, embeddings, or another MCP service.

Version v0.3.0 is available here:
https://github.com/Phelan164/codex-howto/releases/tag/v0.3.0

I would especially value critical feedback from developers who try either workflow:

1. Which engineering-loop step catches a real problem?
2. Which step adds overhead without enough value?
3. Which wiki query routes poorly or lacks evidence?
4. Where should one agent stop and a bounded subagent begin?

This is a community project, not official OpenAI documentation. Product claims link back to the official docs.

[Phelan164]

Update: v0.3.0 is now released with the review-first Living Wiki and leaner model-adaptive skills. The flagship skills are also indexed at skills.sh, with an isolated Codex installation smoke test completed.

npx skills add Phelan164/codex-howto --skill engineering-loop -g -a codex -y

I also opened a community engineering-loop benchmark so the workflow can be evaluated with evidence rather than intuition.

The protocol compares the same bounded task in three conditions: no skill, the v0.2 full engineering-loop skill, and the v0.3 lean version. It holds the model, reasoning effort, repository revision, tools, prompt, and done conditions constant, then records checks, regressions caught, human corrections, elapsed time, and available context or token data.

Negative and neutral results are especially useful. If the full loop adds cost without catching anything consequential, that is a reason to simplify it. Sanitized reports from different stacks and task types are welcome as issue comments or pull requests.

[Phelan164]

v0.4 follow-up: Codex How To v0.4.0 — Safer Living Wiki is now published.

The update adds index-first routing for prior decisions and experiments, explicit engineering capture and query archive operations, revision-pinned source dependencies, and stronger safety boundaries for untrusted wiki/source text, path confinement, and sensitive repository evidence. The release gate now covers 26 utility tests, both playground tests, and six wiki pages with zero lint warnings.

The project still does not claim automatic token savings: the wiki efficiency experiment requires repeated evidence before recommending additional retrieval infrastructure. Useful feedback includes queries the index misses, lessons that should produce no durable wiki change, and anonymized no-skill/full-skill/lean-skill measurements.

[Phelan164]

Measurement update: the repository now has six controlled GPT-5.6-sol runs
across two task sizes, and the result is deliberately mixed.

Task	Quality result	Lowest reported-token variant
Small backend boundary fix	All variants passed	No repository skill
Medium 2048 browser game	All variants passed	Lean engineering-loop v0.4.0

On the game task, the lean skill used 31.2% fewer reported tokens than
v0.2.0 and 54.0% fewer than the no-repository-skill control. On the
smaller backend fix, the control remained cheapest.

My current interpretation is not “skills save tokens.” It is that lifecycle
guidance has to earn its context cost by task class, with acceptance and
evidence quality evaluated before speed or tokens.

• Backend measurement
• Reproducible 2048 benchmark and result
• Replication request

I would especially value independent runs that falsify the tentative boundary:
small bounded fixes may not need a lifecycle skill, while multi-surface tasks
may benefit from concise workflow guidance. Neutral and negative results are
welcome.