[feature]: First-class development artifacts for work items: commits, pull requests, and merge requests

Is there an existing issue for this?

• I have searched the existing issues

Related issues and context:

• #2508 asks for linking Git commits to issues.
• #9048 proposes moving integration-triggered actions into the automation engine.
• #9056 covers a narrower GitHub case where issues referenced by an open PR do not trigger state mapping.
• #8088 asks for GitLab integration parity with GitHub.
• #6611 asks for creating GitHub branches from work items.
• #8906 asks to expose integration and repo mapping through public REST APIs.

Summary

Plane should treat development activity from GitHub and GitLab as first-class development artifacts on work items, without turning pull requests, merge requests, or commits into new work item types.

The core model would be:

• A work item can have linked development artifacts: commits, GitHub pull requests, and GitLab merge requests.
• GitHub and GitLab integrations normalize incoming SCM events.
• Plane Automations consume those normalized events to update work item state, add comments, send notifications, and create backlinks.
• GitHub and GitLab share the same conceptual artifact/event model so GitLab parity is not implemented as a separate one-off path.

This is similar to how Linear and Jira surface development activity inside an issue: PRs/MRs are not issues themselves, but they are visible and actionable development signals attached to the issue.

Why should this be worked on?

Plane already has strong integration foundations, including GitHub/GitLab connections, issue sync, repository/project mapping, and PR/MR state automation direction. The missing piece is a coherent work-item-level development artifact surface and event model.

For product and engineering teams, this would unlock these workflows:

• See linked PRs/MRs/commits directly on the work item detail page.
• Know review state at a glance: review requested, approved, changes requested.
• Know merge readiness at a glance: draft, open, ready for merge, merged, closed.
• Follow branch-specific automation rules when a PR/MR references a work item.
• Trigger work item state transitions from SCM lifecycle events through Plane Automations.
• Keep a backlink comment on GitHub/GitLab so engineers can navigate both ways.
• Avoid duplicate links/comments when the same webhook is delivered more than once.
• Give GitHub and GitLab users the same mental model and API surface.

Suggested product behavior

A work item should be able to display linked development artifacts with fields such as:

• source: github or gitlab
• artifact_type: pull_request, merge_request, or commit
• external_id
• url
• state
• review_state
• merge_state
• head_branch
• base_branch

Artifacts should be associated through common reference mechanisms:

• branch name
• PR/MR title
• PR/MR description
• commit message
• magic words or bracketed work item keys, where appropriate

For example:

• [WEB-344] in a PR/MR title links the artifact and can trigger state automation.
• WEB-345 without automation syntax can still create a link/reference without moving state.

Suggested implementation split

This does not need to land as one large change. A safer split would be:

1. Minimal data/API layer

   • Reuse IssueLink metadata if that is the preferred lightweight path, or add a small development artifact metadata model.
   • Make the representation provider-neutral so GitHub PRs and GitLab MRs use the same shape.

2. GitHub MVP

   • Create/update a linked artifact when GitHub webhooks or integration events reference a work item.
   • Show the PR link and lifecycle/review state on the work item detail page.
   • Keep webhook handling idempotent.

3. Automation integration

   • Emit normalized events such as pr.opened, pr.review_requested, pr.ready_for_merge, pr.merged, and pr.closed.
   • Let Plane Automations decide state transitions, comments, and notifications instead of hardcoding transitions inside the integration.

4. GitLab parity

   • Reuse the same artifact/event model for GitLab merge requests.
   • Emit mr.opened, mr.review_requested, mr.ready_for_merge, mr.merged, and mr.closed events.

Acceptance criteria

• A PR/MR linked to a work item is visible from the work item detail page.
• PR/MR state changes update the linked artifact state.
• Review requested, approved, and changes requested states can be recorded.
• Merge events can trigger Plane Automation state transitions.
• The same PR/MR webhook delivered multiple times does not create duplicate links or duplicate comments.
• GitHub and GitLab use the same conceptual model.
• PRs/MRs/commits remain development artifacts attached to work items, not separate work item types.

Non-goals

• Do not introduce pull requests or merge requests as Plane work item types.
• Do not hardcode provider-specific state movement inside integrations when the automation engine can own the action.
• Do not make GitHub and GitLab diverge into separate product models.

Begin with the existing IssueLink metadata path, GitHub/GitLab integration webhook events, Plane Automations, and the work item detail page. Compare the GitHub MVP and GitLab parity requirements against the acceptance criteria, including shared artifact representation and idempotent repeated webhook handling. Done means linked artifacts are visible, state and review changes are recorded, automation events work, and duplicate links/comments are avoided without creating new work item types.