Setting Up a New Project

Setting up a new (greenfield) project happens by talking to the Architect — the same conversational surface you use for all planning. You describe what you want to build, answer a short sequence of guided questions, and Architect generates your roadmap and first set of stories. Because it's an Architect draft, you can set a project up together with the rest of your workspace (see Setting up together) and pick the conversation back up on any device.

Choosing where your repos are created — the git host and workspace — happens on the New Project screen, before the conversation begins. Setting up API keys and command-line tools isn't something you do up front: Trinity prompts you for what a story actually needs, when it needs it, and you can manage everything from Project Settings → Secrets at any time.

Your progress is saved automatically to the server, so you can close the app and return later without losing work. A project's phase (setup → planning → structured → executing) is derived from what you've actually produced — your roadmap, PRDs, and stories — not a stored "current step," so resuming is always safe. A project stays in setup until its first PRD lands, moves to planning while that PRD has no stories yet, sits in structured once it has a plan but nothing has run, and reaches executing the moment work actually starts. On a project with more than one PRD, the roadmap you see is always the newest PRD's, so an older round's roadmap never masks a newer plan's direction.

For the mechanics of the Architect surface itself — sessions, the Mine/All list, inline review cards, the plan strip, and how a plan is committed — see Architect. This chapter covers the greenfield-specific journey that runs on top of it.

The setup questions

When you start a brand-new project, Architect opens a short, guided question sequence and adapts it to what you're building. The steps you'll see, in order:

Clarify (always) — describe your idea, then settle the set of targets you're building (Web App, Website, Mobile, Desktop, Extension, CLI, API, or Library), grouped by the codebase each ships from. Usually that's one codebase per target; group two together when they genuinely build from the same source (a React Native app that also ships for the web).
Design (for every codebase shipping a target with a design surface — Web App, Website, Mobile, Desktop, Extension, and CLI, whose design system is its terminal palette and output styling) — look-and-feel questions that feed the design guide, asked once per codebase. Two targets built from one codebase are answered together, since the design system belongs to the codebase they share; a codebase shipping only API or Library targets skips the step.
Stack — tool and framework suggestions, settled per codebase once its design is in place. Targets that share a codebase share one stack.
Backing services (Docker) (only when your stack needs them) — Architect works out, for each codebase, whether it needs Docker Compose and which databases, caches, queues, or object stores it runs on, and captures that setup so a greenfield project comes up with the services it needs. Each codebase gets its own answer: an API that needs Postgres and Redis sits happily alongside a marketing site that needs nothing. A pure frontend or static app skips this.
Structure (always) — choose how your repositories are organized: a single repo, one monorepo, a turborepo, or separate repos. A single-target project settles the repo count automatically, but you still confirm whether that one repo is a plain single repo or a workspace.
Repositories — home each codebase onto a repository and confirm the destination (often inherited from what you picked on the New Project screen), the repo set, and visibility in one card. Targets come along with the codebase they ship from.
Phasing (always) — settle the ordered list of phases your project ships in, starting with the MVP.
Business details — the concrete facts a plan can't infer: monetization, legal or compliance needs, launch timeline, and how many people are building it.
Generate (always) — Architect writes your roadmap and first stories. Before generating, it also offers to build an interactive prototype of the settled design — your app's key screens and the flow between them, in every theme and facet your design system carries. See Architect.

Steps that don't apply are skipped automatically — an API-only project won't see Design, and a pure frontend app skips Backing services. Design settles one codebase at a time; the stacks are then worked out for every codebase at once and confirmed a card at a time as each comes back, and a codebase's backing services follow directly from its own confirmed stack. Trinity also pre-answers whatever your description already implies and pauses at each natural break, so a step you've effectively already answered passes in a single confirming exchange.

Throughout the conversation, the sidebar rail on the right shows every decision the Architect has captured so far — toggle the Vision, Packages, or Phasing panels to see the current state, or open the Stack, Structure, or Design system modals to inspect what's been staged. Everything is a read-only mirror of the session's draft workspace; you shape it by talking, and nothing touches your real project until you explicitly accept.

You don't configure agent skills or service keys as a step here. Core agent skills are scaffolded into your project automatically, and the service keys your stack needs are managed from Project Settings → Secrets — a story that needs an unset key surfaces a runtime gate when it runs.

For the full Architect surface — sessions, the sidebar rail, conversation modes, how slots work, and the commit flow — see Architect.

Clarify

Describe your idea at whatever level you have it — vague or detailed — and Trinity acts as a co-thinker, proposing concrete framings when you're struggling to articulate something. You can:

Upload reference files — images, documents, and fonts ground the rest of the conversation in your actual materials
Add reference URLs — websites or tools you want Trinity to learn from

Trinity then asks focused, one-at-a-time questions about target platforms, frameworks and languages, database, authentication, and key integrations. Each question offers options with explanations; an option that carries risk (experimental framework, end-of-life, etc.) shows a risk badge. Trinity prefers free and open-source defaults, and a priceable option carries a researched pricing badge — a Free / Free tier / Paid pill you can hover for the vendor's own detail, a link to the source page, and how recently it was checked. The more context you give early, the more of these questions answer themselves.

Pasting a spec doesn't end the conversation. If you drop in a brief, a requirements doc, or a long written description, Trinity captures it as your vision and then works through what the document didn't settle — who it's really for and at what scale, what success would actually look like, the assumption the whole idea rests on, what's deliberately out of scope, how each feature behaves at its edges, what happens on an empty or offline or permission-denied screen, the features it implies without naming, and anything in it that contradicts itself. Those come one at a time with a recommendation attached, the same as every other question. Whatever the document genuinely answers is still skipped, so a thorough spec can make for a short conversation — but it never skips the conversation itself, and Trinity won't ask you to sign off on the vision until it's been through it.

Trinity brings things you didn't ask for. At least once before you sign off on the vision — pasted spec or not — it puts a batch of its own suggestions in front of you: the surface your described flow implies, an export or backup nobody mentioned, a state that quietly decides half the interface. They come as one table, each row carrying Trinity's proposed take, so taking or leaving one is a word rather than a discussion. In the same spirit, when a feature has a well-established standard behind it — how recurring events repeat, how calendars are exchanged, how money is stored, how simultaneous editing works, how search is done — Trinity names that standard here rather than saving it for Stack, because it settles what the feature is and not which library builds it. And when it thinks a choice will bite you later, it says so once with the concrete cost attached before going along with it; leaving a concern unanswered isn't read as agreeing with it.

Design

For every codebase shipping a target with a design surface — including a CLI, whose design system is its terminal palette and output styling — Trinity settles a look and feel, one codebase at a time. The design system belongs to the codebase, so everything shipping from it answers together, and one system can cover several codebases — your web app and mobile app can point at the same palette rather than each getting their own. Trinity grounds on the systems your project already uses before proposing a new one.

It opens with a single open message rather than a card: the feel you're after, anything you already have to work from (a logo, brand colours, mockups, an existing site — drop them straight into the conversation), and whether you already know how many themes you want or roughly what colours they should be. Nothing has been drafted yet, so there's nothing to pick between and no card to pick it on. "Nothing in mind, surprise me" costs you nothing, and so does answering only the part you have an opinion about — whatever you leave unsaid, Trinity proposes for you. Whatever you do say becomes the frame every direction after it is drafted inside.

From there the questions come one at a time in a fixed order, because each answer is the ground the next one is previewed against: the accessibility level first, then which colour facets you ship (light, dark, or both), your colour direction, typography, density, corner shape, elevation, translucency, glow, and motion. Translucency and glow are the only two that don't always come up — they're asked when what you described calls for them, and independently of each other, so you might see both, either, or neither (see Architect). Last comes the one step with nothing to answer: Trinity writes each codebase its design contract. These answers feed the design guide the agents read while implementing.

Stack

Trinity suggests specific tools and frameworks for each codebase once its design settles, one codebase at a time. For each suggestion you can Accept it, Swap it for an alternative (shown side by side), Find alternatives in the same category, Ask about it to discuss trade-offs, or Override with your own preference. Choices are per-codebase, so a Web App and a Mobile app in separate codebases pick independently — while two targets built from the same codebase share one set of picks, because they share one dependency tree. Accepted suggestions flow into the project's stack tracker.

A priceable suggestion carries a researched pricing badge — a Free / Free tier / Paid pill with the vendor's own detail, a link to the source page, and a freshness date, rather than a guessed figure — and there's always at least one fully-free option among the alternatives. Suggestions are grounded in your description and your Clarify answers — if you said "SvelteKit + IndexedDB" or "local-only, no backend", the picks respect that.

Structure

Trinity proposes how to organize your repositories — a single repo, a monorepo, a turborepo, or separate repositories — as a recommendation you can accept or change, showing the two options that genuinely fit your project. Codebases that share a language and lean on code-sharing point toward a monorepo; codebases with independent deploy cadences and disjoint stacks point toward separate repos. The step is never skipped: a single-target project is one repo automatically, so the card asks the one thing still open — a plain single repo holding one package at its root (the recommendation) or a workspace. Separate repositories are never offered to a project that ships one repo. This step decides the structure only — the actual repositories are created when you commit your first plan.

Phasing

Once each codebase's design and stack are settled, Trinity asks you to settle the phases your project ships in — a named, ordered list, each phase with a one-line intent. This is purely about order and scope; what you're building was already settled in the steps before it. That list becomes the backbone of your roadmap — the first phase is your MVP, and everything after it builds on what shipped before — so the step always runs, however small the project.

What scales is the depth, not whether it happens. A multi-target build earns a real conversation about which target lands first, when the rest follow, and where external dependencies wire in. A small single-target app gets the obvious sequence pre-filled on a card for you to accept or nudge.

Business details

Trinity asks for the concrete facts a plan can't invent for you: how the project makes money, any legal or compliance constraints it has to respect, your launch timeline, and how many people are building it. These land in your project's vision and steer what gets planned — they're also editable later from Project Settings → Business.

Generate

Architect generates your roadmap — overview, vision, phasing, architecture and design system — onto the PRD it plans, and writes your first stories through the full planning pipeline. Each story arrives already calibrated — its audit passes, model tier, and reasoning effort are set the same way a story planned from scratch would be.

Accepting your first plan is the moment Trinity provisions the project — repositories, the codebases inside them, their targets, and the accepted stack land together, and the project flips from onboarding to planning so the full project surface unlocks. Nothing is created until you confirm. From there you land on the stories list, ready to run.

Service keys live in Project Settings → Secrets and aren't part of the Architect conversation. A story that needs a key that isn't set yet pauses at a gate rather than failing.

Setting up together

A greenfield setup is an Architect draft, so it can be a shared, real-time conversation. If your project has more than one member, any of them can open the draft and contribute:

See who's here — a row of participant avatars shows everyone in the conversation; replies and answers stream to all of you live.
Tag the agent — type @ and pick @agent to pull the assistant into the turn. In a shared conversation it replies only when tagged, so everyone can talk things through without it jumping in; on your own it answers every message.
Answer attribution — every answered question shows who answered it.

See Architect for how sessions are shared and resumed across people and devices.