Workflow · Essential
Seed Outlain with the current state of your project
The fastest way to make every spec Outlain writes feel like it was written by someone who actually works on your codebase.
The problem
Out of the box, Outlain only knows what you upload. Without project context, a generated spec is grounded in your customer research but floats in implementation space - it can't reference your actual architecture, your stack, your conventions, or the features you already shipped.
The fix
Give Outlain a one-time internal summary of the project alongside the research transcripts. Every spec it writes from then on knows the lay of the land.
Generate a technical + architectural summary of the project
Use an AI coding agent that can read your codebase to produce a dense internal summary. We use Claude Code, but Cursor, Codex, Copilot Workspace, or any similar agent works. Point it at the repo root and ask for:
- Tech stack (languages, frameworks, key libraries)
- High-level architecture and module boundaries
- Core data models and their relationships
- Main user flows and the code paths that drive them
- Deployment target, environments, and any CI specifics
- Known constraints, tech debt, and non-goals
Keep it to a few thousand tokens. A shorter, denser summary beats a long walk through every file. Aim for the kind of document you'd hand a senior engineer on day one.
Upload the summary AND your transcripts to the project
Open the project in Outlain, go to the Documents tab, and upload both:
- The internal summary you just generated (plain text or Markdown).
- Any customer interview transcripts or research notes relevant to the features you want to build next.
Both live in the same project so Outlain can pull from either when generating a spec. The summary tells it what already exists, the transcripts tell it what users need.
Generate specs as usual
From here on, every spec Outlain generates in this project grounds itself in both the research you uploaded AND the project summary. You'll notice:
- Tasks reference real files, services, and data models.
- Non-functional requirements inherit the constraints you described.
- Out-of-scope items are genuinely out of scope - not “we didn't think of them.”
- The spec's scope fits your actual architecture, instead of assuming a greenfield project.
Refresh the summary whenever the codebase drifts
The summary ages. When you ship a meaningful architectural change (new service, new data model, major refactor), regenerate it and re-upload. Delete the old one to avoid drift - Outlain will use whatever it finds in the project, and two contradictory summaries will confuse every spec that follows.
In practice this means ~once a month for active projects.
Why this works
Outlain is a retrieval-augmented system. Every spec generation pulls the most relevant chunks from your uploaded documents and hands them to the writer model. When the summary is in the project, the chunks that get retrieved include both what users said and what the system looks like. The writer can't hallucinate an architecture when the real one is sitting in context.