wtf-design-task

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

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.

Process

0. GitHub CLI setup

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.

1. Identify the Task

If the user provided an issue number in their request, use it directly. Otherwise call AskUserQuestion (per ../references/questioning-style.md):

• question: "Which Task are you designing?"
• header: "Task"
• options: from recent open issues labeled task

Walk Task → Feature per ../references/spec-hierarchy.md to extract Functional Description, Gherkin, Design Reference (Task) and user stories / ACs / visual context (Feature).

2. Lifecycle check

Apply the present-label overwrite gate from ../references/lifecycle-labels.md for the designed label on the Task — output is "Design Reference", re-run verb is "Redesign". If absent, continue silently.

3. Load the design steering document

Load docs/steering/DESIGN.md per the strict consumer-side load in ../references/steering-doc-process.md (recommended skill: wtf.steer-design). Apply its design principles, tokens, component patterns, and accessibility standards silently throughout this session.

4. Explore the design system

Use the Agent tool with these concrete searches (run in parallel):

• Glob('src/components/**/*', 'src/**/components/**/*', 'components/**/*') — existing UI components; note file names that match domain objects or UI states in the Task
• Glob('**/{tokens,theme,variables,design-tokens}.{css,scss,ts,js,json}') + Grep for CSS custom property declarations (--) or Tailwind config keys — design tokens in use (colors, spacing, typography)
• Glob('src/**/*.{stories,story}.{ts,tsx,js,jsx,mdx}') — Storybook stories as pattern references for similar screens or flows
• Grep for figma.com URLs across all .md, .mdx, and issue body files in the repo — existing Figma references linked in related issues or docs

5. Identify UI states from Gherkin

For each Gherkin scenario in the Task:

• Identify the UI state it represents (e.g. empty, loading, error, success, disabled, edge case)
• Note any interaction or transition implied by the When/Then steps

List these states explicitly — this becomes the design coverage checklist.

6. Ask about design assets

Call AskUserQuestion (per ../references/questioning-style.md):

• question: "How would you like to handle design assets for this task?"
• header: "Design assets"
• options:
  • I have Figma frames → provide frame URLs; I'll validate coverage against Gherkin scenarios (Path A)
  • Generate designs for me → use Figma MCP to generate frames from the Gherkin scenarios and design system (Path B)
  • Scaffold a spec only → no Figma; produce a text component spec from the scenarios (Path C)
  • Partial — some states designed → provide available frames; remaining states go to generate or scaffold

Path A — Human provides frames: Collect frame URLs. For each Gherkin scenario from step 5, check whether a frame covers it. Flag any scenario with no matching frame as a gap. Present the coverage matrix: scenario → frame URL (or ⚠ gap). If gaps exist, call AskUserQuestion (per ../references/questioning-style.md):

• question: "How should I handle the uncovered scenarios?"
• header: "Gaps"
• options:
  • Generate missing frames → run Path B for the gaps
  • Leave as pending → record gaps in the Design Reference and continue

Path B — AI generates via Figma MCP: Check whether the Figma MCP tool generate_figma_design is available. If unavailable, warn the user and fall back to Path C (scaffold).

If available: for each uncovered UI state, call generate_figma_design with:

• The Gherkin scenario as the design brief
• Component patterns and tokens from docs/steering/DESIGN.md (loaded in step 3)
• Any shared components identified in the parent Feature's Design Handoff (if available)

Collect the generated frame URLs and treat them as Path A frames from this point forward.

Path C — Scaffold spec only: Draft a component spec using the structure in references/component-spec-template.md, listing each state with its required UI elements and interactions. No Figma frames — this is a text-only design brief for the developer.

Partial: Collect available frame URLs, run Path A validation on covered states. For uncovered states, call AskUserQuestion (per ../references/questioning-style.md):

• question: "How should I handle the remaining states?"
• header: "Remainder"
• options:
  • Generate → run Path B
  • Scaffold → run Path C

7. Draft the Design Reference

Produce the content for the Design Reference section of the Task:

• Frame URLs mapped to Gherkin scenarios (Path A/B), or scaffolded component spec (Path C)
• Coverage matrix: scenario → frame URL or ⚠ pending
• Component breakdown: which exist in codebase, which are new
• Interaction notes: hover, focus, error states, transitions
• Responsive behavior if applicable
• Design tokens to apply

8. Review with user

Show the draft. Then call AskUserQuestion (per ../references/questioning-style.md):

• question: "Does this cover all the states in the Gherkin?"
• header: "Review"
• options:
  • Yes — looks complete → proceed to update the task
  • Missing states → add more coverage
  • Other changes → adjust something else

Apply edits, then proceed.

9. Update the Task issue

Note: read the current body with the gh body helper, replace only the Design Reference section with the new content (Read + Edit tools), and preserve all other sections unchanged. See ../references/gh-body-helper.md.

python3 .wtf/gh-body.py read <task_number>        # prints a temp path; Read it, edit the Design Reference section
python3 .wtf/gh-body.py edit <task_number> --body-file "<path-from-read>"

Add the designed lifecycle label to mark this step complete:

gh issue edit <task_number> --add-label "designed"

Print the updated Task issue URL.

10. Offer to continue

Call AskUserQuestion (per ../references/questioning-style.md):

• question: "What's next?"

• header: "Next step"

• options:

  • Implement this Task → run wtf.implement-task for this Task now (default)
  • Design another Task → design another Task for the same Feature
  • Stop here → 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.