Ticket preparation
Most work items start with a title and maybe a service relation. Whether the ticket comes from Jira, Azure DevOps, Linear, or any other system, "work item" is Port's term for the unit of work that needs resolution. That thin starting point is not enough for a human to start safely. It is definitely not enough for an AI agent.
The ticket preparation phase closes that gap. It takes a work item from any source, assembles the context needed to act on it, evaluates whether the work is suitable for AI delegation, and delivers a routing decision with supporting documentation - before a single line of code is written.
What ATR produces
| Before ATR | After ticket prep | |
|---|---|---|
| Description | "Fix login bug" | PRD with user impact, scope, and acceptance criteria |
| Service context | None | T2 service, 3 downstream dependencies, no active incidents |
| Blast radius | Unknown | Low |
| Routing decision | - | AI READY: delegate to Claude Code |
The ticket didn't change. The context did.
The problem
AI coding tools have improved. Claude Code, GitHub Copilot, and similar agents can implement well-specified tasks reliably. The bottleneck in software delivery has shifted upstream.
It now sits in the work before and around coding: understanding what the ticket is really asking for, assembling context from multiple systems, writing a PRD, drafting a tech spec, and deciding whether the work is safe for an agent to touch. Each of these steps happens manually today. Each one adds delay, and quality depends on who happens to be doing it.
The workflow
The ticket prep workflow runs as a Port workflow, triggered automatically when a ticket is created or manually from the Self-Service Hub. It executes five steps and delivers a decision:
- Context lake query - Port pulls service metadata, repository structure, team ownership, service tier, and blast radius from your software catalog. No manual research required.
- PRD generation - Port AI generates a product requirement document using a team-defined skill, enriched with relevant previous PRDs via Notion.
- Tech spec - Port AI produces an implementation plan, drawing on code patterns from GitHub and previous specs from Notion.
- Routing decision - Two layers evaluate whether the work is AI-ready:
- Deterministic scorecards check service tier, blast radius, active incidents, and priority. Your platform team defines the rules.
- AI narrative assessment provides a written explanation of the routing decision, grounded in the PRD and tech spec.
- Slack notification - The engineer receives the work item name, PRD link, tech spec link, service link, origin ticket link, routing decision, and three action buttons: Delegate to Claude Code, Iterate on PRD, Continue in IDE.
The work item entity in Port serves as the persistent source of truth. It holds the PRD, tech spec, blast radius score, and routing scorecard - independent of the Slack message.
Implementation guides
- Work item blueprint pattern - the entity model that this workflow is built on.
- The work item blueprint implementation guide - technical setup including blueprints, relations, and scorecards.
- Enrich tasks with AI-powered context - context assembly for any ticket type.
- Improve specifications with Port AI - AI triage and spec generation.
- Automatically resolve tickets with coding agents - full delegation to Claude Code or GitHub Copilot.
- Automatically resolve tickets with n8n and Port context - Port as context lake in an n8n workflow.
- Auto-fix services when scorecards degrade - detect scorecard degradation and delegate the fix to a coding agent.