它的核心目标不是直接替你拍板，而是让 Agent 在开始写前端或者重构前端之前，先系统化地向你提问，把这些关键问题问清楚：
-
项目类型是什么
-
用户是谁
-
页面模式有哪些
-
数据流怎么走
-
组件体系怎么分层
-
状态管理怎么选
-
路由和布局怎么组织
-
是否 SSR / CSR / SSG
-
是否要移动端适配
-
是否有设计系统
-
团队约束和交付节奏是什么
name: “frontend-architecture-planner”
description: “Use when starting a new frontend project or refactoring an existing one. This skill asks structured questions to clarify product scope, UI patterns, component architecture, data flow, state management, routing, rendering strategy, styling, and engineering constraints before implementation.”
Frontend Architecture Planner Skill
Purpose
This skill helps the agent determine the correct frontend architecture before coding.
The agent must not jump straight into implementation. It should first ask structured questions, identify constraints, summarize decisions, and only then propose an architecture.
This skill is designed to avoid premature implementation and reduce architectural drift.
When to use
Use this skill when:
- starting a new frontend project
- redesigning or refactoring an existing frontend
- defining project structure before implementation
- choosing routing, state, styling, rendering, and component strategies
- standardizing engineering conventions across a frontend codebase
- building reusable design systems or product shells
- clarifying unclear product requirements before coding UI
Core rule
Do not begin implementation until enough architectural questions have been answered.
The agent should first clarify the system, then recommend the architecture, then ask for confirmation if major tradeoffs exist.
Workflow
Step 1: Clarify the product and delivery context
Ask the user:
- What kind of frontend is this: dashboard, marketing site, admin panel, SaaS app, editor, e-commerce, internal tool, mobile web app, or other?
- Who are the primary users?
- What are the top 3 to 5 user tasks?
- Is this a new project or a refactor of an existing one?
- Is this single-team or multi-developer collaboration?
- Is speed of delivery more important, or long-term maintainability?
- Are there existing design references, wireframes, or product constraints?
Step 2: Clarify page and interaction patterns
Ask the user:
- What page types exist: list page, detail page, create/edit form, dashboard, wizard, settings, auth, landing page, etc.?
- Which interactions are core: search, filtering, sorting, pagination, inline edit, drag-and-drop, file upload, modal workflows, real-time updates?
- Which components are critical: input, select, date picker, table, drawer, tabs, tree, chart, editor?
- Are there complex form flows?
- Are there responsive requirements?
- Are accessibility and keyboard interactions required?
The agent must identify repeated page patterns and repeated component patterns.
Step 3: Clarify rendering and delivery strategy
Ask the user:
- Is SEO important?
- Should the project use SSR, SSG, CSR, or hybrid rendering?
- Is fast first paint important?
- Does the app need authenticated private routes?
- Will the app run as a public website, internal tool, embedded app, or desktop shell?
- Does the app need internationalization?
Step 4: Clarify data and state architecture
Ask the user:
- Where does data come from: REST, GraphQL, RPC, local storage, realtime backend?
- Is there caching or offline behavior?
- Is data mostly server state or client state?
- Are there complex cross-page states?
- Does the project need optimistic updates?
- Does the user already prefer a stack such as React Query, Zustand, Redux, SWR, Apollo, or context-only?
The agent should distinguish:
- server state
- client UI state
- form state
- derived state
- persistent state
Step 5: Clarify component architecture
Ask the user:
- Should the project use an external UI library or custom components?
- Is there an existing design system?
- Should components be divided into primitives, shared business components, and page-level containers?
- Should forms, tables, filters, and dialogs follow common patterns?
- Does the user want strict reuse rules?
The agent must determine whether the codebase needs:
- design tokens
- primitive UI components
- shared layout shell
- domain components
- feature modules
- page compositions
Step 6: Clarify styling system
Ask the user:
- Preferred styling approach: Tailwind, CSS Modules, styled-components, Emotion, Sass, or other?
- Is there already a color system, spacing scale, typography scale, radius, and shadow system?
- Is dark mode required?
- Should all pages inherit from a common app layout?
- Are responsive breakpoints already defined?
The agent should identify whether the project needs:
- design tokens
- shared layout rules
- spacing system
- typography rules
- responsive rules
- component appearance rules
Step 7: Clarify engineering conventions
Ask the user:
- Is TypeScript required?
- How strict should typing be?
- What testing level is expected: none, unit, component, E2E?
- Is Storybook needed?
- Are there linting, formatting, and CI requirements?
- How should folders be organized?
- Are there naming conventions for files, hooks, services, and components?
- Are there performance constraints or bundle-size concerns?
Step 8: Synthesize decisions
After enough answers are collected, summarize the architecture in this structure:
- Product type
- Primary user goals
- Page types
- Interaction complexity
- Rendering strategy
- Routing strategy
- Layout strategy
- Component layering
- Styling strategy
- State strategy
- Data-fetching strategy
- Form strategy
- Engineering conventions
- Risks and unresolved decisions
Step 9: Propose the architecture
The agent should then propose:
- recommended framework/runtime
- recommended routing model
- recommended project folder structure
- recommended state management split
- recommended component layering
- recommended shared layout pattern
- recommended styling approach
- recommended testing scope
- recommended implementation sequence
The proposal must explain tradeoffs, not just list tools.
Step 10: Confirm before implementation
Before coding, ask the user to confirm or adjust:
- architecture direction
- state strategy
- styling strategy
- component boundaries
- project structure
Only after that should implementation begin.
Decision principles
The agent should optimize for:
- clarity before speed
- consistency before novelty
- reuse before duplication
- explicit state boundaries
- predictable page patterns
- maintainable component layering
- user interaction quality, not only visual consistency
Anti-patterns
Do not:
- start coding before clarifying major architectural unknowns
- choose libraries only based on popularity
- mix server state and UI state without rationale
- let every page invent its own layout pattern
- let every form invent its own validation behavior
- let every component define ad hoc interaction rules
- assume a style system is enough to define architecture
- reduce architecture to folder naming only
Output format
When using this skill, the agent should respond in 4 sections:
1. Clarifying Questions
Ask grouped questions by category:
- product
- pages
- interactions
- data/state
- styling
- engineering constraints
2. Preliminary Architectural Read
Briefly state what the current answers imply.
3. Recommended Direction
Propose the likely architecture direction, with tradeoffs.
4. Open Decisions
List what still must be decided before coding.
Preferred questioning style
- Ask in grouped batches, not one question at a time.
- Ask only architecture-relevant questions.
- Prefer concrete choices over vague brainstorming.
- When possible, provide options for the user to choose from.
- If the user already implied a preference, use it instead of re-asking.
- If uncertainty remains, identify the architectural risk explicitly.
Example prompts that should trigger this skill
- Help me define the frontend architecture before coding
- Ask me questions to determine the right frontend stack
- I want to design a maintainable React frontend structure
- Help me choose routing, state, and component structure
- Before writing the UI, clarify the architecture with me
- Help me plan a frontend app shell and component system