From ARC-1 — SAP ABAP for Claude
Explains ABAP objects with full dependency context via SAPContext and optional ATC code quality analysis. Supports classes, CDS views, behavior definitions (BDEF), reports, and more.
How this skill is triggered — by the user, by Claude, or both
Slash command
/arc-1:explain-abap-codeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Explain ABAP objects with full dependency context and optional ATC code quality analysis.
Explain ABAP objects with full dependency context and optional ATC code quality analysis.
This skill replicates SAP Joule's "Explain Code" capability by combining ARC-1 (SAP system access) with mcp-sap-docs (documentation & best practices). It goes beyond J4D by providing compressed dependency graphs via SAPContext.
| Setting | Default | Rationale |
|---|---|---|
| Object type | Auto-detect via SAPSearch | Don't make user look up the type |
| Depth | Overview | Start high-level, user can ask for detail |
| ATC | No | Only run if user asks about code quality |
| Dependencies | Fetch via SAPContext | Always get the dependency graph |
| BDEF handler class | Discover from implementation in class clause | The behavior logic lives in the bound pool class |
The user provides an ABAP object name (e.g., ZCL_TRAVEL_HANDLER, ZI_SALESORDER, Z_REPORT_POSTING).
Only the object name is required. If the user provides just an object name, auto-detect the type and proceed immediately with an overview explanation.
Optionally, the user may specify:
If the user didn't specify a type, search for the object:
SAPSearch(query="<object_name>")
Use the first result's type. If ambiguous (multiple matches), ask the user.
SAPRead(type="<type>", name="<object_name>")
SAPRead(type="CLAS", name="<class_name>", method="*")
This returns all methods with their signatures, visibility (public/protected/private), and parameter types. Essential for understanding the class API.
SAPRead(type="DDLS", name="<entity_name>", include="elements")
Returns a formatted listing of all fields with key markers, aliases, associations, and expression types.
Depending on type, also read associated objects:
SAPRead(type="CLAS", name="<class>", include="testclasses") — check if tests existSAPRead(type="BDEF", name="<entity>") — check if behavior definition exists; SAPRead(type="DCLS", name="<entity>_DCL") — check CDS access control; SAPRead(type="DDLX", name="<entity>") — check for metadata extensionsSAPRead(type="DDLS", name="<entity>") — read the associated CDS viewThese may fail if the related artifact doesn't exist — that's fine, skip them.
A behavior definition is only meaningful together with its bound CDS root entity and its behavior pool (handler) class. When the object is a BDEF, do this instead of (or in addition to) the steps above:
Read the BDEF source:
SAPRead(type="BDEF", name="<bdef_name>")
Identify the implementation type + bound pool class by reading the BDEF source:
managed / unmanaged / projection / abstract / interface — this is the implementation kindstrict ( 2 ) → latest RAP syntax checks; with draft / with collaborative draft → draft-enabled... implementation in class <ZBP_NAME> unique; names the behavior pool class. Extract <ZBP_NAME> with a regex like implementation\s+in\s+class\s+(\S+). (A projection; BDEF may have no pool class — it reuses the base behavior via use ....)Read the behavior pool class (the handler logic lives in its local includes — usually CCIMP):
SAPRead(type="CLAS", name="<ZBP_NAME>", include="implementations")
If that returns empty, also try include="definitions" (CCDEF) and the main include. The local handler classes are named lhc_<alias> and each FOR DETERMINE / FOR VALIDATE / FOR MODIFY method implements the corresponding BDEF declaration.
Read the bound CDS root entity to understand the data model the behavior governs:
SAPRead(type="DDLS", name="<root_cds>", include="elements")
The root CDS name appears in define behavior for <root_cds> alias <alias>.
For a projection BDEF, also read the underlying base BDEF (the one it projects) to see which operations are reused (use create; use update; use action ...).
These reads may fail if an artifact doesn't exist (e.g. a pure abstract BDEF) — skip gracefully.
A function group's logic is spread across nested includes: the main program references the TOP (global data) and UXX (function-module dispatcher) includes, and the actual FUNCTION … ENDFUNCTION bodies live in further-nested LZ<grp>U01/U02… includes pulled in from UXX (PBO/PAI subroutines in …O…/…I… includes). Read the whole tree in one call with expand_includes:
SAPRead(type="FUGR", name="<group>", expand_includes=true)
This returns the main source plus every nested include (recursively, depth/count-capped), each prefixed with a === <name> === marker — so you get all the function module bodies and flow logic in one read. Without expand_includes, you only get the function-module list.
Screen flow is not available. Dynpros (screens) and GUI status (CUA) are not exposed by ADT over REST — they are SAPGUI-only (SE51/SE41), and the endpoints return 404. So for a FUGR you can explain the business purpose, function-module responsibilities, and flow logic from the code, but not the screen layout / PBO-PAI screen sequence beyond what the PBO/PAI module code reveals. State this limitation if the user asks about the screen flow specifically.
SAPContext(type="<type>", name="<object_name>")
This automatically extracts all dependencies and fetches compressed public API contracts for each. It provides:
For complex objects with deep dependency chains, use depth=2:
SAPContext(type="<type>", name="<object_name>", depth=2)
If SAPContext fails (e.g., unsupported type), fall back to manual reads of key dependencies identified in the source code.
Supported types: SAPContext accepts CLAS, INTF, PROG, FUNC, DDLS (on-prem) / CLAS, INTF, DDLS (BTP). It does not accept BDEF. So when explaining a BDEF, run dependency/impact analysis on the bound CDS root entity instead:
SAPContext(action="impact", name="<root_cds>")
action="impact" (DDLS only) returns the downstream blast radius — projection views, consumption views, and services that build on the behavior. This is the "dependencies / who consumes this" answer for a behavior definition. For the handler class internals, run SAPContext(type="CLAS", name="<ZBP_NAME>").
If the user asked to explain code quality or ATC findings:
SAPDiagnose(action="atc", type="<type>", name="<object_name>")
If a specific ATC variant is needed (e.g., S/4HANA readiness):
SAPDiagnose(action="atc", type="<type>", name="<object_name>", variant="<variant>")
Group findings by priority:
hasQuickfix flag. If true, mention that SAP provides a machine-applicable quickfix proposal for that location.For unfamiliar SAP APIs found in the source code:
search("<class_or_function_name> ABAP documentation")
For ATC findings that need explanation:
search("<checkTitle> simplification item S/4HANA")
For SAP Notes if available:
sap_notes_search(q="<finding_or_api_name>")
Use documentation results to enrich the explanation with official SAP context.
Present a structured explanation with the following sections. Adapt depth based on user preference (overview vs detailed).
For classes:
For CDS views:
Structure the explanation around the RAP behavior graph you read in Step 1f:
strict(2) and with draft if present.define behavior for <CDS> alias <alias> — persistent table, lock master/lock dependent, authorization master/authorization dependent, etag.create / update / delete, create-by-association (association _X { create; }), and whether draft actions (Edit, Activate, Discard, Resume, Prepare) are present.determination <name> on save|on modify — what each derives, read from the matching FOR DETERMINE method in the pool class.validation <name> on save — what each enforces, from the FOR VALIDATE method.action <name> (+ static/factory/parameter/result), from the FOR MODIFY / FOR READ methods.side effects { ... } declarations (what UI refresh / recompute they trigger).field ( readonly | mandatory | numbering : managed ), mapping for <table>.use ....From SAPContext results:
DCLS) rules if present (row-level restrictions, role mapping)authorization master, authorization dependent by) when present in BDEFFrom ATC results:
Offer the user next steps:
SAPDiagnose(action="quickfix"))apply_quickfix)SAPWrite(action="scaffold_rap_handlers"))| Error | Cause | Fix |
|---|---|---|
| Object not found | Name misspelled or object doesn't exist | Use SAPSearch to find similar names |
| SAPContext fails | Object type not supported for dependency analysis | Fall back to manual reads of key dependencies found in source |
| ATC check returns no findings | No ATC configuration or clean code | Inform user — no findings is good news |
| ATC variant not found | Specified variant doesn't exist on system | Run default ATC, list available variants |
| Method listing empty | Object is not a class or has no methods | Skip method listing, explain from source only |
| Source is empty | Object exists but has no source (e.g., generated proxy) | Inform user, try reading related objects instead |
SAPContext rejects BDEF type | BDEF isn't a supported SAPContext type | Run SAPContext(action="impact", name="<root_cds>") on the bound CDS root instead |
| BDEF pool class not found | projection; BDEF (no own pool) or class name parsed wrong | Skip the class read; explain from the projection's use clauses + base BDEF |
npx claudepluginhub arc-mcp/arc-1 --plugin arc-1Runs ATC readiness checks on S/4HANA custom code, groups findings, and generates clean-core replacement ABAP code.
Checks ABAP code quality with abaplint static analysis and Clean ABAP manual review. Lints syntax, validates best practices, and helps configure abaplint.json.
Assists with ABAP code for SAP systems: internal tables, structures, ABAP SQL, OOP, RAP, CDS views, EML statements, ABAP Cloud, strings, dynamic programming, RTTI/RTTC, field symbols, data references, exceptions, unit testing.