Tracker Integrations
Works with your existing tracker
Planwright doesn't build custom integrations for project trackers. It doesn't need to. When both the Planwright MCP and your tracker's MCP are available in the same agent session, your agent — Claude Code, Cursor, Codex, or any MCP-capable coding tool — bridges them: it reads from your tracker, creates objectives, and syncs status back. No custom connectors, no API keys in Planwright, no sync infrastructure to maintain.
Any tracker with an MCP server works the same way. The pattern is identical whether you're importing a Jira epic, a Linear feature, a GitHub issue, or an Azure DevOps work item.
Trackers with MCP servers
Jira
Official — AtlassianMost common enterprise tracker. The primary example used in this guide.
Linear
CommunityPopular with product engineering teams. Works identically to the Jira pattern.
GitHub Issues
Official — GitHubAlready available if you use the GitHub integration. No additional MCP setup needed.
Azure DevOps
CommunityEnterprise teams in the Microsoft ecosystem. Same import and sync pattern.
Asana
CommunityCommon in cross-functional teams. Works with any agent that has read and comment access.
Shortcut
CommunityDeveloper-focused tracker used by smaller engineering teams.
Official MCPs are maintained by the tracker vendor. Community MCPs are open-source. Both work identically — your agent doesn't distinguish between them.
How it works
Agent-mediatedYour agent is the integration layer — not a background service.
Both MCPs run inside the same agent session. Your agent reads the work item directly from your tracker, creates Planwright objectives tagged with a label encoding the source item, posts a filtered board link back to the tracker, and begins executing. Tracker stakeholders can click the board link to see objective status scoped to their work item — no Planwright account required.
Status flows back to the tracker on request: ask your agent to sync, and it reads the current lane of every objective tagged with that item's label and posts a structured comment. When all objectives reach done, your agent notifies the tracker and asks before transitioning the work item to closed — it never closes tracker items automatically.
The workflow
Jira shown as exampleThe same four steps apply to any tracker.
Import
Tell your agent to import a tracker item: "Import EPIC-42 from Jira and start working on it." Your agent reads the item, decomposes it into objectives tagged JIRA:EPIC-42, and posts a filtered board link back to the tracker. Your team sees a Planwright board scoped to that epic — no board clutter from unrelated objectives.
Execute
Your agent claims the first scheduled objective and executes the normal Planwright workflow: decompose, commit, request acceptance. Each objective moves through the lanes independently. The tracker item stays open in Jira while work progresses in Planwright.
Sync
When you want a tracker update: "Sync EPIC-42 status to Jira." Your agent reads the current lane of every objective tagged JIRA:EPIC-42 and posts a structured status comment — how many are done, in progress, and queued, with the board link. Sync is on request, not continuous.
Close
When all objectives reach done, your agent posts a completion notice and asks before transitioning the tracker item to closed. Tracker items often carry business sign-off beyond code completion — the agent never closes them without explicit confirmation.
How it works across all trackers
These principles apply regardless of which tracker you use.
Tracker items are not objectives
When your agent imports a work item, it reads the title, description, and acceptance criteria as context for decomposition — not as a list of objectives to import one-to-one. The agent derives its own objectives from the intent. If you import tracker tickets as objectives, you let human-written task breakdowns drive agent execution, which defeats the point. Breakdown is the agent's job.
Labels link tracker items to objectives
Every objective created from a tracker item is tagged with a label that encodes the source: JIRA:EPIC-42, LINEAR:FEAT-123, ADO:WORK-ITEM-789. The Planwright board accepts a label filter, so the filtered board URL (scoped to one tracker item's objectives) can be posted back to the tracker — stakeholders see Planwright status without needing a Planwright account.
No background sync
There is no server-to-server connection between Planwright and any tracker. Status flows back whenever the agent works on the objective — not on a schedule, not via webhooks. Every tracker comment is a deliberate checkpoint. This keeps the integration explicit and auditable rather than noisy and automatic.
No tracker admin access required
The integration uses your own credentials via the tracker's MCP. No app installations, no service accounts, no webhook configuration in Planwright. The only permission needed is the ability to read work items and post comments — standard for any team member.