Ticket to code change
Create an automation that turns implementation-ready tickets into tested pull requests or merge requests.
Information to collect
Ask the user for:
- The issue tracker: Jira Cloud or Linear.
- The source-control provider: GitHub, GitLab, or Bitbucket Cloud.
- The project or team to watch and the label or workflow state that means "implementation ready".
- How a ticket identifies its target repository and base branch.
- The polling schedule or issue event to use.
- The ticket state to set when work starts and when the change request opens.
- Whether linked dependencies must be completed before dispatch.
Setup workflow
- Verify that both required integrations are connected and can read the selected project and repository.
- Prefer an issue event trigger when the deployment can receive events; otherwise use cron polling with durable issue-ID deduplication.
- Limit each run to a small configurable number of new tickets. On initial deployment, establish a baseline instead of dispatching the entire backlog.
- Build a prompt that includes the full ticket, acceptance criteria, dependency status, repository, base branch, and provider-specific request terminology. Require the agent to run the repository's tests before opening the pull request or merge request.
- Create the automation through the Automation backend described in
<RUNTIME_SERVICES>. Use its prompt-preset endpoint and authenticate with the runtime-provided automation API key. - Configure the automation to post the OpenHands conversation URL immediately and the resulting pull-request or merge-request URL back to the ticket.
Do not dispatch tickets with unresolved dependencies or without an unambiguous target repository; comment on the ticket with the missing information instead.