Menu
This skill should be used when a designer is picking up a Task issue to add design coverage. Triggers on phrases like "I want to design task
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
This skill should be used when a developer wants to open a pull request for a completed task branch โ for example "create a PR", "open a pull request", "submit this for review", "make a PR for task
This skill should be used when a user wants to decompose an Epic into its complete set of Features all at once, invoked automatically after write-epic completes, or triggered by phrases like "create all features for this epic", "walk me through all the features", "let's break down this epic", or "plan the features for epic
This skill should be used when a user wants to plan and create the complete set of Tasks for a Feature all at once, systematically walk through every implementable slice of work for a Feature, or create tasks in batch with step-by-step confirmation. Triggers on phrases like "plan all tasks for this feature", "create all tasks for feature
This skill should be used when a developer is ready to implement a GitHub Task issue and needs to read the full spec hierarchy (Task + Feature + Epic), explore the codebase, produce a concrete Technical Approach with real file paths, and drive TDD implementation against Gherkin scenarios. Triggers on phrases like "implement task
Use when new insights change the scope, acceptance criteria, domain language, or technical constraints of an existing Epic, Feature, or Task โ for example "refine epic
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", 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.
| name | wtf:design-task |
| description | This skill should be used when a designer is picking up a Task issue to add design coverage. Triggers on phrases like "I want to design task |
Pick up an existing Task as a designer. Core value: reads the Gherkin scenarios to identify every UI state that needs design coverage, then helps you document the design references back into the issue so developers have a single source of truth.
See references/component-spec-template.md for the expected structure when scaffolding a component spec without Figma frames.
Run steps 1โ2 of ../references/gh-setup.md (install check and auth check). Stop if gh is not installed or not authenticated. Extensions are not required for this skill.
Skip this step if invoked from wtf:write-task or another skill that already ran gh-setup this session.
If the user provided an issue number in their request, use it directly. Otherwise search for recent open issues with label task to populate options and call AskUserQuestion with question: "Which Task are you designing?", header: "Task", and options pre-filled with 1โ2 likely open Task issue references inferred from GitHub search (e.g. recent open issues labeled task).
Fetch the Task first, extract the Feature number from its Context section, then fetch the Feature:
gh issue view <task_number> # Functional Description, Gherkin, Design Reference โ also yields feature number
# Extract feature number, then:
gh issue view <feature_number> # User stories, ACs, visual context
Check whether the task already has a designed label:
gh issue view <task_number> --json labels --jq '.labels[].name'
If the designed label is present, call AskUserQuestion with:
question: "This task already has a designed label. Continuing will overwrite the existing Design Reference. How would you like to proceed?"
header: "Already designed"
options: [{label: "Redesign it", description: "Overwrite the existing Design Reference with a new one"}, {label: "Exit", description: "Leave the existing design as-is"}]
Redesign it โ continue.
Exit โ exit immediately.
If the designed label is absent, continue silently.
Check whether docs/steering/DESIGN.md exists:
cat docs/steering/DESIGN.md 2>/dev/null
If the file exists: read it and keep it in context. Use its design principles, tokens, component patterns, and accessibility standards to inform every decision in this session. Do not surface it to the user โ just apply it silently.
If the file does not exist, call AskUserQuestion with:
question: "docs/steering/DESIGN.md doesn't exist yet. This document captures your design principles, tokens, and component patterns. Would you like to create it now?"
header: "Design steering doc missing"
options: [{label: "Create it now", description: "Run wtf:steer-design before continuing (recommended)"}, {label: "Skip for this session", description: "Continue without it โ design decisions won't reference project standards"}]
Create it now โ follow the wtf:steer-design process, then return to this skill and continue from step 4.
Skip for this session โ continue without it.
Use the Agent tool to search the codebase for:
For each Gherkin scenario in the Task:
List these states explicitly โ this becomes the design coverage checklist.
Call AskUserQuestion with question: "Do you have Figma frames ready to link?", header: "Design assets", and options: [{label: "Yes โ I have Figma frames", description: "Collect frame URLs and map to UI states"}, {label: "No frames yet โ scaffold from Gherkin", description: "Draft a component spec from the scenarios"}, {label: "Partial โ some states designed, some not", description: "Collect available frames and scaffold the rest"}].
references/component-spec-template.md, listing each state with its required elements and interactionsProduce the content for the Design Reference section of the Task:
Show the draft. Then call AskUserQuestion with question: "Does this cover all the states in the Gherkin?", header: "Review", and options: [{label: "Yes โ looks complete", description: "Proceed to update the task"}, {label: "Missing states", description: "I want to add more coverage"}, {label: "Other changes", description: "I want to adjust something else"}].
Apply edits, then proceed.
Note: read the current issue body first (
gh issue view <task_number>), replace only the Design Reference section with the new content, and preserve all other sections unchanged. Write the full updated body to a temp file and use--body-file.
gh issue edit <task_number> --body-file /tmp/updated-task-body.md
Add the designed lifecycle label to mark this step complete:
gh issue edit <task_number> --add-label "designed"
Print the updated Task issue URL.
Call AskUserQuestion with:
question: "What's next?"
header: "Next step"
options: [{label: "Implement this Task", description: "Run wtf:implement-task for this Task now (default)"}, {label: "Design another Task", description: "Design another Task for the same Feature"}, {label: "Stop here", description: "Exit โ no further action"}]
Implement this Task โ follow the wtf:implement-task process, passing the Task number in as context so the user is not asked for it again.
Design another Task โ restart this skill from step 1, reusing the same Feature context.
Stop here โ exit.