If you landed here, you already have code — yours or inherited — and the question that brought you isn’t “how do I type faster”. It’s one of these:
- How do I give an agent the context of my repo without spending three hours explaining the architecture?
- How do I close a user story with real proof, not “the unit test passes”?
- How do I keep four agents working in parallel from clobbering each other’s context across tmux panes?
PaellaDoc solves these three by construction, not configuration. Here’s the first step.
First step: reverse-intake
- Open PaellaDoc.
- Point it at your repo from the projects screen. Any structure works: monolith, monorepo, scattered scripts.
- The reverse-intake reads your code. It detects languages, frameworks, conventions. It proposes an inferred PRD, inferred epics, and user stories that match what’s already built.
- You review, fix what doesn’t fit, and sign off. That becomes the project’s baseline.
From there each new story runs in its own worktree. Each agent works in isolation. Each close runs Playwright real against your dev server, evidence on disk.
What NOT to expect yet
- The reverse-intake doesn’t invent what it doesn’t find. If your repo has no tests, it won’t fabricate acceptance criteria — it tells you the criteria need to be written together before anything closes.
- It doesn’t translate decisions that live in Slack or in your head. If the architecture has an unwritten “why”, capture it as a decision record when you sign off the baseline.
Share here
- What the reverse-intake found in your repo (especially the surprises).
- Which story you opened first as a worktree.
- If your repo is legacy: which area scares you most to automate first. That’s usually the one that closes fastest under a gold gate.
Rule: if you share a project, include evidence — a baseline screenshot, an inferred-PRD fragment, or the exported .paella.
— @jlcases