Work Tracker Intake

Work tracker intake decides which external work items can become MergeLoom runs.

Configure the work tracker from the customer controller, then set the active intake source in Workflow.

MergeLoom intake is polling and manual sync from the customer controller. It is not an inbound webhook listener for normal customer work tracker setup.

Supported Intake Sources

Source	Typical eligibility checks
Jira	JQL match, managed label, ready status, assignment, repository routing label.
GitHub Issues	Open issue, managed label, assignment, repository routing label when needed.
GitLab Issues	Open issue, managed label, assignment, repository routing label when needed.
Azure Boards	WIQL match, tag, state mapping, assignment, repository routing tag when needed.
monday.dev	Board and status mapping, item fields, repository routing value when needed.
Linear	Team/project configuration, status, labels, assignment where available.

The default managed intake label or tag is:

mergeloom

For repository routing, use:

repo-<alias>

Assignment Enforcement

Current intake enforces assigned-user checks where the provider exposes assignment. The work item should be assigned to a MergeLoom workspace user.

If the assignee is not a workspace user, MergeLoom should deny intake, leave the item in place, and record the reason in controller-side audit.

Continuation Comments

When a completed or blocked run needs another pass, add a new comment that starts with one of the supported continuation prefixes:

MergeLoom - please also update the tests

Also supported:

MergeLoom: please also update the tests
MergeLoom -> please also update the tests

Then move the item back to the configured ready state. MergeLoom checks for a new continuation comment before creating the next attempt.

Jira

Jira intake usually uses a JQL rule plus labels and status mapping.

Example:

project = MIR AND labels = "mergeloom" AND status = "To Do" ORDER BY updated ASC

For Jira Epic campaigns, put mergeloom on the Epic. Use an Epic repo-<alias> label as the default repository for child issues, and use child repo-<alias> labels only when a child issue needs to override the Epic default.

GitHub Issues and GitLab Issues

An eligible issue should usually be:

• open
• labelled mergeloom
• labelled repo-<alias> when more than one work repository is enabled
• assigned to a MergeLoom workspace user

If the issue is skipped, check controller-side audit before changing worker settings.

Azure Boards

Configure:

• organization
• project
• intake WIQL
• ready, in-progress, review, blocked, and done states
• tag or field strategy for mergeloom and repo-<alias>

MergeLoom can post comments and move states where the connected account has permission.

monday.dev and Linear

Configure the provider-specific board, team, status, assignment, and routing fields in the controller.

Use one board or team for the first rollout. After the first PR/MR path is stable, add broader routing and more repositories.