mirror of
https://github.com/azaion/ai-training.git
synced 2026-04-22 22:26:36 +00:00
Oleksandr Bezdieniezhnykh
fb5191a663
- 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.
32 lines
3.2 KiB
Plaintext
32 lines
3.2 KiB
Plaintext
---
|
|
description: "Enforces concise, comment-free, environment-aware coding standards with strict scope discipline and test verification"
|
|
alwaysApply: true
|
|
---
|
|
# Coding preferences
|
|
- Always prefer simple solution
|
|
- Generate concise code
|
|
- Do not put comments in the code, except in tests: every test must use the Arrange / Act / Assert pattern with language-appropriate comment syntax (`# Arrange` for Python, `// Arrange` for C#/Rust/JS/TS). Omit any section that is not needed (e.g. if there is no setup, skip Arrange; if act and assert are the same line, keep only Assert)
|
|
- Do not put logs unless it is an exception, or was asked specifically
|
|
- Do not put code annotations unless it was asked specifically
|
|
- Write code that takes into account the different environments: development, production
|
|
- You are careful to make changes that are requested or you are confident the changes are well understood and related to the change being requested
|
|
- Mocking data is needed only for tests, never mock data for dev or prod env
|
|
- Make test environment (files, db and so on) as close as possible to the production environment
|
|
- When you add new libraries or dependencies make sure you are using the same version of it as other parts of the code
|
|
- 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.
|
|
- 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
|
|
- Do not touch code that is unrelated to the task
|
|
- Always think about what other methods and areas of code might be affected by the code changes
|
|
- When you think you are done with changes, run the full test suite. Every failure — including pre-existing ones, collection errors, and import errors — is a **blocking gate**. Never silently ignore, skip, or proceed past a failing test. On any failure, stop and ask the user to choose one of:
|
|
- **Investigate and fix** the failing test or source code
|
|
- **Remove the test** if it is obsolete or no longer relevant
|
|
- Do not rename any databases or tables or table columns without confirmation. Avoid such renaming if possible.
|
|
|
|
- Make sure we don't commit binaries, create and keep .gitignore up to date and delete binaries after you are done with the task
|
|
- Never force-push to main or dev branches
|
|
- Place all source code under the `src/` directory; keep project-level config, tests, and tooling at the repo root
|