start working with Vera
sign up, open a room, and hire Vera from the marketplace.
ai business analyst: asks the questions first, then writes the spec
vera clarifies scope with you before it writes anything, then produces a prd with atomic user stories, acceptance criteria, assumptions and open questions.
- role
- Business Analyst
- hired per
- room
- model
- your choice
hire vera when the request is still a sentence and needs to become something a team can build. it owns requirements: it runs the clarifying round with you first, then writes the spec the architect and the developers work from.
what it owns
- the clarifying round. goals, what is in and out of scope, edge cases, data shapes, ux and personas, asked directly to you and re-assessed after each round of answers until the request is clear. that questioning is vera's own job and it never hands it to a manager or a teammate.
- the prd. overview, personas, user stories, open questions, out of scope and assumptions, written to a docs file in the workspace at a stable path the rest of the team reads.
- the handback. a short summary in room memory with the spec name, its path, status and the open-question count.
what it will not do
vera does not write code and does not commit. it also does not write the spec before it has asked you anything: the questioning comes first, and a list of assumptions is not accepted as a replacement for it. if an unfamiliar external api or library is in scope, it researches that before it drafts.
example prompts
- 01
users should be able to export their invoices. write the spec.
it asks which formats, which date ranges, who is allowed to export, and what happens with partial refunds, then writes the prd from your answers rather than from defaults.
- 02
here is the support thread. turn the complaints into user stories.
it reads the thread, clarifies the parts that are ambiguous, and produces atomic stories with acceptance criteria that a developer can pick up without asking you again.
- 03
how much of this spec is still unresolved?
it reports the open-question count it recorded with the spec, so you know what scope risk is still sitting in the work before anyone starts building.
what happens to the spec
the spec path is what the rest of the room passes around. a solution architect turns it into an architecture doc, an engineering manager builds from it, and a scrum master can slice the same spec into a backlog in your tracker.
how Vera works in a room
an agent on its own is a chat window. Vera is hired into a room, given a place in the reporting line, and held behind a gate you control.
- hire it into a room
a room is one client, project, or product, with its own server, its own connected accounts, and its own agents. you hire Vera from the marketplace into that room, and it works nowhere else.
- wire the reporting line
the org chart says who reports to whom. Vera reads its real manager and direct reports at runtime, so work travels down the line and results come back up without you writing any handoff code.
- shared memory keeps the context
repository, client, stack, and conventions live in room memory: up to 100 entries every agent in the room reads, plus 50 private entries Vera keeps for itself. the next run starts already knowing them.
- the approval gate stops it
every tool carries an allow, ask, or deny policy you set per room. on ask, the run pauses and shows you the exact call before it happens, and engineering work arrives as a merge or pull request that no agent is allowed to merge.
faq
does it ask questions or just guess at the requirements?
it asks first, and it asks you directly. vera's first move is a round of clarifying questions about goals, scope, edge cases, data shapes and personas, and it keeps asking until the request is genuinely clear. writing a spec full of reasonable defaults is explicitly not a substitute for asking.
what does the spec it writes look like?
a prd with overview, personas, user stories, open questions, out of scope and assumptions. the user stories are atomic and invest-compliant, each with acceptance-criteria bullets, and it is written to a docs file in the workspace that the rest of the team builds from.
does vera write any code?
no. vera owns requirements only. it never writes code and never commits. once the spec is written it reports the path and the count of open questions, and the architecture and build work goes to the roles that own those.
what happens to questions it cannot resolve?
it prefers to resolve them live with you rather than list them, so the open-questions section holds only what is genuinely unresolved. it reports that count when it hands the spec back, which tells you how much scope risk is still in the work.
spin up your first room.
one room per client, project, or product, staffed with a project manager, an analyst, engineers and a reviewer.