sapdev-ai
OrganizationSAP GUI automation plugins for AI coding assistants
Categories
Indexed Skills (50)
sap-activate-object
Activates an inactive SAP repository object via SAP GUI Scripting. Routes to the correct transaction by object type: SE38 for reports/programs/function- group main programs, SE37 for function modules, SE24 for classes/interfaces /methods, SE11 for DDIC objects (table, view, dataelement, structure, tabletype, typegroup, domain, searchhelp, lockobject). Handles the "inactive objects worklist" popup that SAP shows when there are multiple inactive objects of the same locality (transportable vs. local — SAP filters the popup by package locality of the triggering object). Verifies activation via PROGDIR (programs/FMs include) and DWINACTIV. Prerequisites: Active SAP GUI session (use /sap-login first).
sap-api-advisor
Natural-language SAP API discovery over RFC (no GUI): turn a goal like "create a sales order" or "post a goods movement" into a ranked, trap-annotated, paste-ready shortlist of BAPIs / function modules / classes — with released state (S/4), interface + documentation for the top candidates, the team's known traps inlined, and a ready-to-paste CALL FUNCTION snippet. Reads the BAPI catalog (BAPI_MONITOR_GETLIST), TFDIR/TFTIT name+text, SEOCLASS, ARS_W_API_STATE (S/4 released state), FUPARAREF/FUNCT + DOCU_GET. HARD rule: it never test-calls a candidate — snippets are text only. Read-only; deploys nothing. Use for: "which BAPI/FM for X", find an API, is this BAPI released, API to create/read/post <object>, discover function module, released API S/4. `successor` (released→sanctioned replacement) is phase 2; `scan` is phase 3. Prerequisites: an RFC-capable connection profile (/sap-login). No dev-init, no GUI.
sap-atc
Runs the SAP ABAP Test Cockpit (ATC) end-to-end as a quality gate: builds an SCI Object Set scoped to the target object(s), creates an ATC Run Series bound to that set, polls the ATC Run Monitor until the run completes, then reads the Priority 1 / Priority 2 / Priority 3 finding counts from the Manage Results screen and (best-effort) downloads the result text file. Applies the customer brief's MAX_PRIORITY threshold to decide pass / fail. Replaces the legacy SCI-results-tree implementation that lacked a Priority column. Per-stage VBS references are recorded against the S/4HANA 1909 ATC layout — re-record on first failure with /sap-gui-probe --record if your release uses different tree node IDs / grid column IDs. Prerequisites: Active SAP GUI session (use /sap-login first).
sap-call-bdc
Executes BDC (Batch Data Communication) sessions in SAP via RFC. Reads SHDB recording files from the bdc/ folder, connects via SAP NCo 3.1, calls ABAP4_CALL_TRANSACTION, and outputs full BDCMSGCOLL messages to a result file. Connection parameters resolved from the AI session's pinned profile in connections.json (saved via /sap-login). Prerequisites: SAP profile saved via /sap-login (RFC password required). SAP NCo 3.1 (32-bit, .NET 4.0) in GAC.
sap-change-package
Changes the package (TADIR-DEVCLASS) assignment of an SAP repository object via the "Object Directory Entry" dialog (Goto > Object Directory Entry). Routes by object type to SE38 / SE37 / SE24 / SE11 / SE91 / CMOD (the last for enhancement projects — used by /sap-cmod). Handles three flows automatically based on current vs new package locality: (a) $TMP → transportable (Z*/Y*): resolves a modifiable TR via /sap-transport-request, then enters the new package + TR. (b) transportable A → transportable B: pre-checks E071/E070 to ensure the object is NOT linked to a modifiable TR (would block the move). (c) transportable → $TMP: confirms the move and presses "Local object". Verifies via TADIR re-query. Prerequisites: Active SAP GUI session (use /sap-login first).
sap-check-abap
Validates ABAP source (report / program / FM / class / include) before deployment — one skill, dimension-dispatched: naming (variable conventions), type (DDIC type validity), unused (dead variables), sql (SELECT/UPDATE/DELETE fields vs table defs), contract (offline generation rules), spec (offline: code covers every dependency / message / text / selection field in the design spec), fm (CALL FUNCTION params / sections / types vs the live FM over RFC — absorbed from the former sap-check-fm), syntax (compiler-level EDITOR_SYNTAX_CHECK via RFC, catching real errors offline before any GUI upload). Writes tab-delimited result files with fix advice; feed findings to /sap-fix-abap. SAP connection optional — offline skips type/sql/fm/syntax; live dimensions that can't run report COULD_NOT_CHECK, never a silent pass. Prerequisites: SAP GUI (SAP.Functions COM); SAP NCo 3.1 (32-bit) + the dev-init wrapper Z_GENERIC_RFC_WRAPPER_TBL for the syntax dimension.
sap-check-fix
Routes "check and fix" / "check" / "fix" requests for an EXISTING SAP object to the correct workbench skill (sap-se38 / sap-se37 / sap-se24 / sap-se11) by an explicit object-type keyword, or — when no keyword is given — auto-detects the type by probing SE38 → SE37 → SE24 → SE11 (Display), then dispatches in check-and-fix mode. If the object matches an SAP-enhancement-component pattern (function-exit FM EXIT_SAP*, exit include ZX*, table-enhancement CI_*, SAPLX* screen exit), it is confirmed via MODSAP and routed to /sap-cmod instead (which edits the correct underlying object — for a function exit the ZX* customer include, never the standard FM — and re-activates the CMOD project). Invoke on "check and fix / check / fix <kind> <name>" where <kind> is report/program, FM, class/interface, a DDIC type, or omitted. Prerequisites: active SAP GUI session (/sap-login first). Does not deploy new objects — the target must already exist.
sap-cmod
Manages the full lifecycle of SAP Enhancement Projects (classic modifications) via CMOD using SAP GUI Scripting, plus read-only RFC lookups. Operations: check / status, create, change short text, activate, deactivate, delete the project; add and remove SAP enhancement assignments (position-aware — finds the right row by value, never a fixed index); change the project's package (delegates to /sap-change-package); and route "edit an enhancement component" to the correct workbench skill by component type (E function exit -> /sap-se38, S screen -> /sap-se51, T table -> /sap-se11, C GUI code -> /sap-se41). Prerequisites: Active SAP GUI session (use /sap-login first); SAP NCo 3.1 (32-bit, .NET 4.0) in GAC for the RFC lookups.
sap-compare
Compare the SAME ABAP object across two SAP systems — the pinned connection (LEFT) and a second saved profile selected with --against <hint> (RIGHT). DDIC objects (table / structure / data element / domain / table type) are compared field-by-field over RFC on BOTH sides (DDIF_FIELDINFO_GET). Programs / includes / function modules are compared by source over RFC via RPY_PROGRAM_READ (sap_rfc_read_source.ps1). Emits a structured field diff (diff.json), a unified source diff, and an AI summary that annotates each difference with the likely cause — including release skew using each system's saved release marker. Read-only: never modifies either system. Prerequisites: BOTH systems saved via /sap-login (RFC password required, same Windows user — DPAPI is CurrentUser-scoped). Class source compare is limited (RFC class source unsupported until ADT mode).
sap-dev-clean
Conservative cleanup of the artefacts /sap-dev-init created. Walks reverse dependency order — wrapper FM, DDIC structure + table type, utility program, function group, package — and deletes only what the operator confirms, skipping any artefact the operator extended (a function group with user-added FMs, a package with user-added Z* tables) unless --force. Deleted objects are unassigned from their transport request (via /sap-se01 remove-objects) and the request is deleted if it ends up empty, so a later /sap-dev-init can re-create the same names cleanly (no lingering name-lock). settings.json keys are preserved unless --settings. The canonical "blow away and rebuild" sequence is /sap-dev-clean ; /sap-dev-init. Pass --reset for a full reset (implies --force + --settings, clears the dev-default keys and deletes the dev TR). Prerequisites: active SAP GUI session (/sap-login first); SAP NCo 3.1 (32-bit). Delegates deletes to /sap-se37, /sap-se11, /sap-se38, /sap-function-group, /sap-se21.
sap-dev-init
Initializes the SAP development environment after plugin installation. Ensures a transport request, package, and function group exist in SAP, then deploys the ZCMRUPDATE_ADDON_TABLE utility program. Mode-aware: respects `sap_dev_mode` (GUI / RFC / BDC) and selects the preferred skill variant for each step, falling back to the next mode in the chain when no implementation exists for the preferred mode. Prerequisites: Active SAP GUI session (use /sap-login first). SAP NCo 3.1 (32-bit, .NET 4.0) in GAC for RFC sub-steps.
sap-dev-status
Read-only status report for the sap-dev-init artefacts: transport request, package, function group, the wrapper FM Z_GENERIC_RFC_WRAPPER_TBL plus its DDIC parameter structure / table type, and the ZCMRUPDATE_ADDON_TABLE utility program. Queries via RFC (TLIBG, TDEVC, TFDIR, DD02L, DD40L, PROGDIR, E070, TADIR) and emits one parseable line per artefact plus a summary STATUS line. Auto-invokable as a pre-flight from any sap-dev skill — exit code 0 = healthy, 1 = gaps, 2 = RFC failure, 3 = config mismatch (anchor gate — destructive callers must refuse). Pure read-only; never modifies the SAP system. Prerequisites: SAP NCo 3.1 (32-bit, .NET 4.0) in GAC.
sap-diagnose
Incident triage orchestrator for SAP support. From a single anchor (time window, user, transaction, background job, business-object key, or a known short-dump) it fans out across its read-only evidence readers — the internal RFC set (SM13 update-task failures, SM12 locks, SLG1 application log, SM37 jobs, SMQ tRFC/qRFC queues, Gateway/OData error-log preflight) plus the GUI dump reader /sap-st22 — correlates the evidence into incident clusters, and produces ranked root-cause hypotheses with a recommended fix path. Pass --reader <name> (sm13 | sm12 | slg1 | sm37 | smq | gateway | st22) to run one reader standalone and just print its evidence. PURE READ-ONLY: never writes to SAP; lock remediation is delegated to /sap-sm12 release, stuck-update remediation to manual SM13. With --fix it hands a custom-code-defect top hypothesis to /sap-fix-incident (the gated, write-capable companion) — diagnose itself still writes nothing. Safe to point at production. Prerequisites: a saved /sap-login profile (RFC password); SAP
sap-doctor
Read-only environment preflight ("doctor") for the sap-dev toolchain — diagnoses why skills fail BEFORE they run, across six default groups: gui (GUI + scripting reachable), cfg (32-bit PowerShell, NCo 3.1, work_dir, connections.json), rfc (pinned-profile connectivity), srv (client modifiability), auth (user authorizations vs the required set), devenv (dev-init artefacts). Emits one CHECK line per probe + a verdict (READY / DEGRADED / BLOCKED); a probe that can't run reports SKIP, never a false PASS, each with a copy-pasteable FIX. The default run is pure read-only and safe to chain (exit 0 = ready, 1 = blocked). OPT-IN group --screens replays the golden-screen baselines against the live system to catch control-ID drift before a GUI skill mis-steps (navigates the live session, off by default; --update-baseline writes baselines). Absorbed /sap-gui-screen-check. Prerequisites: SAP GUI; NCo 3.1 (32-bit) for rfc/srv; an active session for gui.
sap-enhancement-advisor
Finds the safest extension point for a requested SAP behavior change and recommends which enhancement mechanism to use — so a project doesn't fail by modifying the wrong place (copying standard, editing a fragile exit, missing the right BAdI). Complements /sap-se19 (which IMPLEMENTS a BAdI): this skill DECIDES. Three auto-detected modes: inspect one BAdI / enhancement spot (classify classic/new/migrated + list implementations); inspect one SMOD enhancement (components + the CMOD projects using it); or enumerate candidates for a program / tcode (enhancement spots, referenced BAdIs, user-exit includes). Scores candidates with a transparent heuristic (released enhancement interface > BAdI > exit > implicit; avoid standard modification), flags risks, and emits candidates.tsv + a recommended plan. The optional business-intent string is advisory only (the ranking is structural). Read-only; never modifies SAP. Prerequisites: SAP profile via /sap-login (RFC); SAP NCo 3.1 (32-bit) in GAC.
sap-error-kb
Curate the team frequently_errors knowledge base — the per-object store of recurring FM / class-method / codegen mistakes that sap-gen-abap reads to steer generation away from known traps. Deploy skills (sap-se38/se37/se24) and sap-atc auto-record new FM/METHOD errors here as CANDIDATE rows; this skill lets a human review and promote them. Four operations: - list show CANDIDATE rows awaiting review (default; --all also shows CONFIRMED) - promote mark a CANDIDATE row CONFIRMED so it starts influencing generation - mute suppress a row (seed or candidate) so it is never injected - show print one per-object file for manual editing Pure-local: reads/writes {custom_url}\frequently_errors\ (team-shared, NOT MEMORY files). No SAP connection required.
sap-evidence-pack
Generates a reviewer / customer / audit-ready delivery evidence pack from the artifact index — answers "what did we change, how was it checked, and why is it safe?". It does NOT run checks; it COLLECTS what the other delivery-assurance skills already registered (transport-readiness, impact-analysis, ATC, check-abap, ABAP Unit, …) for a scope (TR / object / package), a ticket, or a date range, into one categorized pack folder + a human-readable index.md with an executive summary, a verdicts table, and — crucially — an honest "Missing evidence" section that states what was NOT produced instead of pretending everything was checked. Pure-local (reads the manifest + copies files); read-only w.r.t. SAP. Prerequisites: the other skills must have run first to register artifacts; SAP NCo 3.1 (32-bit) only when resolving an object name to a scope key.
sap-explain-object
Read-only comprehension aid for an EXISTING ABAP object. Auto-detects the type (program / include / function module / class) via RFC, acquires the active source, resolves the include tree, and builds a structure + call/data map (units, PERFORM / CALL FUNCTION / CALL METHOD edges, DB read/write targets, SUBMIT / CALL TRANSACTION, selection screen); optionally pulls callers via /sap-where-used-list. Emits an explanation dossier + machine-readable map.json. Never modifies SAP. With --spec it enriches the map over RFC (DDIC table texts + keys, message texts, auth objects) and renders a formal, review-ready spec document — Markdown, Word (--format docx), or a filled spec_template.xlsx (--format xlsx) that round-trips through /sap-docs-extract; each section marked CONFIRMED vs INFERRED. --spec folds in the former /sap-document-object. Prerequisites: pinned /sap-login connection. Class download, --callers, and --format docx/xlsx need a GUI session / the anthropic-skills docx|xlsx.
sap-file-transfer
Transfers files between the local PC and the SAP application server, and lists app-server directories. Four modes: upload (CG3Z, PC -> app server), download (CG3Y, app server -> PC), list and exists (headless RFC via EPS2_GET_DIRECTORY_LISTING - no AL11 scraping). Text (ASC) or binary (BIN) transfer, explicit --overwrite flag, popup-guarded (overwrite Query, cannot-open-file Information popup), locale-independent (all outcomes read via control IDs + MessageType, verified for JA logons). Wires the SAP GUI Security precheck/sidecar around the local-file IO. Closes the file-interface test loop: upload test input -> /sap-run-report -> list -> download output -> diff against the spec's expected output (golden rows / Mapping (File Out)). No transport request involved - this skill touches no repository object. Typical asks: "upload <file> to the SAP server", "download /tmp/x from S4D", "list /usr/sap/trans", "does /tmp/out.txt exist on the app server". Prerequisites: active SAP GUI session (use /sap-login first) for
sap-fix-abap
Fixes ABAP source code issues found by sap-check-abap (all dimensions). Reads the check result file(s), builds a fix plan, and applies fixes: - NAMING violations: renames variables throughout the file - UNUSED variables: comments out declarations - SYNTAX-SAFE rewrites (SQL_STRICT_COMMA / line-length / DECL_ORDER) - CALL FUNCTION param fixes (UNKNOWN_PARAM rename / MISSING_MANDATORY stub / WRONG_SECTION move) from the `fm` dimension — absorbed from the former sap-fix-fm - SYNTAX errors: a bounded AI-assisted check->patch->re-check loop that drives the headless `sap_rfc_syntax_check.ps1` engine (no blind auto-fix) - TYPE_NOT_FOUND and other semantic codes: flagged for manual review Creates a timestamped backup (.bak) before modifying the source file. Prerequisites: Run sap-check-abap first to produce the result file(s). The `fm` and `syntax` fix paths need SAP NCo 3.1 (32-bit) + the dev-init wrapper.
sap-fix-incident
Closes the loop from a /sap-diagnose root cause to a deployed, test-verified fix — conservatively and test-first. Takes a diagnose deliverable (or a dump key) whose top hypothesis is a CUSTOM-CODE DEFECT, acquires the failing source, reasons a minimal patch, reproduces the defect as a RED ABAP Unit test (via /sap-gen-abap-unit), applies the patch, re-checks with /sap-check-abap, deploys to a modifiable DEV system behind a transport, and proves the test GREEN with /sap-run-abap-unit. HARD GUARD RAILS: only custom-code-defect hypotheses on Z*/Y* objects; never patches SAP standard (→ Note/enhancement, analysis only); never writes to a non-modifiable / production system — the fix is made in DEV and handed to /sap-transport-readiness → /sap-se01 release → /sap-stms. Deploy is gated (Rule 2): default is to PROPOSE a diff and wait for confirmation. Prerequisites: a /sap-diagnose deliverable or a dump; pinned DEV /sap-login profile + active GUI session; SAP NCo 3.1 (32-bit) for RFC.
sap-forms
Makes the suite see SAP forms: SmartForms, SAPscript, and Adobe forms — inventory them with real usage evidence, read a 40-node form as a navigable tree/spec, and feed /sap-cc-* scope decisions with counts instead of anecdotes. inventory enumerates all three form families (STXFADM SmartForms, TADIR SAPscript/Adobe) with namespace/package filters, overlays the TNAPR output-determination assignment (output types, channels, driver program, routine) and NAST usage counts in a date window -> forms_inventory.tsv. download smartform exports the XML via the SMARTFORMS Utilities->Download GUI menu (no FM route exists — SSF_DOWNLOAD_FORM is absent on both releases); download sapscript exports ITF via RSTXSCRP (confirm-gated report). inspect adobe reads the readable Adobe metadata (TADIR + TNAPR usage) and is honest that the FP* layout tables are NOT RFC-readable (RAWSTRING columns) so there is no XDP extraction. explain parses a downloaded SmartForm XML into a page/window/text/code/condition node tree (or a SAPscript I
sap-function-group
Full lifecycle for SAP function groups: check existence, create, re-activate, query PROGDIR state, and delete. Mode-aware — picks the RFC fast-path (`RS_FUNCTION_POOL_INSERT`, `RFC_READ_TABLE` on TLIBG / TFDIR / TADIR / PROGDIR) when possible, falls through to GUI scripting (SE37 menus + SE38 delete) when no RFC equivalent exists. Honours `userConfig.sap_dev_mode` (GUI / RFC); the default chain for each operation is documented in the SKILL.md mode dispatch table. Replaces the now-removed `sap-se37-fugr` skill — call this skill for every function-group lifecycle step. Deletion is irreversible: the skill MUST confirm with the user before delegating to /sap-se38. Prerequisites: SAP NCo 3.1 (32-bit, .NET 4.0) in GAC for RFC paths; active SAP GUI session (use /sap-login first) for GUI paths.
sap-git
Install-free, read-only git backend for custom ABAP: gives Z code the PR-style review, blame, readable TR diffs, and whole-package-on-disk that abapGit would — without installing abapGit (often politically impossible on customer systems) and without ever writing to SAP. snapshot serializes a PACKAGE / TR / object-list scope to an abapGit-ISH tree over proven RFC reads and commits it to a local git repo with the TRs currently referencing the scope annotated in the message; diff re-serializes and shows working-system-vs-last-snapshot as a git diff; log/status are local git reads. Fully headless (no GUI/VBS), zero SAP writes. Fidelity is tri-state and honest: programs / function modules / message classes are FULL (RPY + T100 reads); DDIC (tables/data-elements/domains/table-types/views) and classes are PARTIAL deterministic metadata JSON (direct DD0xL / SEO reads — class SOURCE over RFC is unsupported, so classes ship as explicit metadata stubs; full DDIC via the Z_GENERIC_RFC_WRAPPER_TBL DDIF_*_GET path is v1.5)
sap-gui-inspect
Inspects the currently active SAP GUI session — structurally and/or visually — so a stuck GUI script (unexpected popup, a control ID that moved between releases, a greyed-out field, a hung transition) can be understood. Two mode families: STRUCTURAL dumps component IDs + properties — `tree` (component tree of all/one window), `menu` (menu bar), `type` (every component of a type, e.g. GuiButton/GuiShell), `id` (full property dump of one findById path), `wnd` (one window); VISUAL `screenshot` HardCopies every window into one annotated PNG (sub-modes topmost | composite | full, where full also dumps the topmost window's tree). The orchestrator reads the PNG with the Read tool. Other skills call this mid-flow to discover the current screen state. Replaces the former /sap-gui-object-details and /sap-gui-diagnose. Prerequisites: active SAP GUI session (/sap-login first); RZ11 sapgui/user_scripting = TRUE on the server.
sap-gui-probe
Drive a SAP transaction step by step against a natural-language scenario, dumping each screen's full property tree via /sap-gui-inspect and emitting a synthesized recording-style VBS at the end. Designed as a skill-authoring aid: probe SE37 before writing a new /sap-se37 flow. Captures more than the SAP recorder -- not just findById paths and actions, but also Changeable, Tooltip, IconName, popup transitions, and the program/transaction/screen identity at every step. Capture modes: * drive (default) -- Claude drives the transaction live (Steps 0-4). * --record [<vbs>] -- fallback when Claude can't reliably drive the flow (unfamiliar or write-heavy transaction, or when a real operator's exact clicks are wanted as ground truth): guides you to record it with SAP GUI's built-in Script Recording and Playback, then parses the saved VBS into the same findById/action map. Replaces the former /sap-gui-record skill; parsing an already-saved recording needs no live session. Two safety modes (drive only): * mode=confirm
sap-gui-skill-scaffold
Author a new transaction-specific SAP skill from multiple natural-language scenarios. Runs /sap-gui-probe for each scenario, then merges the resulting probe folders into one coherent skill folder: SKILL.md with mode dispatch, one references/sap_<name>_<mode>.vbs per probe, parameter tokens derived by cross-probe diff (values that vary across probes become %%TOKEN%%; values that stay constant bake in), popup-branch guards at every step where any probe observed a wnd[1] popup. Output is a ready-to-test draft. Prerequisites: active SAP GUI session (use /sap-login first).
sap-impact-analysis
Pre-change / pre-release impact analysis — answers "if I change this object, what else might break?" from SAP's system-maintained cross-reference index (not by parsing source, which is blocked, nor by driving the slow GUI where-used). Resolves the object, then gathers reverse dependencies (where-used), forward dependencies (what it uses), runtime entry points (tcodes, jobs, variants, RFC-enabled flag), and transport history. Computes a transparent LOW/MEDIUM/HIGH risk band from where-used fan-out + standard-object flag, writes a markdown report + per-dimension TSVs + risk findings, and registers them for /sap-evidence-pack. Discloses the dynamic-dispatch blind spot and reports COULD_NOT_CHECK rather than guessing on read failures. Inputs: program / class / FM / table / data element / domain / tcode (and TR / package by expansion). Read-only. Prerequisites: SAP profile via /sap-login (RFC); SAP NCo 3.1 (32-bit) in GAC.
sap-job
Manages ABAP background jobs on a live SAP system — schedule, list, status, log, spool, cancel, delete. Mode-aware: prefers the RFC fast-path (schedule via the RFC-enabled Z_RUN_REPORT; list/status via TBTCO; spool id via TBTCP; delete via BP_JOB_DELETE) and falls through to GUI (SM36 schedule / SM37 operations) when RFC is unavailable, honouring userConfig.sap_dev_mode. Scheduling a report EXECUTES it (possibly recurring), and cancel/delete are destructive — the skill ALWAYS confirms those before acting, per skill_operating_rules Rule 5. Reads (list/status/ log/spool) run without confirmation. Reuses Z_RUN_REPORT (deployed by /sap-dev-init) and delegates spool text to /sap-sp02 and abort detail to /sap-st22. Prerequisites: active SAP GUI session (/sap-login). The RFC path additionally needs SAP NCo 3.1 (32-bit) + Z_RUN_REPORT; without them the skill uses the SM36/SM37 GUI paths.
sap-login
Opens a SAP GUI connection and logs in using SAP GUI Scripting. Multi-profile connection store (Phase 4): save multiple SAP connections (different SID / Client / User / endpoint) at `{work_dir}\runtime\connections.json`, with passwords DPAPI-encrypted at rest. Picks the right one for this AI session via a 4-step identity compare and an AI-session pin. Also verifies SAP NCo 3.1 RFC connectivity (direct or load-balanced via MessageServer + LogonGroup + SystemID). Supports three connection methods: SAP Logon pad entry name (OpenConnection), load-balanced /M/<msrv>/G/<grp>/S/<sid> string, and direct /H/<host>/S/<port>. Checks existing sessions first; reuses the active connection when it matches the saved default. Prerequisites: SAP GUI installed, SAP GUI Scripting enabled (client + server).
sap-rfc-wrapper
Reaches non-RFC-callable ABAP code from outside the system (e.g. SAP NCo 3.1), in two modes: `fm` CALLS a non-RFC-enabled function module via the generic wrapper Z_GENERIC_RFC_WRAPPER_TBL (reads the FM interface, builds asXML, invokes it over RFC, returns the deserialized outputs); `class` GENERATES + deploys a dedicated RFC wrapper FM for a non-RFC-callable class method (reads the method interface, emits Z_CLSWRP_<CLASS>_<METHOD>, deploys via /sap-se37). The modes compose: `class` builds a wrapper FM, `fm` then calls any FM. Replaces the former /sap-rfc-wrapper-fm and /sap-rfc-wrapper-class. Prerequisites: SAP profile via /sap-login (RFC password); SAP NCo 3.1 (32-bit) in GAC. `fm` needs Z_GENERIC_RFC_WRAPPER_TBL (deploy via /sap-dev-init); `class` needs an active SAP GUI session for the /sap-se37 deploy.
sap-run-abap-unit
Executes ABAP Unit tests on a deployed object (program or global class) via SAP GUI Scripting and reports per-method pass / fail with a verdict gate. Opens the object in SE38 / SE24, triggers the ABAP Unit run (via the SE38/SE24 menu), and parses the result display. Closes the generate -> deploy -> activate -> TEST loop for /sap-gen-abap output (Z<PROGRAM_ID>_TEST) and works standalone on any brownfield object. GUI backend, verified on S/4HANA 1909. Results-only by default; with --with-coverage it ALSO measures code coverage (Unit Tests With Coverage), running the suite twice (counts + coverage) since the coverage display has no status-bar summary. The RFC backend (Z_AUNIT_RUN, Phase 2) does both in one headless call. Result/coverage component IDs are release-specific; if the skill emits NEEDS_RECORDING, record them once with /sap-gui-probe --record (see "Result parsing" below). Prerequisites: Active SAP GUI session (use /sap-login first); developer authorization to run ABAP Unit (S_DEVELOP on the object).
sap-run-report
Executes an ABAP report/program on a live SAP system and captures the output — foreground (SA38 F8, interactive list) or background (scheduled job), with or without a variant, or ad-hoc selection values. Also maintains variants — create/overwrite (set) and delete via the SAPLSVAR GUI dialogs, list/show via RFC. Mode-aware: prefers the RFC fast-path where present and falls through to GUI (SA38 F8 / Execute-in-Background) when RFC is unavailable, honouring userConfig.sap_dev_mode. Executing a report can change data (UPDATE / COMMITting BAPI / job submit / IDoc / mail) — the skill ALWAYS confirms before it runs, per skill_operating_rules Rule 5. Prerequisites: active SAP GUI session (use /sap-login first). The RFC background path additionally needs SAP NCo 3.1 (32-bit) + Z_RUN_REPORT (deploy via /sap-dev-init); variant list/show route through /sap-rfc-wrapper.
sap-scratch-run
A guarded write-run-inspect REPL for SAP so the AI can empirically OBSERVE what the system does instead of guessing (the ABAP debugger is unreachable via GUI Scripting). `run` turns a question into a tiny read-only $TMP probe report, statically guards it (a hard REFUSE on any write / COMMIT / CALL TRANSACTION / SUBMIT / dynamic-write / file / lock construct), syntax- checks it headlessly, deploys it ($TMP, no transport), executes and captures the list, then auto-deletes it and verifies the deletion. `fm` calls a function module with a supplied parameter set and captures the exporting/tables result + wall-clock runtime, routing by TFDIR.FMODE (remote-enabled → direct RFC; classic → the dev-init wrapper). Lets gen-abap / fix-abap / diagnose verify SAP behaviour empirically. Every deploy and every FM call is confirm-gated (an FM may mutate and the skill cannot statically prove otherwise); `run` also refuses on a non-modifiable/production client. Prerequisites: /sap-login; for `run` a GUI session (deploy/execute
sap-se01
Manages SAP transport requests via transaction SE01 (SAP GUI Scripting). Four modes: CREATE (default — a new Workbench TR, Customizing only when explicitly asked; description per userConfig.rule_of_tr_description; the new TRKORR is resolved locale-independently and echoed as RESULT_TR, unresolvable = hard ERROR, never a guess); RELEASE (`release <TR>` — pre-checks status + object inventory, asks explicit confirmation, releases the request + open tasks — irreversible); DELETE (`delete <TR>` — empties then deletes an UNRELEASED request bottom-up, confirms first, verifies removal; refuses released / non-dev TRs); REMOVE-OBJECTS (`remove-objects <TR> [OBJECTS=a,b]` — unassigns E071 entries but KEEPS the request, clearing the name-lock so deleted objects can be re-created). Prerequisites: active SAP GUI session (/sap-login first).
sap-se11
Creates and updates ABAP Dictionary objects in SAP via SE11 using SAP GUI Scripting. Supports all 9 DDIC object types: Database table, View, Data element, Structure, Table type, Type group, Domain, Search help, and Lock object. Uses tab-delimited definition files for structured input. Existence check, create or update, save, and activation. Also supports delete mode: when the user asks to delete a DDIC object (e.g. "delete table ZTABLE", "drop structure ZSTRUCT", "remove domain ZDOM"), routes by object type to the correct SE11 radio + name field, presses Shift+F2 from the initial screen, confirms via btnSPOP-OPTION1 (Yes), handles dependent-object and post-delete TR popups, and verifies removal. Deletion is irreversible — the skill asks for explicit confirmation before running the VBS. For database tables, SE14 is the canonical drop path; this skill flags the SE14 fallback if the SE11 delete leaves the table in place. Prerequisites: Active SAP GUI session (use /sap-login first).
sap-se14
SE14 (DB Utility) for stuck DDIC tables — closes the gap /sap-se11 names but never implemented. check is a read-only RFC snapshot of DDIC-vs-DB consistency (DD02L active row + pending version, DWINACTIV inactive worklist, TBATG open conversion/DB-utility request with its state, DBDIFF DDIC/DB diff, QCM<T>/QCM8<T> shadow table, DDPRH log header) -> verdict CONSISTENT / ADJUST_NEEDED / CONVERSION_RUNNING / CONVERSION_TERMINATED / NOT_FOUND; it is safe to auto-chain after a failed table activation. adjust drives SE14 "Activate and adjust database" on the **save-data path only** — the delete-data radio is structurally unreachable (no code path selects it; the save-data radio is asserted by component ID before the adjust press), not merely gated. unlock recovers a TERMINATED conversion (continue = restart; release-lock only when a QCM-data guard proves no data is stranded). Both write modes are confirm-gated, GUI-driven (SAPMSGTB, identical on both releases), and post-verified by an authoritative RFC re-read. No T
sap-se16n
Queries any SAP table via SE16N using SAP GUI Scripting and downloads the result set as a tab-delimited text file. Supports filtering by any combination of table fields with single value, multi-value (IN list), or range (BT) selection, and any of the standard SE16N operators (EQ, NE, GT, LT, GE, LE, BT, NB, CP, NP, IN). Optionally restricts the output columns to a specific set of fields; if no SELECT list is given, all fields are returned. Detects the "no values found" path and writes a marker file instead of an empty download. Typical use: dump rows from any SAP table for inspection or as reference data for development. Snapshot modes add a table-state assertion primitive: `snapshot save <name>` captures a query result under {artifact_dir}\snapshots; `snapshot diff <a> <b>` row-diffs two snapshots on declared key columns (ignoring volatile columns) via the shared keyed-diff engine — ADDED/REMOVED/CHANGED/SAME; `snapshot list` enumerates them. Prerequisites: Active SAP GUI session (use /sap-login first). `sna
sap-se19
Full lifecycle for SAP BAdI implementations via SE19 (BAdI Builder) using SAP GUI Scripting: Create, Update, Display, Delete, Activate, and Deactivate — for BOTH Classic BAdIs (SXS_ATTR / SXC_*) and New BAdIs (Enhancement Framework / BADI_IMPL). Auto-detects the BAdI type via RFC (SXS_ATTR-EXIT_NAME for Classic, BADI_IMPL-BADI_NAME for New); asks the user when a migrated BAdI is genuinely ambiguous (e.g. MB_MIGO_BADI, ME_PROCESS_PO_CUST). For Create the user supplies a BAdI DEFINITION / enhancement-spot name; for all other operations the user supplies a BAdI IMPLEMENTATION name. Implementing-class work (method source, class create/activate) is delegated to /sap-se24; package reassignment is delegated to /sap-change-package. NEVER deletes a BAdI definition or any implementation it did not create. Prerequisites: Active SAP GUI session (use /sap-login first). SAP NCo 3.1 (32-bit) for the RFC type-detection step.
sap-se21
Creates, checks, or deletes SAP development packages via transaction SE21 using SAP GUI Scripting (VBS). First verifies package existence using RFC_READ_TABLE on TDEVC, then creates it via the live GUI session. Delegates transport-request resolution to /sap-transport-request — never prompts the user for a TR or calls /sap-se01 directly. Also supports delete mode: when the user explicitly asks to delete a package (e.g. "delete package <X>", "drop package <X>"), navigates to SE21, fills the package name, presses Shift+F2 (sendVKey 14) from the initial screen, walks the confirmation popup chain, and verifies removal. Deletion is irreversible — the skill MUST confirm with the user (showing TADIR child count from the existence check) before launching the VBS. Connection parameters from settings.json (sap-dev-core plugin). Prerequisites: SAP GUI installed, SAP GUI Scripting enabled, an active logged-in session (run /sap-login first).
sap-se24
Deploys ABAP class/interface source to a SAP system via SE24 (SAP GUI Scripting) — creates or updates classes: existence check, source upload (full CLASS DEFINITION … IMPLEMENTATION … ENDCLASS via the source-code view), save, activate. Also three secondary modes on an existing class: check-and-fix ("fix Class" / "check and fix Class" with no source — syntax-check, download, fix, re-upload, activate); change-properties (Description / Program Status / Category via Goto → Properties, then Save + Activate; normalises a form-based Class Builder to source-based for the edit); delete ("delete class/interface <X>" — irreversible, asks for explicit confirmation, verifies removal). Handles the original-language + Workbench-request popups per /sap-transport-request. Prerequisites: active SAP GUI session (/sap-login first).
sap-se37
Deploys ABAP function module source to a SAP system via SE37 (SAP GUI Scripting) — creates or updates FMs: existence check, source upload (full FUNCTION … ENDFUNCTION include), save, activate. Also four secondary modes on an existing FM: check-and-fix ("fix FM" / "check and fix FM" with no source — syntax-check, download, fix, re-upload, activate); change-attributes (Short Text / Processing Type: Regular / Remote-Enabled / Update Module); reassign-function-group ("reassign FM <X> to <FG>" — moves it, then re-activates); delete ("delete <FM>" — irreversible, asks for explicit confirmation, verifies removal). Handles the original-language + Workbench-request popups per /sap-transport-request. Prerequisites: active SAP GUI session (/sap-login first).
sap-se38
Deploys ABAP source to a SAP system via SE38 (SAP GUI Scripting) — creates or updates programs: existence check, source upload (file path or pasted code), syntax check, save, activate, and (for Report type 1) selection-text update. Also three secondary modes on an existing program: check-and-fix ("fix PGM" / "check and fix PGM" with no source file — syntax-check, download, fix errors, re-upload, activate); change-attributes (Title / Status / Type / header fields via Goto → Attributes, then Save + Activate so it persists); delete ("delete program <X>" — irreversible, asks for explicit confirmation, verifies removal). Handles the SAPLSETX original-language popup and the Workbench-request popup per /sap-transport-request. Prerequisites: active SAP GUI session (/sap-login first).
sap-se41
Manages PF-STATUS (GUI status) subobjects of an SE41 Menu Painter interface (program / function pool) on a live SAP system via SAP GUI Scripting. Supports the operations CREATE, UPDATE, DISPLAY, DELETE, ACTIVATE, DEACTIVATE, COPY and an existence CHECK. SE41 has no Upload/Download for status definitions — function codes are entered field by field from a pipe-delimited definition file. Package (development class) changes are delegated to /sap-change-package. Prerequisites: Active SAP GUI session (use /sap-login first).
sap-se51
Maintains screens (dynpros) in a SAP system via SE51 using SAP GUI Scripting. Two modes: (a) FLOW LOGIC — create new screens or update an existing screen's flow logic (PROCESS BEFORE OUTPUT / PROCESS AFTER INPUT). Existence check (SE51 Display), flow logic paste via Windows clipboard, save, activate. (b) LAYOUT / ADD ELEMENT — add layout elements (static Text labels, Input/Output fields, checkboxes, pushbuttons, radio buttons) to an existing screen via the ALPHANUMERIC Screen Painter (Edit > Create Element). This is the only scriptable placement path: the graphical drag-and-drop Layout Editor is a non-scriptable ActiveX control the recorder cannot capture, and the element-list grid is read-only for placement. Requires the per-user "Graphical Layout Editor" setting OFF. Prerequisites: Active SAP GUI session (use /sap-login first).
sap-se54
Generates a table maintenance dialog in SAP via SE54 using SAP GUI Scripting. Checks if the maintenance dialog already exists, then generates it with authorization group, function group, maintenance type, and screen number. Existence check and generation flow. Prerequisites: Active SAP GUI session (use /sap-login first).
sap-se91
Manages SAP message classes via SE91 using SAP GUI Scripting. Creates new message classes or updates messages in existing ones. Existence check (SE91 Display), message text editing via inline table, and save. Messages are provided as tab-separated number/text pairs in a file. Also supports change-properties mode: when the user asks to change a message class's header attributes (Short Text, Person Responsible, ...), opens SE91 with the Header radio (radRSDAG-MIDFLAG) in change mode, updates the supplied fields on tabpHEAD, then Saves. Handles the conditional original-language popup and the post-save Workbench-request popup (per /sap-transport-request). Prerequisites: Active SAP GUI session (use /sap-login first).
sap-sm12
Lists and safely releases SAP enqueue locks (transaction SM12) over RFC — no GUI. Two modes. `list` (read-only) dumps current lock entries via ENQUEUE_READ with a computed lock AGE and a best-effort owner-liveness column, filterable by user / table / lock argument / client / age. `release` (destructive, gated) releases a stale lock ONLY after proving the owner has no session on ANY application server (a liveness gate that reads TH_SERVER_LIST + TH_USER_LIST, and TH_SYSTEMWIDE_USER_LIST on multi-instance systems), showing the lock evidence, requiring the operator to TYPE the owner's user name to confirm, deleting via ENQUE_DELETE, then re-reading to verify and writing an audit line. It hard-refuses whenever the owner is still live or liveness cannot be proven — there is no --force. Automates exactly the risky part of the daily "clear a stuck lock" op (the owner-death check operators get wrong on multi-instance systems), so it is safer than the manual SM12 path, not just faster. Use for: stuck / stale enqueue l
sap-snro
Creates, maintains, and manages SAP Number Range Objects (NRO) via SNRO using SAP GUI Scripting. Number Range Objects are crucial for generating unique identifiers for SAP master data and document numbers (e.g. material numbers, document numbers, custom Z document IDs). Supports existence check, create new NRO with short text / long text / domain (number length) / warning percentage, update header attributes, and maintain number range intervals (sub-objects with FROMNUMBER / TONUMBER / current number / external flag). Handles the package + transport request popup (3-way pattern: explicit TR, $TMP local object, or new transport). Prerequisites: Active SAP GUI session (use /sap-login first).
sap-log-analyze
Summarize sap-dev JSONL log files. Aggregates per-skill counts, success/fail rates, p50/p95 duration, top error_class, and recent FAILED runs (with parent_run_id chain). Filters by --since / --skill / --status. With --builds, instead reconstructs generated-ABAP builds from the same logs and reports first-pass-yield KPIs (gen/check/syntax/activation/ATC/ABAP-Unit) to a dashboard. Reads log_dir from sap-dev-core/settings.json.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.