wtf.feature-to-tasks
Feature to Tasks
Break a Feature down into its full set of Tasks and create them one by one. Core value: proposes the complete task list upfront derived from the Feature's Acceptance Criteria, then walks through writing each Task with full user control.
Process
0. GitHub CLI setup
Run the setup check from ../references/gh-setup.md. Stop if gh is not installed or not authenticated. Note whether the extensions are available — this determines whether native sub-issue and dependency links are created downstream (via wtf.write-task).
Skip this step if gh-setup was already confirmed this session (e.g. when chained from wtf.write-feature or wtf.epic-to-features).
1. Identify the Feature
If a Feature number was passed in as context, use it directly. Otherwise call AskUserQuestion (per ../references/questioning-style.md):
- question: "Which Feature are you breaking into Tasks?"
- header: "Feature"
- options: from recent open issues labeled
feature
Walk Feature → Epic per ../references/spec-hierarchy.md to extract ACs, edge cases, user stories (Feature) and Goal, Context (Epic).
Extract any existing Proposed Tasks checklist items (named, unnumbered items) from the Feature body. In Step 2, use these as the starting point for the proposal rather than generating from scratch.
List Features already created under the Epic via gh sub-issue list <epic_number> per the cookbook in ../references/gh-setup.md — used in step 4 to identify the next Feature.
2. Propose the full Task list
Based on the Feature's Acceptance Criteria, User Stories, and Edge Cases, derive a proposed list of Tasks. Each task should be a vertical slice — touching all layers needed for one observable, user-facing behavior.
Present the list as plain numbered text, for example:
Here are the Tasks I'd propose to implement this Feature:
- Add settlement status field to Payment Aggregate
- Expose settlement status on the payments API endpoint
- Display settlement status in the merchant dashboard UI
- Send settlement notification email when status changes
Then call AskUserQuestion (per ../references/questioning-style.md):
- question: "Does this list look complete? You can add, remove, or rename any Task before we start."
- header: "Task list"
- options:
- Looks good → proceed with this list
- Make changes → add, remove, or rename a Task
Wait for the user to confirm or adjust the list. Apply any changes.
3. Walk through Tasks one by one
For each Task in the confirmed list, in order:
- Announce: "Creating Task [N/total]: [task description]"
- Follow the
wtf.write-taskprocess, passing:- The Feature number (skip step 1 of write-task — Feature already fetched)
- The task description as the pre-filled proposal in step 2 of write-task (user can confirm or adjust)
- Skip write-task clarification questions already answered by the loaded Feature context (ACs, user stories, edge cases). Only ask about scope or contract details that cannot be derived from the Feature.
- Before moving to the next Task, call
AskUserQuestion(per../references/questioning-style.md):- question: "Task [N] created. Ready to continue to Task [N+1]: [next task description]?" (replace [N]/[N+1] with actual numbers and description)
- header: "Continue?"
- options:
- Yes, continue → proceed to the next Task (default)
- Pause here → exit; print a summary of which Tasks were created and which remain; suggest
/clearbefore resuming - Skip this task → mark as skipped in the list and move to the next
- Add a new task → call
AskUserQuestionwith question "What is the new task?", header "New task", options from plausible tasks inferred from the remaining Feature ACs; add the confirmed task, then continue
4. Completion
When all Tasks have been created (or skipped), print a summary:
"Feature #<feature_number> Task breakdown complete. Created: [list with issue numbers] Skipped: [list if any]"
Then call AskUserQuestion (per ../references/questioning-style.md):
- question: "What's next?"
- header: "Next step"
- options:
- Implement first Task → follow
wtf.implement-taskwith the first created Task number (default) - Tasks for next Feature → follow
wtf.feature-to-taskswith the next Feature fromgh sub-issue listthat has no child tasks yet - Stop here → exit, no further action
- Implement first Task → follow
Suggest
/clearbefore continuing if the conversation has grown long.
More from xiduzo/wtf
wtf.write-feature
This skill should be used when a user wants to create a GitHub Feature issue, break down an Epic into user-facing capabilities, write user stories in domain language, or capture what a domain actor can do — for example "create a feature", "write a feature for this epic", "add a feature to an epic", "break this epic into features", "write user stories for this feature", or "describe what this actor can do". Use this skill to write a single Feature; use `wtf.epic-to-features` to generate the full set of Features for an Epic at once. Not applicable to Tasks, Epics, or bug reports.
38wtf.write-task
This skill should be used when a user wants to create a task, write a ticket, decompose a feature into implementable work, break down a story, define a vertical slice for development, or write Gherkin scenarios — for example "create a task", "write a task for this feature", "break this feature into tasks", "define implementation work", or "add a sub-issue to this feature". Guides creation of a GitHub Task issue linked to a parent Feature and Epic, derives Gherkin acceptance scenarios from the Feature's ACs, enforces DDD ubiquitous language in scenarios, and checks for vertical-slice integrity and task dependencies.
38wtf.write-epic
This skill should be used when a user wants to create, draft, or plan a GitHub Epic issue — for example "write an epic", "I want to define a new initiative", "scope out this strategic project", "turn this idea into an epic", "plan work that spans multiple features", or "start from a bounded context". Also use when the user asks to define domain outcomes, capture a large initiative before breaking it into features, or describe work in terms of business goals rather than technical tasks.
38wtf.steer-design
This skill should be used when a team wants to create or refine the design guidelines document — for example "create the design steering doc", "document our design system", "write the design principles", "document our component patterns", "set up the design guidelines", or "update the design doc". Generates docs/steering/DESIGN.md as a living document capturing design principles, the design system, tokens, component patterns, and accessibility standards. Generated once and refined — not regenerated from scratch.
37wtf.reflect
This skill should be used when a developer wants to capture learnings from a difficult session, record what Claude got wrong, save implementation gotchas, or update the steering docs with hard-won knowledge — for example "let's reflect", "capture what we learned", "that was painful, save this", "update the steering docs with what went wrong", "I need to debrief", "what went wrong today", "log this lesson", "save this gotcha", "document this mistake", "I want to write this down before I forget", "add this to the steering docs", or when prompted by the intervention tracker after multiple corrections. Routes each learning into the right steering doc (TECH, QA, DESIGN, or VISION) under a "Hard-Won Lessons" section.
37wtf.verify-task
This skill should be used when a QA engineer wants to test or verify a completed task, run through acceptance criteria, check Gherkin scenarios against the implementation, record pass/fail results, or sign off on a ticket before merge. Triggers on phrases like "verify task #42", "run QA on this issue", "test the acceptance criteria", "sign off on task", "check if this task is ready to merge", "does this task meet its acceptance criteria", "run acceptance tests for task #X", "walk through the Gherkin for task #X", or "I want to test this task".
37