ntent
How we take a product from a pile of requirements to screens that match them. People read it, and coding agents install it.
Before ntent, how we worked at DBiz lived in three places: an engineering playbook repo, a folder of process guides, and a methodology page that mostly existed as a link somebody had to go find. Each was right about something and out of date about something else. ntent puts all three in one site. I designed and built it over September, first under the name Groundwork, and it’s now public at ntent.app.
The method underneath is the intent model, which has its own note. The short version: write down what the product must do in one file everyone shares, build from it, check the build against it, and change the file first when a requirement changes.
Two readers
The site has two readers, a person and their coding agent, and they want different things. The person wants to know which setup fits their project, and why. The agent wants exact paths and file contents.
So setup starts with two questions. The first is what people will ask you to account for, and it picks one of four tiers: a spike that may not survive two months gets 8 steps, a product that will outlast the current team gets 45. The second is what the product does. Each true answer adds its own steps on top, whatever the tier: evals when a model’s output reaches a user, one place for access rules when people sign in, and so on.
Nobody copies anything
The old playbook asked people to copy files into their repo by hand. Now you paste one prompt into your agent. It reads /llms.txt, fetches the plan for your tier, and writes the files itself.
The plan is shaped for a machine on purpose. Every step names an exact path and says whether to write a new file or merge into one that’s already there. That second part is what stops a setup run from flattening your package.json. Every file carries a hash, so if the site changed between the plan and the file, the agent fetches the plan again instead of half-installing. When it’s done, it writes a manifest: what went in, what it skipped, and why.
Every check fails once
A check that always passes might be working, or it might be broken. From the outside you can’t tell. So every check ntent ships has to go red on a small file that breaks its rule before anyone trusts it green. The install test does this for real. It installs every tier plan into a scratch repo, commits through the installed hook, and drives every gate red and then green.
Every file in the library also carries two plain lines: what it catches, and how you know it’s working. The second is the one junior developers need most and the easiest one to skip, so the type won’t compile without it.
The site reads those files straight off disk at build time. The snippet on a page is the same file the tests run against, so the two can’t drift apart.
The method, drawn five ways
The method page draws the same process from five sides, each for a different listener: the contract for clients and product managers, the three lanes for team leads, the change loop for designers and engineers, the layers for front-end, and the shared plan for everyone.
It isn’t finished. Upgrading a repo from one release to the next is still to do, and so is installing into a monorepo. The old playbook repo is still there too. It gets archived once someone has checked that everything made it across.
When the agent finishes, it tells you what it added, what it skipped, and why. The site asks you to read that before you commit.