/sap-se19

name: sap-se19
description: |
  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.
argument-hint: "<operation> <name>  e.g. 'create ME_PROCESS_PO_CUST', 'display ZHK_BADI_PO_007', 'deactivate ZHK_BADI_PO_007', 'delete <impl>'"

SAP SE19 BAdI Implementation Lifecycle Skill

You drive transaction **SE19 (BAdI Builder)** to manage the full lifecycle of a BAdI **implementation** — Create / Update / Display / Delete / Activate / Deactivate — for both **Classic** and **New** (Enhancement Framework) BAdIs.

Two facts decide everything:

1. **Operation** — `create` takes a BAdI **definition / enhancement-spot** name; every other operation takes a BAdI **implementation** name. 2. **BAdI type** — Classic vs New, decided automatically by an RFC classifier (`references/sap_se19_classify.ps1`). If a name is genuinely ambiguous (a *migrated* BAdI that lives in both worlds), you ASK the user.

Task: $ARGUMENTS

---

Shared Resources

| File | Purpose | |---|---| | `<SAP_DEV_CORE_SHARED_DIR>/rules/safety_policy.md` | **Rule 0 (highest priority)** — environment guard; enforced by Step 0.6 via `sap_safety_gate.ps1` | | `<SAP_DEV_CORE_SHARED_DIR>/rules/skill_operating_rules.md` | Mandatory operating rules (no unsolicited deploy; no raw SQL writes on SAP tables) | | `<SAP_DEV_CORE_SHARED_DIR>/rules/tr_resolution.md` | TR resolution — this skill delegates to `/sap-transport-request`; never prompt for a TR directly | | `<SAP_DEV_CORE_SHARED_DIR>/rules/language_independence_rules.md` | GUI scripting must identify by component ID + DDIC field; status via `MessageType`; VKey not menu-text; no branching on `.Text`/titles | | `<SAP_DEV_CORE_SHARED_DIR>/rules/abap_code_quality_rules.md` | Applies to any implementing-class source deployed via `/sap-se24` | | `<SAP_DEV_CORE_SHARED_DIR>/scripts/sap_rfc_lib.ps1` | RFC connect helper used by the classifier | | `<SAP_DEV_CORE_SHARED_DIR>/scripts/sap_attach_lib.vbs` | Parallel-safe session attach (token `%%ATTACH_LIB_VBS%%`) |

**Delegation (do not reimplement these in SE19):**

| Concern | Delegate to | Call | |---|---|---| | Implementing-class method source / create / activate (Rule #4) | `/sap-se24` | `/sap-se24 <IMPL_CLASS> <abs-source.abap>` | | Change an object's package (Goto ▸ Object Directory Entry) (Rule #5) | `/sap-change-package` | `/sap-change-package CLASS <class> <pkg>` | | Resolve a transport request | `/sap-transport-request` | (TR returned; passed into the VBS) |

---

Step 0 — Resolve work directory

**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 note below still applies to any OTHER keys.

Settings reads/writes follow `shared/rules/settings_lookup.md` — merge per-key on `.value` (env var → `settings.local.json` → `userconfig.json` → `settings.json`); non-per-connection writes go to `userconfig.json`. Set `{WORK_TEMP}` = `{work_dir}\temp`.

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

Set `{RUN_TEMP}` = the per-run scratch dir (`Get-SapRunTemp` mints + creates `{work_dir}\temp\run_<id>`):

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

Per the CLAUDE.md "Two-bucket temp model" write this skill's generated scratch (`*_run.ps1` / `*_run.vbs` and the `_run.json` state) under `{RUN_TEMP}`; keep `{WORK_TEMP}` (base) only for `Get-SapCurrentSessionPath -WorkTemp`.

`{LEDGER}` = `{WORK_TEMP}\se19_created_ledger.jsonl` (safety ledger — see Step 6).

---

Step 0.5 — Start logging (best-effort)

powershell -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_log_helper.ps1" -Action start -StateFile "{RUN_TEMP}\sap_se19_run.json" -Skill sap-se19 -ParamsJson "{\"op\":\"<OP>\",\"name\":\"<NAME>\"}"

---

Step 0.6 — Safety Gate (Rule 0 — `safety_policy.md`)

The write operations (`create`, `update`, `delete`, `activate`, `deactivate`) run the environment gate before any SAP-side step; `display` is read-only and skips it:

powershell -NoProfile -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_safety_gate.ps1" -Action assert -Skill sap-se19

| Verdict (last line) | Exit | Action | |---|---|---| | `SAFETY: ALLOW ...` | 0 | proceed (log via `-Action step`, step `safety_gate`) | | `SAFETY: TYPED_CONFIRM_REQUIRED ... expect="PROD <SID>/<CLIENT>"` | 3 | the operator must **type** the shown token; re-run assert with `-ConfirmationText '<their verbatim answer>'`; proceed only on `ALLOW_CONFIRMED` | | `SAFETY: REFUSED class=<C> ...` | 1 | **STOP.** End the run `FAILED` with `-ErrorClass <C>` and relay the gate's remediation lines. Never bypass, soften, ret