/sap-gui-probe

name: sap-gui-probe
description: |
  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 (default) -- read-only actions auto-proceed; write
      actions (Save / Activate / Delete and the matching VKey codes 11, 14,
      27, 28, 33) pause for explicit user confirmation.
    * mode=auto  -- opt-in via trailing `--auto` flag in the scenario;
      every action proceeds without prompting.

  Prerequisites: Active SAP GUI session (use /sap-login first).
argument-hint: "<TXN>: <scenario>   |   <TXN>: <scenario> --record [<vbs-path>]   e.g. 'SE37: display FM RFC_READ_TABLE then exit'   (append --auto to skip confirmations)"

SAP GUI Probe Skill

You drive a SAP transaction step by step against a natural-language scenario the user supplied. At every screen transition you call the sap-gui-inspect VBS to capture a full property dump, you emit one small action JSON describing the next move, you classify that action as READ or WRITE, you (optionally) confirm with the user, and you execute it.

When the scenario is complete you synthesize every action into one replayable VBS. The output folder is the deliverable -- a fresh skill author can read it and write a deterministic skill for the probed flow.

Task: $ARGUMENTS

---

Shared Resources

| File | Purpose | |---|---| | `<SAP_DEV_CORE_SHARED_DIR>/rules/safety_policy.md` | **Rule 0 (highest priority)** — environment guard; enforced by the drive-mode write classifier via `sap_safety_gate.ps1` | | `<SAP_DEV_CORE_SHARED_DIR>/rules/skill_operating_rules.md` | Mandatory operating rules | | `<SAP_DEV_CORE_SHARED_DIR>/rules/settings_lookup.md` | Settings model — merge per-key on `.value` (env var → `settings.local.json` → `userconfig.json` → `settings.json`); non-per-connection writes go to `userconfig.json` | | `<SAP_DEV_CORE_SHARED_DIR>/rules/language_independence_rules.md` | GUI-scripting language independence — identify by component ID + DDIC field name, status-bar checks via `MessageType` codes (S/W/E/I/A), VKey instead of menu-text, no branching on `.Text`/`.Tooltip`/window titles | | `<SAP_DEV_CORE_SHARED_DIR>/rules/sap_gui_scripting_reference.md` | Component-ID grammar + type-prefix / VKey / toolbar tables + runtime gotchas. Used by `--record` mode (Mode R) to decode a recorded VBS into findById paths. Promoted from the retired `sap-gui-record` skill. |

---

Step 0 — Resolve work directory and run folder

**Resolve `work_dir` via the env-aware helper** — do NOT take `work_dir` from a direct `settings.json` read (that ignores the `SAPDEV_AI_WORK_DIR` env var and `userconfig.json`). Use the `WORK_DIR=` value printed by:

powershell -NoProfile -ExecutionPolicy Bypass -Command ". '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_settings_lib.ps1'; . '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_connection_lib.ps1'; Write-Output ('WORK_DIR=' + (Get-SapWorkDir))"

The settings note below still applies to the OTHER keys.

**Settings reads/writes follow `shared/rules/settings_lookup.md`** — merge per-key on the `.value` field (env var → `settings.local.json` → `userconfig.json` → `settings.json`); non-per-connection writes go to `userconfig.json`. Read sap-dev-core's `settings.json` (go 2 levels up from `<SKILL_DIR>` to the plugin root, then `settings.json`). | Setting | Default if blank | |---|---| | `work_dir` | `C:\sap_dev_work` |

Derive:

• `{WORK_TEMP}` = `{work_dir}\temp`
• `{TS}` = current timestamp `yyyyMMdd-HHmmssfff` (milliseconds — REQUIRED for parallel-safety; two probes started in the same second under a parallel scaffolder run would otherwise collide on folder name)
• `{PID}` = the orchestrator's process ID — append as an extra suffix to guarantee uniqueness across simultaneous AI sessions on the same host. PowerShell: `$PID`. Bash on Windows: `echo $$` (the cygwin/git-bash PID, distinct per shell). Either works.
• `{TXN}` = transaction code extracted from the scenario in Step 1
• `{RUN_FOLDER}` = `{work_dir}\probes\{TXN}_{TS}_p{PID}`

Ensure folders exist (one Bash call, two mkdir):

cmd /c if not exist "{WORK_TEMP}" mkdir "{WORK_TEMP}"
cmd /c if not exist "{RUN_FOLDER}" mkdir "{RUN_FOLDER}"

**Why ms + pid?** Today's parallel scaffolder spawns N sub-agents from one process; each sub-agent invokes this skill in its own cscript run, but they all derive `{TS}` from `Get-Date -Format 'yyyyMMdd-HHmmss'` and can land in the same second. Adding `fff` (ms) and the process ID makes collisions effectively impossible in practice. Sub-agents under the SAME orchestrator process share `{PID}` but have different `{TS}` ms; sub-agents under DIFFERENT orchestrator processes (the typical AI-session-vs-AI-session case) have different `{PID}`. Either axis alone is sufficient; using both is belt-and-braces.

---

Step 0.5 — Start logging

State file: `{RUN_FOLDER}\sap_gui_probe_run.json`. Best-effort.

powershell -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_log_helper.p