Frontend-Workflow

Frontend Workflow: Frontend Project Orchestration

1. Top Priority: Read the Project First

Before modifying any files, you must:

1. Read AGENTS.md, CLAUDE.md, README, and other applicable development conventions in the project root.
2. Inspect package.json, lock files, build configuration, routing configuration, and existing components.
3. Identify the current project's tech stack, framework version, UI component library, CSS approach, and run commands.
4. If the project is a front-end/back-end separated project, clarify the boundary between frontend and backend and do not modify backend API contracts without authorization.
5. If the project already has a design system, component conventions, or page styles, prioritize inheriting and improving them, rather than rebuilding from scratch.

Do not determine the tech stack solely based on user descriptions or directory names; you must inspect the actual files.

2. Identify Tech Stack and Decide Skill Usage

Case A: React Project

Execute in order:

1. frontend-design: Determine visual direction, design specifications, and page layout.
2. frontend-production-shadcn: Implement components, layout, and interaction, provided the project is compatible.
3. premium-ui: Inspect the actual page and drive fixes.

Only directly use the specific component implementation plan from that skill when the project has already adopted or explicitly allows the corresponding technologies (React, Tailwind CSS, shadcn/ui).

Case B: Vue 3 Project

Execute in order:

1. frontend-design: Determine visual direction, design specifications, and page layout.
2. Use frontend-production-shadcn only as a reference for design conventions and engineering quality—do not execute instructions specific to React, JSX, React Hooks, or shadcn/ui.
3. Complete the implementation using the project's existing Vue 3, TypeScript, routing, UI component library, and CSS approach.
4. premium-ui: Inspect the actual page and drive fixes.

Do not migrate a Vue 3 project to React just to fit a second skill.

Case C: Other Tech Stacks

First inspect the project's existing technologies and constraints. Use frontend-design for visual planning, refer to transferrable design principles from frontend-production-shadcn, and implement using technologies applicable to the current project. Finally, use premium-ui's review methodology for acceptance.

3. Strictly Execute the Three Phases

Phase One: Visual Design

Invoke frontend-design.

Requirements:

• Clarify the page goal, primary users, and core actions.
• Determine visual direction, fonts, colors, spacing, layout, and information hierarchy.
• Propose substantially different design directions and explain the final selection rationale.
• Produce an actionable design specification before beginning implementation.

Phase Two: Engineering Implementation

Invoke frontend-production-shadcn (or only refer to its design principles) depending on the tech stack.

Requirements:

• Reuse existing components and dependencies first.
• Implement complete pages, navigation, forms, responsive layout, and interaction states.
• Handle loading, empty data, error, disabled, and success feedback.
• Keep real business logic—do not mock interactions to pretend functionality is complete.
• Do not perform large-scale refactoring or framework replacement without authorization.

Phase Three: Visual QA

Invoke premium-ui to inspect the real implementation, not just read the code.

Requirements:

• Prefer to start the project and inspect pages using available browser or screenshot tools.
• Check typography, alignment, whitespace, colors, hierarchy, component consistency, and responsive behavior.
• Verify that buttons, forms, navigation, and main interactions work.
• Document gaps between design goals and actual appearance.
• Fix identified issues and re-inspect.

If the environment lacks browser or screenshot capabilities, you must clearly state that you cannot perform a true visual QA — do not claim to have checked the page's visual state.

4. Execution Rules

1. After each phase, briefly report the conclusion before moving to the next phase.
2. If a skill does not exist, is not loaded, or cannot be executed, state it clearly and adopt a feasible alternative.
3. Do not assume other skills will run automatically; explicitly request invocation or reading of the corresponding skill when necessary.
4. Follow user explicit requirements, project conventions, and the existing tech stack.
5. Do not sacrifice accessibility, maintainability, performance, or business correctness for visual effects.
6. After completion, run the project's supported build, lint, and test commands and report the results.

5. Final Delivery

Upon completion, report:

• Identified tech stack and versions.
• Adopted design direction and key design decisions.
• Modified files and their functional purpose.
• Execution status of each of the three phases.
• Build, test, and actual visual inspection results.
• Outstanding issues and items requiring human confirmation.