ワンクリックでManusで任意のスキルを実行

implement-ticket

Work a ticket reference to completion — fetch the issue, clarify intent with the user, then plan or implement via plan mode or /plan-adr.

Manusで実行

概要

Work a ticket reference to completion — fetch the issue, clarify intent with the user, then plan or implement via plan mode or /plan-adr.

インストールコマンド

npx skills add https://github.com/zantarix/claude-code --skill implement-ticket

このコマンドをClaude Codeにコピー＆ペーストしてスキルをインストール

ソース

zantarix/claude-code

スター1

フォーク0

更新日2026年6月4日 00:28

SKILL.md

readonly

name	implement-ticket
description	Work a ticket reference to completion — fetch the issue, clarify intent with the user, then plan or implement via plan mode or /plan-adr.

Work the ticket reference in $ARGUMENTS (e.g. #14, org/repo#14, or a full issue URL). If no reference is provided, ask the user for one before proceeding.

No local codebase reads are permitted before Step 4. Steps 1–3 are exclusively remote context (ticket data, git remotes, platform CLI/MCP calls). Do not read source files, schemas, configs, or local ADR files at any point before calling EnterPlanMode.

Step 1: Disambiguate the platform

GitHub and GitLab share the #N notation. Infer the platform from project context (which platform plugin's rules and MCP are present, CI config, etc.). If inconclusive, check the origin remote. On GitLab, honour the reference sigil per the ref-notation rule (# issue, ! MR, & epic).

Step 2: Fetch and read the ticket

Fetch the referenced issue with its comments and any linked/related items. Read everything before forming a plan — the ticket content shapes all subsequent decisions.

On GitLab:

Also fetch the title and description of any related/linked/child/parent issues for additional context.
Set the work item's status to In progress per the status rule. If you updated the status, then also assign the ticket to @self for the user.

Step 3: Clarify with the user

Before planning, surface anything that needs the user's input based on the ticket content alone:

Ask about scope or priority if the ticket is ambiguous.
Flag conflicts between the ticket and decisions that are visible from the ticket description (referenced ADRs, stated constraints).

Keep questions focused; don't ask about things you can resolve by reading the ticket or project context.

Step 4: Enter plan mode

Call EnterPlanMode directly — do not invoke any skill at this step. /plan-adr must not be used as the entry point into planning.

Inside plan mode:

Explore the codebase to understand scope and existing patterns.
Based on what you find, assess whether the work warrants /plan-adr: does it introduce a new architectural surface, require choosing between alternatives with meaningfully different trade-offs, or commit to a cross-cutting pattern? Apply the criteria from the adr rule.
- If yes: exit plan mode, then invoke the /plan-adr skill with the ticket context and exploration findings as the starting point.
- If no: complete the implementation plan here and present it to the user for approval. The plan must include a note identifying the ticket being implemented (e.g. "This plan implements #N") so that when a PR/MR is created later, the issue number is available in context.

The /plan-adr invocation, if warranted, comes after exploration — never before.

Step 5: Follow through

Work the agreed path through to the user's stated goal. The goal may be planning only rather than full implementation — deliver what was actually asked for and stop there.

このリポジトリの他の Skills

同じリポジトリ

create-merge-request

zantarix/claude-code

Create a GitLab merge request for the current branch, describing the changes made. Adds a `Closes #N` line when the work implements a ticket. If /review was run in this session and the session folder is known, posts the review to the MR as a batched draft-note review via the `gitlab:post-mr-review` skill. Use proactively whenever the user asks to create an MR or merge request.

2026-06-031

post-mr-review

zantarix/claude-code

Reconcile a prior code review against the current branch state, then publish it to the GitLab MR as a single batched review: inline diff comments for findings in files the MR changed, and a summary comment (table + findings in untouched files) for the rest. Use after a review's fixes have been applied and you want to post the review to the MR.

2026-06-031

review

zantarix/claude-code

Run all *-reviewer agents over the current changes — partitioning a large diff into cohesive chunks reviewed in parallel — then fix critical/major findings in a single pass. Stores all output under .reviews/. There is no re-run loop: the human review (local, or via the create-pull-request / create-merge-request skills) is the verifying gate; this skill's job is to surface and fix the obvious issues before that gate. Proactively use this skill to review code you've created if you have added or modified more than two functions, or whenever you complete an implementation plan.

2026-06-031

create-pull-request

zantarix/claude-code

Create a GitHub pull request for the current branch, describing the changes made. Adds a `Closes #N` line when the work implements a ticket. If /review was run in this session and the session folder is known, posts the review.md file verbatim as a comment. Use proactively whenever the user asks to create a PR or pull request.

2026-06-031

create-child-task

zantarix/claude-code

Create preparatory work as child Task work items under a GitLab ticket — e.g. "draft an ADR", "decide between options", spike research, dependency upgrades. Use when a ticket's pre-work should be tracked as sub-tasks rather than buried in the description.

2026-06-021

custom-work-item-types

zantarix/claude-code

Create or convert a GitLab work item to a custom type that the MCP enum doesn't support — Bug, Incident, Ticket, or Tracker — via glab api graphql. Use when creating one of these types or changing an existing item's type.

2026-06-021

ソース

zantarix

zantarix/claude-code

GitHub リポジトリを開く Creator のリポジトリを見る

インストールコマンド

ダウンロード

Manusで実行

役立つ用途SOC

ソフトウェア開発者コンピュータ・数学職15-1252L4

name	implement-ticket
description	Work a ticket reference to completion — fetch the issue, clarify intent with the user, then plan or implement via plan mode or /plan-adr.

Work the ticket reference in $ARGUMENTS (e.g. #14, org/repo#14, or a full issue URL). If no reference is provided, ask the user for one before proceeding.

Step 1: Disambiguate the platform

Step 2: Fetch and read the ticket

Fetch the referenced issue with its comments and any linked/related items. Read everything before forming a plan — the ticket content shapes all subsequent decisions.

On GitLab:

Also fetch the title and description of any related/linked/child/parent issues for additional context.
Set the work item's status to In progress per the status rule. If you updated the status, then also assign the ticket to @self for the user.

Step 3: Clarify with the user

Before planning, surface anything that needs the user's input based on the ticket content alone:

Ask about scope or priority if the ticket is ambiguous.
Flag conflicts between the ticket and decisions that are visible from the ticket description (referenced ADRs, stated constraints).

Keep questions focused; don't ask about things you can resolve by reading the ticket or project context.

Step 4: Enter plan mode

Call EnterPlanMode directly — do not invoke any skill at this step. /plan-adr must not be used as the entry point into planning.

Inside plan mode:

Explore the codebase to understand scope and existing patterns.
Based on what you find, assess whether the work warrants /plan-adr: does it introduce a new architectural surface, require choosing between alternatives with meaningfully different trade-offs, or commit to a cross-cutting pattern? Apply the criteria from the adr rule.
- If yes: exit plan mode, then invoke the /plan-adr skill with the ticket context and exploration findings as the starting point.
- If no: complete the implementation plan here and present it to the user for approval. The plan must include a note identifying the ticket being implemented (e.g. "This plan implements #N") so that when a PR/MR is created later, the issue number is available in context.

The /plan-adr invocation, if warranted, comes after exploration — never before.

Step 5: Follow through

Work the agreed path through to the user's stated goal. The goal may be planning only rather than full implementation — deliver what was actually asked for and stop there.