Skip to content
Development
Skill

/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

From plugin
sap-dev
8123 skills3 agents
Install
$ npx -y skills add sapdev-ai/sap-dev --skill sap-dev-init --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/sap-dev-init

Context preview

The summary Claude sees to decide when to auto-load this skill.

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.md

sap-dev-init.SKILL.md
name: sap-dev-init
description: |
  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.
argument-hint: ""

SAP Dev Init Skill

You initialize the SAP development environment by ensuring all required objects exist in the target SAP system. This is typically run once after plugin installation.

Task: $ARGUMENTS

---

Shared Resources

| File | Purpose | |---|---| | `<SAP_DEV_CORE_SHARED_DIR>/scripts/sap_tr_object_entries.ps1` | RFC E071/E070 read (Step 1.5) — with `-OnlyOrphaned`, finds dev-init objects whose definition is gone but whose lock lingers in an old unreleased request (would block re-create); cleared via `/sap-se01 remove-objects` | | `<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 | | `<SAP_DEV_CORE_SHARED_DIR>/rules/language_independence_rules.md` | GUI-scripting language independence — applies to the GUI-driving sub-skills this orchestrator dispatches (sap-transport-request, sap-se21, sap-function-group, sap-se38) | | `<SAP_DEV_CORE_SHARED_DIR>/rules/abap_code_quality_rules.md` | ABAP code-quality rules — the `Z_GENERIC_RFC_WRAPPER_TBL` wrapper FM source deployed by this init flow follows modern syntax, OOP / exception conventions, and no literal MESSAGE strings. **Exception:** `ZCMRUPDATE_ADDON_TABLE.abap` (Step 8) is deliberately **classic-syntax** so a single source activates on ECC 6.0 / NetWeaver ≤7.40 as well as S/4HANA — do NOT modernize it (see that file's header + sap-update-addon Step 4c). |

---

Step 0 — Resolve Work Directory and Mode

**Resolve `{work_dir}` per `<SAP_DEV_CORE_SHARED_DIR>\rules\work_dir_onboarding.md`** — `/sap-dev-init` is an onboarding entry point (probe → use the env value / soft tip / first-run prompt + set / migrate-on-change). **Never read `settings.json` directly for `work_dir`** (that ignores `SAPDEV_AI_WORK_DIR` + `userconfig.json`). Probe:

powershell -NoProfile -ExecutionPolicy Bypass -File "<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_workdir_setup.ps1" -Action probe

Once `{work_dir}` is known, apply the current-session env bridge (doc Step E): prefix subsequent PowerShell commands with `$env:SAPDEV_AI_WORK_DIR='{work_dir}';` (escape the `$` as `\$` when the command runs through bash; see `work_dir_onboarding.md` Step E). The settings note below covers 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`. Resolve sap-dev-core paths: 2 levels up from `<SKILL_DIR>` to the plugin root, then `settings.json` and (if present) `settings.local.json`. Read `custom_url`, `sap_dev_mode`.

**Per-connection keys (Phase 4.4)**: `sap_dev_mode` is SAP-system-specific (GUI/RFC/BDC capability varies per system). Per `settings_lookup.md` § Per-connection exception, read it from `connections.json[pinned-profile].dev_defaults` FIRST (resolve the pin via `{work_dir}\runtime\session_registry.json` `ai_sessions[<id>]`); only fall back to the two-file merge when `dev_defaults` is empty. Sub-steps that delegate to `/sap-transport-request`, `/sap-se21`, `/sap-function-group` inherit the same per-connection routing for TR/PKG/FG. **WRITES — standing dev defaults go in the connection block, not the global layer:** when this skill persists a standing default (TR / package / FG / `way_to_get_transport_request` / `rule_of_tr_description` / `tr_description_template`), write it **Connection-scoped** — `<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_dev_default.ps1 -Action set -Key <k> -Value <v> -Scope Connection` (or `Set-SapUserSetting … -Scope Connection`) — NOT `/update-config` (that writes the shared global layer, read only as a last-resort fallback, and not system-qualified). The delegated `/sap-transport-request` now persists the resolved TR **Session-scoped** (task default), so after it resolves the dev TR, ALSO persist that TR Connection-scoped here so the standing dev TR survives across conversations.

| Setting | Default if blank | |---|---| | `work_dir` | `C:\sap_dev_work` | | `custom_url` | `{work_dir}\custom` | | `sap_dev_mode` | `GUI` |

Set `{WORK_TEMP}` = `{work_dir}\temp`

Ensure the temp directory exists:

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

Set `{RUN_TEMP}` = the per-run scratch dir from `Get-SapRunTemp` (env bridge applied):

powershell -NoProfile -ExecutionPolicy Bypass -Command "\$env:SAPDEV_AI_WORK_DIR='{work_dir}'; . '<SAP_DEV_CORE_SHARED_DIR>\scripts\sap_connection_lib.ps1'; Write-Output ('RUN_TEMP=' + (Get-SapRunTemp))"

dev-init's OWN scratch (the `sap_dev_init_run.json` state file and the `sap_gui_security_warmup_*.vbs` it generates) goes under `{RUN_TEMP}`. **The cross-skill handoff files stay on `{WORK_TEMP}` (base), by design**: the `.def` / `.abap` sources this skill copies for `/sap-se11`, `/sap-se37`, `/sap-se38` are passed to those child skills as **absolute paths** and consumed there as user-supplied files (the child never deletes them and writes its own scratch in its own per-run dir). Keeping the handoffs on base avoids an rmdir-ordering hazard — dev-init does **NOT** `rmdir {RUN_TEMP}`; its existing per-file cleanup and `/sap-dev-clean` handle the handoff artifacts as before.

Validate `sap_dev_mode`. Allowed values: `G

Read more
Ships withsap-dev

SAP development automation skills for AI coding assistants. Windows-only — the skills drive SAP GUI for Windows via GUI Scripting (plus optional RFC via SAP NCo); there is no macOS/Linux path.

Get the whole plugin

Other skills on sap-dev.