Skip to content
Back to skills

Ticket To Code Change

ASecurity

Set up a ticket-to-code-change automation using Jira or Linear as the issue tracker and GitHub, GitLab, or Bitbucket as the source-control provider. Watches for implementation-ready tickets, starts an OpenHands conversation to implement and test the request, opens a pull or merge request, and links the result back to the ticket.

  • 151 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 4, 2026
devopsgitapibackend

Works with

  • api

Security analysis

A100/100

Pro scans all 4 files and shows the line behind each finding

Scanned September 4, 2026

npx -y skills add OpenHands/extensions --skill ticket-to-code-change --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Ticket To Code Change?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Ticket To Code Change
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/openhands-ticket-to-code-change/badge)](https://www.skillsdirectory.com/skills/openhands-ticket-to-code-change)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: ticket-to-code-change
description: >
  Set up a ticket-to-code-change automation using Jira or Linear as the issue
  tracker and GitHub, GitLab, or Bitbucket as the source-control provider.
  Watches for implementation-ready tickets, starts an OpenHands conversation
  to implement and test the request, opens a pull or merge request, and links
  the result back to the ticket.
triggers:
  - /ticket-to-code-change:setup
---

# 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:

1. The issue tracker: Jira Cloud or Linear.
2. The source-control provider: GitHub, GitLab, or Bitbucket Cloud.
3. The project or team to watch and the label or workflow state that means
   "implementation ready".
4. How a ticket identifies its target repository and base branch.
5. The polling schedule or issue event to use.
6. The ticket state to set when work starts and when the change request opens.
7. Whether linked dependencies must be completed before dispatch.

## Setup workflow

1. Verify that both required integrations are connected and can read the
   selected project and repository.
2. Prefer an issue event trigger when the deployment can receive events;
   otherwise use cron polling with durable issue-ID deduplication.
3. Limit each run to a small configurable number of new tickets. On initial
   deployment, establish a baseline instead of dispatching the entire backlog.
4. 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.
5. 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.
6. 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.

Files in this skill

  • .plugin/plugin.json522 B
  • README.md236 B
  • SKILL.md2.2 KB
  • commands/ticket-to-code-change-setup.md502 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…