azaion/detections
1
0
Fork 0
mirror of https://github.com/azaion/detections.git synced 2026-04-23 01:26:32 +00:00
Code Issues Packages Projects Releases Wiki Activity

Generalize tracker references, restructure refactor skill, and strengthen coding rules

Browse Source 
- 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
This commit is contained in:
Oleksandr Bezdieniezhnykh
2026-03-28 02:42:36 +02:00
parent 5be53739cd
commit d28b9584f2
47 changed files with 1248 additions and 884 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.cursor/skills/document/SKILL.md
+4 -4
View File
@@ -177,7 +177,7 @@ Re-entry is seamless: `state.json` tracks exactly which modules are done.
- By directory structure (most common)
- By shared data models or common purpose
- By dependency clusters (tightly coupled modules)
2. For each identified component, synthesize its module docs into a single component specification using `templates/component-spec.md` as structure:
2. For each identified component, synthesize its module docs into a single component specification using `.cursor/skills/plan/templates/component-spec.md` as structure:
- High-level overview: purpose, pattern, upstream/downstream
- Internal interfaces: method signatures, DTOs (from actual module code)
- External API specification (if the component exposes HTTP/gRPC endpoints)
@@ -214,7 +214,7 @@ All documents here are derived from component docs (Step 2) + module docs (Step
#### 3a. Architecture
Using `templates/architecture.md` as structure:
Using `.cursor/skills/plan/templates/architecture.md` as structure:
- System context and boundaries from entry points and external integrations
- Tech stack table from discovery (Step 0) + component specs
@@ -229,7 +229,7 @@ Using `templates/architecture.md` as structure:
#### 3b. System Flows
Using `templates/system-flows.md` as structure:
Using `.cursor/skills/plan/templates/system-flows.md` as structure:
- Trace main flows through the component interaction graph
- Entry point -> component chain -> output for each major flow
@@ -370,7 +370,7 @@ This is the inverse of normal workflow: instead of problem -> solution -> code,
**Role**: Technical writer
**Goal**: Produce `FINAL_report.md` integrating all generated documentation.
Using `templates/final-report.md` as structure:
Using `.cursor/skills/plan/templates/final-report.md` as structure:
- Executive summary from architecture + problem docs
- Problem statement (transformed from problem.md, not copy-pasted)