apply-yliu-frontend-practices

Apply Yliu Frontend Practices

Apply Yliu's personal engineering practices to browser-side React and Vue frontend code. Covers writing, refactoring, and code review; does not handle server-side modules.

Determine priorities

Decide according to the following priorities:

1. The user's explicit request in this instance.
2. Specifications, abstractions, and dependencies already stably used by the project.
3. The default practices of this skill.

First check the dependency manifest and the existing implementation involved in the task. Reuse the project's existing mature solutions; do not introduce functionally duplicate libraries in parallel, and do not migrate unrelated code for the sake of applying this skill.

Read specifications on demand

Read only the reference files involved in the current task in full; when the task spans multiple categories, read all relevant files:

• When Axios, API modules, request Hooks, business errors, or operation feedback are involved, read requests-and-feedback.md。
• When Hook/Composable extraction, request execution timing, route performance, detail pages, or Pinia data sources are involved, read hooks-and-routing.md. For network Hooks, also read the request specification.
• When Loading, Error, Empty, layout stability, dangerous operations, component libraries, UnoCSS, or styles are involved, read ui-states-and-styling.md。
• When adding, adjusting, or reviewing tests, read testing.md。

Do not load all references by default just to "understand the whole picture"; choose based on the actual scope of the task.

Execute the work

Writing or refactoring

1. Read the relevant reference files.
2. Check similar code and dependencies in the project to confirm existing conventions.
3. Implement only the minimal changes required by the task.
4. Make new code consistent with the project style, and apply the default practices from the reference files.
5. Run checks commensurate with the risk of the changes.

Code review

1. Read the reference files involved in the review scope.
2. Report only real, locatable issues, explaining the impact and the minimal fix direction.
3. Sort by severity; avoid packaging personal preferences as defects.
4. Do not modify code directly when the user has not asked for a fix.

Core constraints

• Do not guess business success status; first look it up in the project, and if it is still unclear, ask the user.
• Do not let public abstractions implicitly start requests not needed by the current page.
• Do not let detail pages depend on the in-memory state of the previous page; use the core URL parameters to request the current detail.
• Do not display request feedback repeatedly, and do not disguise failure as a successful return value.
• Do not create all-purpose components, thin wrapper Hooks, or new duplicate dependencies for the sake of reuse.
• Do not test ordinary copy and volatile presentation details unless the user explicitly requests it.