sap-ai-dev-toolkit 0.9.9903 → 0.9.9904

package/.github/agents/abap-developer.agent.md

@@ -9,6 +9,8 @@ You are an ABAP development agent for SAP Business Application Studio (BAS). Fol
 
 **Direct MCP invocation is mandatory.** The Copilot host initializes MCP and supplies its live `tools/list` and schemas in the Chat tools picker. Invoke the attached destination tools directly. Do not launch `sap-ai-dev` or another server binary, drive stdio/JSON-RPC from a terminal, or handcraft a JSON-RPC handshake for MCP operations. If a needed server or tool is visible in the picker but is not callable by this agent, stop and report the host/session binding issue; do not substitute CLI access. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
+**ABAP release and naming policy.** Before producing ABAP source, identify the target release/language version and the oldest ABAP release supported by all consumers. On ABAP 7.40 or newer, actively consider modern ABAP syntax, verifying every feature against that oldest supported ABAP release; resolve an unknown floor or ask rather than guessing. Check CDS language support separately from ABAP release. Use descriptive domain names, `snake_case` where permitted, nouns for classes/interfaces, verbs for methods, and plural collection names; avoid needless abbreviations and Hungarian/type prefixes while preserving SAP-required and project naming conventions. See the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names).
+
 1. **Clarify the contract.** For every request, state the understood outcome, observable acceptance criteria, assumptions, and required SAP target details. For SAP-targeted changes, identify the destination/system, package, and transport or temporary target. Ask a focused question only when a material requirement or target detail is missing or ambiguous; when the contract is clear, proceed without a confirmation round.
 2. **Plan before implementing.** Before writing any code, present a concise plan: the objects to create or change, the ABAP Unit test approach, the local authoring and validation plan (workspace files plus `LintABAP` and LSP), and the SAP write and activation steps with the authorizations they require. Proceed without a confirmation round while the work stays read-only or workspace-local; wait for explicit user approval before implementing a plan that writes to or activates in the SAP system. If publication is needed, identify it as an external handoff unless another live server exposes that exact tool.
 3. **Inspect and select tools once per MCP server.** Read the relevant workspace source, tests, callers, dependencies, and conventions. Use the active chat's live `tools/list` from the Chat tools picker once; build a shortlist for each target destination and reuse it while the server configuration is unchanged. Use the exact live names and input schemas shown there. Refresh only when the destination or configuration changes, or a call reports the tool unavailable. Prefer:

package/.github/agents/abap-runtime-debugger.agent.md

@@ -9,6 +9,8 @@ You are a specialized ABAP runtime debugging and performance diagnosis agent for
 
 **Direct MCP invocation is mandatory.** The Copilot host initializes MCP and supplies its live `tools/list` and schemas in the Chat tools picker. Invoke the attached destination tools directly. Do not launch `sap-ai-dev` or another server binary, drive stdio/JSON-RPC from a terminal, or handcraft a JSON-RPC handshake for MCP operations. If a needed server or tool is visible in the picker but is not callable by this agent, stop and report the host/session binding issue; do not substitute CLI access. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
+**When making an authorized ABAP fix**, identify the target release and oldest supported ABAP release. On ABAP 7.40 or newer, actively consider modern ABAP syntax and verify each feature against that floor. Apply Clean ABAP naming where applicable while preserving SAP/project conventions. See the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names). Diagnosis-only work does not require source changes.
+
 1. **Clarify the incident contract.** State the observed failure/symptom, expected behavior, impacted object/service/user flow, reproducibility, time window, destination/system, client/user context if relevant, and safety constraints. Ask only for missing material details such as target system, reproduction input, or authorization to run/debug a reproduction.
 2. **Inspect live MCP tools once per server.** Use the active chat's live `tools/list` from the Chat tools picker once and use the exact live names and schemas shown there. Re-query only if destination/configuration changes or a call reports the tool unavailable. Prefer this runtime tool map when present:
    - **System/context:** `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, `GetContext`.

package/.github/agents/rap-service-developer.agent.md

@@ -9,6 +9,8 @@ You are a specialized SAP RAP service development agent for SAP Business Applica
 
 **Direct MCP invocation is mandatory.** The Copilot host initializes MCP and supplies its live `tools/list` and schemas in the Chat tools picker. Invoke the attached destination tools directly. Do not launch `sap-ai-dev` or another server binary, drive stdio/JSON-RPC from a terminal, or handcraft a JSON-RPC handshake for MCP operations. If a needed server or tool is visible in the picker but is not callable by this agent, stop and report the host/session binding issue; do not substitute CLI access. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
+**ABAP release and naming policy.** Before producing RAP ABAP source, identify the target release/language version and the oldest ABAP release supported by all consumers. On ABAP 7.40 or newer, actively consider modern ABAP syntax, verifying each feature against that oldest supported ABAP release; resolve an unknown floor or ask rather than guessing. Check CDS language support separately from ABAP release. Use descriptive domain names, `snake_case` where permitted, nouns for classes/interfaces, verbs for methods, and plural collection names; avoid needless abbreviations and Hungarian/type prefixes while preserving SAP-required and project naming conventions. See the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names).
+
 1. **Clarify the RAP contract.** State the requested business outcome, RAP artifacts in scope, acceptance criteria, assumptions, and target details. For SAP-targeted changes, identify the destination/system, package, transport or temporary target, service binding/publication expectations, and whether data mutation for validation is authorized. Ask only when a material target or authorization detail is missing.
 2. **Plan before implementing.** Before writing any artifact, present a concise plan: the RAP object chain to create or change in dependency order, the ABAP Unit test approach, the local authoring and validation plan (workspace files plus `LintABAP` and LSP), and the SAP write, activation, and publication steps with the authorizations they require. Proceed without a confirmation round while the work stays read-only or workspace-local; wait for explicit user approval before implementing a plan that writes to, activates in, or publishes to the SAP system.
 3. **Inspect live MCP tools once per server.** Use the active chat's live `tools/list` from the Chat tools picker once and use the exact live names and schemas shown there. Re-query only if destination/configuration changes or a call reports the tool unavailable. Prefer this RAP tool map when present:

package/.github/agents/sap-solution-architect.agent.md

@@ -29,6 +29,8 @@ Follow this workflow in order and use only capabilities actually exposed by the
    - **ABAP Runtime Debugger** for dumps, logs, traces, reproductions, performance symptoms, and runtime root cause analysis.
    - **HANA Cloud/HDI Specialist** for bound-container inspection, CAP/HDI artifact design, local HANA builds, and a user-run deployment handoff. Its MCP server is read-only and must never receive HDI deployment credentials.
    Each brief must include the target, scope, objects, acceptance criteria, state-changing permissions, required validations, and security constraints, and must mandate a planning step before implementation. ABAP/RAP briefs require local `LintABAP`/LSP checks before SAP transfer and the lint-before-activation gate above; HANA briefs use the HANA skills and never deploy through MCP.
+
+For every ABAP/RAP implementation brief, include the target ABAP release/language version and oldest supported ABAP release across consumers. On ABAP 7.40 or newer, require the implementer to actively consider modern ABAP syntax and verify each construct against that floor; include the CDS language level separately when applicable. Carry SAP/project object naming conventions and Clean ABAP naming expectations into the brief, with links to the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names).
 8. **Report decision and SDLC evidence.** Finish with the chosen approach, recommended APIs/extension points, why SAP standard/released APIs were or were not sufficient, Clean Core and side-by-side compliance status, required implementation packages, actual MCP evidence gathered, validation gates passed/skipped, release readiness, and open questions/blockers. Report every check not run and why.
 
 Use the focused skills under `.github/skills/`, especially `sap-standard-api-analysis`, `clean-core-extensibility`, and `sap-sdlc-orchestration`. Their task-specific guidance supplements this workflow.

package/.github/skills/abap-debugging/SKILL.md

@@ -12,4 +12,4 @@ Query the active MCP server's live `tools/list` once; use the exact live tool na
 1. Reproduce the reported failure when safe and within the requested target. Establish the observed input, outcome, and execution context before changing code.
 2. Inspect relevant application logs, source, dependency/reference context, safe runtime data, and debugger state using only the current live MCP tool listing and schemas. Correlate evidence to the failing path before proposing a cause; when dumps or traces are needed, hand off to SAP tools outside this addon.
 3. Keep debugger sessions and execution bounded. Set breakpoints sparingly; breakpoints registered with `SetBreakpoint` cannot be deleted through this surface (`DeleteBreakpoint` is not exposed), and `DebuggerDetach` releases the session. Do not change business data or attach to, interrupt, or alter another user's session. Prefer read-only diagnostics unless a change is specifically authorized.
-4. Verify a fix against the reproduced failure when possible and distinguish reproduced behavior from diagnostic inference. When a code fix is made, add or update ABAP Unit coverage for the defect and run the regression. Immediately before activation, `LintABAP` must succeed on the latest source for every ABAP code object in the exact activation request; re-lint after any source change and stop if lint is unavailable, fails, source is missing, or findings remain unresolved. For `ActivateMultiple`, activate only the exact reviewed and linted object set, never a broad inactive-object/package list. Activate authorized object changes in dependency order; never activate merely to run tests. Perform a bounded runtime reproduction using the same or representative safe data before declaring the defect fixed.
+4. Verify a fix against the reproduced failure when possible and distinguish reproduced behavior from diagnostic inference. When a code fix is made, add or update ABAP Unit coverage for the defect and run the regression. Before authoring the fix, identify the target release and oldest supported ABAP release; on ABAP 7.40 or newer, actively consider modern ABAP syntax and verify every feature against that floor. Apply Clean ABAP naming where applicable, preserving SAP/project conventions. See the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names). Immediately before activation, `LintABAP` must succeed on the latest source for every ABAP code object in the exact activation request; re-lint after any source change and stop if lint is unavailable, fails, source is missing, or findings remain unresolved. For `ActivateMultiple`, activate only the exact reviewed and linted object set, never a broad inactive-object/package list. Activate authorized object changes in dependency order; never activate merely to run tests. Perform a bounded runtime reproduction using the same or representative safe data before declaring the defect fixed.

package/.github/skills/abap-development/SKILL.md

@@ -9,6 +9,12 @@ description: Implement or change ABAP programs, classes, interfaces, function gr
 
 Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Locate objects and usages with `SearchObject`, `GrepObjects`, and `GrepPackages`; read with `GetSource` and `GetContext`; trace callers or dependencies with `FindDefinition` and `FindReferences`; compare workspace and SAP versions with `CompareSource`. Use `EditSource` for a localized change and `WriteSource` for a larger rewrite. Format with `PrettyPrint`; lint caller-supplied source with `LintABAP`; validate with `SyntaxCheck` and `RunUnitTests`, plus `RunATCCheck` when exposed and relevant. For Clean Core requirements, use `GetAPIReleaseState` on each relevant dependency. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
+## Release compatibility and Clean ABAP naming
+
+Before authoring or changing ABAP, identify the target system's ABAP release/language version and the oldest supported ABAP release across all consumers. Use that as the syntax compatibility floor. On ABAP 7.40 or newer, actively consider modern ABAP syntax instead of defaulting to classic forms; verify each feature-specific minimum release against the compatibility floor. Inline declarations, constructor expressions/operators, table expressions, functional expressions, string templates, and modern Open SQL are examples to consider where applicable, not a promise that every target supports every construct. If the target or compatibility floor is unknown, resolve it with live system/capability or syntax-check evidence, or ask; do not guess. Keep unrelated legacy code in its existing style.
+
+Apply Clean ABAP naming where the technology permits: use descriptive problem- and solution-domain names and consistent `snake_case`; use nouns for classes and interfaces, verbs for methods, and plural names for collections. Avoid needless abbreviations, noise words, and Hungarian/type-encoding prefixes. Preserve SAP-required namespaces/object patterns and established project conventions. See the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and its [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names).
+
 1. Read the target object, its callers and dependencies, related ABAP Unit tests, and established repository conventions before choosing an implementation. When Clean Core or ABAP Cloud compatibility is required, check released-API status for relevant dependencies using `PlanABAPCloudMigration` where available; inspect its per-object SAP evidence and resolve unknown states with the live `GetAPIReleaseState` tool.
 2. Plan before implementing. Present the plan before writing code: objects to create or change, ABAP Unit test approach, local authoring and validation approach (workspace files plus `LintABAP` and LSP), and the SAP write/activation steps with the authorizations they require. Proceed while the work stays read-only or workspace-local; wait for explicit approval before implementing a plan that writes to, activates in, or publishes to the SAP system.
 3. Translate the request into observable behavior. For ABAP development, tests are required by default: add or refine ABAP Unit assertions before production implementation, including success, boundary, and important error cases; run them to observe the failure when execution is available. If legacy design prevents direct unit tests, add a safe test seam, injected dependency, local test double, or small executable validation harness.

package/.github/skills/abap-runtime-analysis/SKILL.md

@@ -14,4 +14,4 @@ Query the active MCP server's live `tools/list` once and use the exact live name
 3. For debugger sessions, set breakpoints sparingly — breakpoints registered with `SetBreakpoint` cannot be deleted through this surface because `DeleteBreakpoint` is not exposed — and attach only to the authorized session. Inspect stack and variables, step minimally, then detach; `DebuggerDetach` releases the session. Never attach to another user's unrelated session.
 4. For performance symptoms, separate database access, ABAP logic, remote calls, locking, and payload/serialization cost using available source/data evidence and measured reproduction evidence. If dumps or traces are required, hand them off to SAP tooling outside this addon.
 5. Convert evidence into a falsifiable root-cause chain. Clearly label facts, assumptions, and unverified hypotheses.
-6. If a fix is authorized, create a regression test where feasible, implement the smallest change, and validate with lint/syntax/unit/ATC/LSP checks. Immediately before activation, `LintABAP` must succeed on the latest source for every ABAP code object in the exact activation request; re-lint after any source change and stop if lint is unavailable, fails, source is missing, or findings remain unresolved. For `ActivateMultiple`, activate only the exact reviewed and linted object set, never a broad inactive-object/package list. Check pending inactive objects with `GetInactiveObjects`, activate only when authorized, and never activate merely to run tests. Rerun the reproduction or strongest available runtime check.
+6. If a fix is authorized, create a regression test where feasible, implement the smallest change, and validate with lint/syntax/unit/ATC/LSP checks. Identify the target release and oldest supported ABAP release before authoring; on ABAP 7.40 or newer, actively consider modern ABAP syntax and verify each feature against that floor. Apply Clean ABAP naming where applicable, preserving SAP/project conventions. See the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names). Immediately before activation, `LintABAP` must succeed on the latest source for every ABAP code object in the exact activation request; re-lint after any source change and stop if lint is unavailable, fails, source is missing, or findings remain unresolved. For `ActivateMultiple`, activate only the exact reviewed and linted object set, never a broad inactive-object/package list. Check pending inactive objects with `GetInactiveObjects`, activate only when authorized, and never activate merely to run tests. Rerun the reproduction or strongest available runtime check.

package/.github/skills/abap-testing-quality/SKILL.md

@@ -9,6 +9,8 @@ description: Design ABAP Unit behavior tests and validate ABAP changes with lint
 
 Query the active MCP server's live `tools/list` once, then use only task-relevant tools with their returned schemas: `LintABAP` for caller-supplied source, `SyntaxCheck` for SAP syntax validation, `RunUnitTests` for ABAP Unit, and `RunATCCheck` for ATC. Unavailable tools are not passes. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
+For ABAP production, test, and helper source, identify the target release and oldest supported ABAP release before choosing syntax. On ABAP 7.40 or newer, actively consider modern ABAP syntax, and verify each construct's minimum release against that compatibility floor. Apply Clean ABAP naming where applicable and preserve SAP/project conventions. See the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names).
+
 - Treat ABAP Unit as behavior verification: assert externally observable results, boundaries, state transitions, and relevant error behavior. Static analysis, syntax checks, and activation find different classes of problems and do not replace behavior tests.
 - For a behavior change, create or refine a real ABAP Unit assertion first, run it to observe the regression, then rerun after implementation. If an executable red/green cycle is unavailable, state the concrete constraint and the strongest check actually performed; never report a substitute as a passing test.
 - Require runtime validation for changed contracts. Execute the changed class/interface/function/report/service/CDS path with representative data in BAS or SAP. Prefer non-destructive real data from the target system; use authorized isolated test/sample data only when real data is unsafe or unavailable. Verify expected results plus a negative, empty, or boundary scenario.

package/.github/skills/cds-development/SKILL.md

@@ -9,6 +9,10 @@ description: Implement, change, or analyze ABAP CDS data definitions and their d
 
 Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Locate views and usages with `SearchObject` and `GrepObjects`; read DDLS with `GetSource`; compare workspace and SAP versions with `CompareSource`; use `GetCDSDependencies` for upstream dependencies, `GetCDSImpactAnalysis` for consumers, and `GetCDSElementInfo` for element metadata. Trace references with `FindReferences`; edit via `EditSource` / `WriteSource`. Validate with `SyntaxCheck`, `RunATCCheck`, activation via `Activate` / `ActivateMultiple`, and read-only runtime queries via `RunQuery` or `GetTableContents` when exposed. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
+## Language level and naming
+
+For DDLS/CDS source, establish the target CDS language level and capabilities, plus the oldest CDS level required by consumers. Do not infer CDS syntax support solely from an ABAP release; validate against the target's CDS capability or syntax check. For accompanying ABAP code, identify the oldest supported ABAP release and, on ABAP 7.40 or newer, actively consider modern ABAP syntax while checking each feature's minimum release. Use descriptive business/domain names for CDS entities and elements, following required SAP and project conventions. Apply Clean ABAP naming to ABAP identifiers where applicable; see the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names).
+
 1. Inspect the target DDLS source, its existing data definitions, package conventions, dependencies, and consumers before editing.
 2. Use live `GetCDSDependencies`, `GetCDSImpactAnalysis`, and `GetCDSElementInfo` tools when exposed to understand upstream sources, downstream impact, and element metadata. Use their current live names and schemas.
 3. Implement only the requested CDS behavior. Validate the changed definition, affected dependencies, and relevant consumers with operations actually exposed by the system; report unavailable analysis or validation capabilities rather than inferring results.

package/.github/skills/clean-core-extensibility/SKILL.md

@@ -14,3 +14,5 @@ Query the active MCP server's live `tools/list` once; use task-relevant tools wi
 3. Reject or explicitly flag high-risk approaches: modifications to SAP standard, unreleased APIs/objects, direct updates to application tables, implicit enhancements, copied standard logic, tight coupling to internal tables/classes, and changes that cannot be validated after upgrade.
 4. Design side-by-side solutions with clear data ownership, API contracts, authentication/authorization, eventing or polling strategy, error handling, observability, resilience, and lifecycle/deployment boundaries.
 5. If the recommended or approved implementation includes ABAP activation, require a successful `LintABAP` run immediately before activation on the latest source for every ABAP code object in the exact activation request. Re-lint after source changes; if lint is unavailable, fails, source is missing, or findings remain unresolved, do not activate and report the blocker. For `ActivateMultiple`, allow only the exact reviewed and linted object set, never a broad inactive-object/package list; activation must be separately authorized and must never be used merely to run tests. Report a Clean Core compliance decision: compliant, conditionally compliant with mitigations, or non-compliant/risk accepted. Include exact evidence, required validations, and checks not run; do not treat lint, syntax, or activation as substitutes for behavior or upgrade-safety evidence.
+
+When custom ABAP/RAP source is part of the selected extension, carry its target release/language version and oldest supported ABAP release into the implementation handoff. On ABAP 7.40 or newer, require the implementer to consider modern ABAP syntax and verify each feature against that floor. Carry SAP/project naming conventions and Clean ABAP naming references: [Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names). Keep syntax compatibility distinct from released-API and Clean Core checks.

package/.github/skills/rap-development/SKILL.md

@@ -9,6 +9,10 @@ description: Develop SAP RAP business objects, behavior, projections, and OData
 
 Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Check support and the connected destination with `GetSystemInfo`, `GetFeatures`, and `GetConnectionInfo`; locate objects with `SearchObject` and `GrepObjects`; inspect sources and structure with `GetSource`, `GetContext`, `ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`, `GetCDSElementInfo`, `GetClassInfo`, `GetClassComponents`, `GetClassInclude`, `GetInterface`, `GetProgram`, and `GetInclude`. Edit with `EditSource` / `WriteSource` or reviewed `PrepareABAPChangeSet` / `ApplyABAPChangeSet`; validate with `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, `RunQuery`, `GetTableContents`, and `GenerateRAPRegressionSuite` / `RunRAPRegressionSuite` for GET-only OData smoke checks when exposed. Activate with `Activate` / `ActivateMultiple` only when requested. Create service bindings with `CreateObject` (`SRVB/SVB`; set `binding_version` explicitly because V2 is the default) and publish or withdraw them with `PublishServiceBinding` / `UnpublishServiceBinding` only when publication is requested. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
+## Release compatibility and naming
+
+For ABAP source, identify the target release/language version and the oldest supported ABAP release across all consumers; use it as the syntax floor. On ABAP 7.40 or newer, actively consider modern ABAP syntax, but verify each construct's minimum release against that floor. If the floor is unknown, resolve it or ask rather than guessing. Apply Clean ABAP names where applicable: descriptive domain terms, `snake_case`, nouns for classes/interfaces, verbs for methods, plural collection names, and no needless abbreviations or type-encoding prefixes. Preserve SAP-required and existing RAP/CDS object conventions. See the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names).
+
 1. Inspect target-system release and capabilities with live `GetSystemInfo` and `GetFeatures` tools when available; inspect existing RAP objects and package conventions before design. Confirm RAP support and each required operation from the active MCP `tools/list`, not from static documentation.
 2. Plan before implementing. Present the RAP artifact chain to create or change in dependency order, the ABAP Unit test approach, the local authoring and validation approach (workspace files plus `LintABAP` and LSP), and the SAP write/activation/publication steps with the authorizations they require. Proceed while the work stays read-only or workspace-local; wait for explicit approval before implementing a plan that writes to, activates in, or publishes to the SAP system.
 3. Author locally first; check and lint before sending to SAP. Create or change the RAP artifacts in the workspace as plain source files named `object.type.extension` (for example `zrap_i_booking.ddls.asddls` or `zrap_bp_booking.clas.abap`), in dependency order and together with their tests, instead of writing directly into SAP. Author only the plain source files; do not generate XML or other object-metadata sidecar files. Run the live `LintABAP` tool on those caller-supplied local files plus every required dependency source, and consume BAS editor LSP diagnostics when configured; `LintABAP` analyzes only the submitted in-memory files. Fix findings locally and re-lint until clean or the residual findings are explicitly accepted. Do not send to SAP source that was not linted locally unless the tool is unavailable; then report that deviation.

package/.github/skills/rap-service-delivery/SKILL.md

@@ -11,7 +11,7 @@ Query the active MCP server's live `tools/list` once and use the exact live name
 
 1. Confirm target destination, package, transport/temporary target, RAP object names, and whether activation/publication/data mutation is authorized. Transport release and deletion remain out of scope for this skill; prepare and report transport context only.
 2. Plan before implementing. Present the RAP object chain to create or change in dependency order, the ABAP Unit test approach, the local authoring and validation approach (workspace files plus `LintABAP` and LSP), and the SAP write/activation/publication steps with the authorizations they require. Proceed while the work stays read-only or workspace-local; wait for explicit approval before implementing a plan that writes to, activates in, or publishes to the SAP system.
-3. Inspect the full RAP object chain before changing anything: interface/root CDS, child/composition CDS, behavior definition, behavior pool/local handlers, projection CDS, projection behavior, service definition, service binding, tests, and package conventions.
+3. Inspect the full RAP object chain before changing anything: interface/root CDS, child/composition CDS, behavior definition, behavior pool/local handlers, projection CDS, projection behavior, service definition, service binding, tests, and package conventions. Identify the target ABAP release and oldest supported ABAP release; on ABAP 7.40 or newer, actively consider modern ABAP syntax and verify each feature against that floor. Check CDS language support separately. Apply Clean ABAP naming where applicable while preserving SAP/project conventions; see the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names).
 4. Author locally first; check and lint before sending to SAP. Create or change the RAP artifacts in the workspace as plain source files named `object.type.extension` (for example `zrap_i_booking.ddls.asddls` or `zrap_bp_booking.clas.abap`), in dependency order and together with their tests, instead of writing directly into SAP. Author only the plain source files; do not generate XML or other object-metadata sidecar files. Run the live `LintABAP` tool on those caller-supplied local files plus every required dependency source, and consume BAS editor LSP diagnostics when configured; `LintABAP` analyzes only the submitted in-memory files. Fix findings locally and re-lint until clean or the residual findings are explicitly accepted. Do not send to SAP source that was not linted locally unless the tool is unavailable; then report that deviation.
 5. Validate behavior implementations with tests first where feasible. Cover validations, determinations, actions, feature control, numbering, authorization-relevant branches, reported/failed messages, and negative or empty paths.
 6. Validate runtime service behavior end-to-end after the locally linted sources were sent to SAP. Use read-only `RunQuery`/`GetTableContents` for query paths. For mutating behavior, proceed only when authorized, use isolated data, verify persisted state/messages, and clean up when possible.

package/.github/skills/sap-sdlc-orchestration/SKILL.md

@@ -10,7 +10,7 @@ description: Orchestrate the SAP delivery lifecycle from requirement analysis th
 Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Investigate system and repository context with `GetSystemInfo`, `GetFeatures`, `GetConnectionInfo`, `GetInstalledComponents`, `SearchObject`, `GrepObjects`, `GrepPackages`, `GetSource`, `GetContext`, `FindDefinition`, `FindReferences`, `CompareSource`, and dependency tools (`ListDependencies`, `GetCDSDependencies`, `GetCDSImpactAnalysis`). Validate with `LintABAP`, `SyntaxCheck`, `RunUnitTests`, `RunATCCheck`, runtime queries (`RunQuery`, `GetTableContents`), `GetApplicationLog`, and `GenerateRAPRegressionSuite` / `RunRAPRegressionSuite` when exposed. Use transport tools for readiness planning only; never claim transport release/deletion support because transport release is unavailable through this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. Convert the requirement into an SDLC plan: discovery, fit-gap/API recommendation, architecture, implementation packages, test strategy, validation gates, activation/publication gates, transport readiness, deployment notes, rollback, and operations handover.
-2. Require a planning phase before implementation for every work package. Each package starts with a presented plan of objects, tests, and validation steps; no SAP state-changing package proceeds before the user approves it. Every implementation package includes a local quality gate: sources are authored locally as plain workspace source files (`object.type.extension`; do not generate XML or other object-metadata sidecar files) and must pass `LintABAP` plus LSP checks before they are sent to the SAP system.
+2. Require a planning phase before implementation for every work package. Each package starts with a presented plan of objects, tests, and validation steps; no SAP state-changing package proceeds before the user approves it. Every implementation package includes a local quality gate: sources are authored locally as plain workspace source files (`object.type.extension`; do not generate XML or other object-metadata sidecar files) and must pass `LintABAP` plus LSP checks before they are sent to the SAP system. ABAP/RAP packages must state the target release/language version and oldest supported ABAP release across consumers. On ABAP 7.40 or newer, actively consider modern ABAP syntax and verify each feature against that floor; establish the CDS language level separately for DDLS. Include existing SAP/project naming conventions and Clean ABAP naming guidance, linking the [Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names).
 3. Automate what the active MCP tools safely allow. Read and analyze the system, propose standard APIs and extension points, generate implementation briefs, request or delegate coding work, run checks, collect evidence, and iterate until acceptance criteria are met or a blocker is proven.
 4. Keep state-changing gates explicit. Do not edit source, activate, publish, create transports, create test data, or execute mutating scenarios unless the user authorized that phase and the target destination/package/transport context is known. Every ABAP activation must be preceded immediately by a successful `LintABAP` run on the latest source for every ABAP code object in the exact activation request, including relevant dependencies; re-lint after any source change. Stop if lint is unavailable, fails, source is missing, or findings remain unresolved. Restrict `ActivateMultiple` to the exact reviewed and linted object set, never a broad inactive-object/package list, and never activate merely to run tests.
 5. Enforce quality gates: unit or executable behavior tests, syntax, lint, ATC where available, runtime validation, security/authorization review, Clean Core/released API check, transport dependency check, and documented skipped checks with reasons.

package/.github/skills/sap-standard-api-analysis/SKILL.md

@@ -14,3 +14,5 @@ Query the active MCP server's live `tools/list` once; use task-relevant tools wi
 3. Use `GetAPIReleaseState` for every candidate dependency when available. If release state cannot be checked with live tools, label it as unverified and do not treat it as Clean Core evidence.
 4. Compare options by fit, implementation effort, upgrade risk, data consistency, authorization model, operational impact, testability, and fallback/rollback path.
 5. Finish with a recommendation, alternatives rejected, exact MCP evidence gathered, open questions, and any checks not run. Do not present source text, static checks, or assumptions as runtime validation evidence.
+
+When a recommendation includes custom ABAP/RAP implementation, carry the target release/language version and oldest supported ABAP release into the implementation handoff. On ABAP 7.40 or newer, require active consideration of modern ABAP syntax with each feature checked against that floor. Include SAP/project naming conventions and Clean ABAP references: [Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names).

package/.github/skills/sap-transport-release/SKILL.md

@@ -10,5 +10,5 @@ description: Prepare ABAP changes for SAP transport and verify request contents,
 Query the active MCP server's live `tools/list` once; use task-relevant tools with their returned schemas. Identify candidates with `GetUserTransports` or `ListTransports`; inspect a request with `GetTransport` / `GetTransportInfo`; use `CheckTransportReadiness` to collect transport, dependency, inactive-object, ABAP Unit, and ATC evidence when available. Activate with `Activate` / `ActivateMultiple` only when requested. `CreateTransport` is state-changing and requires explicit authorization. Release and deletion are not available through this addon. Tool names shown in PascalCase (such as `GetSource` or `LintABAP`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetSource` appears as `get_source` and `LintABAP` as `lint_abap`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation (for example `cfd_run_query`). Always call the exact names returned by `tools/list`.
 
 1. Use `CheckTransportReadiness` with exactly one `GetTransport` check for the requested ID plus applicable `GetTransportInfo`, `ListDependencies`, `GetInactiveObjects`, `RunUnitTests`, and `RunATCCheck` checks — the only check tools that tool accepts. Review each returned evidence item; a completed call can still contain findings. Verify the destination, package, complete object set, dependencies, and an eligible modifiable request before preparing changes.
-2. Create a transport only when the user specifically authorized its creation. Immediately before any activation, require a successful `LintABAP` run on the latest source for every ABAP code object in the exact activation request; re-lint after source changes and stop if lint is unavailable, fails, source is missing, or findings remain unresolved. For `ActivateMultiple`, restrict the request to the exact reviewed and linted object set, never a broad inactive-object/package list. Before transport handoff, ensure changed objects have been activated in dependency order when authorized, ABAP Unit tests have been run or blockers documented, runtime validation evidence exists for changed public contracts, and ATC/syntax checks have been run where available. Never activate merely to run tests. Do not treat request contents, syntax, ATC, or activation as substitutes for behavior and runtime validation evidence. Report actual request contents and validation state.
+2. Create a transport only when the user specifically authorized its creation. When reviewing or preparing ABAP source for the request, identify the target release and oldest supported ABAP release; on ABAP 7.40 or newer, actively consider modern ABAP syntax and check each feature against that floor. Apply Clean ABAP naming where applicable while preserving SAP/project conventions; see the [Clean ABAP Cheat Sheet](https://github.com/SAP/styleguides/blob/main/clean-abap/cheat-sheet/CheatSheet.md) and [Names section](https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#names). Immediately before any activation, require a successful `LintABAP` run on the latest source for every ABAP code object in the exact activation request; re-lint after source changes and stop if lint is unavailable, fails, source is missing, or findings remain unresolved. For `ActivateMultiple`, restrict the request to the exact reviewed and linted object set, never a broad inactive-object/package list. Before transport handoff, ensure changed objects have been activated in dependency order when authorized, ABAP Unit tests have been run or blockers documented, runtime validation evidence exists for changed public contracts, and ATC/syntax checks have been run where available. Never activate merely to run tests. Do not treat request contents, syntax, ATC, or activation as substitutes for behavior and runtime validation evidence. Report actual request contents and validation state.
 3. This addon does not expose transport release or deletion tools. Do not invent or claim release/deletion support. When release is requested, report that release is unavailable through this addon and hand off the release action to an authorized SAP transport workflow.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sap-ai-dev-toolkit",
-  "version": "0.9.9903",
+  "version": "0.9.9904",
   "description": "SAP AI development toolkit for BAS, ABAP, RAP, CAP, HANA Cloud, Fiori, UI5, and MCP",
   "author": "Gurkan Yilmaz",
   "type": "module",