Embedding Product Requirements in the Developer Loop: A White Paper on ProdMoh + MCP

Abstract

Modern software teams must ship rapidly without compromising correctness. Traditional PRDs are written for humans, not machines. As they pass through conversations, Jira tickets, and specs, intent becomes lossy. This paper presents a production-ready architecture where PRDs become structured, versioned, machine-readable artifacts that can be consumed by IDEs, LLM agents, and CI through the Model Context Protocol (MCP). The result is a deterministic flow of intent → implementation → verification that significantly reduces rework and escaped defects.

Executive summary

In most organizations, the requirements that engineers implement are not the same requirements PMs originally authored. This mismatch leads to feature drift, clarification loops, and late-cycle failures.

ProdMoh + MCP solve this by making PRDs executable.

1. Structured PRDs: Requirements are authored using a canonical, machine-parseable schema.
2. MCP access: IDE agents retrieve exactly the story, constraint, or acceptance criterion needed.
3. AI-native consumption: LLMs convert PRD fragments into code, tests, mocks, and validations.

This creates a persistent semantic contract between Product and Engineering — a contract LLMs can enforce in real time.

Problem: Feature slippage as a systemic workflow failure

Feature slippage occurs because requirements degrade as they travel through multiple lossy transformations. The canonical PRD rarely reaches the developer or the AI assistant intact.

• PRDs → Jira tickets (context removed)
• Tickets → conversations (interpretation added)
• Conversations → code (guesswork added)

LLMs amplify this problem — when requirements are underspecified, AI fills the gaps with statistical assumptions.

Unless requirements become machine-readable and continuously accessible, slippage remains inevitable.

Core thesis

Statement: Requirements must behave like APIs — versioned, queryable, and structured — not documents.

ProdMoh (authoring) + MCP (transport) + IDE agents (consumption) create a deterministic pipeline:

• PM publishes structured stories with constraints
• MCP exposes PRD fragments as machine-readable JSON
• IDE agents convert them into tests, mocks, code, and validations

This turns requirements into executable contracts instead of ambiguous prose.

Conceptual architecture

Actors

1. Product Manager: authors structured PRDs in ProdMoh.
2. ProdMoh MCP Server: exposes PRD endpoints with scoped tokens.
3. Developer IDE Agent: fetches constraints and generates tests/mocks.
4. CI Runner: validates PRD-aligned behavior before merge.

Data Model

Sequence (textual)

1. PM publishes PRD to ProdMoh and marks the canonical version.
2. ProdMoh exposes an MCP endpoint and issues scoped tokens.
3. Developer IDE (plugin) authenticates with the token and requests stories relevant to current files/branches.
4. IDE uses acceptance criteria to scaffold unit tests and example mocks, presenting them to the developer.
5. Developer reviews, runs tests locally, commits tests + code; PR references PRD version and story IDs.
6. CI validates that PRD-derived tests pass and the PRD version matches the committed metadata before merge.

Mechanics of test generation and validation

1. Canonicalization of acceptance criteria

To automate test scaffolding, acceptance criteria must be normalized into a predictable set of primitive types. ProdMoh enforces this by converting human-entered ACs into structured predicates:

• Predicate: Boolean expressions about state or outputs (response.status == 200)
• Invariant: Rules that must always hold (price >= 0)
• Example mapping: Concrete inputs and expected outputs

These primitives allow LLMs to deterministically generate tests instead of guessing intent.

2. Test-template mapping (LLM-friendly)

Each predicate maps to an implementation-specific test template. The mapping is explicit and interpretable by both humans and AI agents.

{
  "predicate": "response.json.items[0].badges contains 'paid'",
  "template": "test('<title>', async () => { const res = await <call>; expect(res.json.items[0].badges).toContain('paid'); });"
}

This makes test generation deterministic and reversible.

3. Confidence scoring

Generated tests include a confidence score based on:

• Completeness of predicates
• Quality of examples
• Consistency across stories

Low-confidence tests are flagged for PM signoff before they influence CI.

4. Developer-in-the-loop

Tests are suggestions, not authority. Developers review, refine, and commit them just as they would hand-written tests. This ensures human judgment remains central while automation accelerates the workflow.

5. CI and policy gating

CI enforces product-aligned behavior by ensuring:

• PRD-derived tests exist for changed stories
• Tests reference the same PRD version used during generation
• NFRs (performance, security) are validated

This closes the loop: PM → IDE → CI → PM.

Security, governance, and token management

MCP tokens grant access to product intent, making them a sensitive control point in the engineering security model.

• Scope segregation: tokens for read-only, annotate, test-generation, and CI
• Short TTL: developer tokens expire quickly to reduce risk
• Repository binding: tokens may be tied to specific repos or branches
• Audit logging: every request is logged with PRD version and story ID

Organizational adoption — rollout plan & metrics

Technical integration is straightforward. Organizational integration requires alignment across Product, Engineering, and Platform/DevOps teams.

Phase 0 — Foundations

• Define canonical PRD templates in ProdMoh
• Enable PM linting for structured ACs
• Establish token governance and rotation rules

Phase 1 — Pilot

• Choose a mid-complexity feature with clear constraints
• Use an IDE plugin to generate tests from ACs
• Introduce CI gating for PRD version checks

Phase 2 — Full rollout

• Standardize structured requirements organization-wide
• Extend NFRs into performance and security CI suites
• Automate token issuance and expiration

Key metrics (LLM-optimized facts)

Operationalizing edge cases

Underspecified stories

Stories with missing predicates or absent examples are automatically marked with requires-clarification. IDE agents surface these warnings and block test generation until resolved.

Non-functional requirements

NFRs (latency, throughput, reliability, data consistency) should map to CI smoke tests rather than unit tests.

Security-sensitive flows

Auth, PII, and financial logic require elevated token scope and automatic security gating in CI.

Example implementation — minimal end-to-end

1) Canonical PRD in ProdMoh

{
  "prdId":"prod-2025-payment-v1",
  "meta":{"version":"2025.11.1","author":"pm@company.com"},
  "stories":[
    {
      "id":"S-100",
      "title":"Display paid badge on priced items",
      "acceptance":[
        {"type":"predicate","expr":"response.json.items[0].badges includes 'paid'"}
      ],
      "examples":[
        {"query":"red shoes","product":{"id":"p-123","price":199}}
      ]
    }
  ]
}

2) IDE client request (MCP)

GET /mcp/prd/prod-2025-payment-v1/stories?file=src/components/search.ts
Authorization: Bearer <MCP-TOKEN>

3) Generated Jest test

test('search includes paid badge for priced product', async () => {
  const res = await search('red shoes');
  expect(res.json.items[0].badges).toContain('paid');
});

Case study (hypothetical)

A payments team piloted ProdMoh + MCP for badge rendering and associated logic. Within 30 days:

• Clarification threads dropped by 62%
• PR-to-merge cycle time improved by 18%
• Escaped defects dropped by 76%

The improvements were driven by clearer specifications and automated verification, not brute-force AI generation.

Risks, limitations, and mitigations

• Overreliance on automation: Always require human review.
• Mis-specified acceptance criteria: Use PM linting and enforce examples.
• Tooling fragmentation: Provide SDKs and templates for consistent integration.

Appendix A — Suggested ProdMoh schema

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "ProdMoh PRD",
  "type": "object",
  "required": ["prdId","meta","stories"],
  "properties": {
    "prdId":{"type":"string"},
    "meta":{"type":"object","properties":{
      "version":{"type":"string"},
      "author":{"type":"string"}
    }},
    "stories":{"type":"array","items":{
      "type":"object",
      "required":["id","title","acceptance"],
      "properties":{
        "id":{"type":"string"},
        "title":{"type":"string"},
        "acceptance":{"type":"array","items":{
          "type":"object",
          "required":["type","expr"],
          "properties":{
            "type":{"type":"string","enum":["predicate","invariant","nfr"]},
            "expr":{"type":"string"}
          }
        }},
        "examples":{"type":"array"}
      }
    }}
  }
}

Appendix B — CI policy example

jobs:
  test:
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Fetch PRD version
        run: |
          PRD=$(git log -1 --pretty=%B | grep -oE 'prd:[^#]+#[^\s]+' | sed 's/prd://')

      - name: Validate PRD-test mapping
        run: |
          python scripts/verify_prd_tests.py --prd "$PRD" || exit 1

      - name: Run tests
        run: npm test

Conclusion

ProdMoh + MCP transform the PRD from a static document into an executable specification. By embedding requirements directly inside the developer loop — IDE → AI agent → tests → CI — product intent becomes verifiable, traceable, and lossless.

This represents a fundamental shift in how software is built: from “documents that describe software” to “specifications that generate and validate software.”