How we work.
Everyone does spec-driven development now. Ours rests on standards engineers already know — an executable spec, a design you can look at, and guard rails that hold every time.
Spec Kit, Kiro, OpenSpec and Tessl drive the agent from specifications written as Markdown documents. Superpowers and grill-me bring discipline to the agent's workflow as skills. NoVibe takes the grilling — through the agent's own question tool — and builds on standards instead:
- The spec
- Gherkin that executes as the tests — BDD
- The design
- a C4 model with arc42 views, and ADRs
- What holds
- git hooks, not instructions
- A change
- one small slice per session
- 1
Specify
The requirements engineer asks, one question round at a time, until a Gherkin feature file holds what to build: concrete scenarios, agreed one by one.
- 2
Design
The architect asks the same way until a LikeC4 model holds the design, its views layered after arc42. An ADR only for a crucial, cross-cutting decision.
- 3
Build
Test-first: the feature file is what executes, red → green, until every scenario passes.
- 4
Review & ship
Review agents check the code against the architecture and for security while you start the next slice; agent merge answers the comments and merges.
In order.
The spec and the model are the contract; the code is their consequence.
Plan wide, build small.
Specify as much as you like; build one rule, three scenarios at most, at a time. What the slice doesn't need is parked as backlog — never gold-plated in.
Small batches are one of the seven capabilities that decide whether AI helps a team or hurts it. DORA 2025
Enforce, don't hope.
Skills guide the agent; git hooks, tests and linters enforce what has to hold every time.
One task, one session.
Each slice runs in a session of its own, review agents alongside. No lead agent briefing developer agents — every agent reads the spec first-hand.
What that means, day to day.
Feature files by functionality
Folders are what the system does; epics and priorities live in the plan, never in the file. A feature's @id: is its ticket.
Concrete scenarios
Real values, and what someone outside can see — never a rule restated in the abstract.
Plain industry terms
No invented names, no vague words.
Test and review the architecture
Architecture tests — ArchUnit and its kind — and review agents that flag where the code drifts from the model.
Automate what costs you time
A check you keep doing by hand becomes a guard rail; a review you keep repeating becomes an agent.
Run remote
A sandbox per session keeps the agent away from your machine, and the work goes on when you close your laptop. agentbox is one way; where your agents run is your choice.
The cockpit reads a repository's default branch instead of assuming main.
cockpit#26, seven commits:
- spec the cockpit speaks of a repository's default branch instead of main
- arch the cockpit reads the repository's default branch instead of assuming main
- feat the cockpit says the default branch where it said main
- feat the Worker takes the default branch from GitHub instead of MAIN
- spec the default branch shown first is develop, so the example proves it is not assumed to be main
- arch CI runs push runs on this repository's default branch
- test the stand-in's default branch is the one the scenario names