Fix .cursor skills consistency: flow resolution, tracker-agnostic refs, report naming, error recovery

- Rewrite autopilot flow resolution to 4 deterministic rules based on source code + docs + state file presence
- Replace all hard-coded Jira references with tracker-agnostic terminology across 30+ files
- Move project-management.mdc to _project.md (project-specific, not portable with .cursor)
- Rename FINAL_implementation_report.md to context-dependent names (implementation_report_tests/features/refactor)
- Remove "acknowledged tech debt" option from test-run — failing tests must be fixed or removed
- Add debug/error recovery protocol to protocols.md
- Align directory paths: metrics -> 06_metrics/, add 05_security/, reviews/, 02_task_plans/ to README
- Add missing skills (test-spec, test-run, new-task, ui-design) to README
- Use language-appropriate comment syntax for Arrange/Act/Assert in coderule + testing rules
- Copy updated coderule.mdc to parent suite/.cursor/rules/
- Raise max task complexity from 5 to 8 points in decompose
- Skip test-spec Phase 4 (script generation) during planning context
- Document per-batch vs post-implement test run as intentional
- Add skill-internal state cross-check rule to state.md
This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-03-28 02:34:00 +02:00
parent cbf370c765
commit cdcd1f6ea7
33 changed files with 225 additions and 150 deletions
+1 -2
View File
@@ -5,7 +5,7 @@ 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 `# Arrange`, `# Act`, `# Assert` section comments. 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 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
@@ -20,7 +20,6 @@ alwaysApply: true
- 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
- **Leave as-is for now** (acknowledged tech debt — not recommended)
- 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
+2 -2
View File
@@ -1,8 +1,8 @@
---
description: "Git workflow: work on dev branch, commit message format with Jira IDs"
description: "Git workflow: work on dev branch, commit message format with tracker IDs"
alwaysApply: true
---
# Git Workflow
- Work on the `dev` branch
- Commit message format: `[JIRA-ID-1] [JIRA-ID-2] Summary of changes`
- Commit message format: `[TRACKER-ID-1] [TRACKER-ID-2] Summary of changes`
-7
View File
@@ -1,7 +0,0 @@
# Project Management
- This project uses **Jira ONLY** for work item tracking (NOT Azure DevOps)
- Jira project key: `AZ` (AZAION)
- Jira cloud ID: `1598226f-845f-4705-bcd1-5ed0c82d6119`
- Use the `user-Jira-MCP-Server` MCP server for all Jira operations
- Never use Azure DevOps MCP for this project's work items
+1 -1
View File
@@ -4,7 +4,7 @@ globs: ["**/*test*", "**/*spec*", "**/*Test*", "**/tests/**", "**/test/**"]
---
# Testing
- Structure every test with `//Arrange`, `//Act`, `//Assert` comments
- Structure every test with Arrange / Act / Assert section comments using language-appropriate syntax (`# Arrange` for Python, `// Arrange` for C#/Rust/JS/TS)
- One assertion per test when practical; name tests descriptively: `MethodName_Scenario_ExpectedResult`
- Test boundary conditions, error paths, and happy paths
- Use mocks only for external dependencies; prefer real implementations for internal code