Help us improve
Share bugs, ideas, or general feedback.
From backend-chapter
Create a split-off Jira ticket from an original ticket, with correct content and metadata. Use this skill **after** the decision has been made that a piece of work must live in its own Jira ticket.
npx claudepluginhub suitsupply/bec-marketplace-plugins --plugin backend-chapterHow this skill is triggered — by the user, by Claude, or both
Slash command
/backend-chapter:split-jira-ticketThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill **after** the decision has been made that a piece of work must live in its own Jira ticket. This skill does not make that decision; it executes the split correctly.
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
Use this skill after the decision has been made that a piece of work must live in its own Jira ticket. This skill does not make that decision; it executes the split correctly.
Resolve cloudId once via getAccessibleAtlassianResources before any other Atlassian call. All writes use contentFormat: "markdown"; fetch with responseContentFormat: "markdown".
Fetch the original (getJiraIssue) — capture: epic link, parent (if subtask), sprint, status, issue type, project key.
Classify dependency vs follow-up using the rule below. Record the result; it drives both the link type and the sprint decision.
Draft the new ticket content following the Ticket content rules. The new ticket must be self-contained — a developer should not need to open the original to act on it.
Create the new ticket (createJiraIssue) in the same project as the original. Set:
story-builder-assisted (merge, do not overwrite).customfield_16182): copy from the original only if the split-off work lives in the same repository and the field is set on the original. Skip otherwise.Link to the original:
is blocked by link from the original to the new ticket (i.e. the original is blocked by the split-off).relates to link between the original and the new ticket, and prefix the new ticket's summary with Follow-up: so the relationship is visible in lists.Sprint placement (dependency only):
Comment on the original (addCommentToJiraIssue, one comment) — state the new ticket key, the classification (dependency or follow-up), the one-sentence rationale, and what sections (if any) of the original were narrowed as a result.
Chat summary — new ticket key + title, classification, epic, sprint (or "none"), repo URL copied (yes/no), original ticket key.
If the original ticket's acceptance criteria cannot be met without the split-off being completed first, the split-off is a dependency. Otherwise, it is a follow-up.
Apply the rule against the original's own AC as written, not against a hypothetical broader scope. If meeting the original's AC requires the split-off work to already be in place, it's a dependency — no matter how small the split-off is. If the original's AC can be signed off while the split-off remains open, it's a follow-up — no matter how related the work feels.
Edge cases:
If applying the rule is genuinely ambiguous, default to follow-up and flag the ambiguity in the comment on the original — a follow-up can always be reclassified, an incorrect dependency reshapes a sprint.
The new ticket's description must be self-contained. Context, Goal, and Acceptance Criteria are mandatory. This should be agnostic of the implementation details.
For dependencies, list the original ticket key under Dependencies in the new ticket and note in Scope → Out what stays in the original. For follow-ups, note in Context that this was carved out of the original and what the original already covers.
Apply refine-jira-ticket skill to append the implementation details.
story-builder-assisted label when created via this skill.