The fastest way to explain Bridge is to walk through one idea from the moment it arrives to the moment it becomes an implementable spec. Here is a single, real-feeling example.
The capture
It's a Tuesday evening. You're on a walk. You have a thought: it would be useful to have a small app that tracks every book I've ever mentioned wanting to read, across any source — a friend's recommendation, a podcast, a Twitter post, something my coworker said on Slack. One place. Searchable. Tagged by who recommended it and why.
You open Bridge on your phone and press record. You say that paragraph out loud, more or less. Twenty seconds. You keep walking.
You didn't title the note. You didn't pick a category. You didn't write any acceptance criteria. Good. That's the point. The only job of the capture phase is to get the idea out of your head before it decays.
The interview
Later — ten minutes later, an hour later, two days later — you open Bridge and the planner starts the interview. It doesn't ask you "what features do you want." It asks the harder questions.
You mentioned "across any source." How is a source entered? Typed manually, pasted from a share sheet, parsed from a URL? Which of those is core to the first version?
You answer. Share sheet is core. URL parsing is nice to have. Manual typing is the fallback.
When you say "tagged by who recommended it and why," is "who" a freeform name or a reference to a contact? If it's a reference, does the app need contact permissions?
You answer. Freeform string. You don't want a contact permission prompt.
A book mentioned at work, on a podcast, and by a friend — is that one book with three sources, or three separate entries that can be linked? Which model matches how you'd actually search?
You think about it. One book, multiple sources. Dedupe at capture time by ISBN when available, by fuzzy title match otherwise.
The interview surfaces the decisions the idea implied but you never explicitly made. It does this in your surface — the same mobile app where you captured the idea — at your pace.
The consolidation
Three weeks earlier, you captured a note that said "I keep meaning to re-read things but I can't remember which books I marked as re-read candidates." Bridge flags that as related. It proposes merging: the reading-list idea is a superset of the re-read idea, and a "re-read candidate" is just a tag.
You accept the merge. The brief updates.
Another note from last month said "I want a friends-only feed where people post things they're currently excited about." Bridge flags it as potentially related but different enough to keep separate. You agree. It stays as its own brief.
At the end of consolidation, what was scattered is now structured. One brief, one owner, one set of decisions.
The specification
The brief produces artifacts.
schema.sql — a relational schema. A books table with an ISBN-nullable key, a sources table with a type enum and a freeform recommender_name column, a tags table, a join table, and an index on the fuzzy-match column. The decisions you made in the interview show up as concrete columns and constraints.
openapi.yaml — an API contract. POST /books with a share-sheet payload shape, GET /books with tag and source filters, POST /books/{id}/reread-candidate as the tag-as-action endpoint. Response shapes include the denormalized source list.
component-tree.md — a UI component hierarchy. A BookListScreen with a FilterBar, a BookRow that shows collapsed source attribution, a BookDetailScreen with the full source list, a ShareSheetIntake flow.
plan.md — a phased implementation plan. Phase 1: schema migrations and the POST/GET endpoints. Phase 2: the share-sheet intake. Phase 3: the fuzzy-match dedupe. Acceptance criteria for each phase are explicit. The things you said were "nice to have" in the interview are in a Phase 4 that may or may not ship.
What changed
At the start of this example, you had a paragraph. At the end, you have a spec a developer could implement tomorrow — or hand to a coding agent and evaluate the output against the acceptance criteria in plan.md.
Nothing about the artifacts is magical. They are what a thoughtful engineer would produce after thirty minutes of interviewing you about the idea. The shift is that the thirty minutes happened in thirty-second bursts across two days on your phone, instead of requiring you to block out a meeting and sit at a laptop.
The four phases — Capture, Interview, Consolidate, Specify — are the shape of that shift. Bridge is the surface that makes them possible in the margins of your day.
That's the whole product. The deeper rationale lives in Plans are the high-yield phase of the work.