Building with AI

An AI assistant writing abap2UI5 starts at a disadvantage nothing about your project causes. Almost every abap2UI5 example on the public web builds its view with z2ui5_cl_xml_view, the frozen predecessor of z2ui5_cl_ui5_view_builder — so that is what a model writes when asked for an app, confidently, and in an API that is no longer the one to use.

Everything below is a way of telling it otherwise, in rising order of effort.

Paste the essentials

The zero-setup version, for any assistant with web access: paste this ahead of your task. It corrects the four things a model most reliably gets wrong about abap2UI5:

Before writing any abap2UI5 code, read https://abap2ui5.github.io/docs/llms.txt
and follow it to the pages you need.

Four things that override whatever you remember about abap2UI5:
1. An app is ONE ABAP class implementing z2ui5_if_app. Everything enters main( ),
   which dispatches on client->check_on_navigated( ) (the display branch, true on
   first start too), client->check_on_event( `X` ) and - for one-time setup only -
   client->check_on_init( ).
2. Build the view with z2ui5_cl_ui5_view_builder and its verbs ele / tag / a / end /
   stringify. z2ui5_cl_xml_view is the FROZEN predecessor - it is what most examples
   online show, and it is not what to write.
3. Bind with client->_bind( ). It is bidirectional; only what the user edited comes back.
4. Every roundtrip is a fresh ABAP session. Nothing survives on the server except
   the app class itself, which is serialized.

Before building something from scratch, check whether it exists: the sample
catalogue lists every app with the words to search it by, at
https://github.com/abap2UI5/samples/blob/main/SAMPLES.md

When you are done, check the result with the abap2UI5-linter
(npx abap2ui5lint) - it reads the view your ABAP builds and needs no SAP system.

Point it at the right index

Two files describe this project to a machine, and they answer different questions:

abap2ui5.github.io/docs/llms.txt	the map of the prose — every chapter of this site with one line of what it covers, and llms-full.txt for all of it in one fetch
github.com/abap2UI5/abap2UI5/llms.txt	the map of the code — the interface files to read instead of guessing at a signature, and the guide for building apps that ships with the framework

Both are short and both are free to give an assistant that has web access. It is the cheapest correction available: an agent that has read either one does not reach for the frozen builder.

Put the conventions in the repository

An index tells an agent what abap2UI5 is. AGENTS.md tells it what your project is — and it is read automatically, by every session, without anybody remembering to paste anything.

The app-template ships one written for app-building: the class shape, the lifecycle, the view builder, binding, events, and the gates to run before calling the work done. It also ships a .claude/settings.json allowlist so an agent can run npm run check itself instead of stopping to ask.

Give it the gates

An agent that cannot check its own work will hand you an app that does not render. The two gates of the template need no SAP system, which means an agent can run them on its own:

npm run check

The abap2UI5 linter half is the one that matters here: it reconstructs the view from the builder chain and reports the names UI5 does not have, the bindings that point at nothing — and a class still built on the frozen builder.

Give it the loop

The MCP server turns the checks into a development loop, still without a system. It works with any MCP client — Claude Code, Cursor, VS Code:

claude mcp add abap2ui5 -- npx --yes @abap2ui5/mcp-server

The tools an agent then has:

examples	search the three sample catalogues — has somebody already built a value help, a tree, navigation between two apps? Answers with a class to read, never with a snippet to trust
capabilities	whether abap2UI5 can express a UI5 feature at all, from the verified capability map
validate_view	the linter's gates, in seconds, against your project's own config
deploy_app	write the class into a local sandbox and compile it
build_backend / run_app	transpile the framework and the app to Node, boot it headless, and hand back the errors and a screenshot
pitfalls	the defects a green run still does not catch — abapGit import, activation, the oldest UI5 release

Set-up is levelled: validating views needs one small checkout and a minute; the screenshot loop needs a browser and a first build measured in tens of minutes. Stop where the value stops for you — the MCP Server page has the three levels, every tool and the loop they are meant to be used in.

From the editor

The VS Code extension registers that same MCP server for every client in the window — Copilot agent mode, Claude Code, anything else speaking MCP — so an agent working in your editor has the loop without any separate configuration. Point abap2ui5.mcp.reposRoot at the folder holding the checkouts and the extension passes the paths through.

It adds a second server of its own for the half that one deliberately does not have: your configured systems. An agent can list them, search app classes over ADT and get the app rendered on the real system as a screenshot — while every credential prompt stays an ordinary VS Code dialog the agent never sees.

Next Steps

• Working Off-Stack — the repository all of this assumes
• Tooling — the human side of the same loop: the template, the linter, and the VS Code extension