> For the complete documentation index, see llms.txt.
Skip to main content

Check out Port for yourself ➜ 

Set up a PRD agent for ticket triage

Most tickets arrive too thin to hand to a coding agent: a title, maybe a sentence. This guide sets up a PRD agent, a PM agent that runs a PRD skill, to close that gap and decide what happens next.

From thin ticket to routed workA thin ticket goes through a PRD agent that runs the generate-prd skill, producing a full PRD. A routing scorecard then checks the ticket and routes it to a human reviewer or hands it to an AI coding agent.Thin ticketTitle only, no contextPRD agentRuns the generate-prd skillFull PRDProblem, scope, open questionsRouting scorecardChecks priority, owner, confidenceNeeds humanReviewer approves or sends backReady for AI agentHand off to a coding agent

In under 15 minutes you get:

  • A PRD agent that rewrites thin ticket descriptions into a spec (problem statement, success criteria, scope, constraints) and flags what it can't fill in.
  • A scorecard that routes each ticket to a human or an AI coding agent, based on rules you control.
  • One clear point where a human approves a suggestion or sends it back with feedback.

Every step below uses concrete identifiers and complete JSON, so you, or a coding agent working on your behalf, can implement this directly in your own Port organization without guesswork.

Once a ticket is routed, hand it off to a coding agent using the Automatically resolve tickets with coding agents guide.

Want to follow the guide step by step? Scroll down to Build the flow.

Or implement it in one shot with your coding assistantCursorClaude CodeGitHub Copilot

Connect Port MCP to Cursor, Claude Code, or GitHub Copilot, then copy the prompt below to implement this entire guide automatically against your Port account.

I want to set up a PRD agent for ticket triage in Port: a PM agent that runs a PRD skill to turn thin tickets into a full spec, plus a scorecard that routes each ticket to an AI coding agent or a human.

Here is what I need you to do, step by step:

1. Ask me which blueprint represents my tickets (for example jiraIssue or linearIssue) if you don't already know, and use that blueprint identifier everywhere below instead of <TICKET_BLUEPRINT>. Also ask which property represents ticket ownership (for example assignee).

2. Create the `skill` blueprint if it doesn't already exist in my organization (see Port's Skills docs), then create a skill entity with identifier "generate-prd", title "Generate PRD", and instructions that make an agent gather context from the ticket's linked service, repository, team, and owner relations (noting any missing relation as an open question instead of guessing), then produce a PRD in markdown with Problem Statement, Success Criteria, Out of Scope, Dependencies, and Open Questions sections.

3. Extend my ticket blueprint with these properties:
   - spec_stage (string, enum: Not started, Draft, Awaiting approval, Approved, default Not started)
   - confidence_score (number, 0-100)
   - ai_suggested_description (string, markdown)
   - prioritized (boolean)

4. Create a scorecard called "ticket_routing_readiness" on my ticket blueprint with two rules:
   - level "Triaged" when prioritized = true and the ownership property is not empty
   - level "Ready for AI agent" when prioritized = true, the ownership property is not empty, spec_stage = Approved, and confidence_score >= 90
   Levels, in order: "Not triaged" (red, default), "Triaged" (yellow), "Ready for AI agent" (green).

5. Create a Port workflow titled "Triage ticket with PRD agent" with these nodes in sequence:
   - trigger (EVENT_TRIGGER): fires on ENTITY_CREATED for my ticket blueprint.
   - run_prd_skill (AI): loads the generate-prd skill with the load_skill tool, gathers context from linked entities, and returns spec_stage, confidence_score, and ai_suggested_description as JSON.
   - write_suggestion (UPSERT_ENTITY): mapping.identifier is `{{ .outputs.trigger.diff.after.identifier }}`. mapping.properties writes spec_stage, confidence_score, and ai_suggested_description, each as its own `{{ .outputs.run_prd_skill.response | fromjson | .<field> }}` template, for example `"confidence_score": "{{ (.outputs.run_prd_skill.response | fromjson | .confidence_score) | tonumber }}"`.
   - human_review (INPUT): pauses with an Approve / Send back for more detail decision and a feedback notes field (give it the identifier `notes`), notifying a reviewer email I provide.
   - approve_ticket (UPSERT_ENTITY): on the approve outlet, sets spec_stage to the plain string "Approved" and confidence_score to the plain number 100. These are static literals, they do not need `{{ }}`.
   - revise_with_feedback (AI): on the send_back outlet, reruns the generate-prd skill, incorporating the reviewer's feedback read from `{{ .outputs.human_review.responses[0].inputs.notes }}`.
   - write_revised_suggestion (UPSERT_ENTITY): same templating rule as write_suggestion, reading from revise_with_feedback's response instead of run_prd_skill's.

   Three rules that must hold across every UPSERT_ENTITY mapping in this workflow: (1) every dynamic value, including `identifier`, must be wrapped in `{{ }}`. A bare JQ path with no `{{ }}` is stored as a literal string, which fails validation on the number property and silently corrupts the string properties instead of working. (2) An INPUT node's submitted values live under `.outputs.<node_id>.responses[0].inputs.<field>`, never a flat `.outputs.<node_id>.<field>` path. (3) Always wrap an AI-extracted confidence_score in `tonumber`, for example `(.outputs.run_prd_skill.response | fromjson | .confidence_score) | tonumber`. The AI's structured output can come back as a quoted numeric string even when the schema says "number", and `fromjson` alone does not fix that.

6. If I don't have a live ticket integration connected yet, create a `mockWorkItem` entity on my ticket blueprint instead, with title "Add search to the storefront" and description "Users can't search for products on the website", leave prioritized and the ownership property empty. Use it to test the workflow end to end before I connect a real integration.

7. Use the Port MCP server's tools to create each artifact directly in my organization, and confirm each step with me before moving to the next.

Reference guide: https://docs.port.io/guides/all/setup-prd-agent-for-ticket-triage

Common use cases​

  • Turn a one-line ticket into a spec a coding agent can actually execute against.
  • Route deterministically instead of relying on a gut call for which tickets are safe to delegate.
  • Give a human one clear control point: approve the PRD agent's suggestion, or send it back with notes.

Prerequisites​

This guide assumes the following:

  • You have a Port account and have completed the onboarding process.
  • One ticket, issue, or work item integration is installed, for example Jira, Linear, GitHub issues, GitLab issues, or Azure DevOps work items.
  • The skill blueprint is installed in your organization. See Step 1 of the Skills guide if you need to create it first.
  • For the Workflow option: you have access to workflows in Port. Workflows are currently in open beta and available to all users.
No integration connected yet?

You don't need a live Jira, Linear, or other integration to try this guide. Create a mockWorkItem entity directly on your ticket blueprint instead, it triggers the same flow as a real synced ticket. See Create a test ticket for exact steps.

Before you start, decide​

This guide uses placeholders so it works with any ticket source. Decide these values up front, then substitute them everywhere they appear:

PlaceholderSet it to
<TICKET_BLUEPRINT>Your ticket blueprint identifier, for example jiraIssue or linearIssue.
assigneeWhatever property your integration uses to represent ownership.
90The minimum confidence score (0-100) your team accepts before routing a ticket to an AI agent.

Build the flow​

Test the flow​

Now let's verify that a new ticket gets triaged and routed correctly.

Create a test ticket​

  1. Create a new ticket in your ticket source with minimal information, for example:
    • Title: "Add search to the storefront".
    • Description: "Users can't search for products on the website".
Test without connecting an integration

Skip the integration and create a mockWorkItem entity directly on your <TICKET_BLUEPRINT> blueprint instead:

  1. Go to your catalog page and open your ticket blueprint.
  2. Click + Entity.
  3. Set the identifier to mockWorkItem, the title to "Add search to the storefront", and the description to "Users can't search for products on the website".
  4. Click Create.

Creating this entity fires the same ENTITY_CREATED event a real synced ticket would, so the rest of the flow (PRD agent, scorecard, review) behaves identically. Delete mockWorkItem once you're ready to test against real tickets.

Verify the PRD agent ran​

  1. Go to your Port catalog and find the synced ticket.
  2. Check that confidence_score and spec_stage were filled in, and that ai_suggested_description holds a full PRD (problem statement, success criteria, out of scope, dependencies, open questions).
  3. Check the ticket_routing_readiness scorecard. Without a priority and assignee set, it should read Not triaged.

Verify routing​

  1. Set the ticket's priority and assignee. The scorecard should move to Triaged.
  2. Approve the suggestion:
    • Workflow: open the workflow run, click Provide inputs on the human_review node, and press Approve.
    • Actions & automations: run the review_prd_agent_output action and choose Approve.
  3. Check that the scorecard moves to Ready for AI agent, and that spec_stage is now Approved.
  4. Repeat on a different ticket, but send it back with a note instead (Send back for more detail on the input node, or the same choice in the review_prd_agent_output action). Check that the PRD agent regenerates ai_suggested_description and keeps spec_stage as Draft.