Use Yliu's method to complete product development. It covers pre-development confirmation, project initialization, technology selection, front-end and back-end implementation, page interaction, testing, and pre-delivery verification.
This method provides default choices, but it will not override user requirements, nor will it force a full migration of old projects.
Decision order
When encountering different approaches, decide in the following order:
- First, follow the user's explicit requirements for this task.
- When the user has not specified, continue using the approach already stably used by the project.
- When neither of the first two provides an answer, then adopt the default approach of this skill.
New projects can directly adopt this skill. Old projects use a gradual approach by default: new code uses the new approach; old code that needs to be modified for this task can be adjusted along the way; other old code remains unchanged. Only when the user explicitly requests a full refactor should a unified migration be carried out.
Only when the user explicitly states that the project is currently in the development phase, or explicitly requests that we be responsible for implementing a feature from scratch, should the corresponding project or feature be treated as being in the development phase. Do not infer this on your own based on version numbers, code maturity, or ongoing development. Within the scope explicitly specified by the user, compatibility with the old implementation may be omitted, and adjustments or refactoring may be made directly according to best practices without being limited to gradual adaptation; other explicit constraints of the user must still be followed, and authorization for a single feature must not be extended to unrelated features or the entire repository.
Workflow
- First review the task, existing code, dependencies, scripts, and configuration to understand the goals, constraints, and the project's current approach, and clarify the verifiable results that should appear after completion.
- Confirm directly any information that can be confirmed from the project; do not ask again. Clarify key ambiguities that affect scope, behavior, or implementation direction first; judge low-risk details yourself, and clearly state the necessary assumptions and trade-offs that affect the results.
- According to the task scope, read the corresponding specifications below. For complex tasks, provide brief steps and the corresponding verification methods; for simple tasks, execute directly.
- Before writing code, first check whether it can be reused in the project, then evaluate mature community solutions. Adopt the simplest implementation that satisfies the current requirements; when a simpler feasible solution is found, proactively propose it, and explain the problems with the original solution if necessary.
- By default, follow the project style and only make the changes needed for the current task; explicitly authorized refactoring should be carried out within the authorized scope.
- Verify the results according to the scope of changes and risk. If verification fails, continue to locate and correct the issue; when encountering an unsolvable obstacle, explain the reason. When completing, explain the verification results and the parts not yet verified.
Read specifications as needed
- When involving target users, device and theme scope, cross-platform differences, project initialization, ports, package management, Monorepo, Git hook,
.gitattributes, technology selection, aliases, or community solutions, read project-and-architecture.md。 - When involving TypeScript, scope of changes, code cleanup, comments, Hook, Composable, component abstraction, or code reuse, read implementation-practices.md。
- When involving APIs, requests, routing, page data, Loading, error feedback, dangerous operations, or styles, read requests-routing-and-ui.md。
- When involving databases, ORM, data validation, unified responses, Swagger, time, environment variables, back-end logs, or production orchestration, read backend-data-and-runtime.md。
- When involving testing, type checking, Lint, formatting, building, or post-completion verification, read testing-and-validation.md。
When a task involves multiple aspects, read all relevant specifications. Ordinary tasks do not need to load all files just to understand the full picture.
Core principles
- New projects directly adopt the new approach; existing projects by default are adapted gradually only when modified; compatibility exceptions during development follow the decision order above.
- First reuse the project's existing capabilities, then evaluate mature community solutions. Only when neither is suitable should you implement it yourself.
- Isomorphic projects prioritize reusing language, types, and validation rules to reduce duplicate maintenance.
- A page only manages its own requests. Cross-page core state should preferably be placed in the URL.
- Request failures must enter the error flow. Loading should affect only the corresponding area as much as possible.
- Do not add unrequested features, configurations, or extension capabilities. Abstractions and dependencies must bring actual benefits, and do not design for hypothetical needs.
- Only test important and stable behavior. The intensity of checks should remain consistent with the risk of the change.