Day Zero: I Audited How My AI Projects Actually Begin

TL;DR

I audited how my AI projects actually begin across 94 project directories. The useful finding was not that I need more ambition. It was that I need a cleaner Day Zero.

The best projects did not start with code. They started with governance: plan mode before mutation, a local AGENTS.md, an OpenSpec project.md, Beads issues, and contract tests that made the first real behavior hard to fake. The weaker projects started with enthusiasm and then asked memory to do a job that belongs in the repository.

The audit showed a discipline funnel: the most common project-start artifact appeared in 71/94 directories, while the least common appeared in 31/94. That is adoption decay from about 75% to 33%. In plain English: I am good at starting with rules, less consistent at starting with tests.

This field note is the third piece in the same operating system as Commitmaxxing & Tokenminimizing and How I Run AI Agents: make progress durable, make context smaller, and do not let agent speed outrun system memory.

Quick Glossary for Beginners

Term	Plain-English version
AGENTS.md	Repo-local instructions for the next AI agent.
OpenSpec / openspec.dev	A place to write intent before implementation.
Beads	A git-friendly issue tracker for agent work.
Plan mode	Read, inspect, and propose before changing files.
git worktree	A separate checkout so parallel sessions do not collide.
Contract tests	Small tests that lock the first promises the project must keep.

Day Zero Is a Conversation, Not a Scaffold

The old temptation is to treat a new AI project like a scaffold command. Create a directory, install packages, ask an agent to build the first version, and clean it up later.

That is backwards for the way I now work.

Day Zero should be a conversation before it becomes a diff. I want plan mode first: read-only inspection, explicit assumptions, a narrow first milestone, and approval before anything mutates the repository. The point is not to slow the work down. The point is to prevent a plausible first pass from becoming accidental architecture.

This matters because AI agents are unusually good at filling blank space. If the project does not say what it is, the agent will infer. If the repo does not say what is out of scope, the agent will expand. If the first task has no verification, the agent will optimize for completion language instead of a working contract.

So my Day Zero question is not, “What can the agent generate?” It is, “What does the repo need to know before the agent is allowed to generate?”

Four Artifacts Before Any Code

The audit pushed me toward a simple rule: four artifacts before any meaningful implementation.

First, AGENTS.md. Every project needs local instructions that tell the next agent how this repo works: commands, boundaries, conventions, and dangerous areas. Global rules are useful, but local rules are where the actual project becomes legible.

Second, OpenSpec. At minimum, I want an openspec/project.md that says what the project is for, what it is not for, and what capabilities it should eventually support. When the work is bigger, I want a change proposal before implementation. The value is not bureaucracy. The value is forcing intent to become reviewable.

Third, Beads. If work exists only in a chat thread, it is fragile. Beads gives the project a durable issue graph: ready work, blocked work, discovered follow-ups, and closeout state. It turns “we should do this next” into something the next session can actually find.

Fourth, contract tests. These are not comprehensive test suites. They are the first public promises the project must keep. A route exists. A content file has required frontmatter. A parser rejects malformed input. A CLI prints the expected shape. Contract tests keep the first agent from confusing “generated code” with “working system.” This article itself is guarded that way:

expect(article).toContain('## TL;DR');
expect(article).toContain('94 project directories');
expect(words).toBeLessThan(1800);

What Auditing 94 Project Directories Revealed

I looked across 94 project directories and counted the presence of the artifacts I expect to see near the start of an AI-native project. These are public-safe aggregate counts, not a claim that every directory represents the same kind of product. For the verification row, I counted whether a project had a tests/ directory; some projects may have other checks, but that was the cleanest comparable signal.

Day Zero artifact	Count	Approx. adoption
Local rules or project guidance	71/94	~75%
OpenSpec directory or planning space	65/94	~69%
Beads issue tracking	49/94	~52%
OpenSpec project.md identity file	47/94	~50%
Contract tests or first verification gate	31/94	~33%

That is the discipline funnel: rules show up first, tests show up last. The adoption decay from 75% to 33% is the part I cannot unsee.

It explains why some projects feel easy to resume and others feel like archeology. A repo with AGENTS.md, OpenSpec, Beads, a worktree habit, and contract tests can hand itself to the next session. A repo with only generated code needs a human to reconstruct intent.

Where My Process Leaks

The audit surfaced five recurring leaks.

Registry drift is the first. A project exists, but the master list of projects, status, or ownership lags behind. The result is not dramatic failure. It is quiet confusion: which projects are active, archived, blocked, or safe to ignore?

Docs-artifact mismatch is the second. The README says one thing, the issue tracker says another, and the code says a third. AI agents amplify this because they will often trust whichever artifact they read first. If the artifacts disagree, the model can sound confident while following stale instructions.

Parallel-session collision is the third. Multiple agent sessions are powerful, especially with worktree isolation, but only if the lanes are explicit. Without that, two sessions can solve adjacent problems in incompatible ways. The work looks productive until merge time.

Closeout churn is the fourth. The code changes, tests run, and then the final bookkeeping gets postponed: close the Beads issue, update the spec, commit the trail marker, remove stale notes. That last mile is where tokenminimizing either compounds or fails.

Blocked-issue review is the fifth. A blocked issue should not become a graveyard. It needs a rhythm: still blocked, now unblocked, no longer relevant, or needs a different owner. Otherwise the tracker becomes a museum of intentions.

The Fixes I Am Making

I am not solving this with a motivational rule. I am turning it into a Day Zero ritual.

The first fix is a scaffold generator that creates the boring good defaults: AGENTS.md, OpenSpec skeleton, Beads initialization, a minimal test file, and a public-safe README shape. The generator should not decide the product. It should remove excuses for missing the basic governance layer.

The second fix is a registry validator. If a project exists, the registry should know about it. If a registry entry points at a dead directory, that should be visible. Registry drift is exactly the kind of friction a small script can catch before it becomes cognitive debt.

The third fix is a scheduled blocked-issue review. Blocked work should be inspected as a system signal, not as personal failure. Sometimes the right move is to unblock. Sometimes it is to archive. Sometimes it is to admit the project no longer matters.

The fourth fix is bundling closeout into the work itself. A task is not done when the diff exists. It is done when the issue, spec, tests, commit, and handoff agree. That is the practical side of commitmaxxing: make the useful state durable before the next session forgets why it exists.

Try This: A Minimal Day Zero

If you are starting from nothing, do not copy my whole system. Copy the shape:

1. Create AGENTS.md with commands, style rules, and what not to touch.
2. Create openspec/project.md with the project purpose, non-goals, and first capability.
3. Track one issue in Beads, or even a plain TODO.md if you are not ready for tooling.
4. Add one contract test for the first public behavior.
5. Only then ask the agent to implement the first slice in a separate worktree.

The win is not the brand of tool. The win is that the repo knows what good looks like before generation starts.

The Audit Is the Method

The important part of this audit is not the exact counts. The important part is that the system became inspectable.

Once the work is inspectable, taste can improve. I can see that I am better at project rules than first tests. I can see that worktree discipline helps, but only when paired with a clear issue lane. I can see that plan mode is most useful when it produces artifacts the execution harness can actually use.

That is the same thread running through my recent writing. Commitmaxxing asks what should become durable now. Tokenminimizing asks what the next worker should not need to rediscover. The agent-harness article asks which model or role should handle which kind of work. This Day Zero audit asks whether the project itself is ready to receive agent work.

For me, that is the physician-builder lesson. Speed is not the first draft. Speed is safe resumption. Speed is fewer hidden assumptions. Speed is the next agent, or the next human, opening the repo and finding enough structure to do the right thing without a séance.

Day Zero is where that starts. Not with a bigger prompt. With a smaller surface for confusion.