Your stack
The repository you already have, or one from nothing
Recognition is a shortcut, never a gate. A repository whose markers we know gets its setup, dev and check commands seeded for free; one we do not know is recorded as unrecognised, and your own model writes those commands against the tree in front of it.
01Your stack
Your repo as it stands, or a new one from nothing.
The table below is a shortcut, not a gate. A stack it recognises gets its build, test and lint commands seeded without asking anyone; a stack it does not recognise is recorded as unrecognised and your own model writes the commands instead.
- The repo you already have
- Any language, including the parts nobody wants to open. We read the tree, seed the commands we can, and say plainly which ones we guessed.
- Anything the table does not list
- Recorded as unrecognised rather than forced into the nearest row. The build, test and lint commands are then authored against your repo instead of read out of a table, and the run says which happened.
- A new project from nothing
- An empty repo is scaffolded with the house framework, through that framework's own generator. We vendor no templates, and an existing tree is never rewritten into a framework: that is a change a person approves, not a scaffold.
Recognised out of the box
- Bun
- Node
- Python
- Go
- Rust
- Ruby
- ultimate
Nothing here requires a recognised stack. The recognised list only decides whether the first commands arrive for free.
How a repository is picked up
Recognised from a marker file
Detection reads the top level of the checkout and nothing else: bun.lock, package.json, pyproject.toml, requirements.txt, setup.py, go.mod, Cargo.toml, Gemfile. The most specific marker wins, so a lockfile beside a manifest decides the row. Nothing is fetched over the network and nothing is inferred from the repository name.
Not recognised, not refused
A tree with no marker we know is recorded as unrecognised rather than pushed into the nearest row. Your own model then reads the repository and writes the three commands, and the run record says which of the two happened.
Your commands win
Seeded commands land as scripts in the repository and every write is a never clobber write. A setup, dev or check script you already ship survives untouched, and one you rewrite afterwards stays rewritten.
Why the commands matter
The check command is what a worker runs to prove its own pull request, and what the deep review lane runs over a diff. A repository with three real commands gets graded mechanically; one with none is reviewed without that gate.
The list is a shortcut, not a ceiling
The recognised list exists so that a repository we can name mechanically has a working gate before any model is asked a question. It decides nothing else. A repository outside the list is still cloned, still read, still worked on and still opens pull requests; what it loses is the free command trio, and it gets that back the moment your own model writes all three commands itself. That is the whole of the qualification, and we would rather print it than sell a list of languages we do not maintain.
Starting from nothing
One house framework
An empty repository is scaffolded by running the house framework's own generator, not by copying templates we keep here. We vendor nothing, so you get whatever that framework ships today rather than a stale copy of it.
Or the house layout in your stack
Name a different stack on a new repository and it gets the house repository shape instead: Bun, Node, Python, Go, Rust, Ruby. A stack outside that list is refused by name, with the reason in the record, rather than quietly falling through to an empty base.
An existing tree is never rewritten
There is no migrate command and there will not be one. Applying a framework to a repository that already holds code is a rewrite a person approves, so the scaffold refuses it by name instead of narrowing it to a partial job that reads like success.
Next
Where to read further
- How it works
The lifecycle a run follows on your repository, from the issue to the merged pull request.
- Install
What the GitHub App asks for, what the runner needs on your machine, and what happens on the first pass.
- Documentation
The policy file, the command trio, the artifacts a setup pass writes, and the exit codes a gate may use.
- Request access
Access is invite only while the fleet grows. Tell us which repositories you want picked up first.
Ship more. Maintain less.
We expect software to be written faster than any team can review it. Bring your repos, your boxes and your keys. We bring the org that keeps up.