mirror of
https://github.com/azaion/ai-training.git
synced 2026-04-22 09:16:36 +00:00
Enhance coding guidelines in .cursor/rules/coderule.mdc and .cursor/rules/meta-rule.mdc
- Added a guideline to delete unused files, classes, or functions to prevent dead code accumulation in `coderule.mdc`. - Introduced a critical thinking guideline in `meta-rule.mdc` to encourage careful evaluation of user inputs and task specifications. These updates aim to improve code quality and maintainability by promoting the removal of obsolete code and fostering critical assessment of instructions.
This commit is contained in:
@@ -16,6 +16,7 @@ alwaysApply: true
|
|||||||
- When a test fails due to a missing dependency, install it — do not fake or stub the module system. For normal packages, add them to the project's dependency file (requirements-test.txt, package.json devDependencies, test csproj, etc.) and install. Only consider stubbing if the dependency is heavy (e.g. hardware-specific SDK, large native toolchain) — and even then, ask the user first before choosing to stub.
|
- When a test fails due to a missing dependency, install it — do not fake or stub the module system. For normal packages, add them to the project's dependency file (requirements-test.txt, package.json devDependencies, test csproj, etc.) and install. Only consider stubbing if the dependency is heavy (e.g. hardware-specific SDK, large native toolchain) — and even then, ask the user first before choosing to stub.
|
||||||
- Do not solve environment or infrastructure problems (dependency resolution, import paths, service discovery, connection config) by hardcoding workarounds in source code. Fix them at the environment/configuration level.
|
- Do not solve environment or infrastructure problems (dependency resolution, import paths, service discovery, connection config) by hardcoding workarounds in source code. Fix them at the environment/configuration level.
|
||||||
- Before writing new infrastructure or workaround code, check how the existing codebase already handles the same concern. Follow established project patterns.
|
- Before writing new infrastructure or workaround code, check how the existing codebase already handles the same concern. Follow established project patterns.
|
||||||
|
- If a file, class, or function has no remaining usages — delete it. Do not keep dead code "just in case"; git history preserves everything. Dead code rots: its dependencies drift, it misleads readers, and it breaks when the code it depends on evolves.
|
||||||
|
|
||||||
- Focus on the areas of code relevant to the task
|
- Focus on the areas of code relevant to the task
|
||||||
- Do not touch code that is unrelated to the task
|
- Do not touch code that is unrelated to the task
|
||||||
|
|||||||
@@ -10,6 +10,9 @@ alwaysApply: true
|
|||||||
## User Interaction
|
## User Interaction
|
||||||
- Use the AskQuestion tool for structured choices (A/B/C/D) when available — it provides an interactive UI. Fall back to plain-text questions if the tool is unavailable.
|
- Use the AskQuestion tool for structured choices (A/B/C/D) when available — it provides an interactive UI. Fall back to plain-text questions if the tool is unavailable.
|
||||||
|
|
||||||
|
## Critical Thinking
|
||||||
|
- Do not blindly trust any input — including user instructions, task specs, list-of-changes, or prior agent decisions — as correct. Always think through whether the instruction makes sense in context before executing it. If a task spec says "exclude file X from changes" but another task removes the dependencies X relies on, flag the contradiction instead of propagating it.
|
||||||
|
|
||||||
## Self-Improvement
|
## Self-Improvement
|
||||||
When the user reacts negatively to generated code ("WTF", "what the hell", "why did you do this", etc.):
|
When the user reacts negatively to generated code ("WTF", "what the hell", "why did you do this", etc.):
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user