Sc4sap:create Object

SC4SAP Create Object

Guided ABAP object creation workflow. Hybrid mode: confirms transport and package interactively, then auto-creates, writes initial code, and activates the object.

Invoke /sc4sap:trust-session with parent_skill=sc4sap:create-object to pre-grant all MCP tool + file-op permissions for this session (eliminates per-tool "Allow this tool?" prompts during Create* + activation flow).

• If .sc4sap/session-trust.log already has a line within the last 24h, skip silently.
• Otherwise run it and surface the one-line confirmation.

Full spec: see ../trust-session/SKILL.md.

Priority: Standard DE (1) → existing CBO DE (2) → new CBO DE (3) → Data Type + Length (4, last resort). Raw primitives like LIFNR CHAR 10 / MATNR CHAR 40 / BUKRS CHAR 4 are forbidden when an authoritative SAP data element exists. Before each field, run SearchObject against DTEL and check .sc4sap/cbo/<MODULE>/<PACKAGE>/inventory.json.

FM signature is stored inline in the FUNCTION statement source (SAP parses it on write and updates TFDIR/FUPARAREF automatically). There is no separate "parameters" endpoint. Every FM source MUST declare IMPORTING / EXPORTING / CHANGING / TABLES / EXCEPTIONS clauses directly between FUNCTION {name} and the first .. Never emit the placeholder " You can use the template 'functionModuleParameter' ... line, never use *"*"Local Interface: blocks as a substitute, never declare shadow locals like lv_iv_xxx TYPE ... to stand in for missing parameters.

Remote-Enabled (RFC) flag is a separate concern — stored in TFDIR.FMODE, not in source. Currently requires manual SE37 Properties update; flag this in the completion report.

Auto-execute (after confirmation):

• Create object via appropriate MCP Create* tool
• Generate initial implementation (skeleton with proper structure)
• Activate the object
• Verify activation via GetInactiveObjects

Per-step model allocation (skill main thread runs on Sonnet 4.6 per frontmatter; creation delegates to sap-executor; the report is rendered on main):

At Step 2 (metadata collection) — when the object belongs to a specific SAP module (MM table, SD structure, PS data element, …) — the main thread reads SAP_ACTIVE_MODULES from sap.env / config.json and consults ../../common/active-modules.md. If companion modules are active, proactively suggest integration fields (e.g., creating an MM CBO table in a landscape with PS active → suggest adding PS_POSID / AUFNR). Do NOT add silently — propose to user and let them accept/decline, then pass the confirmed field list through to the executor dispatch.

The reference file covers:

• General rules (prefix, case, character set, length limits)
• Module codes (SD/MM/FI/CO/...) for the Z{MODULE}_... pattern
• Object-specific patterns — Classes (ZCL_/ZIF_/ZCX_), Programs (ZR_), Function Groups/Modules, Data Dictionary (ZT_/ZDE_/ZDO_), UI (Dynpro/GUI Status), OData/RAP (Z_I_/Z_C_/Z_BP_/Z_SB_), Enhancements, IDoc/ALE
• Code-level naming (variables: LV_/LS_/LT_/IV_/EV_/MV_; constants GC_/LC_; types TY_; methods)
• Validation rules (uppercase, Z/Y prefix, character set, max length, non-generic)

Quick validation checklist (applied before every create):

1. Starts with Z or Y (customer namespace)
2. UPPERCASE only, characters in [A-Z0-9_]
3. Within max length (30 chars for most objects)
4. Not generic (ZTEST/ZTEMP/ZDUMMY forbidden)
5. Object-type prefix follows the reference (e.g., ZCL_ for classes, ZIF_ for interfaces)
6. Screen = 4-digit number (e.g., 0100); GUI Status = uppercase identifier (e.g., STATUS_0100) — both require a parent program

If the user-provided name violates any rule, suggest a compliant alternative based on configs/common/naming-conventions.md before proceeding.

Task: {{ARGUMENTS}}