Skip to main content

ticket-to-code-change

Set up a ticket-to-code-change automation using Linear as the issue tracker and GitHub, GitLab, or Bitbucket as the source-control provider. The Jira templates are served by the jira-issue-to-pr skill instead. 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.

소스 정보

저장소
OpenHands/extensions
최근 소스 활동
2026년 10월 12일 10:42
감지된 SKILL.md 언어
영어
스타
175
포크
119

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
6 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
ticket-to-code-change
description
Set up a ticket-to-code-change automation using Linear as the issue tracker and GitHub, GitLab, or Bitbucket as the source-control provider. The Jira templates are served by the jira-issue-to-pr skill instead. 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: Linear. Jira automations are set up with the `jira-issue-to-pr` skill instead, which ships a poller. 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's prompt-preset endpoint. On OpenHands Cloud or Enterprise the backend is the `<HOST>` value in your system prompt, authenticated with `Authorization: Bearer $OPENHANDS_API_KEY`. On a local Agent Canvas it is the Automation backend described in `<RUNTIME_SERVICES>`, authenticated 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.
GitHub에서 보기