Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/paramveer-cyber/Deployaar/llms.txt

Use this file to discover all available pages before exploring further.

A Product Requirements Document (PRD) in Deployaar is the specification layer that bridges a plain-English feature request and the code an agent writes. It is not optional documentation — it is the machine-readable contract the coding agent implements against and the ground truth the AI code reviewer checks every PR against. A weak PRD produces weak code; a precise one produces code that matches intent. PRDs are generated automatically by packages/services/prd as soon as clarification is complete, but they require human approval before the pipeline proceeds.
You can edit any PRD section before approving it. The UI exposes all seven fields as editable text areas. If the generated content is imprecise or misses important context, correct it before clicking Approve — the coding agent will read whatever is in the approved PRD.

​
PRD Structure

Deployaar generates exactly seven sections for every PRD, each targeting a distinct dimension of the feature spec. All sections are stored as free-form text and versioned with the PRD record.
FieldPurpose
problemStatementA clear articulation of the problem this feature solves. Written from the user’s perspective.
goalsA bulleted list of measurable goals the feature must achieve once shipped.
nonGoalsAn explicit list of what this feature will not do. Prevents scope creep and gives the reviewer clear non-goal boundaries to enforce.
userStoriesUser stories in “As a [user], I want [goal] so that [reason]” format. Defines who benefits and how.
acceptanceCriteriaConcrete, testable conditions that must all be true for the feature to be considered done. These are the primary signal for the AI code reviewer.
edgeCasesCorner cases, error states, and failure modes the implementation must handle. Only edge cases listed here are enforced by the AI reviewer.
successMetricsHow success will be measured after the feature ships — engagement metrics, error rates, latency targets, etc.
The schema is defined in packages/services/prd/index.ts using Zod structured output and enforced during the extraction pass: 
const prdStructuredOutputSchema = z.object({
  problemStatement: z.string().describe("Clear articulation of the problem being solved"),
  goals: z.string().describe("Bulleted list of measurable goals this feature achieves"),
  nonGoals: z.string().describe("Explicit list of what this feature will NOT do"),
  userStories: z.string().describe("User stories in 'As a [user], I want [goal] so that [reason]' format"),
  acceptanceCriteria: z.string().describe("Concrete, testable criteria that must be true for the feature to be considered done"),
  edgeCases: z.string().describe("Edge cases, error states, and failure modes to handle"),
  successMetrics: z.string().describe("How success will be measured after shipping"),
});

​
How Generation Works

PRD generation is triggered by the feature-request/clarification.complete Inngest event and runs inside the onClarificationComplete workflow function. The generatePrd function in packages/services/prd orchestrates a two-pass AI call:
1

Context assembly

The service loads the feature request title, the raw description (rawRequest), and the full clarification thread from the database. The thread is formatted as a readable conversation with PM: and Requester: prefixes.
2

Raw PRD generation

A generateText call sends the context to the user’s configured AI provider with a system prompt that instructs the model to act as a senior product manager writing a production-quality spec. The output is free-form markdown prose.
3

Structured extraction

A second generateText call with Output.object({ schema: prdStructuredOutputSchema }) extracts the seven sections from the raw prose into the typed schema. This ensures every PRD has the same machine-readable structure regardless of which AI provider generated it.
4

Persistence

The structured sections are saved to the database. If a PRD record already exists for the feature request, it is updated in place (generatedAt is set). The feature request status is set to prd_pending.
The AI provider used for generation is whatever the requesting user has configured in their settings (Anthropic, OpenAI, Google Generative AI, or DeepSeek), resolved via resolveLanguageModelForUser. The clarification thread is the primary input — if clarification was skipped or thin, the PRD is generated from the original request description alone.

​
PRD Approval

PRD approval is the primary human-in-the-loop checkpoint in the Deployaar pipeline. No code is written and no engineering tasks are generated until an owner or admin explicitly approves the PRD. The approval call in packages/services/prd enforces role-based access: 
if (memberRole !== "owner" && memberRole !== "admin") {
  throw ApiError.forbidden("Only owners and admins can approve PRDs");
}
On approval:
  1. The PRD record is stamped with approvedByUserId and approvedAt.
  2. The feature request status transitions to planning.
  3. The prd/approved Inngest event fires, triggering the onPrdApproved workflow.
  4. The workflow calls generateTasks, which breaks the PRD into 5–15 ordered engineering tasks.
The onClarificationComplete workflow uses step.waitForEvent with a 30-day timeout to hold the pipeline open until the prd/approved event arrives. If no approval occurs within 30 days, the workflow exits without proceeding.

​
PRD and Code Review

Once a coding agent run produces a PR, the AI code reviewer re-reads the PRD in full before evaluating a single line of code. The reviewer is explicitly grounded in the spec:
  • Acceptance criteria are the primary signal. If all acceptance criteria are met, that is strong evidence the PR should pass.
  • Non-goals define what the reviewer may not flag as missing — if something is listed as a non-goal and the PR doesn’t implement it, that is correct behaviour.
  • Edge cases define which corner cases are mandatory. Edge cases not listed in the PRD are at most suggestions, never blocking.
The reviewer is instructed never to invent requirements beyond what the PRD explicitly states. This means editing the PRD before approval is the right place to tighten requirements — not post-hoc review comments.
Once the coding agent starts a run, modifying the PRD has no effect on that agent run. The agent reads PRD content at the start of the run and caches it in its system prompt. To apply PRD changes, you must trigger a new agent run after editing.

Build docs developers (and LLMs) love

Get started for freeTalk to us