/visionaire:start15–50 executable specs per session. $20 each. Everything your developer needs to open on Monday morning.
Takes the approved architecture and translates it into implementation-ready feature contracts — given/when/then acceptance criteria, explicit scope boundaries, dependency ordering — one file per feature, in the order they should be built.
None of this is theoretical. These are the patterns that show up every time.
Architecture defines the system. It doesn't tell a developer what to build first, where the scope ends, or what "done" means for each piece of work. Every gap in that handoff becomes a decision made in code — fast, invisible, and expensive to revisit once it's been shipped.
3–8 hours of rework per ambiguity gap. A typical handoff from architecture to implementation carries 12–20 unresolved gaps. That's a sprint before a line of real code ships.
The Features Phase reads what the previous five phases produced and converts the system design into concrete, ordered, testable work units.
WHAT is required. HOW is forbidden. Scope boundaries explicit. Dependencies named and ordered. Acceptance criteria observable — not a hope, a gate. These rules are enforced by the stage gate, not by convention.
Every unresolved scope question, every unnamed dependency, every vague acceptance criterion becomes a decision made in code under pressure — and a conversation weeks later about whether to rewrite it.
Start my spec session — $297The agent reads the three approved documents — Product Brief, UI/UX, Architecture — and derives the complete, ordered feature set without requiring your input during generation. You review the output, not the process.
The agent reads BRIEF.md, UIUX.md, and ARCHITECTURE.md completely. It extracts user-facing capabilities from the journeys, system capabilities from the architecture components, integration requirements, constraints, and the explicit out-of-scope decisions from each document.
Distinct, independently testable units of work are identified. Each feature must deliver incremental value, fit within 180k token context, and have explicit prerequisite relationships. Features are sequenced — F-001 before anything that depends on it. No circular dependencies pass this step.
Each feature receives the full template: header, scope with explicit in/out, dependencies, user interaction with all states, constraints traced to UIUX.md or ARCHITECTURE.md, observable acceptance criteria, assumptions, examples marked illustrative, and related document links. WHAT-only language enforced throughout.
An autonomous review agent evaluates every feature against all 10 contract criteria. If any feature fails any criterion — even one — the entire batch is REJECTED. The writer revises and resubmits. APPROVED means all criteria pass across all features. Implementation can begin immediately.
This is the last formal gate in the Visionaire workflow. Features Review APPROVED means implementation can begin with zero ambiguity — scope defined, dependencies named and ordered, acceptance criteria testable, no HOW embedded in the requirements. If the gate rejects, the batch is revised and reviewed again. Nothing goes to implementation on an incomplete spec.
Rejection is precision. It names the exact gap that would have become a sprint of rework. Here's what that looks like in practice.
The feature seemed obvious: "Change Request Tracking." The agent wrote it. You read it — looks fine. The stage gate comes back REJECTED: "Acceptance criteria contain implementation detail. 'Stores change request in database' is HOW, not WHAT. 'User receives confirmation that the change request was submitted' is WHAT." Two criteria flagged across three features.
The rejection specifies exactly what to fix. The writer revises the three flagged features, resubmits the full batch. Second review returns APPROVED. The total additional time: 12 minutes. The alternative — discovering the implementation coupling six weeks into build — would have cost a sprint of refactoring.
A revised feature batch that passes all 10 criteria across all features — including clean WHAT/HOW separation that keeps implementation decisions open for your engineering team.
Sarah's ScopeGuard needs a client portal — a substantial feature with multiple views, approval flows, notification states, and permission rules. The agent flags it during feature identification: estimated implementation context exceeds the 180k token limit. The feature as specified would cause an AI agent to halt mid-implementation.
The feature gets split: F-007 covers the portal authentication and basic view, F-008 covers the approval workflow, F-009 covers the notification system. Each is independently completable. Dependencies are made explicit — F-008 depends on F-007, F-009 depends on F-008. The split also makes the features independently reviewable and independently shippable.
Three implementation-ready features in place of one that would have failed mid-execution, with explicit dependencies that preserve the correct build sequence.
During feature generation, the agent surfaces a conflict: the architecture's notification service implies real-time email delivery, but BRIEF.md explicitly ruled out email infrastructure as out of scope for v1. The feature spec for "Change Request Notifications" can't be written without resolving this — the scope boundary in Vision contradicts the system design in Architecture.
The conflict is flagged before any feature is written. You review the two documents, confirm the intent — notifications should be in-app only for v1 — and the constraint is updated in the feature spec to trace back to BRIEF.md. The architecture's email service is marked as a future dependency, not a v1 requirement. The conflict is resolved in the spec, not in a code review six weeks later.
A feature spec that correctly reflects the v1 scope boundary, with the conflict documented so the team understands why in-app-only was chosen and what the email infrastructure is being held for.
Every phase before this one produced a definition. Architecture defined the system. Features define the work. Features Review APPROVED is the signal that implementation can begin — nothing left ambiguous, nothing left to interpret at the keyboard.
Features is also the final stage gate. When Features Review approves, the six-phase definition process is complete. Implementation begins with a full document chain — IDEA.md through F-001...F-N — tracing every decision from concept to specification.
Teams do it. The tradeoffs are the same every time.
The choice isn't between specification and speed. It's between ambiguity resolved now — in a document, before a line of code is written — and ambiguity resolved later, in code, under pressure, during the sprint that was supposed to ship. $297 is not the cost of a spec. It's the cost of not rewriting the first sprint.
I built this phase because the most expensive conversations I've seen in engineering weren't about hard technical problems — they were about what "done" meant, who owned which edge case, and which dependency somebody assumed would already exist. None of those conversations needed to happen. They were spec failures, not engineering failures. This phase eliminates them before the first pull request opens.
— Robert Evans15–50 specs per session. Scope defined. Dependencies ordered. Acceptance criteria testable. No interpretation required, no alignment meetings mid-sprint, no ambiguity resolved in code.