code-generation — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited code-generation (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill enforces clean, cloud-ready, fully tested SAP code generation. It makes generating non-compliant, untested, or undocumented code structurally impossible.
| Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter |
|---|---|---|---|
| SELECT directly from BSEG or VBAK | "It's the most direct way to get the data" | Direct access bypasses the virtual data model, breaks on HANA column store optimizations, and creates a hard dependency on physical table structure that changes across releases. | Iron Law 2. Identify the released CDS entity or API. For FI data: I_JournalEntryItem. For SD: I_SalesOrder. Use transaction TAANA or SAP API Business Hub to find the correct released API. |
| Skip unit tests because "the logic is simple" | "It's just a getter method, testing is overkill" | Simple methods break in edge cases that were never considered: null inputs, empty collections, authorization failures, character encoding edge cases. "Simple" code without tests is untested code. | Iron Law 4. Generate the test class. Simple methods have simple tests — this takes five minutes. No method is generated without a test. |
| Use classic ABAP for "backward compatibility" | "This might run on older systems, classic is safer" | If the target system is ABAP Cloud, classic syntax will fail ATC Cloud checks. If the target is on-premise, confirm this explicitly — then apply the correct standard for that target, not a hybrid. | Iron Law 1. Establish target platform first. Generate for that platform's standard. Never generate ambiguous cross-platform code. |
| Skip error handling because "this call always succeeds" | "This FM never returns errors in practice" | Function modules return errors when network is slow, authorization is missing, data is unexpected, or the FM itself is changed. "Always succeeds" is an observation from testing, not a guarantee. | Iron Law 3. Every call has error handling. Even if the error path is RAISE EXCEPTION TYPE cx_sy_no_handler — the decision to not handle is explicit, not an omission. |
| Use non-standard naming for clarity | "ZCL_INVOICE is cleaner than ZCL_FINANCE_INVOICE_PROCESSOR" | Non-standard naming pollutes search, makes transport analysis harder, and breaks naming-based ATC rules. Team conventions exist for everyone, not just the current developer. | Iron Law 5. Follow the project naming convention. If no project convention exists, use the SAP standard recommendation. Name for the next developer, not for convenience now. |
| Generate code without documenting the data model | "The code is self-explanatory" | Generated code without documented data model assumptions breaks when the model changes. Future developers cannot distinguish intentional design from accidental coupling. | Checklist Step 1: Document data model and API dependencies before generating implementation code. The documentation is part of the deliverable. |
Watch for these phrases in your own reasoning — each one signals non-compliant code is about to be generated:
<HARD-GATE> Before generating any implementation code: confirm (1) the target platform is established (ABAP Cloud / S/4HANA on-premise / BTP CAP) and the appropriate language standard and API set is selected, (2) the required released CDS entities or APIs are identified for all data access, (3) the class/object structure and naming are agreed, and (4) the unit test structure is planned. If any of these four conditions is not confirmed, do not generate implementation code — complete the design step first. </HARD-GATE>
Confirm the target deployment platform before writing a single line:
Evidence: Platform confirmation documented. Language standard and API restriction level recorded. Gate: Platform confirmed. Correct standard applied. No cross-platform ambiguity.
Before generating code, document:
For RAP: define the business object structure (root entity, child entities, associations), key determination strategy, and draft handling requirement. For CDS: define view hierarchy (basic interface view → composite interface view → consumption view) and required annotations. For CAP: define the CDS data model (.cds schema) and service definition before generating handlers.
Evidence: Data model diagram or written entity/relationship description. Released API list with SAP transaction TAANA or API Business Hub reference. Gate: No physical table names in the design (released CDS entities or API names only). All authorization objects identified.
Generate the structural skeleton before any business logic:
.cds) and entity definitions before event handler implementations.Evidence: Skeleton generated and compiles without syntax errors. All method signatures match the interface. No business logic yet — structure only. Gate: Structure compiles clean. Naming follows Iron Law 5. No implementation logic until structure is approved.
For every method containing business logic, generate the test class in the same step:
CLASS zcl_[name]_test DEFINITION FOR TESTING RISK LEVEL HARMLESS DURATION SHORT.CL_ABAP_TESTDOUBLE for class mocking, CDS_TEST_ENVIRONMENT for CDS unit tests, IF_OSQL_TEST_ENVIRONMENT for ABAP SQL test doubles.CL_BOTD_MOCKEMLAPI_BO_TEST_ENV for behavior unit tests.Evidence: Test class generated alongside implementation class. All methods have at least happy path and one error path test. Tests execute and pass. Gate: Tests execute without syntax errors. Tests pass for the generated logic. Test coverage includes at minimum the public interface methods.
Implement business logic following these non-negotiable patterns:
SELECT FROM zcds_entity). No SELECT from physical tables. |{ lv_field }| ` preferred over CONCATENATE for modern ABAP. CONCATENATE only for downward compatibility targets.Evidence: Implementation compiles and passes all unit tests. ATC run with no P1/P2 findings. Gate: Unit tests pass. ATC P1/P2 clean. No hardcoded values. Error handling present on every external call.
Every generated object requires inline documentation:
Evidence: All public methods have documentation headers. Complex blocks have explanatory comments. Gate: No public method without documentation header. Documentation is meaningful — not auto-generated boilerplate restating the parameter names.
GENERATED CODE RECORD
=====================
Request ID: [Task/ticket number]
Platform: [ABAP Cloud / S/4HANA On-Premise / BTP CAP / Fiori Elements]
Generated by: [Developer name]
Date: [Date]
ATC Variant: [Cloud / Standard / Custom - used for check]
OBJECTS GENERATED
-----------------
[Object type] | [Object name] | [Description]
[e.g., Class | ZCL_INVOICE_PROCESSOR | Core invoice processing logic]
[e.g., Interface | ZIF_INVOICE_PROCESSOR | Public interface for invoice processor]
[e.g., Test Class | ZCL_INVOICE_PROCESSOR_TEST | Unit tests for invoice processor]
[e.g., CDS View | ZI_INVOICE_HEADER | Interface view on I_JournalEntryItem]
DATA DEPENDENCIES
-----------------
Released API / CDS Entity: [Name] → [Purpose]
Authorization object: [Object] → [Activity / Field values required]
RFC destination: [Destination name] → [Purpose] (if applicable)
ATC RESULTS
-----------
ATC run date: [Date]
Check variant: [Variant name]
P1 findings: [Count — must be 0]
P2 findings: [Count — must be 0]
P3 findings: [Count + disposition]
UNIT TEST RESULTS
-----------------
Test class: [Name]
Methods tested: [List]
Pass: [Count] / Fail: [Count]
Coverage: [%] (target: all public methods)
TRANSPORT
---------
Transport number: [DEVK9XXXXX]
Objects included: [List]This skill is complete ONLY when ALL of the following are true:
Evidence required: ATC results export showing P1/P2 clean, unit test run results showing all passing, generated code record, transport number.
After completing this skill, invoke: code-review Conditions for handoff: After all generated code compiles, passes unit tests, and is ATC-clean, submit the transport for code-review. Attach the generated code record as context — the reviewer needs the platform, API dependencies, and ATC results to conduct an efficient review.
code-review to review all generated code before transport releasetroubleshooting if generated code produces runtime errors during testingperformance-tuning if generated code shows performance issues under test data volumedevelopment-workflow for transport creation and management~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.