원클릭으로 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.