Building with Your Coding Agent

When the spec lives in one tool, the code in another, and your understanding of the codebase in your head, a coding agent has to guess at the parts it cannot see. ProdE's MCP server feeds both your project context and your codebase understanding straight into your editor, so the agent reads requirements, acceptance criteria, and the engineering plan directly. You can also point it at a project to check status or review work against the spec, for example "check project 7, what is done and what is remaining" or "check project 7, review the code changes against the requirements and tell me if every acceptance criterion is met."

This guide assumes the planning is done (see New Feature Development) and ProdE's MCP server is connected. If it is not, set it up for Cursor, GitHub Copilot (VS Code), Windsurf, or Claude Code.

What Your Agent Gets

In its default Knowledge + Projects mode, ProdE's MCP server gives your agent two sets of tools:

Together, your agent knows both what to build and how your codebase actually works. (If you do not use Projects, the Knowledge only mode gives just the first set.)

Step 1: Pull the Requirement Into Context

Instead of pasting a ticket, point your agent at the requirement by its ID. Using the Projects tools it reads the full spec: description, acceptance criteria, the engineering plan, and any blocker resolutions or design decisions tied to it.

• "Read REQ-5 from the checkout project and summarize what I am building and the acceptance criteria."
• "Pull the engineering plan for this workstream and tell me which files it says to change."
• "Check the checkout project, what is done and what is remaining?"

This means when you say "implement REQ-5," the agent already knows what REQ-5 is and what done looks like.

Step 2: Ground the Work in Your Real Codebase

Before writing code, have the agent confirm how the relevant area actually works, using the Knowledge tools. This keeps the implementation consistent with your existing patterns instead of inventing new ones.

• "Find where we currently handle OAuth callbacks and follow the same pattern."
• "Show me the existing data model for users and any migrations that touch it."
• "Find all usages of validateToken so the change stays consistent."

Step 3: Implement

Now ask the agent to build it. Because it has the acceptance criteria, the engineering plan, and a real understanding of your conventions, the code it produces lands much closer to what you want on the first pass.

• "Implement REQ-5 following the engineering plan and the patterns you found. Cover every acceptance criterion."

Step 4: Update Dev Status as You Go

Keep the project current without leaving your editor. The Projects tools let the agent move each requirement through its dev status:

Not Started  →  Planned  →  Developed  →  Tested

• "Mark REQ-5 as developed."

Updating status from the IDE is what keeps the pipeline metrics accurate for everyone tracking delivery, without anyone doing manual bookkeeping.

Step 5: Keep the Spec True as You Build

When the implementation makes you change a call or surface a gap, record it where the rest of the team will see it, rather than letting it live only in your head or the diff. The agent can log a decision, update a requirement's acceptance criteria, or edit a project document directly.

• "Log a decision: we will reject unsupported currencies rather than defaulting to USD, because the payments service does not store the original currency."
• "Update REQ-7's acceptance criteria to cover the case where the user denies OAuth permission."

Decisions and requirement changes are visible alongside the rest of the project, so the plan stays current as the implementation evolves. See Workstreams and Requirements.

A Typical Loop

Putting it together, a single requirement usually looks like this:

1. Read the requirement and its acceptance criteria (Projects tools).
2. Research the relevant code and patterns (Knowledge tools).
3. Implement against the engineering plan.
4. Mark the requirement developed (Projects tools).
5. Record any decisions or spec changes you made along the way (Projects tools).

Then move to the next requirement. The agent never loses the thread, because the context lives in ProdE rather than in the conversation.

Related: For the planning that produces these specs, see New Feature Development. To monitor the pipeline as work lands, see Guide: Tracking Delivery.