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

- 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

.cursor/skills/plan/steps/01_artifact-management.md

@@ -67,7 +67,7 @@ DOCUMENT_DIR/
 | Step 3 | Diagrams generated | `diagrams/` |
 | Step 4 | Risk assessment complete | `risk_mitigations.md` |
 | Step 5 | Tests written per component | `components/[##]_[name]/tests.md` |
-| Step 6 | Epics created in Jira | Jira via MCP |
+| Step 6 | Epics created in work item tracker | Tracker via MCP |
 | Final | All steps complete | `FINAL_report.md` |
 
 ### Save Principles

.cursor/skills/plan/steps/06_work-item-epics.md

@@ -7,7 +7,7 @@
 **Constraints**: Epic descriptions must be **comprehensive and self-contained** — a developer reading only the epic should understand the full context without needing to open separate files.
 
 1. **Create "Bootstrap & Initial Structure" epic first** — this epic will parent the `01_initial_structure` task created by the decompose skill. It covers project scaffolding: folder structure, shared models, interfaces, stubs, CI/CD config, DB migrations setup, test structure.
-2. Generate epics for each component using the configured work item tracker (Jira MCP or Azure DevOps MCP — see `autopilot/protocols.md`), structured per `templates/epic-spec.md`
+2. Generate epics for each component using the configured work item tracker (see `autopilot/protocols.md` for tracker detection), structured per `templates/epic-spec.md`
 3. Order epics by dependency (Bootstrap epic is always first, then components based on their dependency graph)
 4. Include effort estimation per epic (T-shirt size or story points range)
 5. Ensure each epic has clear acceptance criteria cross-referenced with component specs
@@ -22,7 +22,7 @@ Each epic description MUST include ALL of the following sections with substantia
 - **Architecture notes**: relevant ADRs, technology choices, patterns used, key design decisions
 - **Interface specification**: full method signatures, input/output types, error types (from component description.md)
 - **Data flow**: how data enters and exits this component (include Mermaid sequence or flowchart diagram)
-- **Dependencies**: epic dependencies (with Jira IDs) and external dependencies (libraries, hardware, services)
+- **Dependencies**: epic dependencies (with tracker IDs) and external dependencies (libraries, hardware, services)
 - **Acceptance criteria**: measurable criteria with specific thresholds (from component tests.md)
 - **Non-functional requirements**: latency, memory, throughput targets with failure thresholds
 - **Risks & mitigations**: relevant risks from risk_mitigations.md with concrete mitigation strategies