The sap-abap skill
sap-abap is the general-purpose skill for driving abapctl. It is the thing you load into an agent so that, when a user mentions SAP, ABAP, ATC, transports, CDS, RAP, OData, or any of the development primitives abapctl covers, the agent knows which command fits the intent, how to call it safely, and what to do with the result.
It is not a wrapper or a code layer; it is a Markdown mental model. The skill is two files: SKILL.md (the decision aid you keep loaded) and reference.md (the flag catalog and non-obvious behaviors you consult when picking flags).
What it gives an agent
- A mental model of what abapctl is and where it sits (the deterministic primitive under the agent's reasoning).
- An intent→command map: a scannable table from "what the user wants" to "which command does it", covering browse/understand, read source, run checks, preview data, consume OData, refactor, write/activate, create, transport, workspace, Clean Core, system.
- A safety model: every command pre-classified read-only / mutating / destructive, plus the rules for
--dry-run,--yes, transports, and dual-mode refactoring (evaluate-first, execute-only-with-an-action-flag). - A failure decoder: common symptoms (401/403, HTTP 423 lock,
CAPABILITY_NOT_AVAILABLE) mapped to cause and fix. - The non-obvious rules that otherwise cost an agent cycles. For example:
source getwith no--includereturns the full global class including method bodies (and writing a globalIMPLEMENTATIONinto theimplementationsinclude breaks activation), positions are 1-based, andtext-elements putrequires--categoryand does not auto-activate.
The core principle: never assume a command exists
The most important instruction in the skill is that the skill is a map, not the territory. The CLI evolves (new command groups, new flags) and any static skill file can lag. So before acting, the agent grounds itself in the live contract on the machine it is running on:
abapctl tools list --jsonis the authoritative machine-readable contract: every command, its parameters, and itsreadOnly/destructive/idempotentannotations. Run this first to discover the real command set and to decide safety. Treat thedestructiveflag as binding regardless of what the skill says.abapctl <group> --helpandabapctl <group> <cmd> --helpgive exact flags, choices, and defaults when you need detail beyond the contract.- Only then consult the skill's tables as a shortcut for which command fits an intent.
The corollary: do not invent command names, flags, or values from memory or from the skill alone. If a command or flag is not in tools list --json / --help on this system, it does not exist there, so adapt rather than guess. If tools list shows a command the skill doesn't mention, trust tools list. The live contract always wins.
How an agent uses it
A typical loop the skill encodes:
- Discover and ground:
tools list --json, then--helpfor detail. - Understand before changing with
code definition,code element-info,code referencesto map impact. - Round-trip source:
source get→ edit →check syntax --source→source put→ re-check, always previewing destructive writes with--dry-runand only passing--yesafter a human approves. - Read exit codes as signal:
0clean,1partial (findings exist, diffs present, treat as data, not a crash),2hard error (auth/config/SAP fault, so stop and surfaceerror.code).
The skill also reminds agents to pass -c <connection> and --json on every call, to persist a --session-file to save login round-trips, and to probe capability (discover / tools coverage) before assuming a feature exists on a given system. See Capabilities & gating for why that matters.
Installing it
The skill ships with the Clean Core kit under .kiro/skills/sap-abap/. Copy that directory into your project and the agent auto-discovers it on the next session. It is also a dependency of the rest of the kit: the clean-core-remediator subagent lists it as a resource, so every per-object worker reads the same abapctl reference before guessing a flag.