From developer
Turn a /spike-it output into tracker tickets ready for /plan-it or /do-it. Decomposes the spike into demo-able blocks of work, gets user approval, resolves the epic, then creates the tickets in the issue tracker. Use when the user says "task it", "create tickets", "break into tickets", "make the tickets", or wants to turn a spike or feature breakdown into tracked issues.
How this skill is triggered — by the user, by Claude, or both
Slash command
/developer:task-itThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Decompose a `/spike-it` output into vertical-slice tickets with HITL/AFK classification,
Decompose a /spike-it output into vertical-slice tickets with HITL/AFK classification,
get approval, create them in dependency order, and turn the spike into a tracking ticket. The final
ticket is always a mandatory HITL QA verification task.
Tracker: "the project's tracker" means whatever issue system the repo's CLAUDE.md declares — a GitHub issue via
gh, a Jira ticket via the Atlassian MCP, etc. Read it to learn which tracker is in use and how to create, reference, and edit tickets. Default to GitHub issues viaghif nothing is declared.
$ARGUMENTS may contain:
/look-up.ai/spike_some-feature.md) -- read the file/spike-it outputIf no spike context is found, use AskUserQuestion:
What are we breaking into tickets? Give me a spike ticket reference, spike file path, or description.
Read the spike. Extract:
Summarise what you found back to the user.
Break the spike into issues. Each issue is a vertical slice -- it cuts through all layers
end-to-end, is demo-able or verifiable on its own, and is worth showing at end of sprint.
/plan-it handles fine-grained decomposition within an issue; /task-it defines the deliverable
units.
For each issue, draft:
### Issue N: {conventional prefix}: {summary}
**Type:** feat | fix | refactor | chore
**Mode:** HITL | AFK
**Summary:** 1 sentence
**Description:** 2-4 sentences -- what changes from the user's perspective. No file paths.
Use domain language. Describe behaviours, not implementation.
**Acceptance Criteria:**
- [ ] Observable, testable behaviour 1
- [ ] Observable, testable behaviour 2
**Depends on:** Issue N (if any)
**Blocked by:** Issue N (if any -- use when strict ordering required)
**Labels:** [relevant labels from spike]
Issue bodies must survive radical codebase changes:
UBIQUITOUS_LANGUAGE.md if it exists)The last issue in every decomposition is a HITL QA verification task:
### Issue N: chore: manual QA verification
**Type:** chore
**Mode:** HITL
**Summary:** Verify all slices work together end-to-end
**Description:** Run through every user-observable change enabled by this spike.
Confirm each slice integrates correctly and nothing was missed.
**Acceptance Criteria:** (generated per Step 2a below)
**Depends on:** all other issues
**Labels:** qa
The QA task body contains a detailed checklist covering every user-observable change. Structure it as checkboxes grouped by feature flow, then by view/page within each flow.
## QA Checklist
### Flow 1: {Actor} -- {Goal}
#### {View / Page / Screen}
- [ ] {action} -> {expected observable outcome}
- [ ] {action} -> {expected observable outcome}
#### {Next View / Page}
- [ ] {action} -> {expected observable outcome}
### Flow 2: {Actor} -- {Goal}
#### {View / Page / Screen}
- [ ] {action} -> {expected observable outcome}
### Edge Cases
- [ ] {scenario} -> {expected outcome}
- [ ] {scenario} -> {expected outcome}
To generate:
Show the full issue list with mode classification:
{N} issues from spike
{spike name}:
- {prefix}: {summary} -- {type} -- {mode} -- {1-line description}
- {prefix}: {summary} -- {type} -- {mode} -- {1-line description} ... N. chore: manual QA verification -- chore -- HITL
Dependency order: 1 -> 2 -> 3 (4 and 5 independent) -> N (QA)
Ask: "Adjust any issues, or approve to create?"
Iterate until the user approves. They may want to merge, split, reorder, reclassify HITL/AFK, or drop issues. The QA task is mandatory -- it cannot be dropped.
Create tickets in dependency order so real ticket identifiers can be referenced in Blocked by
fields. Create each one in the project's tracker (per the repo's CLAUDE.md — gh issue create for
GitHub, the Atlassian MCP for Jira, etc.).
For each approved ticket:
{type}: {summary} using conventional prefixes## Parent Spike
{spike-ticket-ref}
## Description
{description}
## Acceptance Criteria
- [ ] {criterion}
## Blocked By
{blocker-ticket-ref} (if any)
After creating all tickets, present:
Created {N} tickets:
- {ref} -- {summary} (AFK)
- {ref} -- {summary} (HITL) ...
Edit the spike ticket (fallback: plan ticket if no spike) to append a task list at the bottom:
## Tasks
- [ ] {ref} -- {summary} (AFK)
- [ ] {ref} -- {summary} (AFK)
- [ ] {ref} -- {summary} (HITL)
- [ ] {ref} -- manual QA verification (HITL)
Edit the spike ticket in the tracker (per the repo's CLAUDE.md — gh issue edit for GitHub, the
Atlassian MCP for Jira, etc.) to append this. This turns the spike into a tracking ticket — trackers
that support child-issue checklists will show progress as the work tickets are closed.
Present the final state:
Tracking ticket: {ref} (spike) Work tickets: {ref}, {ref}, {ref} QA ticket: {ref}
Pick one to
/plan-itor/do-it?
npx claudepluginhub xxkeefer/skills --plugin developerCreates bite-sized, testable implementation plans from specs or requirements, with file structure and task decomposition. Activates before coding multi-step tasks.