Oom/fixing

.claude/skills/debug-matcher-pass/SKILL.md → .claude/skills/ov-debug-matcher-pass/SKILL.md

@@ -1,6 +1,7 @@
 ---
-name: debug-matcher-pass
-description: Debug why an OpenVINO MatcherPass transformation is not firing. Use this skill immediately when a user says a transformation is "not applied", a "pass has no effect", a "matcher never triggers", a pattern "doesn't match", a "callback never fires", "WrapType predicate is too strict", a subgraph "not fused" despite the pass being registered, or they see "END: PATTERN DIDN'T MATCH" in matcher logs. Also trigger when a MatcherPass works on one model but silently skips another, when the user wants to add a reproducer test for a transformation that should fire but doesn't, or when they suspect an opset version mismatch preventing a match. Do NOT trigger for: writing a new MatcherPass from scratch, debugging a pass that fires but produces wrong numerical results, crashes in pass registration, or general questions about what MatcherPass is.
+name: ov-debug-matcher-pass
+description: >
+  Debug why an OpenVINO MatcherPass transformation is not firing. Use this skill immediately when a user says a transformation is "not applied", a "pass has no effect", a "matcher never triggers", a pattern "doesn't match", a "callback never fires", "WrapType predicate is too strict", a subgraph "not fused" despite the pass being registered, or they see "END: PATTERN DIDN'T MATCH" in matcher logs. Also trigger when a MatcherPass works on one model but silently skips another, when the user wants to add a reproducer test for a transformation that should fire but doesn't, or when they suspect an opset version mismatch preventing a match. Do NOT trigger for: writing a new MatcherPass from scratch, debugging a pass that fires but produces wrong numerical results, crashes in pass registration, or general questions about what MatcherPass is.
 ---
 
 # Debug MatcherPass Skill
@@ -15,6 +16,8 @@ Produce two deliverables before finishing:
 
 The only filesystem change should be the test file edit. Do not create additional output files.
 
+**Early exit — all passes fired:** If Step 2a shows `CALLBACK SUCCEDED > 0` for every pass under investigation, skip Steps 3–6. Post a lightweight confirmation summary (use the "all fired" variant in the Diagnosis Report Template) and do not write a reproducer test. There is no bug to reproduce.
+
 ---
 
 ## Step 0: Gather Prerequisites
@@ -36,20 +39,20 @@ Ask the user only if the transformation name or run command is missing. The buil
 
 ## Step 1: Verify Debug Build
 
-The matcher logging macros are compiled in only when `ENABLE_OPENVINO_DEBUG=ON`. Check whether the current build already has it:
+The matcher logging macros are compiled in only when `ENABLE_DEBUG_CAPS=ON`. Check whether the current build already has it:
 
 ```bash
-grep -i "ENABLE_OPENVINO_DEBUG" build/*/CMakeCache.txt
+grep -i "ENABLE_DEBUG_CAPS" build/*/CMakeCache.txt
 ```
 
 If the flag is absent or set to `OFF`, reconfigure CMake using the existing build directory and build type from Step 0:
 
 ```bash
-cmake -B <build_dir> -DENABLE_OPENVINO_DEBUG=ON
+cmake -B <build_dir> -DENABLE_DEBUG_CAPS=ON
 cmake --build <build_dir> --parallel
 ```
 
-> **Note:** Logging also works in `Release` builds as long as `ENABLE_OPENVINO_DEBUG=ON` is set at configure time.
+> **Note:** Logging also works in `Release` builds as long as `ENABLE_DEBUG_CAPS=ON` is set at configure time.
 
 ---
 
@@ -68,6 +71,42 @@ Additional env vars:
 - **`OV_MATCHERS_TO_LOG`** — comma-separated list of matcher names to filter (omit to log all matchers, which produces very large output).
 - **`OV_VERBOSE_LOGGING=true`** — prints additional node details (element type, shape, attributes); use when the basic log does not identify the failure clearly.
 
+### Wait for the command to complete
+
+Matcher logs are interleaved with normal output. If the command is long-running (e.g., model compilation on GPU), **wait for it to finish before analyzing**. Parsing a partial log will produce incorrect statistics (e.g., undercounting successful callbacks). Verify completion by checking for the final your_run_command output line or the process exit code.
+
+---
+
+## Step 2a: Collect Per-Pass Statistics
+
+Before diving into detailed log analysis, run a quick tally to build an overview of which passes fired and how many times. This is especially important for **pipeline cascade** investigations with multiple passes.
+
+Use this Python snippet (adjust the `pass_names` list):
+
+```bash
+python3 -c "
+import re, sys
+pass_names = ['PassA', 'PassB']  # <-- replace with actual pass names
+with open('matcher.log') as f:
+    content = f.read()
+for p in pass_names:
+    s = len(re.findall(rf'\[{p}\] END: PATTERN MATCHED, CALLBACK SUCCEDED', content))
+    m = len(re.findall(rf'\[{p}\] END: PATTERN MATCHED', content))
+    d = len(re.findall(rf'\[{p}\] END: PATTERN DIDN.T MATCH', content))
+    print(f'{p}:  CALLBACK SUCCEDED={s}  MATCHED={m}  DIDN\'T MATCH={d}')
+"
+```
+
+Interpret the output:
+- **CALLBACK SUCCEDED > 0** → pass fired and transformed nodes.
+- **MATCHED > 0 but SUCCEDED = 0** → pattern matched but the callback returned `false` (check callback logic).
+- **DIDN'T MATCH > 0 and MATCHED = 0** → pattern was attempted but never matched any node (proceed to Step 3 for root cause).
+- **All counts = 0** → pass name not found in the log at all (not registered, or the pass is a `GraphRewrite` wrapper — log the inner `MatcherPass` names instead).
+
+> **Note on `GraphRewrite` wrappers:** If a pass is a `GraphRewrite` that calls `add_matcher<InnerPass>()`, the matcher log will use the inner pass names, not the wrapper name. Check the header for inner pass names and use those in `OV_MATCHERS_TO_LOG`.
+
+For pipeline cascades, use the tally to quickly classify each pass as ✅ fired / ❌ root cause / ❌ downstream casualty before spending time on detailed log analysis.
+
 ---
 
 ## Step 3: Analyze the Log — Identify Root Cause
@@ -128,12 +167,13 @@ Work inward through the nested blocks to find the deepest `}` labeled with a fai
 7. **Attribute value mismatch** — Pattern constrains an attribute (e.g., `group == 1`, `axis == 0`) that doesn't match the actual node.
 8. **Transformation was already applied** — Graph was modified by a symmetric or overlapping pass earlier; the target op no longer exists.
 9. **Wrong opset version** — Pattern uses `opset::OpX` but the frontend or a prior pass has already replaced it with a different version or a decomposed form.
+10. **Argument count mismatch** — The graph node has a different number of inputs than the pattern expects (e.g., an op with shared-expert inputs has 23 inputs but the pattern only covers the 11-input or 13-input variant). Common when ops have multiple configurations (with/without bias, with/without shared experts).
 
 ### 3e. No output at all from OV_MATCHER_LOGGING
 
 If the log file is empty or contains no matcher output even though the flag is set:
 
-- Confirm `ENABLE_OPENVINO_DEBUG=ON` in `CMakeCache.txt` for the binary you are actually running (not a different build directory).
+- Confirm `ENABLE_DEBUG_CAPS=ON` in `CMakeCache.txt` for the binary you are actually running (not a different build directory).
 - Confirm the env var is exported in the same shell context as the run command: `export OV_MATCHER_LOGGING=true` or prefix it inline.
 - If calling through Python or a launcher script, the env var must survive into the child process — use `os.environ` or prefix the full command.
 - Verify you are running the freshly rebuilt binary, not a cached one from a different `bin/` location.
@@ -280,11 +320,11 @@ See [references/example-diagnosis-report.md](references/example-diagnosis-report
 
 <!-- If multiple passes were investigated, add this table: -->
 ## Summary of passes
-| Pass | Result |
-|---|---|
-| `PassA` | ✅ Fired (`CALLBACK SUCCEEDED`) |
-| `PassB` | ❌ Did not fire — root cause |
-| `PassC` | ❌ Did not fire — downstream: PassB never produced its expected input |
+| Pass | Result | Callbacks | Matches |
+|---|---|---|---|
+| `PassA` | ✅ Fired | 40 | 40 |
+| `PassB` | ❌ Did not fire — root cause | 0 | 0 |
+| `PassC` | ❌ Did not fire — downstream casualty | 0 | 0 |
 
 **Root cause:** <one-sentence summary>
 **Log evidence:** `<exact log phrase that identified the failure>`
@@ -297,6 +337,25 @@ Test name: `<TEST_F name>`
 Status before fix: PASS (transformation did not fire — model unchanged, matches auto-cloned ref; confirms bug reproduced)
 ```
 
+### All-fired variant (early exit)
+
+When all passes fired successfully (Step 2a), use this shorter template instead:
+
+```
+## MatcherPass Diagnosis: <TransformationName(s)>
+
+## Summary of passes
+| Pass | Result | Callbacks | Matches |
+|---|---|---|---|
+| `PassA` | ✅ Fired | <N> | <N> |
+| `PassB` | ✅ Fired | <N> | <N> |
+
+**All transformations fired successfully.** No issues found.
+
+## Reproducer Test
+Not needed — no bug to reproduce.
+```
+
 ---
 
 ## References

.claude/skills/ov-debug/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: ov-debug
+description: Troubleshooting all sorts of failures, crashes, exceptions and errors using debug capabilities. Analyze accuracy, performance, model compilation, or memory issues. Dump tensors and intermediate blobs. Serialize and visualize IRs, execution graphs. Enable verbose, logging. Profile execution. Compare layer outputs. Inspect, trace or dump transformations. Identify executed operations, nodes, primitives, kernels.
+---
+
+# Debug Skill
+
+## Prerequisites
+Build flags that enable debug capabilities (check CMakeCache.txt in the build dir):
+- `-DENABLE_DEBUG_CAPS=ON` — CPU/GPU plugin debug env vars, transformation matcher logging
+
+## Components
+
+| Component                 | Reference file to read                | Routing hints                                                                 |
+|---------------------------|---------------------------------------|-------------------------------------------------------------------------------|
+| openvino_intel_cpu_plugin | @components/debug-intel-cpu-plugin.md | CPU: inference issues, wrong results, slow inference, tensor dumps, execution graphs |
+| openvino_intel_gpu_plugin | @components/debug-intel-gpu-plugin.md | GPU: inference issues, wrong results, slow inference, tensor dumps, execution graphs |
+| transformations           | @components/debug-transformations.md  | transformation not applied, pass not firing, slow compilation, graph inspection |
+
+## Steps
+1. Match the user's symptom to the routing hints above to identify the component(s)
+2. Load the component's reference file
+3. Follow the instructions and recommendations for debugging

.claude/skills/ov-debug/components/debug-transformations.md

@@ -0,0 +1,14 @@
+The debug and troubleshooting of OpenVINO transformations can be performed using various debug capabilities activated via environment variables.
+
+# Reference
+Read `src/common/transformations/docs/debug_capabilities/README.md` — use the "When to use" guidance to match the observed problem to the right capability.
+
+# Handoff
+If the symptom is specifically a MatcherPass not firing (transformation not applied, pattern not matching, callback never called), hand off to the `/ov-debug-matcher-pass` skill — it provides a deeper automated diagnosis workflow with matcher log analysis and reproducer test generation.
+
+# Steps
+1. Read the debug capabilities README
+2. Match the observed symptom to the relevant "When to use" entries
+3. If the issue is a MatcherPass not firing — invoke `/ov-debug-matcher-pass` instead of continuing
+4. Read the linked detail doc for the chosen capability
+5. Use suitable environment variables

.claude/skills/ov-ensure-coding-style/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: ov-ensure-coding-style
+description: Detect and fix clang-format, clang-tidy, and copyright header violations in an OpenVINO C++ codebase. Use when the user complains about code style or formatting, asks to clean up changes, fix linting, add a copyright header, or when a style check or linting CI job is failing. Do not use for build errors, compilation failures, linker errors, test failures, runtime crashes, accuracy issues, or CMake config problems.
+---
+
+# Apply Code Standards
+
+Iteratively detect and fix all clang-format, clang-tidy, and copyright violations introduced by the current branch's changes.
+
+## Step 1: Identify Affected Files and Build Targets
+
+**Before running any commands**, check whether the upstream reference is already confirmed in the conversation. If it is not, stop and ask:
+
+> "I'll diff against `upstream/master`. Let me know if you use a different upstream."
+
+Do not proceed until the user replies. Use the confirmed reference <ref_branch> in all subsequent steps. Once the upstream branch is known, you must fetch <ref_branch> and find a merge-base commit <ref_commit>, against which the diff should be collected. Then run:
+
+```bash
+git diff --name-only <ref_commit> | grep -v '^thirdparty' | tee /tmp/changed_files.txt
+```
+
+Map the changed files to CMake targets. If the mapping is not obvious, ask the user:
+
+> "Which CMake targets cover the files you changed? (e.g., `openvino_intel_cpu_plugin`)"
+
+## Step 2: Check, Fix, Repeat
+
+**Follow the fix order and tool instructions from [coding_style.md](../../../docs/dev/coding_style.md) exactly  — do not rearrange or skip steps.** Read that file before proceeding. Repeat the full cycle until all checks pass.