task-taxonomy-rules

name	Task Taxonomy Rules
description	Rules for creating task breakdowns from Figma designs
user-invocable	false

Task Breakdown Taxonomy

Hierarchy

1. Project — The feature being built
2. Milestones — Logical chunks grouped by UI area, ordered by build dependency
3. Tasks — Specific work items, written for both dev AND QA

Plain Language Rules

• Write tasks so the same text works for development and QA testing
• Reference UI elements by their visible labels from Figma
• NO technical jargon: avoid "API", "state management", "Redux", "component lifecycle"
• Good: "Add 'All Rooms' option to top of rooms nav"
• Bad: "Implement room selection state management"

Task Descriptions

• Each task has a name (what) and description (how/details)
• Descriptions add context: expected behavior, visual details, or clarification

Functionality Markers

• (non-functional) = placeholder/visual only, no behavior
• (disabled) = visible but not interactive
• No marker = fully functional

Multi-Frame Analysis

• Same screen, different state: Same header/layout, differs in states → group together
• Different screens: Different header, different layout → separate milestones
• Drawers/Modals: Group with parent screen, separate tasks for trigger + content

Task Granularity

Be SPECIFIC for:

• Label/text changes: "Change nav label from 'Measurements' to 'Estimate'"
• Adding elements: "Add 3-dot ellipsis icon with rooms/sides radio selection"
• Visual tweaks: "Add shadow to rooms nav container"

Be GENERAL for:

• New complex components: "Implement tasks table with all columns and data"
• Then add specific interaction tasks: "Implement Status column dropdown"

Repeated Patterns

• DON'T task each repeated element (each row, each card)
• DO task the pattern: "Implement room cards with drag handle and 3-dot menu"