forked from 77media/video-flow
65 lines
4.2 KiB
Plaintext
65 lines
4.2 KiB
Plaintext
# .cursorrules
|
|
|
|
# Code Generation and Modification Rules
|
|
- When generating or modifying code, strictly adhere to the user-specified task requirements and do not add extra functionality, edge cases, or unrequested sanity code.
|
|
- Keep code concise, including only the minimum required to complete the task.
|
|
- Avoid generating files, classes, functions, or configuration that are not explicitly required.
|
|
- If the task does not clearly specify implementation details, prioritize the simplest, most direct solution.
|
|
- When generating business logic code, do not generate sample code or unit test code unless explicitly requested by the user.
|
|
|
|
# CSS Style Rules
|
|
- All CSS styles must use Tailwind CSS 3.x syntax.
|
|
- Use of native CSS (e.g., style attributes or .css files) or other CSS frameworks (e.g., less) is prohibited.
|
|
- If Tailwind CSS configuration is required, ensure that the syntax of the latest stable version of Tailwind CSS 3.x is used.
|
|
|
|
# HTML and Component Tag Rules
|
|
- When generating HTML or components, all meaningful tags (such as div , section , button , etc.) must include a data-alt="xxxx" attribute describing the tag's purpose.
|
|
- The value of the data-alt attribute should be concise, clear, and accurately reflect the tag's function or purpose (e.g., "main-content" or "submit-button").
|
|
- Examples:
|
|
- <div data-alt="main-content" class="p-4 bg-gray-100">...</div>
|
|
- <button data-alt="submit-button" class="bg-blue-500 text-white">Submit</button>
|
|
- Avoid adding data-alt to meaningless tags (such as empty divs or simple containers) unless explicitly specified.
|
|
|
|
# Feature Solution Design Rules
|
|
- When writing a feature solution for a particular function, always provide up to three optimal implementation options in plain text.
|
|
- Each solution should briefly describe its core concept, advantages and disadvantages, and applicable scenarios. - Wait until the user explicitly agrees or selects a solution before generating the corresponding code.
|
|
- Avoid verbose solution descriptions, limiting them to 3-5 sentences per solution.
|
|
|
|
# Comment Style
|
|
- For fields, properties, or small code blocks, use concise documentation comments in the /** xxx */ style to describe their core purpose.
|
|
- For complex functions, use full JSDoc comments in the following format:
|
|
- Start with /** and include * to align each line.
|
|
- Include @description to describe the function's main functionality.
|
|
- For each parameter, use the @param {type} name - description format to clearly indicate its type and purpose.
|
|
- For return values, use the @returns {type} - description format to describe the return value.
|
|
- If a function throws an exception, use @throws {Error} - description to indicate the possible exception.
|
|
- If appropriate, include @example to provide a brief usage example.
|
|
- Example:
|
|
/**
|
|
* Calculates the sum of two numbers.
|
|
* @param {number} a - The first number.
|
|
* @param {number} b - The second number.
|
|
* @returns {number} - The sum of a and b.
|
|
* @throws {Error} - If inputs are not numbers.
|
|
* @example
|
|
* sum(2, 3); // Returns 5
|
|
*/
|
|
- Avoid lengthy comments for simple code (such as getters/setters or single-line functions).
|
|
- Comments should be concise and avoid lengthy descriptions.
|
|
- Ensure that comments are comprehensive.
|
|
|
|
# Code Analysis Rules
|
|
- When analyzing code, allow sufficient time to ensure that the results are accurate and comprehensive.
|
|
- Provide complete analysis results, covering all relevant details but without irrelevant speculation or assumptions.
|
|
- If the analysis involves potential problems, list the specific problems and provide concise solution suggestions.
|
|
- Analyze but don't directly modify files to generate code. Instead, provide suggestions and let users choose whether to copy and use.
|
|
|
|
# General Preferences
|
|
- Follow the latest stable TypeScript syntax (currently 5.x).
|
|
- Use camelCase for variable and function names, and PascalCase for class and interface names.
|
|
- Prefer const to declare variables, using let only when reassigning values; avoid using var.
|
|
- Follow Airbnb TypeScript standards for coding style (e.g., 4-space indentation, single quotes).
|
|
- Avoid generating console.log or debugging code unless explicitly requested by the user.
|
|
- Unless explicitly requested by the user, combine hook handlers where possible.
|
|
- Always use async over .then for asynchronous functions.
|