Update skills documentation to reflect changes in directory structure and terminology. Replace references to integration tests with blackbox tests across various SKILL.md files and templates. Revise paths in planning and deployment documentation to align with the updated _docs/02_document/ structure. Enhance clarity in task management processes and ensure consistency in terminology throughout the documentation.

.cursor/skills/implement/SKILL.md

@@ -73,9 +73,9 @@ For each task in the batch:
 - Determine: files OWNED (exclusive write), files READ-ONLY (shared interfaces, types), files FORBIDDEN (other agents' owned files)
 - If two tasks in the same batch would modify the same file, schedule them sequentially instead of in parallel
 
-### 5. Update Jira Status → In Progress
+### 5. Update Tracker Status → In Progress
 
-For each task in the batch, transition its Jira ticket status to **In Progress** via Jira MCP before launching the implementer.
+For each task in the batch, transition its ticket status to **In Progress** via the configured work item tracker (Jira MCP or Azure DevOps MCP — see `protocols.md` for detection) before launching the implementer. If `tracker: local`, skip this step.
 
 ### 6. Launch Implementer Subagents
 
@@ -93,15 +93,30 @@ Launch all subagents immediately — no user confirmation.
 - Collect structured status reports from each implementer
 - If any implementer reports "Blocked", log the blocker and continue with others
 
+**Stuck detection** — while monitoring, watch for these signals per subagent:
+- Same file modified 3+ times without test pass rate improving → flag as stuck, stop the subagent, report as Blocked
+- Subagent has not produced new output for an extended period → flag as potentially hung
+- If a subagent is flagged as stuck, do NOT let it continue looping — stop it and record the blocker in the batch report
+
 ### 8. Code Review
 
 - Run `/code-review` skill on the batch's changed files + corresponding task specs
 - The code-review skill produces a verdict: PASS, PASS_WITH_WARNINGS, or FAIL
 
-### 9. Gate
+### 9. Auto-Fix Gate
 
-- If verdict is **FAIL**: present findings to user (**BLOCKING**). User must confirm fixes or accept before proceeding.
-- If verdict is **PASS** or **PASS_WITH_WARNINGS**: show findings as info, continue automatically.
+Auto-fix loop with bounded retries (max 2 attempts) before escalating to user:
+
+1. If verdict is **PASS** or **PASS_WITH_WARNINGS**: show findings as info, continue automatically to step 10
+2. If verdict is **FAIL** (attempt 1 or 2):
+   - Parse the code review findings (Critical and High severity items)
+   - For each finding, attempt an automated fix using the finding's location, description, and suggestion
+   - Re-run `/code-review` on the modified files
+   - If now PASS or PASS_WITH_WARNINGS → continue to step 10
+   - If still FAIL → increment retry counter, repeat from (2) up to max 2 attempts
+3. If still **FAIL** after 2 auto-fix attempts: present all findings to user (**BLOCKING**). User must confirm fixes or accept before proceeding.
+
+Track `auto_fix_attempts` count in the batch report for retrospective analysis.
 
 ### 10. Test
 
@@ -112,12 +127,12 @@ Launch all subagents immediately — no user confirmation.
 
 - After user confirms the batch (explicitly for FAIL, implicitly for PASS/PASS_WITH_WARNINGS):
   - `git add` all changed files from the batch
-  - `git commit` with a message that includes ALL JIRA-IDs of tasks implemented in the batch, followed by a summary of what was implemented. Format: `[JIRA-ID-1] [JIRA-ID-2] ... Summary of changes`
+  - `git commit` with a message that includes ALL task IDs (Jira IDs, ADO IDs, or numeric prefixes) of tasks implemented in the batch, followed by a summary of what was implemented. Format: `[TASK-ID-1] [TASK-ID-2] ... Summary of changes`
   - `git push` to the remote branch
 
-### 12. Update Jira Status → In Testing
+### 12. Update Tracker Status → In Testing
 
-After the batch is committed and pushed, transition the Jira ticket status of each task in the batch to **In Testing** via Jira MCP.
+After the batch is committed and pushed, transition the ticket status of each task in the batch to **In Testing** via the configured work item tracker. If `tracker: local`, skip this step.
 
 ### 13. Loop
 
@@ -146,6 +161,8 @@ After each batch, produce a structured report:
 | [JIRA-ID]_[name] | Done | [count] files | [pass/fail] | [count or None] |
 
 ## Code Review Verdict: [PASS/FAIL/PASS_WITH_WARNINGS]
+## Auto-Fix Attempts: [0/1/2]
+## Stuck Agents: [count or None]
 
 ## Next Batch: [task list] or "All tasks complete"
 ```
@@ -173,5 +190,5 @@ Each batch commit serves as a rollback checkpoint. If recovery is needed:
 
 - Never launch tasks whose dependencies are not yet completed
 - Never allow two parallel agents to write to the same file
-- If a subagent fails, do NOT retry automatically — report and let user decide
+- If a subagent fails or is flagged as stuck, stop it and report — do not let it loop indefinitely
 - Always run tests after each batch completes