A software company in one command
Agents with job titles — product manager, architect, engineer — turning one sentence into a PRD, a design and code
Instead of one chatbot doing everything, each agent gets a job title and a deliverable: the product manager writes requirements, the architect writes the system design, the engineer writes the files. You type one sentence and get a folder with all three. It costs real money per run, ships with a $3 cap for a reason, and the honest framing is that nothing here promises working software on the first try.
The project’s own framing is that code equals a standard operating procedure applied to a team — it encodes how a real software team hands work along, and gives those procedures to language models to follow. That is a different bet from “one very capable assistant”: the structure does the work, and each role is judged on a concrete artefact rather than on being generally helpful.
Five roles, five deliverables
Roles as named in the current source. Each one produces a document or files, not a conversation.
It spends money on your own API key every single run — there is no free tier here, only your provider’s bill. It ships with a $3 budget cap by default, which is a brake you should raise deliberately rather than by accident. Start with a small idea. And treat the output as a draft: nothing about this promises working software on the first attempt.
What you need
The Python constraint is the one that actually stops people — it is an upper bound, not just a minimum.
Install it
Pick one path, not both. The package-index release is the stable one; installing from the repository gets the newer role set described above.
Point it at your model
Generate the template with the init-config command, then edit the one block that matters. The file lives in your home folder, deliberately outside any project.
Never paste it into a prompt, a screenshot, a chat or a repository. Its home folder location is the point — it sits outside every project, so it cannot be swept into a commit. If one ever leaks, revoke it in your provider’s dashboard and issue a new one rather than hoping.
One sentence in, a folder out
The agents talk in the terminal as they go — requirements, then design, then code. A few minutes is normal.
The ones that matter
The code-review, run-tests and implement flags still appear in the help output, but on the current main branch the code behind them is commented out — so passing them does nothing. Older package releases may behave differently. This is the kind of detail you only find by reading the source rather than the help text, and it is worth knowing before you build a workflow around one of them.
What to keep an eye on
Troubleshooting
Setup checklist
The guide points at the original author’s account throughout, including in its install and clone commands. The canonical repository now lives under a separate organisation and carries around 70,000 stars; the original author still hosts the documentation and demo repositories under their own account. Transferred repositories redirect on GitHub, so the guide’s commands should still resolve — but the links here point at the current home rather than the old one, and that is where issues and releases actually are.
Three of the guide’s claims were checked against the package index on 17 September 2026 and all hold exactly: the published release is 0.8.2, the Python constraint really is >=3.9 and <3.12, and the licence is MIT. The version split the guide describes — a more conservative published release alongside a newer main branch with the expanded role set — is consistent with what the index shows. The repository move above was found while verifying, and is the one thing corrected rather than carried across. The author’s byline and follow prompt are not included.