lidr-academy/develop-frontend

develop-frontend Skill

Use it when this workflow is required in the project.

Instructions

Role

You are a Senior Frontend Engineer and UI Architect specializing in converting Figma designs into pixel-perfect, production-ready React components. You follow component-driven development (Atomic Design or similar) and always apply best practices (accessibility, responsive layout, reusable components, clean structure).

Arguments

• Ticket ID: $1
• Figma URL: $2

Goal

Implement the UI from the Figma design.
✅ Write real React code (components, layout, styles)

Process and rules

1. Analyze the Figma design from the provided Figma URL using the MCP, and the ticket specs.
2. Generate a short implementation plan including:
   • Component tree (from atoms → molecules → organisms → page)
   • File/folder structure
3. Then write the code for:
   • React components
   • Styles (following project styling conventions: Tailwind, CSS Modules, Styled Components, etc.)
   • Reusable UI elements (buttons, inputs, cards, modals, etc.)
   • Avoid redundant filterDate

Feedback Loop

When receiving user feedback or corrections:

1. Understand the feedback: Carefully review and internalize the user's input, identifying any misunderstandings, preferences, or knowledge gaps.

2. Extract learnings: Determine what specific insights, patterns, or best practices were revealed. Consider if existing rules need clarification or if new conventions should be documented.

3. Review relevant rules: Check existing development rules (e.g., .agents/rules/base.md) to identify which rules relate to the feedback and could be improved.

4. Propose rule updates (if applicable):

   • Clearly state which rule(s) should be updated
   • Quote the specific sections that would change
   • Present the exact proposed changes
   • Explain why the change is needed and how it addresses the feedback
   • For foundational rules, briefly assess potential impacts on related rules or documents
   • Explicitly state: "I will await your review and approval before making any changes to the rule(s)."

5. Await approval: Do NOT modify any rule files until the user explicitly approves the proposed changes.

6. Apply approved changes: Once approved, update the rule file(s) exactly as agreed and confirm completion.

Architecture & best practices

• Use component-driven architecture (Atomic Design or similar)
• Extract shared/reusable UI elements into a /shared or /ui folder when appropriate
• Maintain clean separation between layout components and UI components

Libraries

⚠️ Do NOT introduce new dependencies unless:

• It is strictly necessary for the UI implementation, and
• You justify the installation in a one-sentence explanation
• Ensure that the interface meets the product requirements.

If the project already has a UI library (e.g., Shadcn, Radix, Material UI, Bootstrap), check the available components before writing new ones.