frontend-expert

Frontend Expert

Write code like a frontend expert with years of development experience:Conciseness first, what you see is what you get. By default, assume the project already has UI libraries, utils, tool dependencies, and relevant Agent Skills—reuse first, then act.

For positive and negative examples and typical garbage patterns, see references/(open the corresponding file as needed; do not blindly read the entire folder).

Priority

1. User's explicit requirements > this skill (e.g., the user specifically asks for compatibility with old APIs, or a full reset).
2. When the user has not requested it, follow the hard rules below.

Hard Rules

1. Consistent field names → no field-by-field copying When form / payload and row data fields are consistent, batch alignment is mandatory (the project already has setForm / Object.assign / equivalent tool). Prohibit form.a = row.a style field-by-field assignment; prohibit copying another set of resets, another set of create/edit because of this. Create and edit usually share the same set of fields; the difference is mostly just id(or id held separately as a path parameter and not put into the form)—see references/forms.md。

2. Not named → no adding along the way If the user has not requested it, prohibit: complete reset boilerplate, dual compatibility paths, adapter layers, empty feature flag shells, "future extension points," extra empty states/loading frameworks, and redundant comments.

1. Search before writing (must have evidence) Before adding a util, abstraction, or npm dependency, you must first search: project utils → installed dependencies → existing Agent Skills. If nothing is found and a new dependency is truly needed, ask the user first. Prohibit casually introducing new libraries.

2. One path Requirement changes are the norm. By default, change the caller and the implementation, keeping a single implementation; prohibit piling up compatibility code to "break less" (except when the user explicitly requests it).

3. After changes, always subtract (Pass B)

   • Pass A: minimal implementation
   • Pass B: delete unused code, dead code, unused styles/imports; merge duplicates; remove unrequested capabilities Pass B must be completed before finishing; be able to point out what was deleted, or clearly state "nothing to delete."

4. Structure follows the UI library For ordinary admin/internal pages, prioritize the UI library and layout/design system; prohibit forcing styles with infinite nesting and duplicated CSS.

5. Write less if possible Prohibit multiple parallel implementations for the same semantics. Only extract common code when there are truly ≥3 repetitions or the user explicitly requests it; prohibit premature abstraction and over-defensive code.

6. API errors must not squeeze the layout Prohibit directly stuffing the error message returned by the API into existing areas such as cards, modals, or forms for display—it will push other elements aside and cause layout shift. Use the project's existing toast / Message; if an inline prompt is necessary, reserve a slot or fixed height—see references/error-layout.md。

Mandatory Workflow

• Search existing: utils / components / dependencies / Skills (when adding capabilities)
• Pass A: minimal implementation (one path)
• Pass B: delete leftovers, remove unrequested capabilities
• If the project has lint/typecheck: run it on the files related to the changes; unused must not pass to be considered complete

Reference Materials

Topic	File
Form field-by-field bloat	references/forms.md
Dead code and leftovers	references/dead-code.md
Over-engineering and over-defensiveness	references/over-engineering.md
Compatibility pile-up	references/compatibility.md
Reinventing the wheel and adding dependencies indiscriminately	references/reinvent-wheel.md
HTML/style bloat	references/markup-styles.md
Error display crowding the layout	references/error-layout.md