Greenfield
Greenfield is a spec-first harness for building a new app one verified unit at a time.
The problem
Most greenfield LLM flows ask for an app in one breath and hope the pile compiles.
I needed a path from an idea to working code where the plan stays written down and each change stays narrow enough to review. I also needed verification to be something I can run myself, without trusting a chat scrollback. What was missing was a harness that turns intent into specs and scaffolds a starter, then generates and checks one implementation unit at a time while leaving an inspectable trail.
Why I built it
Day to day, I wanted to start a project from a short idea and still know what was decided, what was generated, and what still fails verification.
A local Python CLI was enough for that. The LLM helps with intake, planning, and bounded codegen, while the harness owns the order of work and the verify step, along with the artifacts under .greenfield/.
What I built
Greenfield is a Python CLI for a spec-first greenfield coding harness that combines LLM-assisted planning, bounded codegen, repair, and deterministic verification. It turns a project idea into structured specs and applies a deterministic scaffold (stdlib HTTP by default, or FastAPI). Then it decomposes the work into small implementation units, generates and verifies one unit at a time, and keeps the trail inspectable under .greenfield/.
You install it with pip install -e ., which provides the greenfield console script. Runtime config lives under the user appdir greenfield/ as config.yaml plus .env for secrets such as OPENAI_API_KEY. Generated application source sits in the project root and does not depend on .greenfield/ at runtime.
Three decisions
These are the three choices I would defend in a design review.
1. The spec comes first, then the scaffold, then the units.
The path goes from the idea into SPEC_IN.md, then to project_spec.yaml and system_design.yaml, then through scaffold apply to a work plan of implementation units. I was counting on a written design outliving the chat that produced it, because the failure I care about is inventing an architecture while you are already halfway through generated files. Specs and design artifacts live under .greenfield/specs/, so later inspect, status, and advisor can ground their answers in what was actually recorded.
2. Work happens one unit at a time.
work plan breaks the design into bounded units, and work run <unit-id> gathers context and runs codegen for that unit alone. I can list units, check the latest verification, save checkpoints, and evolve features with feature request / feature plan without treating the whole app as one opaque generation. The bet was that reviewable progress beats a single large write. If a unit fails, repair stays attached to that unit’s traces and does not rewrite the project in one pass.
3. Deterministic verification owns the grade.
verify runs the configured checks for the active unit, with retry and repair around that loop. When every unit is complete, integrate runs the full pytest tests, and verification reports land under .greenfield/verification/. I wanted a command I can re-run to decide whether a unit is done, because an LLM saying “looks good” is not a merge bar. The model may propose code and repairs, and the harness records whether the verify commands passed.
Proof
You can follow the same command path from the public README and docs/QUICK-START.md.
The condensed path from a new directory after install looks like this.
greenfield project init greenfield spec generate greenfield design generate greenfield scaffold apply greenfield work plan greenfield work list greenfield work run <unit-id> greenfield verify greenfield status greenfield integrate greenfield advisor "What should I do next?"
The public repo also confirms that Greenfield needs Python 3.12+ and an OpenAI key for the LLM-backed paths. Config sits under the user appdir, artifacts sit under .greenfield/ (specs, runs, reports, state, traces, verification), and inspect previews those artifacts. Operator detail lives in docs/OPERATOR-GUIDE.md.
greenfield) and goes through user-appdir config, then spec → design → scaffold → bounded work run units, with deterministic verify / integrate. The LLM helps with intake, planning, codegen, and advisor. The durable trail stays under .greenfield/, and app source lives in the project root.
Why I built it this way
I hold these boundaries whenever the cost of a wrong turn is a repo full of generated code I cannot explain.
I write the spec before I generate the bulk of the app, and I change one unit at a time so a failure stays local. Verify commands decide whether each unit is done. If I am going to use an LLM on a greenfield project, I want the plan and the grade to be files I can open on disk.
The code lives at github.com/rdegraci/greenfield, and you can go back home from here.