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.

Feature requests are the single entry point to the Deployaar pipeline. Every automated action — PRD generation, task breakdown, coding agent execution, and PR review — originates from a feature request. Submitting a request is as simple as writing a title and a description in plain English; Deployaar takes care of everything else from there.
Plan limits: Free organizations may have up to 3 feature requests total. Pro plans allow 25, and Pro Max allows 100. Attempting to create a request beyond the limit returns an error. Limits are enforced per organization, not per project.

​
Lifecycle States

A feature request moves through a well-defined sequence of states from submission to shipment. Each transition is either triggered automatically by the pipeline or requires explicit human action.
1

clarifying (initial state)

The request is created with status clarifying and immediately enters the clarification gate. The AI asks targeted questions to fill gaps before spec generation begins.
2

clarifying → prd_pending

Clarification is marked complete (either by the user or automatically when the AI determines no more questions are needed). The feature-request/clarification.complete Inngest event fires and PRD generation begins immediately.
3

prd_pending → planning

A human owner or admin approves the generated PRD. The prd/approved Inngest event fires and engineering tasks are generated.
4

planning → in_development

Engineering tasks have been generated and the coding agent has been assigned. The agent is actively working inside the E2B sandbox.
5

in_development → in_review

The coding agent has pushed a branch and opened a GitHub PR. The AI review workflow runs automatically. When the review returns a passed verdict (zero blocking issues), the status advances to in_review. If the review finds blocking issues, it transitions to fix_needed instead.
6

in_review → fix_needed (or approved)

If the AI review returns needs_work, the status becomes fix_needed. A human owner or admin can approve the release once the review passes, moving it to approved.
7

approved → shipped

An owner or admin calls the ship action. Deployaar merges the PR on GitHub using a squash merge and marks the request as shipped.
The full set of valid status values, as defined in the tRPC models, is:
StatusMeaning
clarifyingAwaiting clarification questions and answers
prd_pendingPRD generated, awaiting human approval
planningPRD approved, tasks being generated
in_developmentCoding agent assigned and running
in_reviewPR opened, AI review triggered
fix_neededAI review returned blocking issues
approvedHuman approved the PR for merging
shippedPR merged; feature delivered
rejectedFeature request manually rejected

​
Clarification Gate

Before any AI specification work begins, every new feature request passes through the clarification service (packages/services/clarification). The AI acts as a senior product manager and identifies the single most important piece of missing information at a time. The clarification service also applies two implicit filters:
  • Duplicate detection — the AI checks whether the title and description overlap significantly with recent feature requests in the same project. Near-duplicates are rejected with a clear message rather than silently creating a second, conflicting spec.
  • Educational question filter — requests phrased as learning questions (“how do I add a button?”, “what is React?”) rather than actionable feature requests are rejected. Deployaar is a delivery pipeline, not a Q&A system.
The AI asks at most one question per round. When it determines the thread already contains enough context to write a high-quality PRD — covering user stories, acceptance criteria, edge cases, and success metrics — it returns null for the next question, signalling that clarification is complete.

​
Creating a Feature Request

1

Navigate to the dashboard

Sign in and go to /dashboard/feature-requests.
2

Select a project

Choose the project you want to add the request to. The project must have a linked GitHub repository — if none is linked, the creation call returns an error.
3

Click New Feature Request

Open the creation form.
4

Enter a title and description

The title must be between 5 and 200 characters. The description (rawRequest) must be at least 10 characters. Write in plain English — no technical spec required.
5

Submit

Deployaar creates the record with source: "manual" and status clarifying, then immediately begins the clarification question flow.
Feature requests can also be created automatically from GitHub Issues. When a GitHub issue with a routable action (opened or edited) is received on a connected repository, the github/issue.received Inngest event fires and createFromGithubIssue creates the request with source: "feature_request_issue". Duplicate issues are deduplicated by (repoId, issueNumber).

​
Clarification Chat

The clarification thread is a persistent back-and-forth between the AI and the feature requester. Each message is stored with a role of either ai or user and a createdAt timestamp. The thread is not discarded after clarification ends. It is carried forward as the primary source of intent for both PRD generation and the coding agent’s system prompt. When the AI writes the PRD, it reads the full thread alongside the original title and description. When the coding agent begins work, the thread is injected directly into its system prompt under the heading “Clarification Thread (primary source of intent)”. This means the quality and specificity of answers in the clarification chat directly determines the quality of the generated code.

​
Approving the PRD

Before the coding agent can run, a PRD must exist and must have been approved by an owner or admin. The approvePrd function enforces this: 
// packages/services/coding-agent/index.ts
if (!prd.approvedAt) {
  throw ApiError.badRequest("PRD must be approved before assigning tasks to the coding agent");
}
Approval transitions the feature request from prd_pending to planning, fires the prd/approved Inngest event, and triggers engineering task generation. Only users with the owner or admin role in the organization can approve PRDs — member role is not sufficient.

Build docs developers (and LLMs) love

Get started for freeTalk to us