How to create a spike ticket

Use the /create-spike-ticket skill when the outcome of a deliverable is known but there is still some ambiguity and open questions left to address before it can be worked in. This applies to projects, enhancements, TSD sections, and implementation plans. A spike is not needed when the steps to take are clear. Rather use the originating workflow: /create-project, /create-enhancement-ticket, /create-tsd-section, or /create-implementation-plan. The skill drafts one parent issue with these sections:

When a project request has unsettled details, /start-work routes to /create-spike-ticket before project creation.

• Purpose
• Decisions
• Out of scope
• Remaining unknowns

Each remaining unknown becomes a subtask with its question, why it blocks, when to resolve it, and a resolver. The resolver is grilling by default. It can also be prototype, research, or task.

The parent summary starts with Spike:. The skill uses the Jira Spike issue type when the project provides it. It uses Task when the project does not provide Spike. An Epic is optional. A blocks link needs an explicit dependency from the user.

The skill shows the complete draft for your review before it creates anything in Jira. It does not update an existing spike.

Choose the next workflow

The spike ticket and its subtasks should not be treated as tickets that can be tackled with /implement. Once the subquestions have answers, use /resolve-spike-ticket to record the decisions and apply the done transition. Then return to the originating workflow, such as /create-project, /create-enhancement-ticket, /create-tsd-section, or /create-implementation-plan, with the spike ticket as context.

To record decisions on an existing spike, use /resolve-spike-ticket.