SC4SAP Analyze Symptom

Performs structured root cause analysis for SAP operational incidents by connecting to the live SAP system through MCP. Auto-collects evidence from dumps, system state, recent transports, and code call graphs before asking the user any question.

<Response_Prefix> Every response triggered by this skill MUST begin with [Model: <main-model> · Dispatched: <sub-summary>] per ../../common/model-routing-rule.md § Response Prefix Convention. </Response_Prefix> <Target_Object>The target object is looked up on the active profile's system only. Not found → stop and ask per ../../common/multi-profile-artifact-resolution.md § Target object not on the active system — never substitute a similar name, never switch profiles on your own.</Target_Object>

<Phase_Banner> Multi-phase skill. Before each Agent(...) dispatch, emit ▶ phase=<id> (<label>) · agent=<name> · model=<Opus|Sonnet|Haiku> per ../../common/model-routing-rule.md § Phase Banner Convention. Resolve the dispatch mode first per ../../common/model-dispatch-mode.md: auto (default) uses the model below/in the rule; user-defined asks the user Opus / Sonnet / Haiku (recommended one first) before each dispatch group. </Phase_Banner>

<Use_When>

• User reports a symptom using words like "error", "dump", "failing", "broken", "not working", "timeout", "slow"
• User has at least one clue: error message, TCode, program name, job name, or affected user/data
• User is unsure which log or transaction to inspect (ST22, SM21, SLG1, SU53, SM13, SM58, WE02, etc.)
• Need to classify whether the issue is custom development vs SAP standard
• Need to trace root cause of an incident that started after a recent transport or patch </Use_When>

<Do_Not_Use_When>

• Root cause is already identified and only a code fix is needed — use /sc4sap:create-program or direct MCP Update* calls
• Pure static code quality review — use /sc4sap:analyze-code
• Need to create a new ABAP object — use /sc4sap:create-object
• Conceptual or configuration-guide question — use a module consultant agent directly </Do_Not_Use_When>

<Session_Trust_Bootstrap> MANDATORY — runs as Step 0 before any MCP call or user interaction.

Invoke /sc4sap:trust-session with parent_skill=sc4sap:analyze-symptom to pre-grant all MCP tool + file-op permissions for this session (eliminates per-tool "Allow this tool?" prompts during auto-investigation — RuntimeAnalyzeDump, ListTransports, GetWhereUsed, etc.).

• Headless host (system prompt declares Host: sc4sap-web) → skip entirely; the host governs permissions.
• If .sc4sap/session-trust.log already has a line within the last 24h, skip silently. Otherwise run it.

Full spec: see ../trust-session/SKILL.md. </Session_Trust_Bootstrap>

<Core_Principles>

• Read-only, always: analysis and reading only — no SAP write tools (Create/Update/Delete/Patch/Write/Activate, RunUnitTest, RuntimeRun*/RuntimeCreate*, CreateTransport), no Edit/Write, even when the user asks for the fix. Fixes appear only as proposals.
• Cheapest evidence first: dump metadata and termination link, then the one failing include; the ~50 KB formatted dump only when those cannot explain the error. A short web lookup (standard identifiers only — never Z*/Y* names, SID, user IDs, or data) runs only when the failure point is standard SAP code. Never re-ask what MCP can answer.
• Evidence over assumption: Do not speculate. No "probably" statements without supporting MCP or user-provided evidence.
• Minimal questions: At most 3 questions per round. Skip any question whose answer is already known via MCP.
• Hypothesis narrowing: Reduce candidate causes to 2–3 from the 8-category framework; each must carry a confidence level and a confirmation path.
• Actionable output: Every hypothesis must include the next evidence step (another MCP call, a TCode, or an escalation target).
• Customization cache first (local, before live MCP) when a Z/Y object or customized SAP include appears in the trace**: read <CUSTOMIZATION_DIR>/<MODULE>/{enhancements,extensions}.json (the path Step 1 resolves once — never search for it) and correlate — a Z* class in a dump may be a known BAdI impl, a customized MV45AFZZ/ZXRSRU01 may be a recorded form-based exit, a failing field may be a recorded append. Follow common/customization-lookup.md. If the cache is absent, suggest /sc4sap:setup customizations but do not block the current analysis. </Core_Principles>

<Analysis_Framework> All hypotheses must map to one of these 8 root cause categories:

Every hypothesis presented to the user must declare its category explicitly. </Analysis_Framework>

<Evidence_Collection_Matrix> Evidence collection strategy — prefer MCP auto-query, fall back to manual TCode guidance:

Rule: For any MCP-supported item, never ask the user — query it directly. </Evidence_Collection_Matrix>

<Workflow_Steps> MANDATORY: Follow the step sequence defined in workflow-steps.md.

Per-step model allocation (the main thread follows the session model — model: inherit; heavy analysis is delegated):

sap-debugger's tool set already covers the dumps feed (RuntimeListFeeds), RuntimeGetDumpById, profiler, transport queries, code reads, enhancement lookup, and customization cache reads — see the agent's Investigation_Protocol for the full inventory. A quick-dump round is read-mostly work (dump → source → explanation), which common/model-routing-rule.md keeps on Sonnet (§ Tier 2 — the debugger still explains the dump, so it is not a pure Haiku fetch); full rounds need cross-file reasoning (dump × transport × source × customization) and stay on Opus. Ambiguity resolves to quick-dump, never to full: the cheap path escalates itself when it cannot finish, and the expensive one has no way back. </Workflow_Steps>

<Question_Strategy> Rule: max 3 questions per response. Never re-ask what MCP already answered.

Priority when information is missing:

1. Exact error text + message class/number — the strongest SAP Note search key
2. TCode / App / Program / Job where the error occurs
3. Reproduction conditions (always vs intermittent; user/data/org specificity)

Situation-specific follow-ups:

• Authorization suspected: Does another user succeed with the same input? Any SU53 capture?
• Batch suspected: Does manual execution also fail? Any recent variant change?
• Interface suspected: Does SM59 Connection Test succeed? What is the IDoc status code (51/52/53/64)?
• Custom development suspected: (First run ListTransports + GetWhereUsed, then) Does TR candidate X match the timing of the incident?
• Standard bug suspected: Release/SP auto-detected via GetSession. Does the same symptom reproduce on QAS/DEV?
• Performance suspected: How much slower than usual? Which resource saturates first — DB / CPU / memory? </Question_Strategy>

<Output_Format> Per-round report template and the final-round consolidated report structure live in output-format.md. Follow it literally for both intermediate rounds and the final analysis. </Output_Format>

<MCP_Tools_Used> Main thread: GetSession only (Step 1). Everything else runs inside the sap-debugger dispatch, so dump payloads, source and transport lists never sit in the orchestrator context. The authoritative tool list and call limits live in the dispatch prompt in workflow-steps.md § Step 2: dump (RuntimeListFeeds dumps feed, RuntimeGetDumpById metadata, formatted view only when needed), one failing include (GetInclude / GetProgram / GetClass / GetFunctionModule), scoped transports (ListTransports, GetTransport, GetObjectInfo), GetWhereUsed, enhancements, existing profiler traces, DDIC schema reads. Never GetProgFullCode, GetTableContents, GetSqlQuery or any write tool. </MCP_Tools_Used>

<Common_Pitfalls_To_Avoid>

• ❌ Asking the user for information MCP can retrieve (system info, program source, recent transports)
• ❌ Firing 4+ questions at once
• ❌ Diagnosing a root cause without an error message in hand
• ❌ Skipping the dump lookup when a dump is suspected and speculating instead (RuntimeListFeeds dumps feed — RuntimeListDumps can return an empty list)
• ❌ Changing anything — code, data, transports, activation — from this skill, even on request
• ❌ Running the full investigation (transports, where-used) on a plain dump with no change-history signal
• ❌ Searching the filesystem for config/caches, or rewriting the debugger's report in the main thread
• ❌ Deflecting with "contact Basis / dev team" without a concrete checklist and evidence
• ❌ Claiming a standard SAP bug before attempting a SAP Note search
• ❌ Pulling the ~50 KB formatted dump before the metadata and failing include were checked, trusting the summary key facts of RuntimeAnalyzeDump / RuntimeGetDumpById (they pick the wrong chapter), or reading a whole program with GetProgFullCode
• ❌ Blaming recent changes without inspecting transport history via ListTransports
• ❌ Listing 4+ hypotheses (narrow to 2–3) </Common_Pitfalls_To_Avoid>

Task: $ARGUMENTS