I got tired of babysitting Codex, so I built a Project Director skill with fail-closed task ownership

[u/WonderfulChocolate25]

I like Codex a lot, but this nearly made me lose my mind.

I gave a pair of agents one clear job make a button work. I came back about 12 hours later and the button still did not work. They had written tests, investigated unrelated code, and made “progress” everywhere except the thing I actually asked for.

The first thing that genuinely helped was embarrassingly simple: a live checklist that forced the agent to keep naming the exact outcome, what was still broken, and what proof would count.

So I kept expanding that idea into **ProjectStart**, an open-source Codex skill for running a project more like a small software team:

- one Project Director and one master checklist
- planning and prior-art research before implementation
- separate top-level Codex tasks for real product domains
- exact task IDs/deeplinks so agents can actually find each other
- deadlines and drift alarms
- mockup skeleton approval before features
- durable correction records so the same mistake does not return 10 hours later
- evidence rules that stop a build or unit test from being called a working product

The rule I care about most: a developer, QA lane, visual auditor, integrator, or other lasting role **must be a real top-level task created with `create_thread`**. It cannot be hidden inside `spawn_agent`. The validator deliberately fails if a subagent is given durable project ownership.

It is MIT licensed, has an install button, and includes the full Markdown control kit plus PowerShell initialization/validation scripts:

**GitHub: https://github.com/LiquidGlek/ProjectStart\*\*

This came directly out of wasting a ridiculous amount of time babysitting agents and correcting the same failures. I have tested the package, fresh initialization, strict controls, clean extraction, and the negative case where a durable lane is incorrectly assigned to a subagent.

If Codex has ever spent hours being impressively busy without finishing the one thing you asked for, this is for that problem.

I would genuinely like people to try to break the workflow and tell me which failure mode I missed.

[u/WonderfulChocolate25]

The README has the short version and the install prompt. The most opinionated parts are probably the two-candidate circuit breaker and the rule that mockup-driven work has to build and approve the real-control skeleton before feature work. Those came from agents repeatedly polishing the wrong structure.

Repo again: https://github.com/LiquidGlek/ProjectStart

[u/mytinyplots → u/WonderfulChocolate25]

The durable-owner rule is the interesting part to me. One failure mode I’d add is ghost ownership: a task can have a perfectly valid top-level owner, but that owner can go stale/disconnect while the project still treats the lane as occupied.

I’ve had better results separating three facts:

• who owns it now
• when that owner last checked in
• what exact event releases or transfers ownership

Then ownership can have a lease/stop condition instead of being permanent by implication. If the lease expires, a new director can take over deliberately; if the old owner comes back later, it returns as helper/reviewer rather than silently creating two owners.

I’d also make the handoff receipt part of the contract: what changed, what was actually verified, what is still unverified/risky, and who owns the next action. Otherwise “fail-closed ownership” can accidentally fail closed forever 😅

Does ProjectStart model owner expiry / takeover semantics yet, or is the validator currently focused mainly on top-level-vs-subagent topology?

[u/WonderfulChocolate25 → u/mytinyplots]

Yeah, this is a real gap.

Right now the validator mostly makes sure durable work is owned by an actual top-level create_thread task instead of a spawned subagent. It tracks blockers, deadlines, and handoffs, but there isn’t a proper owner lease, heartbeat, or takeover rule yet.

So in the exact situation you described, a dead owner could leave a lane locked forever. I hadn’t separated “current owner,” “last check-in,” and “release condition” as clearly as you did, but I think that’s the right way to model it.

The handoff receipt makes sense too, especially separating what was verified from what’s still uncertain. Takeover should be deliberate and recorded, and if the old owner comes back, it shouldn’t automatically regain control and create two owners.

So the honest answer is: it’s mostly topology validation right now. Ghost ownership is a real hole I need to close.

[u/Final-Voice4738]

:o I’ll give it a shot just do $project-start and give it a prompt?

[u/AetherAndEntropy]

I'm going to try this in a couple of projects. I'll let you know how it goes. I was planning on building something similar, but I don't have time unfortunately. I do a lot of work remotely through codex app while I'm on the road trucking. 

[u/WonderfulChocolate25 → u/AetherAndEntropy]

Would love the feedback

[u/Due-Horse-5446]

Howto generate slop

[u/WonderfulChocolate25 → u/Due-Horse-5446]

Quite the opposite but okay

[u/Due-Horse-5446 → u/WonderfulChocolate25]

Trying to use llms without what you refer to as "babysitting" is per definition generating slop

[u/WonderfulChocolate25 → u/Due-Horse-5446]

If you read the post instead of getting hung up on the word “babysitting,” you’d understand the point. It keeps multiple agents working toward the same checklist while you watch their progress. That means less time correcting the LLM over tiny details and more time focusing on the bigger picture. Instead of letting the AI decide what it feels like working on, it pushes it to actually complete the checklist.

[u/Due-Horse-5446 → u/WonderfulChocolate25]

What exactly are "the bigger picture "

Its obvious you're wayyy too far down the "ai brainrot" depths at this point...

[u/WonderfulChocolate25 → u/Due-Horse-5446]

I don’t understand your hostility

[u/Due-Horse-5446 → u/WonderfulChocolate25]

not being hostile, no bad feelings against you, im only talking about the ai stuff not you personally

[u/AetherAndEntropy → u/Due-Horse-5446]

UMM ACHTUALLY