ticket-craft

Overview of ticket-craft skill

ticket-craft is a ticket-writing skill for turning rough product intent into AI-executable work items. It is best for people who create Jira, Asana, Linear, or GitHub issues and want the ticket itself to carry enough context for Claude Code or another agent to start and finish with fewer follow-up questions.

The main job-to-be-done is not “write a nicer issue.” It is to make the ticket self-contained: clear goal, scope, constraints, acceptance criteria, and enough implementation context that an agent can act without guessing. That makes ticket-craft especially useful for epics, feature breakdowns, and spec-like tickets where ambiguity usually slows execution.

What differentiates ticket-craft from a generic prompt is its focus on agent-readiness. It combines familiar software-writing patterns such as INVEST, Given-When-Then, and Definition of Ready with explicit instructions for AI execution. This makes it a good fit when your main risk is not poor prose, but incomplete instructions.

Best fit for AI-executable tickets

Use ticket-craft when the ticket will be handed to an agent, not just read by a human. It is strongest when you already know the outcome you want, but need help translating that into a structured task with boundaries, context, and testable completion criteria.

What it is not for

ticket-craft is not the best choice for brainstorming product direction, writing lightweight task notes, or managing very small tickets that only need a sentence and a link. If the work is still undecided, forcing a fully specified agent-ready ticket can create false certainty.

Why this skill matters

The practical value of ticket-craft is reduced back-and-forth. Better ticket shape means fewer clarification loops, fewer scope surprises, and less time spent re-explaining context in comments. For teams using Claude Code for implementation, that can be the difference between a ticket that starts immediately and one that stalls.

How to Use ticket-craft skill

Install and activate ticket-craft

Use the repository’s skill install flow, then enable ticket-craft in your Claude Code or skill-enabled workflow. The baseline install pattern shown in the source is:

npx skills add alinaqi/claude-bootstrap --skill ticket-craft

If your environment uses a different skill manager or path, preserve the same skill name and adapt the installation method to your setup. The important part of the ticket-craft install step is not the command itself, but making sure the skill is available where you draft tickets.

Give it a real work item, not a vague ask

The strongest ticket-craft usage starts with a messy but specific goal. Good inputs usually include:

• the feature, bug, or epic name
• the target system or repo area
• user impact or business reason
• known constraints, dependencies, or non-goals
• existing behavior that should stay unchanged
• any acceptance tests, screenshots, or links

A weak prompt like “write a ticket for improving onboarding” leaves too much open. A better prompt is: “Create an AI-executable Linear ticket for reducing signup drop-off on mobile. We want to add email autofill support, keep the current step order, exclude social login changes, and define acceptance criteria for iOS and Android.”

Read these files first

Start with SKILL.md, since it defines the ticket structure and the logic behind the framework. Then inspect any repository files the skill references, especially content describing the Core Principle, the INVEST+C criteria, ticket types, and feature-ticket examples. In this repository, SKILL.md is the primary source; there are no supporting rules/, resources/, or scripts/ folders, so the main workflow comes from the skill document itself.

Use a prompt shape that helps the skill

For best results, ask for a ticket in a format the agent can execute. A strong prompt might say:

“Using ticket-craft, draft a Jira ticket for adding webhook retries. Include problem statement, scope, non-goals, implementation notes, acceptance criteria, and edge cases. Assume the agent will work in a Node.js monorepo and should not change API contracts.”

That kind of input improves output quality because it tells the skill what matters most: scope control, environment, and completion signals.

ticket-craft skill FAQ

Is ticket-craft only for Claude Code?

No. The skill is optimized for Claude Code execution, but the ticket format works with any AI agent or ticket system that benefits from explicit context and acceptance criteria. The ticket-craft skill is most valuable when the downstream worker is automated or semi-automated.

How is this different from a normal prompt?

A normal prompt can generate a decent issue summary. ticket-craft is designed to produce a ticket that can survive execution: it pushes for definitions, constraints, and measurable completion. That matters when a vague prompt would otherwise lead to implementation drift.

Do I need to be a technical writer to use it?

No. The skill is useful for product managers, engineers, and ops leads as long as they can describe the desired change. The main requirement is enough source context to state what should happen, what should not change, and what “done” means.

When should I skip it?

Skip ticket-craft when the work is exploratory, the scope is intentionally fluid, or the request is too small to justify a structured ticket. For tiny follow-up tasks, the overhead can outweigh the benefit.

How to Improve ticket-craft skill

Provide sharper source context

The biggest quality gain comes from better inputs. Include the repo area, current behavior, constraints, and any proof points like issue links or user reports. If the ticket depends on an existing pattern, name it. If it must avoid a risky area, say so explicitly.

Ask for boundaries, not just tasks

A common failure mode is over-scoping. Improve ticket-craft results by stating non-goals, forbidden changes, and assumptions the agent should not make. For example: “Do not alter database schema,” or “Keep the current UI copy unchanged unless required for the fix.”

Add completion signals early

If you want reliable execution, specify what success looks like before the ticket is written. Good signals include test cases, acceptance criteria, rollout notes, and edge cases. This is especially important for ticket-craft for Issue Tracking when the issue will be assigned directly to an AI agent.

Iterate after the first draft

If the first ticket is too broad, revise the prompt with one more layer of detail: exact user flow, affected files, or expected output format. The best ticket-craft guide workflow is iterative—draft, tighten scope, then rewrite the ticket so the agent can start without clarification.