*A Campfyrr use-case walkthrough: going from three bullet points to a spec a team can actually build from — without leaving the doc.*
Most specs don't start as specs. They start as a Slack message, a half-formed idea in a standup, or three bullet points someone typed into a doc right before a meeting. The gap between that and a one-pager a team can actually build from is usually where the most context gets lost — because turning bullets into a real plan almost always means someone opens a private chat with their agent, drafts it alone, and pastes the result back in, stripped of how they got there.
Here's what that same moment looks like in Campfyrr.
The starting point
> Priya (human), 10:02am > ## Offline mode for the mobile app > Users on flaky connections are losing form submissions. Need a plan.
Three lines. Not a spec — a problem statement. That's normal, and it's also usually where things stall until someone has the time to turn it into something a team can act on.
Asking the agent to do the first pass, in the open
Priya presses Enter on the empty line below it, and types an instruction into the command line that opens — not a chat window, the same page:
> *"Draft a one-pager: the problem, three approaches with tradeoffs, and what data we'd need to pick one."*
The agent's response streams directly into the doc, under the same heading, visible to anyone who opens it — not a separate transcript Priya would have to copy over later.
> Agent — in response to *"draft a one-pager..."* > ### Approaches > 1. Local queue + retry on reconnect. Simple, but risks duplicate submissions if a retry races an already-succeeded request. > 2. Optimistic local write, sync in background. Better UX, more edge cases around conflict resolution. > 3. Block submission until online, show a clear offline state. Simplest to build, worst UX for anyone genuinely offline for a while. > > ### Data we'd need > How many affected submissions are actually retried successfully today vs. silently lost? That number should decide between (1) and (2).
A teammate joins mid-thought, not after the fact
> Dev (human), 10:11am — joined > We already log retry attempts client-side. I can pull the actual number before we pick an approach.
Dev didn't need Priya to forward anything. The doc was already the whole conversation — the problem, the agent's draft, and now a real next step, all with names and timestamps attached.
Taking a real swing without risking the working draft
Once the data comes back, Priya wants to see what approach (2) would actually look like written out in full technical detail — without disturbing the one-pager the rest of the team is already reading.
> *"Fork this and write out approach 2 in full technical detail — API changes, storage, conflict handling."*
That opens a sandbox: an isolated copy branched from exactly this point in the doc. The agent writes the detailed version there. If it's good, Priya promotes it back over the original with one click. If it's not, she throws it away — the working one-pager the team has been reading never moved.
What this actually gets you
Every step above — the first draft, the teammate joining, the fork, the promote — happened inside one page, with nothing copy-pasted between a chat window and a document. A fourth person opening this doc that afternoon can hover any paragraph and see exactly who or what wrote it, read the reasoning behind approach 2 without asking anyone, and see that approaches 1 and 3 were considered and set aside — not silently dropped.
Where this fits and where it doesn't: this is built for the planning stage — before the IDE opens, while a team is still deciding what to build. It's not a replacement for your issue tracker once the plan is settled, and because there's no auth layer yet, it's best for fast-moving teams working on things that aren't sensitive by nature.
Open a doc — no signup — and try it on the next rough idea that lands in your inbox.
--- Synced from Campfyrr: https://ghostcursor-self.vercel.app/doc/519ea664-1 (id 519ea664-1) · last synced 2026-09-07T19:23:21.236Z