Back to catalog

figma-to-dev-plans

Convert Figma source exports into comprehensive dev_task-prompts_and_plans with implementation guides, component inventories, phased planning, and E2E test plans for Phoenix LiveView

• Category: discovered
• Tags: github, community
• Version: 1.0.0
• Author: walid
• Downloads: 0
• GitHub stars: 1
• Updated: 2025-11-21

• Source: clientt-ai/clientt_phoenix_crm

Download the latest version (v1.0.0) from this page.

SKILL.md

---
name: figma-to-dev-plans
description: Convert Figma source exports into comprehensive dev_task-prompts_and_plans with implementation guides, component inventories, phased planning, and E2E test plans for Phoenix LiveView
---

# Figma to Dev Plans Skill

Convert exported Figma code folders (React/TypeScript) into comprehensive development task prompts and plans with implementation guides, coverage analysis, and phased planning for Phoenix LiveView conversion.

## Overview

This skill automates the process of analyzing a Figma source export and generating a complete `dev_task-prompts_and_plans` folder structure with:
- Component and page inventories
- Technology conversion matrices (React → Phoenix LiveView)
- Database schema requirements
- Implementation phases and timelines
- Testing strategies
- Coverage analysis

## When to Use This Skill

Use this skill when you have:
- A Figma code export folder in `figma_src/` (React/TypeScript/Vite)
- Need to plan Phoenix LiveView implementation
- Want comprehensive development task prompts
- Need to track component coverage and references

## Prerequisites

- Figma source export exists in `figma_src/` folder
- Export contains React/TypeScript components (TSX files)
- Have access to the codebase structure (`lib/`, `test/`, etc.)
- Understand the target technology stack (Phoenix, Ash, LiveView)

## Step-by-Step Process

### Step 1: Analyze Figma Export Structure

**Goal:** Understand what's in the Figma export

**Actions:**
1. Ask user for the Figma source folder path
   - Example: `figma_src/205 Forms Dashboard/`

2. Inventory the export:
   ```bash
   # Count total files
   find "figma_src/[folder]" -name "*.tsx" | wc -l

   # List pages
   ls -1 "figma_src/[folder]/src/components/pages/"

   # List components
   ls -1 "figma_src/[folder]/src/components/"

   # Count lines per page
   wc -l "figma_src/[folder]/src/components/pages/"*.tsx | sort -rn
   ```

3. Read package.json to understand dependencies:
   - UI libraries (shadcn/ui, Material UI, etc.)
   - Icon libraries (Lucide, Font Awesome, etc.)
   - Chart libraries (Chart.js, Recharts, etc.)
   - Form libraries (React Hook Form, Formik, etc.)

4. Create component inventory:
   - **Pages** - Top-level routes/screens
   - **Components** - Reusable UI components
   - **UI Components** - Library components (shadcn/ui, etc.)
   - **Utilities** - Helper functions, hooks

**Output:** Complete file and component inventory with line counts

---

### Step 2: Identify Feature Domains

**Goal:** Group components into logical implementation tracks

**Analysis:**
1. Group pages by feature domain:
   - Forms management → Forms domain
   - Analytics/dashboards → Analytics domain
   - Settings → Settings domain
   - Calendar → Calendar domain
   - Chatbot → Chatbot domain
   - CRM/Contacts → CRM domain

2. Identify cross-cutting concerns:
   - Layout components (Header, Sidebar, Navigation)
   - Authentication pages (Login, Signup, Reset Password)
   - Shared components (KPI cards, tables, charts)

3. Determine MVP scope:
   - Which features are core/essential?
   - Which features can be "Coming Soon"?
   - What's the logical implementation order?

**Ask the user:**
- "Which features are MVP priority?"
- "Which features should be marked as 'Coming Soon'?"
- "Any specific implementation order requirements?"

**Output:** Feature domain groupings with MVP vs Future classification

---

### Step 3: Check Existing Specs for Architectural Patterns

**Goal:** Review existing specifications to understand established patterns before planning implementation

**Actions:**
1. **Check for specs folder:**
   ```bash
   ls -la specs/
   ```

2. **If specs exist, review key areas:**
   - **Multi-Tenancy/Authorization Patterns:**
     - Check `specs/01-domains/authorization/` for company scoping requirements
     - Review `specs/01-domains/authorization/policies/row_level_security.md`
     - Note: ALL tenant-scoped resources MUST have `tenant_id` column
     - Review session management requirements (`live_authz_auth.ex`, `on_mount` hooks)

   - **Role-Based Access Control:**
     - Check `specs/01-domains/authorization/resources/authz_user.md`
     - Note existing roles: `admin`, `manager`, `user` (company-level)
     - Check for `feature_roles` JSONB pattern for feature-specific permissions
     - Understand permission mapping approach (code-based, not database tables)

   - **Database Patterns:**
     - Review `specs/.../DATABASE_SCHEMA.generated.md` if exists
     - Note status field patterns (e.g., `active`, `archived` vs soft delete)
     - Check index naming conventions
     - Review foreign key cascade behaviors

   - **UI/Design System:**
     - Check `specs/05-ui-design/` for design tokens and component guidelines
     - Note: DO NOT export Figma HTML/TSX directly
     - Use DaisyUI Tailwind classes with Phoenix LiveView HEEx templates
     - Figma is reference only, not source code

3. **Document Spec Insights:**
   Create file: `[track-00]/SPEC-INSIGHTS.md` with findings:
   ```markdown
   # Insights from Existing Specs

   **Reviewed:** [Date]

   ## Multi-Tenancy Requirements
   - [What was found about tenant_id requirements]

   ## Authorization Patterns
   - [Existing role structure]
   - [Permission mapping approach]

   ## Database Conventions
   - [Status patterns]
   - [Deletion strategy]
   - [Index patterns]

   ## Design System
   - [Component library to use]
   - [Implementation approach]

   ## Critical Decisions Influenced
   - [How specs answer outstanding questions]
   ```

4. **Cross-Reference with Implementation Plans:**
   - Flag any conflicts between Figma export and existing specs
   - Update database schemas to include `tenant_id` where needed
   - Align role definitions with existing authorization system
   - Note required session management components

**Questions to Answer from Specs:**
- Is multi-tenancy implemented? (Check for `authz_tenants` table)
- What roles exist? (Check authorization domain)
- Is there a permission system? (Check for RBAC patterns)
- What's the deletion strategy? (Soft delete vs status fields)
- What design system is being used? (DaisyUI, etc.)

**⚠️ CRITICAL:** If specs indicate multi-tenancy exists, ALL new tables MUST include `tenant_id` column and proper row-level security policies.

**Output:** SPEC-INSIGHTS.md with all findings that inform implementation decisions

---

### Step 4: Define Implementation Tracks

**Goal:** Create logical tracks for development

**Standard Tracks:**

1. **Track 0: Project Overview** (`YYYYMMDD-00-[name]-project-overview/`)
   - README.md with navigation guide
   - MVP scope and feature list
   - Technology conversion reference
   - Implementation phases
   - Success criteria

2. **Track 1: Primary Overview** (`YYYYMMDD-01-[name]-primary/`)
   - 00-PRIMARY-OVERVIEW.md (executive summary)
   - Complete feature breakdown
   - Database schema overview
   - All implementation phases detailed

3. **Track 2: LiveView UI Conversion** (`YYYYMMDD-02-[name]-liveview-ui/`)
   - Component conversion patterns (React → LiveView)
   - Page-by-page implementation guide
   - Routing configuration
   - Design system migration
   - Testing strategy

4. **Track 3: Domain Models** (`YYYYMMDD-03-[name]-domain-models/`)
   - Ash resources and domains
   - Database schema (SQL)
   - Role-based access control
   - Calculations and aggregates
   - Validation rules

5. **Track N: Feature-Specific Tracks**
   - One track per major feature domain
   - Example: Analytics, Settings, Calendar, etc.
   - Each track follows similar structure

6. **Track xx: Future Features** (`YYYYMMDD-xx-[name]-future-[feature]/`)
   - Documented but not in MVP
   - "Coming Soon" placeholders in UI
   - Complete specs for future implementation

**Folder Naming Convention:**
- Format: `YYYYMMDD-NN-[name]-[description]`
- Example: `20251115-02-forms-liveview-ui`
- MVP tracks: `00-05` (or however many needed)
- Future tracks: `xx-future-[feature]`

**Output:** Track structure with folder names and descriptions

---

### Step 4: Create Project Overview (Track 0)

**File:** `YYYYMMDD-00-[name]-project-overview/README.md`

**Contents:**
```markdown
# [Feature Name] Implementation - Development Task Prompts

## Overview
[Brief description of what's being built]

**Figma Source:** `figma_src/[folder]/`
**Target Stack:** Elixir, Phoenix 1.8+, Ash Framework 3.0+, LiveView 1.1+, PostgreSQL

## Quick Start
1. Read First: [Link to PRIMARY OVERVIEW]
2. Choose Your Track: Based on role/feature
3. Follow the MVP Phases: [Number] phases over [Number] weeks

## Current Scope: MVP Implementation
- ✅ Feature 1
- ✅ Feature 2
- ⏸️ Future Feature 1
- ⏸️ Future Feature 2

## Folder Structure
[Directory tree with all tracks]

## Implementation Tracks (MVP)
[Description of each MVP track]

## Future Phases (Post-MVP)
[Description of future tracks]

## MVP Implementation Phases
[Detailed phase breakdown]

## Technology Conversion Reference
[React → LiveView mapping table]

## Quick Reference by Role
[Frontend, Backend, Full-Stack developer paths]

## Common Questions
[FAQ about the implementation]

## UI Placeholders for Future Features
[Code examples for "Coming Soon" badges]

## Success Criteria (MVP)
[Technical and feature metrics]

## Resources & Documentation
[Links to project docs, external docs, Figma source]
```

**Output:** Complete project overview with navigation

---

### Step 5: Create Primary Overview (Track 1)

**File:** `YYYYMMDD-01-[name]-primary/00-PRIMARY-OVERVIEW.md`

**Contents:**
```markdown
# [Feature Name] - Primary Implementation Overview

## Executive Summary
[Comprehensive overview]

**Source:** `figma_src/[folder]/`
**Target:** Phoenix LiveView Application at `clientt_crm_app/`

## What We're Building (MVP Scope)
[Detailed feature list with MVP vs Future]

## Critical Requirements
[UI layout, RBAC, architectural requirements]

## Major Components
[All tracks with detailed descriptions]

### Track N: [Track Name]
**Folder:** `YYYYMMDD-0N-[folder]/`
**Scope:** [What this track covers]
**Key Files to Create:** [List of files]
**Technology Mapping:** [Conversions needed]
**Database Tables:** [If applicable]

## MVP Database Schema
[Complete SQL schema]

## Implementation Phases
[Detailed phase breakdown with tasks]

### Phase 1: Foundation (Week X-Y)
**Priority:** [Focus area]
**Tasks:**
- ✅ Task 1
- ✅ Task 2

**Deliverables:**
- [What's complete at end of phase]

## Technology Stack
[Complete tech stack for implementation]

## Testing Strategy
[Unit, integration, E2E testing approaches]

## Performance Considerations
[N+1 queries, caching, optimization]

## Security Considerations
[RBAC, policies, XSS prevention, etc.]

## Timeline & Milestones
[Week-by-week breakdown]

## Questions to Clarify Before Starting
[List of questions for stakeholders]

## Success Metrics
[How to measure completion]

## Resources
[Links to all relevant documentation]
```

**Output:** Comprehensive primary overview document

---

### Step 6: Create LiveView UI Track (Track 2)

**File:** `YYYYMMDD-02-[name]-liveview-ui/README.md`

**Contents:**
```markdown
# Track 2: Phoenix LiveView UI Conversion

## Overview
Convert React/TypeScript components to Phoenix LiveView

**Source Files:** `figma_src/[folder]/src/components/`
**Target Location:** `lib/[app]_web/live/` and `lib/[app]_web/components/`

## Critical UI Requirements
[Layout, navigation, RBAC, responsive design]

## Components to Convert

### Priority 1: Core Pages (Week 1)
1. **[Page Name]** ([Lines] lines) → `[target_path]`
   - [Description]
   - [Key components]
   - [Special considerations]

### Priority 2: [Feature] Pages (Week 2)
[Continue listing all pages]

## Technology Conversion Matrix

| React Concept | Phoenix LiveView Equivalent |
|--------------|------------------------------|
| useState | assign in socket |
| useEffect | handle_info / handle_event |
[Complete mapping table]

## File Structure to Create
[Directory tree for LiveView files]

## Component Patterns
[Code examples for:
- Basic LiveView page template
- LiveComponent pattern
- Function component pattern
]

## Routing Configuration
[Router.ex additions]

## Design System Implementation
[Color tokens, typography, component classes]

## Real-Time Updates Pattern
[PubSub integration examples]

## Accessibility Checklist
[WCAG requirements]

## Mobile Responsive Patterns
[Responsive class examples]

## Dark Mode Support
[Theme implementation]

## Performance Considerations
[Code splitting, data loading, debouncing]

## Testing Strategy
[LiveView test examples]

## Common Pitfalls to Avoid
[N+1 queries, missing CSRF, hard-coded URLs, etc.]

## Next Steps
[Implementation order and guidance]
```

**Output:** Complete UI conversion guide

---

### Step 7: Create Domain Models Track (Track 3)

**File:** `YYYYMMDD-03-[name]-domain-models/README.md`

**Contents:**
```markdown
# Track 3: Ash Domain Models & Data Layer

## Overview
Create Ash resources and database schema

**Figma Source:**
- `figma_src/[folder]/src/components/pages/[Page].tsx` (field types)
- [List relevant source files]

**Target Location:** `lib/[app]/`
**Database:** PostgreSQL via AshPostgres

## Critical Authorization Requirements
[RBAC roles and policies]

## Ash Domains to Create

### 1. [Domain Name] Domain
**File:** `lib/[app]/[domain].ex`

Resources:
- [Resource 1] - [Description]
- [Resource 2] - [Description]

## Resources to Implement

### Resource: [ResourceName]
**File:** `lib/[app]/[domain]/[resource].ex`
**Table:** `[table_name]`

**Attributes:**
[List all attributes with types]

**Relationships:**
[belongs_to, has_many, etc.]

**Actions:**
[CRUD + custom actions]

**Policies:**
[Authorization rules]

**Code Example:**
[Complete Ash resource definition]

## Database Schema (SQL)
[Complete CREATE TABLE statements]

## Migrations
[ash_postgres.generate_migrations commands]

## Calculations & Aggregates
[For analytics, derived data]

## Testing Strategy
[Resource test examples]

## Common Pitfalls
[Ash-specific issues to avoid]
```

**Output:** Complete domain models guide

---

### Step 8: Create Feature-Specific Tracks (Track 4+)

For each major feature domain (Analytics, Settings, etc.):

**File:** `YYYYMMDD-0N-[name]-[feature]/README.md`

**Contents:**
```markdown
# Track N: [Feature Name]

## Overview
[What this track implements]

**Source:** `figma_src/[folder]/src/components/pages/[Feature].tsx`
**Dependencies:** Track 2 (UI), Track 3 (Domain)
**Estimated Time:** [Duration]

## [Feature-Specific Sections]
[Metrics to track, pages to build, integrations, etc.]

## Technical Implementation
[LiveView code, Ash resources, calculations]

## Testing
[Feature-specific tests]

## Resources
[Documentation links]
```

**Output:** Feature implementation guides

---

### Step 9: Create Coverage Analysis

**File:** `YYYYMMDD-00-[name]-project-overview/FIGMA-COVERAGE-ANALYSIS.md`

**Contents:**
```markdown
# Figma Source Coverage Analysis

**Date:** [YYYY-MM-DD]
**Figma Source:** `figma_src/[folder]/`
**Dev Task Prompts:** `dev_task-prompts_and_plans/[parent-folder]/`

## Executive Summary
[Coverage status, issues found, component coverage %]

## Figma Export Inventory

### Statistics
- Total TypeScript Files: [N]
- Page Components: [N] ([Total Lines])
- Reusable Components: [N]
- UI Library Components: [N]

### Pages Breakdown
| Page | Lines | Track Coverage | Status |
|------|-------|----------------|--------|
[Complete table]

### Reusable Components
| Component | Purpose | Track Coverage | Status |
|-----------|---------|----------------|--------|
[Complete table]

### UI Library Components
[List all library components with conversion plan]

## Dev Task Prompts Coverage Analysis

### Track-by-Track Coverage
[For each track:
- Folder name
- Figma references (with line numbers)
- Coverage status
- Issues found
]

## Gap Analysis

### Critical Gaps (Must Fix)
[List issues with priority, impact, fix]

### Minor Gaps (Nice to Have)
[List minor issues]

## Recommendations
[High/Medium/Low priority fixes]

## Traceability Matrix
| Figma Page | Lines | Dev Task Track | README Section | Status |
|------------|-------|----------------|----------------|--------|
[Complete mapping]

## Component Mapping Verification
[Verify all components are documented]

## Conclusion
[Overall assessment, issues summary, next steps]
```

**Output:** Complete coverage analysis

---

### Step 10: Create UI Layout & Roles Specification (if applicable)

**File:** `YYYYMMDD-00-[name]-project-overview/UI-LAYOUT-AND-ROLES.md`

**Contents:**
```markdown
# UI Layout & Role-Based Access Control

## Overview
[Shared layout requirements and RBAC specification]

## Shared Layout Architecture

### Header Component
[Description and code example]

### Sidebar Component
[Description and code example with role-based visibility]

### Layout Integration
[How pages use the shared layout]

## Role-Based Access Control (RBAC)

### Roles Definition
[List all roles with permissions]

### Database Schema
[user_roles table SQL]

### Ash Resources
[UserRole resource definition]

### Authorization Helpers
[Helper functions for role checks]

### LiveView Integration
[How to use roles in LiveView]

## UI Patterns

### Detail Views vs Modals
[Guidelines for when to use each]

### Responsive Design
[Mobile, tablet, desktop breakpoints]

### Dark Mode
[Theme support]
```

**Output:** UI layout and RBAC specification

---

### Step 11: Verify and Fix Gaps

**Actions:**

1. **Check Figma References:**
   - Grep for "figma_src" in all track READMEs
   - Ensure every track (except overview) references source files
   - Add missing references

2. **Verify Component Coverage:**
   - Cross-reference component inventory with track documentation
   - Ensure all pages are mapped to implementation tracks
   - Document components that are intentionally out of scope

3. **Fix Broken Links:**
   - Check all markdown links work
   - Remove references to non-existent files
   - Add references to created documentation files

4. **Validate Consistency:**
   - Track numbers match across all READMEs
   - MVP scope is consistent everywhere
   - Phase descriptions match across documents
   - Timeline estimates are consistent

**Output:** All gaps fixed, documentation complete

---

### Step 12: Create E2E Test Documentation for Each Track

**Goal:** Generate E2E test documentation aligned with each implementation track

**Actions:**

1. **Analyze Features by Track:**
   - Review all MVP tracks (1-5)
   - Extract user-facing features specific to each track
   - Identify test priorities per track
   - Map features to user roles

2. **Define Test Priorities per Track:**
   - **Track 1 (Dashboard Primary):** P1 Critical path tests
     - Authentication & authorization
     - Dashboard KPIs
     - Form creation/publishing/submission
     - Role-based access control
   - **Track 2 (LiveView UI):** P3 Layout/UI tests
     - Shared layout (header, sidebar)
     - Responsive design
     - Dark mode (if MVP)
     - Accessibility
   - **Track 3 (Domain Models):** P2 Features + P4 Regression
     - Forms CRUD operations
     - Form lifecycle
     - Submissions management
     - Validation rules
     - Edge cases
   - **Track 4 (Analytics):** P2 Features
     - Dashboard KPIs
     - Per-form analytics
     - Chart visualization
     - Date range filtering
   - **Track 5 (Settings):** P2 Features
     - Profile management
     - Notification preferences
     - Integration placeholders

3. **Create E2E-TESTS.md in Each Track Folder:**

   File: `YYYYMMDD-0N-[track-name]/E2E-TESTS.md`

   Contents for each track:
   - Track name and priority level
   - Test count estimate
   - Execution time
   - When to run (commit/nightly/weekly)
   - Test location (folder structure)
   - Test suites with examples
   - Page objects needed
   - Test data requirements
   - Success criteria
   - Related documentation links

4. **Track-Specific Conte