mirror of
https://github.com/azaion/detections.git
synced 2026-04-22 10:36:32 +00:00
Oleksandr Bezdieniezhnykh
d28b9584f2
- Replace all Jira-specific references with generic tracker/work-item terminology (TRACKER-ID, work item epics); delete project-management.mdc and mcp.json.example - Restructure refactor skill: extract 8 phases (00–07) and templates into separate files; add guided mode for pre-built change lists - Add Step 3 "Code Testability Revision" to existing-code workflow (renumber steps 3–12 → 3–13) - Simplify autopilot state file to minimal current-step pointer - Strengthen coding rules: AAA test comments per language, test failures as blocking gates, dependency install policy - Add Docker Suitability Assessment to test-spec and test-run skills (local vs Docker execution) - Narrow human-attention sound rule to human-input-needed only - Add AskQuestion fallback to plain text across skills - Rename FINAL_implementation_report to implementation_report_* - Simplify cursor-meta (remove _docs numbering table, quality thresholds) - Make techstackrule alwaysApply, add alwaysApply:false to openapi
27 lines
2.4 KiB
Plaintext
27 lines
2.4 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
|
|
- 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.
|
|
|
|
- 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
|