troubleshooting — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited troubleshooting (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill enforces structured root cause analysis. It makes guessing, untested fixes, and undocumented resolutions structurally impossible.
| Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter |
|---|---|---|---|
| Skip ST22 and jump to "known fixes" | "I've seen this error before, I know what it is" | The same error message can have five different root causes. Assuming you know the cause from memory is guessing with extra steps. | Iron Law 2. Open ST22. Read the full dump. The cause is in the evidence, not in memory. |
| Apply a transport or note without diagnosing | "SAP Note 1234567 fixes this class of error" | Notes fix specific causes. If your cause is different, the note changes nothing — or introduces new problems. | Iron Law 3. Confirm the root cause first. Then confirm the note addresses exactly that cause. |
| Skip reproduction because "it's intermittent" | "We can't reproduce it, so we just have to try something" | Intermittent issues have patterns — time, user, transaction, data volume. Find the pattern. Check SM21 for frequency. Use ST05 to catch the failure. | Iron Law 4. Document all known occurrence conditions. Attempt reproduction under those conditions. If truly unreproducible, escalate — do not guess. |
| Fix in production directly | "DEV doesn't have the same data, we need to fix it in PRD" | Fixing production without a tested fix path is gambling with a live system. | Reproduce in DEV or QAS. Test fix there. Transport via standard path. Emergency fixes require documented emergency change process. |
| Close the incident after the symptom disappears | "The error stopped happening, must be fixed" | Errors stop and recur. "It stopped" is not root cause. | Iron Law 5. Root cause must be identified and documented. If cause is unknown, the incident stays open. |
| Treat the first working hypothesis as confirmed cause | "That explains it, let's fix it" | The first plausible explanation is usually the simplest, not the correct one. Systems have complex interactions. | Hypothesize → Test → Confirm. A hypothesis is not confirmed until evidence from diagnostic tools supports it. |
Watch for these phrases in your own reasoning — each one signals you are about to violate structured diagnosis:
<HARD-GATE> Before applying any fix: confirm (1) ST22 or SM21 has been checked and the error evidence is documented, (2) the error has been reproduced in a non-production environment or occurrence conditions are fully documented, (3) a specific root cause hypothesis has been stated and tested against diagnostic evidence, and (4) the fix addresses the confirmed root cause — not just the symptom. If any of these four conditions is not met, no fix may be applied. </HARD-GATE>
Define the exact conditions under which the error occurs. Gather from the reporter: transaction code, user, time, input data, and exact error message or dump ID. Attempt to reproduce in DEV or QAS.
Run all applicable diagnostic tools before forming any hypothesis.
Based only on the collected evidence, form a specific hypothesis. State: "The root cause is [specific cause] because [specific evidence from Step 2]." One hypothesis at a time. Rank hypotheses by evidence strength.
Design a test that would confirm or disprove the hypothesis without applying a permanent fix. Examples: add a breakpoint and inspect variable state, add a temporary assertion, check whether the error occurs only when the specific condition is met, trace with ST05 to confirm the suspected SQL pattern.
State the confirmed root cause with full supporting evidence. The confirmed root cause must be specific enough to determine the correct fix. "Something wrong with the invoice process" is not a confirmed root cause. "LV_VENDOR is not populated when PO type NB has no vendor master record, causing a NULL dereference at ZCL_INVOICE_PROCESSOR line 247" is a confirmed root cause.
Implement the fix in DEV. Apply it to the confirmed root cause only — do not fix adjacent issues in the same change (separate concerns, separate transports). Test the fix under the exact reproduction conditions from Step 1. Confirm the error no longer occurs. Run regression test on related functions.
After transport to production, verify the fix is effective under real conditions. Complete the root cause analysis document.
ROOT CAUSE ANALYSIS
===================
Incident ID: [Ticket/incident number]
System: [SID and client]
Date of occurrence: [Date and time]
Reported by: [User/team]
Resolved by: [Developer/consultant]
Resolution date: [Date]
SYMPTOMS
--------
Transaction: [T-code where error occurred]
Error message: [Exact error text or dump type]
Dump ID: [ST22 dump ID if applicable]
Frequency: [Single occurrence / recurring / intermittent - pattern]
Impact: [Users affected, business process impact]
EVIDENCE COLLECTED
------------------
ST22: [Dump type, program, line, exception, key variables]
SM21: [Relevant log entries and timestamps]
ST05: [SQL findings if applicable]
SAT: [Runtime findings if applicable]
SM50: [Work process status if applicable]
Other: [Any additional tools or logs consulted]
ROOT CAUSE
----------
Confirmed root cause: [Specific, evidence-backed cause statement]
Evidence chain: [How evidence from Step 2 led to hypothesis and confirmation]
FIX APPLIED
-----------
Description: [What was changed and why]
Transport: [Transport number]
Fix applied in: DEV [date] → QAS [date] → PRD [date]
VERIFICATION
------------
PRD verification: [Confirmed resolved / date / by whom]
Regression test: [Pass/fail and scope]
PREVENTION
----------
Recurrence risk: [High / Medium / Low]
Prevention action: [Code fix / config change / monitoring / none required]This skill is complete ONLY when ALL of the following are true:
Evidence required: ST22 export or SM21 log extract, completed Root Cause Analysis document, transport confirmation, production verification record.
After completing this skill, invoke: code-review Conditions for handoff: After root cause is confirmed and fix is implemented, submit the fix code for code-review before transport to production. Attach the RCA document as context for the reviewer — the fix must be reviewed against the confirmed root cause, not in isolation.
code-review to review the fix before transport releaseperformance-tuning when ST05 or SAT evidence points to SQL or runtime performance as the root causedevelopment-workflow for transport management after fix is approved~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.