This is Part 1 of a two-part software-factory series. Part 1 is about building a new product from a blank workspace. Part 2 is about brownfield bug hunting in an existing codebase.
Most "build me an app" agent workflows fail in the same two ways. They either sprint straight into code before the product contract exists, or they produce a pretty scaffold that cannot survive tests, security review, UI validation, and a fresh operator trying to run it.
I wanted a different default: a greenfield software factory that starts from a blank or explicitly designated new-project directory, turns the brief into requirements and architecture, implements vertical slices, validates the release candidate, and stops at a review-ready handoff.
In this article, I will show you that you can actually build a skill for that and fine-tune it based on your needs, but the overall skill framework and structure should be the same.
The important part is the stop. This is not an agent with permission to deploy, create accounts, spend money, or publish a public product because it managed to run a dev server once. It is a disciplined local factory for producing a runnable candidate with evidence.
Greenfield work is not easy, but it has one advantage over brownfield work: you can choose the shape of the system before history chooses it for you. There is no old permission model to preserve, no migration nobody remembers, no UI test that encodes the wrong behavior.
That does not mean the agent should improvise. It means the factory can draw a bright boundary around the new product and protect it from accidental scope creep.
Figure 1 shows the core boundary. The factory accepts a product brief and a blank workspace; it should stop before it turns into a deployment robot or starts rewriting an existing system.
Figure 1: The Greenfield Boundary
This boundary is what makes the skill useful. A greenfield factory should be confident about creating new files inside the authorized project. It should be conservative about anything outside that project: paid APIs, external accounts, public deploys, real user data, and adjacent repositories.
The brownfield article comes second because it has a messier premise. There the factory has to preserve history, reconcile contradictions, and hunt defects across layers. Here the challenge is different: build the smallest coherent thing that earns a serious review.
The tempting version of automation is one agent that does everything. It reads the request, chooses the stack, writes the code, writes the tests, reviews itself, declares success, and hands you a folder.
That is quick. It is also fragile.
The greenfield factory uses a lean orchestrator. It coordinates phases, packets, barriers, fingerprints, state transitions, and authority. It does not perform requirements analysis, architecture, implementation, UI testing, security review, or final validation itself.
Figure 2 illustrates that separation. The orchestrator routes work to specialized workers and accepts only terminal reports that match the frozen inputs.
Figure 2: The Thin Orchestrator
This seems like overhead until the first failure. When a validation lane fails, you need to know which fingerprint it tested, which slice caused the change, which worker owned the file, and which approvals became stale. A single heroic transcript does not give you that.
The orchestrator's job is not to be brilliant. It is to make brilliance auditable.
Good software work has rhythm. First you define what you are building. Then you choose an architecture. Then you plan slices. Then you initialize the skeleton. Then you implement, validate, and hand off.
The skill makes that rhythm explicit. It uses phases so a future agent can resume without reconstructing intent from memory. Each phase has a gate, and a failed mandatory gate blocks progress.
Figure 3 shows the greenfield state machine. The point is not bureaucracy; the point is that every later claim has a predecessor.
Figure 3: The Factory State Machine
If requirements are vague, architecture should not pretend to be precise. If architecture is not accepted, planning should not fake a dependency graph. If implementation changes the source, earlier validation approvals go stale. That is the boring machinery that keeps an autonomous build from becoming theater.
Many agent builds still behave like junior scaffolding projects: create all models, then all routes, then all screens, then try to wire the system together at the end. That creates long periods where nothing demonstrable works.
The factory uses vertical slices instead. Each slice maps requirements to acceptance criteria, implementation, tests, and evidence. A slice should be small enough to review and real enough to prove behavior.
Figure 4 shows the difference. Horizontal layers feel organized, but vertical slices produce runnable product increments.
Figure 4: Vertical Slices Beat Horizontal Scaffolding
This also makes parallel work safer. Independent slices can run in asynchronous waves if their write scopes do not collide. Shared files, lockfiles, schemas, and integration surfaces still need single ownership. The factory is allowed to be fast, but not at the cost of hidden merge chaos.
Validation is not a pile of tests. It is a set of claims about one exact candidate. If security reviewed one build, UI testing ran against another build, and end-to-end tests ran after a dependency changed, the final report is fiction.
The greenfield factory freezes a release-candidate fingerprint before final validation. Then specialist workers run in parallel against that same candidate: clean install, build, unit and integration tests, system tests, security, accessibility, performance, migration or rollback where applicable, documentation, and full UI testing for UI products.
Figure 5 shows the convergence rule. Many validators can run at once, but they must all point to the same candidate.
Figure 5: One Frozen Candidate, Many Validators
Any meaningful source, test, dependency, schema, or configuration change invalidates affected approvals. That is annoying in the best way. It prevents the final handoff from mixing old evidence with new code.
Use this pattern when you want a complete new app, service, API, CLI, library, mobile or desktop product, data system, or full-stack product from scratch. The phrase "from scratch" matters. This is not the right tool for a single bug fix, a PR review, a CI repair, or a small change inside an existing repo.
The factory's finish line is a local, review-ready release candidate. That means a fresh operator should be able to install it, run it, test it, read the handoff, inspect the architecture, and understand which requirements are covered.
It does not mean production is authorized. It does not mean public release is safe. It does not mean security is solved beyond the evidence the validation lanes actually collected.
The cost is less spontaneity. The factory asks for requirements before code, architecture before slices, and evidence before completion. It will block on missing authority instead of guessing. It will rerun validation when fingerprints change.
For small throwaway prototypes, that may be too heavy. For serious first versions, I think it is the right kind of weight.
The win is not that the agent writes more code. The win is that the build has a memory, a contract, a shape, and a review trail.
For paid subscribers, the implementation notes below include the private repository link, the package shape, and the operating runbook I would use for a new product build.
For paid subscribers: the greenfield implementation Agentic Skill package continues below.
Everything above this line is the free argument. Below the paywall are the private GitHub repository link, the greenfield factory runbook, and notes on how Part 2 changes the problem.
