Skip to main content

Using ProdE

ProdE is where your team's feature specs, requirements, codebase knowledge, and project tracking live — in one place. No more jumping between your tracker for tasks, your wiki for docs, your chat for context, and your codebase for truth.

It does this by understanding your codebase. When you connect your repositories, ProdE indexes your code, dependencies, and cross-repo relationships. That knowledge powers everything: answering questions about your system, generating requirements grounded in real code, and catching spec problems before engineering begins.

Understand Your Code

The same codebase knowledge that powers your feature specs is available to you directly — ask questions in Codebase Chat or from your editor via MCP.

  • Codebase Chat — ask questions about your code directly in ProdE's web interface. Great for exploring how things work, finding where features are implemented, or drafting technical documents.
  • MCP Servers — bring the same intelligence into your coding agent (Cursor, VS Code, Windsurf, Claude Code) so it can answer codebase questions and read project context while you work.

A PM scoping a new feature can ask "which services handle billing today and how do they interact with the wallet system?" and get an answer traced back to actual code — without filing a ticket or waiting for an engineer to context-switch. An engineer onboarding onto an unfamiliar service can ask "how does this service process incoming webhook events?" and get a walkthrough grounded in the real implementation, not a stale wiki page.

Plan and Ship Software

With conventional tools, a PM manually writes every ticket, every acceptance criterion, every edge case — scattered across a tracker, a wiki, and a dozen Slack threads. It's tedious, things get missed, and engineers end up asking 20 clarifying questions anyway.

Projects work differently. A PM writes a PRD with the high-level intent — the mental map of what needs to happen. ProdE then researches your codebase to understand what already exists — existing data models, API patterns, infrastructure constraints — and generates detailed requirements with concrete acceptance criteria. When it spots ambiguity, contradictions, or gaps, it raises those as blockers before engineering even begins. Things like "the spec assumes this endpoint supports batch operations, but the current implementation only handles single items" or "the PRD doesn't define what happens during partial failures in this flow."

By the time a project reaches engineering, the requirements are specific, the edge cases are surfaced, and the team isn't discovering spec gaps mid-sprint. Everything lives here — the PRD, the generated requirements, designer mockups, blocker discussions, dev status, and bugs. No context is scattered across other tools.

How the pieces fit together

  1. PM writes a PRD — ProdE researches your codebase and generates requirements organized into workstreams, each with acceptance criteria
  2. ProdE raises blockers — ambiguities, contradictions, wrong assumptions, and missing context are flagged automatically for the PM to resolve
  3. Designers attach mockups — wireframes and flows are stored as artefacts alongside the requirements they support
  4. Engineers plan and build — requirements have clear scope; your coding agent can read specs and acceptance criteria via MCP, update dev status, and file bugs without leaving the editor
  5. Everyone tracks progress — pipeline metrics show what's not started, in progress, developed, and tested across workstreams

See Your First Project to get started.

Getting Started

  1. Ask a question in Codebase Chat — try asking about a part of the codebase you didn't write to see what ProdE knows about your system
  2. Connect your repositories — if your team hasn't already, ProdE indexes your code and builds an understanding of your codebase
  3. Set up MCP in your editor — so your coding agent has codebase and project context while you work
  4. Create your first project — when you're ready to plan a feature with your team