| name | issue-fix |
| description | Fix a triaged CI failure for pytorch or torch-xpu-ops. Use when an issue already contains a root-cause analysis and a proposed fix strategy, and you need to implement the fix, verify it, and prepare a summary. Handles both unit-test (UT) and end-to-end (E2E) failures, including stale XPU skip-marker removal.
|
Fix CI Failure
This skill takes a triaged issue and turns it into a verified code fix. It does
not open the PR itself — see the cross-references at the end.
Execution mode: this skill behaves differently in interactive (default)
vs pipeline mode. See ../references/execution-modes.md.
For environment activation, build commands, the torch-xpu-ops xpu.txt pin,
and rebuild pitfalls, see
../references/environment-setup.md.
Inputs
You need:
- A triaged CI failure issue whose body contains a root-cause analysis and
a proposed fix strategy. Follow them. (If the issue is not yet triaged, triage
it first with the
xpu-issues-triaging skill.)
- The target repo:
pytorch or torch-xpu-ops. Confirm with
basename $(git rev-parse --show-toplevel).
- A reproducer command (pytest invocation, python script, or bash command),
or enough information (failed test name + error context) to construct one.
Step 0: Verify Environment
- Check which repo you're in:
basename $(git rev-parse --show-toplevel)
- If
torch-xpu-ops: you're fixing XPU kernel/operator code (files under src/)
- If
pytorch: you're fixing PyTorch core code (files under torch/, aten/, test/, c10/)
- Verify the worktree is clean:
git status should show no uncommitted changes
- Start from a clean base: checkout the main branch (or your reproducer branch)
Step 1: Reproduce
Reproduce the failure with the test-verification skill — pass it the
reproducer command from the issue (it activates the env and runs it). If the
issue has no command, construct one from the failed test name and error context
first. Confirm the bug actually reproduces before changing any code.
If you modified C++/CUDA/SYCL code (not just Python), rebuild before re-running.
See ../references/environment-setup.md for
the environment activation, build commands, and the torch-xpu-ops xpu.txt
submodule-pin workflow (how to test a torch-xpu-ops fix inside pytorch without
triggering a full rebuild).
Step 2: Implement the Fix
Key Rules
- Minimal changes — fix only what's broken
- Never skip tests — no
@skipIfXpu, @skip, unittest.skip.
- Stay in your repo — if in pytorch, don't modify
third_party/*.
- Exception: you may edit
third_party/torch-xpu-ops/ files when the
triage output explicitly says target_repo == "torch-xpu-ops".
- Never modify unrelated files
- Never cherry-pick upstream fixes. If a fix already landed on trunk, rebase (
git rebase origin/main) instead.
Fix Strategies by Category
- Unit tests (non-E2E): For UT failures (not end-to-end models), see the UT Skip Removal section below.
- Newly added test: Try to enable it for XPU. If XPU support is genuinely missing and out of scope for this fix, do NOT add skip decorators — instead, try to loop and fix, only add "NEEDS_HUMAN" or report to the user if you really can't solve.
- Regression: Find the guilty commit by reviewing recent commit history. Apply an XPU-specific fix if necessary. If you can't identify the guilty commit, compare with cuda/rocm backend to find the root cause.
- Tolerance: Match upstream CUDA tolerances when adjusting XPU tolerances.
- Skip decorator stale: See the UT Skip Removal section below.
For deeper XPU-operator or CUDA-UT-porting fixes (locating the original CUDA
kernel/test, diffing CUDA vs XPU behavior, deciding pytorch vs torch-xpu-ops as
the fix repo), use the xpu-issues-triaging skill.
UT Skip Removal
This section states about how to remove the @skipIfXpu / @xfailIfXPU / @expectedFailureXPU decorator in unit-tests. If not needed, directly go to the next section.
1. Find skip markers — scan for these patterns:
| Pattern | Location |
|---|
@skipXPU, @unittest.skipIf(..., "XPU ...") | Decorator on test method |
@expectedFailureXPU, @xfailIfXPU | Decorator on test method |
DecorateInfo(unittest.skip("..."), device_type='xpu') | Inside OpInfo definitions |
Skip dictionaries: skip_xpu, xfail_xpu | Used in instantiate_device_type_tests |
skipIfXpu in conditional blocks | Inline skip logic |
grep -n "skipXPU\|skipIfXpu\|xfailIfXPU\|expectedFailureXPU\|device_type='xpu'" test/<test_file>.py
grep -n -A2 "DecorateInfo.*skip.*xpu" torch/testing/_internal/common_methods_invocations.py
2. Remove the marker — delete the decorator/entry. Clean up unused imports if the decorator was the last usage. For OpInfo DecorateInfo entries, remove the entry from the decorators list.
3. Dynamic test names — many test classes are dynamically generated via instantiate_device_type_tests (e.g., TestCommonXPU from TestCommon). If simple search fails, check for the base class + device suffix pattern.
Step 3: Verify
After the fix is proposed, re-run via the test-verification skill to confirm
the fix works, and run related tests to check for regressions.
Run EVERY failing test case from the report individually. Do not skip any
case or assume verifying one representative case is sufficient.
If you modified C++/CUDA/SYCL code, rebuild pytorch before verifying (see Step 1).
Step 4: Clean Up
git add <your_files>
git diff --cached --stat
Step 5: Update Issue Description
After fixing, summarize what was changed and why, plus the test results
(pass/fail). In interactive mode (default), report this to the user. In
pipeline mode, write it into the issue body (see below).
Issue-body status (Pipeline mode only)
Pipeline mode only. This stage corresponds to legacy status IMPLEMENTING.
A Python driver script formerly wrote this status; in pipeline mode the agent
does it directly. This stage owns the <!-- agent:fix-log --> slot and the
"Fix implemented" Action Item, and advances <!-- agent:status:IMPLEMENTING -->.
Keep the markers from the templates under .github/ISSUE_TEMPLATE/agent/ intact.
In interactive mode, report to the user instead. See issue-handler/SKILL.md
for the overall stage/label contract and "Execution modes".
Step 6: Open the PR
To open the PR (branch naming, reproducer test, PR body, lint, push), use the
xpu-ops-pr-creation skill. Do not duplicate that workflow here.
HARD RULES
- NEVER modify files outside your repo scope (
torch-xpu-ops vs pytorch).
The only exception is editing third_party/torch-xpu-ops/ files from inside
the pytorch repo when the triage output explicitly says target_repo == "torch-xpu-ops".
- NEVER modify unrelated files — every changed line must trace directly to the issue.
- NEVER add skip decorators (
@skipIfXpu, @skip, unittest.skip). Fix the test.
- NEVER submit a torch-xpu-ops PR for a bug whose root cause is in pytorch core.
- NEVER cherry-pick upstream commits. Rebase instead.
Output
At the end, output:
### Agent Summary
- **What I found:** <root cause in one sentence>
- **What I changed:** <bullet list of files>
- **Test result:** <PASS/FAIL with test command>
- **Open questions / risks:** <concerns or "None">
