Install
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/abap2ui5/abap2ui5/repository-mapgit clone --depth 1 https://github.com/abap2UI5/abap2UI5Wrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/abap2ui5/abap2ui5/repository-map)<a href="https://agentmods.dev/agents/abap2ui5/abap2ui5/repository-map"><img src="https://agentmods.dev/badge/agents/abap2ui5/abap2ui5/repository-map.svg" alt="Measured on agentmods" height="20"></a> Per session 0 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 4,573 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.04573 |
| Opus 5 | $0.00000 | $0.02286 |
| Sonnet 5 | $0.00000 | $0.00915 |
| Haiku 4.5 | $0.00000 | $0.00457 |
Security
Grade A, and why
repository-map scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
docs/agents/repository-map.md · 42 lines
How it starts
The opening of the file, as written. The whole thing — 42 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Repository map — what lives in which directory
Extracted from
AGENTS.md, which points here. It is reference material: an agent needs it once it knows it has to look something up, not before, and AGENTS.md is loaded into every session. Every fact below was in that file unchanged; thesrc/tree itself and the root files stay there, because they are what a reader needs to place a change at all.
Directories
| Directory | Purpose |
|---|---|
app/ |
Frontend tooling (package.json, ui5.yaml, eslint.config.mjs, .prettierrc, .editorconfig) |
app/webapp/ |
UI5 frontend source — Component.js, index.html, manifest.json, controller/, view/, model/, css/, Util.js (the public date helpers exposed as the z2ui5.Util global), cc/ with one file per custom control (Timer.js, Scrolling.js, … — module IDs z2ui5/cc/<Name>, resolved from the z2ui5 XML namespace which maps to z2ui5.cc), and core/ with the internals: Server.js (the JSON POST client that wraps the body as { "value": <payload> } — roundtrip, request sequencing, aborts), Session.js (the session-constant request block, sent once per page load, and the page-location send cadence), ScrollFocus.js (focus/caret + per-slot scroll capture for S_FOCUS/S_SCROLL), AppState.js (owner of the shared frontend state + the documented inventory of all z2ui5.* globals), ViewSlots.js (access layer for the five view slots — lookups, byId resolution and teardown), Lib.js (shared helper module), FrontendAction.js (the action registry/dispatcher behind the controller's eF() entry point and the response's action lists — the handlers live in core/actions/, one domain module each: ControlCall.js with the CONTROL_GLOBAL/CONTROL_BY_ID/BINDING_CALL whitelists and the message toast/box display hooks, Slots.js with the view-slot display machinery and model tracking, Browser.js, Launchpad.js, Variants.js, Shortcuts.js, ViewOps.js, and LegacyCustomJs.js with the legacy eF()-string parser), Router.js (hash routing — the only module allowed to touch the URL hash) and ErrorView.js (the fatal-error overlay); devtools/ is a SIBLING of core/, not a part of it — it holds the entire in-app developer tools, which are deliberately not part of the framework, and the folder sits at the top level precisely because core/ means framework: DevTools.js (the lifecycle facade and the framework's single entry point: shortcut, dialog instance, auto open, error-details provider), DeveloperTools.js + .fragment.xml (the dialog — six groups: Overview / Problems / Roundtrips / View & Data / System / Search, the last being the cross-tab search on a tab of its own), Tabs.js (the tab registry — the ONE table that says what a tab is: its group, label, kind, producer, availability and export position; the tab strip, the search and the export are all driven from it, and adding a tab is one entry here), Format.js (the two value formatters, toJson / prettifyXml), Report.js (the bug report: the plain-text export, the GitHub-ready Markdown form and the downloads), AbapSource.js (the running app's ABAP class — the ADT source endpoint, the deep link at the line of the last event, the source cache), Console.js (in-app capture of UI5's log, uncaught errors/rejections and every console.* call, so the browser's own devtools do not have to be open), Recorder.js (roundtrip history behind the History / Model Diff / View Diff views; observes the framework only through the onAfterRendering callback array and the Resource Timing API), Inspect.js (the read-only reports behind the Overview / Log / Environment / Registry / Actions / Bindings views — the Log merges the framework error log, the console capture and the backend messages into one timeline), Picker.js (the control picker) and LiveEdit.js (roundtrip-free re-render of an edited view XML, through the same actions/Slots.action entry point the backend's VIEW_SLOTS action uses). The tab keys (VIEW, HISTORY, POPUP_MODEL, …) are a compatibility surface — ?z2ui5-devtools=<KEY> and the remembered last tab in sessionStorage both store them, so a key may be added but never renamed. No framework module carries developer-tools code, names a developer-tools module, or holds a developer-tools object — keep it that way: Component.js calls DevTools.install() / DevTools.exit() and that is the whole footprint; core/ErrorView.js reaches the Details action through the generic onErrorDetails callback array (AppState) and hides the button when nothing registered, so deleting devtools/ degrades the framework gracefully instead of breaking it; model/models.js holds the device model setup and model/formatter.js is the curated app-level formatter module (the z2ui5.Formatter global / core:require of z2ui5/model/formatter) that owns the date helpers and value formatters — Util.js is now a deprecated legacy alias re-exporting them |
node/srv/ |
express.mjs (dev server on port 3000), zcl_sicf.clas.abap (reference ICF handler impl — ~15 lines; real apps follow the same pattern), plus the zcl_tst_nav_* test apps used by the browser navigation tests (copied into node/downport/ during auto_transpile) |
node/setup/ |
abap_transpile.json (transpiler config), setup.mjs (SQLite bootstrap for Node unit tests) |
node/tests/ |
Playwright tests — browser tests in e2e/ (example.spec.js shell smoke test, roundtrip.spec.js POST/draft wire contract, lib-sanitizer.spec.js XSS regression tests for Lib.sanitizeMessageDetails, error-view.spec.js fatal-error overlay accessibility/focus/Retry tests, nav-back-forward.spec.js browser history navigation, focus-after-enable.spec.js SET_FOCUS retry after a re-render; run via node/playwright.config.js against the dev server), plus JS unit specs (*.spec.js — see the spec-to-module mapping under "Testing" below) that load the real app/webapp modules via loadModule.js (stubbed sap.ui.define, stubbable dependencies); run them without a browser via npx playwright test -c node/playwright-unit.config.js (the unit config ignores e2e/) |
node/tests-examples/ |
Playwright example specs and performance benchmarks (reference material, not run in CI) — modelUpdate.bench.spec.js measures the model-update strategies and documents its own setup; run via node/playwright-bench.config.js |
docs/agents/ |
The reference material AGENTS.md points at rather than carries: building-apps.md — the in-repo app-building guide (gated by npm run check:guide, and mirrored into app-template's AGENTS.md, which npm run check:shared holds to it); repository-map.md — this file; ci-workflows.md — what every workflow does; test-inventory.md — which frontend module has which JS unit spec |
docs/ |
removal-plan.md — the standing checklist of everything obsolete: what replaces it, what breaks, and what has to happen first. Read it before removing any compatibility symbol, and tick the box in the same PR |
.claude/skills/ |
The four catalogues, by audience: build-an-app (how to write an app with abap2UI5 — the docs/agents/building-apps.md guide), abap-check (every ABAP problem a green CI misses — abapGit round trip, activation, extended check, downport, runtime), ui5-check (every UI5 problem a green CI misses — post-1.71 names, version-sensitive layout, views that fail to load, CSP traps; also the staging area for the abap2UI5 linter, so each entry says what a rule would need to decide it). view-chain-layout (the layout rules for a builder chain — one call per line, four spaces per level, the end( ) column, which factory( ) shape goes with which chain shape; the rules the abap2UI5-linter's chain-house-layout checks — npm run check:abap2ui5; the same file is in both sample repositories). Build with the first two, check with the other two |
backlog/ |
The stock of things to file, in four backlogs by where they get filed: OPEN-ABAP.md (open-abap/open-abap-core, abaplint/transpiler), ABAPLINT.md, ABAP2UI5-LINTER.md and ABAP2UI5.md (this repository). All four are generated from backlog/items/<id>.md — npm run backlog, gated by npm run check:backlog — and each item is written to be pasted into an issue as it stands. A skill section names what it put in the stock with a **Backlog:** line, so the analysis stays next to the defect and the backlog fills itself; converting an item into an issue stays a human step, and a shipped one is deleted rather than kept as a row. Details in backlog/README.md |
tools/ |
Everything that generates an artefact out of app/webapp/, in one place — app2abap/ (→ the embedded ABAP constants in src/01/03/), app2bsp/ (→ BSP pages plus the minified UI5 component preload bundle), app2app_v2/ (the legacy-free UI5 2.x bootstrap patch), bsp_rename/ (deployment identity for a parallel install), build-branches.mjs (drives them into one delivery branch, every build landing in the git-ignored tools/out/), branch-stamp.mjs (the provenance a branch carries, VERSION and the README banner, written at deploy time because it names the commit being made), check-pages.mjs (BSP page invariants on the built artefact), verify-branches.mjs (byte-for-byte diff against the published branches), check-v2-sdk.mjs. Not to be confused with .github/scripts/, which are CI gates: they read the repository and answer yes or no, they do not produce deliverables. Details in tools/README.md |
frontend/ |
The parts of the abap2UI5/frontend delivery branches that are not generated from app/webapp/ — data, not code: abap/cloud/ + abap/standard/ (the ICF/BSP ABAP artefacts each branch ships, with abap/cloud/abaplint.jsonc linting them in place and being copied into each branch with its glob turned to /src/) and common/ (the files every generated branch inherits). The cloud branches ship app/ from this repository directly — a second copy of the Fiori project is what let the two drift apart before. Details in frontend/README.md |
.github/workflows/ |
CI/CD workflows (see below) |
.github/scripts/ |
ui5lint-gate.mjs — runs the UI5 linter and fails on any error; design-accepted findings are suppressed at the source (inline ui5lint-disable comments, whole files in app/ui5lint.config.mjs); testclass-visibility-gate.mjs — fails when a local test class reads a PRIVATE/PROTECTED member of the class under test without LOCAL FRIENDS; api-snapshot.mjs — records/compares the src/02 public-API snapshot (rule 5); check-guide-api.mjs — fails when docs/agents/building-apps.md names a client method or cs_* constant the API does not have; object-naming-gate.mjs — fails when an object outside the public API carries no ui5/ui5f segment (exemptions and the scheduled-but-not-done list live in the script, each with its reason); dynamic-name-gate.mjs — fails when a Z2UI5_* class or interface named by a string literal (dynamic lookup, CREATE OBJECT TYPE (name)) does not exist in src/ (names owned by other repositories live in the script's EXTERNAL list, each with its reason); ui5-icon-gate.mjs — fails when a sap-icon:// name in src/ or app/webapp/ is not in the UI5 1.71 icon font. The 655-name set is derived from @abap2ui5/linter's generated data/icons.json (since <= 1.71, minus what the font removed by then), not hand-kept — it used to be a third copy of UI5 metadata in this ecosystem. src/99 is exempt as frozen and its two wrong icons are printed on every run; frontend-module-gate.mjs — fails when a sap.ui.define dependency array in app/webapp/ names a UI5 module outside the reviewed 1.71 list (a module the floor lacks 404s and the ui5loader drops the WHOLE component — a blank app naming nothing). A newer module belongs behind sap.ui.require( ) at the point of use with an undefined branch, the way Component.js reaches for sap/ui/core/Theming (@since 1.118); shared-file-gate.mjs — fails when something this repository is the source of (see its SHARED list) differs from the copy in a sibling repository: today the view-chain-layout skill (whole file) and .github/abaplint/app-rules.json, the 187-rule abaplint set the three app repositories are judged by, compared as parsed settings against each one's abaplint.jsonc minus its own object_naming; and docs/agents/building-apps.md against the mirror of it in app-template's AGENTS.md, compared as the SECTION from "## 1. The model in one paragraph" down, with the three sentences that name framework-only commands (fmt:chains, the autofix config, check:formatter) applied from the script's GUIDE_DEVIATIONS list first — a mirror that has to rewrite three sentences to stay true cannot also be byte-equal, so the rewrites are declared rather than tolerated, and a deviation whose upstream sentence was edited away fails too; frontend/common/README.md — the file the frontend build copies into every generated branch — against abap2UI5/frontend's own README.md on main, whole file and byte-equal, no deviations: since frontend_deploy writes the finished trees into result/ on that main, the frontend_deploy badge reports on exactly the page it fronts (the copies had drifted in five paragraphs, and both named the reserved resourceRoots z2ui5cc/z2ui5ext when app/webapp/manifest.json reserves z2ui5_cci/z2ui5_ccc); and .github/shared/agents-metadata.md, the metadata convention (what goes on the class, what goes in the meta/ sidecar) that samples, samples-controls and samples-stack each carry inside their AGENTS.md, compared as the SECTION from "## Metadata: what goes on the class, and what goes beside it" down to the next ##, with a consumer's own ### subsection cut out first when the script's METADATA_EXTENSIONS declares it (samples-controls documents its @keywords/@summary generators there) — an addition is a decision, a reworded shared subsection is drift. Reads a local checkout or GitHub raw and says so when neither is reachable; corpus-count-gate.mjs — fails when a corpus size quoted in llms.txt, docs/agents/building-apps.md or the build-an-app skill disagrees with the owning repository's generated catalogue (SAMPLES.md's header count, samples-controls' STATUS.md state block). Those numbers are the reason an agent goes and looks instead of writing from scratch, and they had drifted to ~280 while the corpus stood at 416. Declared claim by claim in the script's CLAIMS list, so citing a count is a decision; same checkout-then-raw-then-say-so resolution as shared-file-gate |
.github/abaplint/ |
Target-specific abaplint configs: abap_702.jsonc, abap_standard.jsonc, abap_cloud.jsonc, auto_abaplint_fix.jsonc, rename.jsonc (namespace rename, used by both the build-rename workflow and the abaplint PR gate; placeholder znamespace) |
.github/shared/ |
Files this repository is the SOURCE of for the whole ecosystem — agents-metadata.md, the metadata convention samples, samples-controls and samples-stack each carry inside their AGENTS.md (a shared file needs one owner and this is the repository the others already depend on; shared-file-gate.mjs is what notices when a copy stops matching), and CONVENTIONS.md, the rules every repository follows — repository roles, workflow and npm-script naming, toolchain versions, which documentation files exist, commit style and the ABAP naming segments. Unlike the rest of this folder, CONVENTIONS.md binds this repository too; it exists because the same job carried three names across sibling repositories and npm run check ran a different set of steps than CI in three of them |
tools/app2abap/ |
trans2abap.js — converts app/webapp/* files into embedded ABAP string constants in src/01/03/, named z2ui5_cl_ui5f_* and capped at 25 characters (MAX_CLASS_NAME_LENGTH) so the rename workflow's 10-character namespace still fits the 30-character ABAP limit. A file whose basename does not fit needs an entry in CLASS_NAME_STEMS; generation fails otherwise rather than truncating |
.github/actions/ |
setup — composite action every job starts from: the Node version, the pinned actions/setup-node sha and the npm ci / npm --prefix app ci / npm run deps installs, in one place instead of copied into every workflow (inputs npm-ci, app-npm-ci, deps, cache; deps implies npm-ci). Checkout stays with the caller — a local action needs the repository on disk first. report-scheduled-failure — opens/updates an issue when a scheduled workflow fails (used by auto_abaplint_fix.yaml, vendor-mirror.yaml, check-v2-sdk.yaml and frontend_deploy.yaml) |
.github/cleaner-profile.cfj |
ABAP Cleaner profile (SAP ABAP Cleaner tool configuration for automated code cleanup) |
Changes
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 42 lines · 0 tokens per session scan A a3bbc7ff378a
repository-map is an agent published in the GitHub repository abap2UI5/abap2UI5 (378 stars, last pushed 4d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 4,573 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Related
Other agents, from other repositories
sap-architect
You are a senior SAP solution architect with 20+ years of experience designing enterprise SAP landscapes. You specialize in S/4HANA architecture, BTP integration patterns, hybrid cloud design, and extensibility strategies. You make architecture decisions based on evidence, trade-off analysis, and long-term…
sap-process-modeler
You are a senior SAP business process consultant with extensive experience in process mapping, optimization, and redesign across SAP modules. You use structured methodologies to map as-is processes, design to-be processes, identify optimization opportunities, and align processes with SAP best practices. You never…
sap-data-analyst
You are a senior SAP data specialist with deep expertise in data migration, data quality management, master data governance, and SAP analytics. You have managed data migrations for 25+ SAP implementations and designed analytics solutions across SAP BW, SAC, and embedded analytics. You treat data as a first-class…
sap-doc-generator
You are a senior SAP documentation specialist who produces client-ready documentation for SAP projects. You generate functional specifications, technical specifications, user guides, training materials, and configuration documents. Your documents are structured, complete, and follow SAP project documentation standards.
sap-estimator
You are a senior SAP project estimation specialist with extensive experience across S/4HANA implementations, migrations, and rollouts. You have delivered 50+ SAP project estimates ranging from 500 to 50,000 person-days. You never give single-number estimates. You always decompose, quantify risk, and present ranges.
sap-migration-analyzer
You are an S/4HANA migration specialist who has led 30+ migration assessments across industries. You understand custom code analysis, simplification item impact, data volume assessment, and integration remediation at an expert level. You approach every migration with systematic rigor and never understate complexity.