mcpField
U
ui5-best-practices-integration-cards

ui5-best-practices-integration-cards

github.com/ui5Development44183 installsUpdated 1w ago
Repository

About ui5-best-practices-integration-cards

A skill that gives agents rules for creating, editing, validating, and previewing UI Integration Cards. It emphasizes declarative card types, correct data and binding placement, and manifest validation.

Key features

  1. 01Guidance for declarative card types
  2. 02Rules for parameter and destination bindings
  3. 03i18n bindings for visible strings
  4. 04Data request placement and JSON responses
  5. 05Manifest and schema validation
  6. 06Preview setup guidance

Use cases

  1. 01Creating a new UI Integration Card
  2. 02Checking card bindings and data paths
  3. 03Validating a card manifest
  4. 04Preparing a card preview

MCP support

The skill instructs agents to use the `create_integration_card` MCP tool for new declarative cards and `run_manifest_validation` for schema checks.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/ui5/plugins-coding-agents --skill ui5-best-practices-integration-cards

After installing, type/ui5-best-practices-integration-cardsin Claude Code to confirm it loaded.

Bundled filesreferences/analytical_chart_types.mdreferences/configuration_editor_example.md

Details

From the project README

Best practices for UI Integration Cards development

Rules an agent must follow when creating, modifying, validating, or previewing a UI Integration Card. Adherence is critical for working cards.

When to load each reference

TriggerLoad
Working on or planning an Analytical cardreferences/analytical_chart_types.md
dt/Configuration.js exists, is being created, or is being modifiedreferences/configuration_editor_example.md

If the trigger applies, load before producing any output. Do not work from memory.

1. Core rules

RuleDetail
Prefer declarative cardsTypes: List, Table, Calendar, Timeline, Object, Analytical. Create an Extension only in exceptional cases.
Use create_integration_card MCP toolWhen creating a new declarative card.
Parameter binding syntax{parameters>/parameterKey/value} — single braces, > separator, value suffix.
Destination binding syntax{{destinations.destinationName}} — double braces, dot. Configure under sap.card/configuration/destinations/. Reference by name; never replace with raw URL.
Use destinations for service URLsWrap every external service URL in a destination under sap.card/configuration/destinations/ and reference it as {{destinations.name}}.
i18n bindingBind every non-data, user-visible string to the i18n model.
LinksUse the actions property; never inline <a> or hand-rolled URL handlers.
Validate before declaring doneSee 3. Validation.
Show preview when requestedSee 4. Preview.
Don't modify provided dataUse it as supplied.
JSON responses onlyThe endpoint behind sap.card/data/request must return JSON. For OData services, append $format=json to the request URL or parameters.

2. Data placement

sap.card/data/ is the only correct top-level location for the data request.

PathPurpose
sap.card/data/pathPrimary data path
sap.card/content/data/pathContent-specific path; overrides the primary path if set
sap.card/header/data/pathHeader-specific path; overrides the primary path if set

Forbidden: putting the request itself under sap.card/content/data/ or sap.card/header/data/.

Symptom — "No data to display": typically caused by a content/data block that overrides the primary data path. Verify 2. Data placement before debugging anything else.

3. Validation

RuleDetail
Valid JSONmanifest.json must parse.
sap.app/typeMust be "card".
Schema validationUse run_manifest_validation MCP tool.
No deprecated propertiesIn manifest.json or elsewhere.
Not a UI5 projectExcept for Component-type cards.

4. Preview

If asked to preview, first check the card folder for an existing preview entry point — package.json start script, README.md, or an existing HTML file. Reuse it if present. Otherwise create an HTML page with a <ui-integration-card> element pointing at the manifest, and serve via an http server.

5. Configuration Editor

The editor lets the Administrator, Page/Content Administrator, and Translator personas customize a card without editing manifest.json directly.

Two pieces:

  1. dt/Configuration.js — exports a function that returns new Designtime({ form: {...} }).
  2. manifest.json — references the file at sap.card/configuration/editor.

Design as the Administrator persona.

RuleDetail
Mirror the manifestEditor reflects the current structure and parameters of manifest.json exactly. manifestpath can target any existing path — a configuration/parameters/*/value for parameterized fields, or a direct path like /sap.card/header/icon/shape for static manifest properties.
All existing fields editableTitle, subtitle, header icon, parameters — make them configurable.
Ask the userBefore deciding which fields to expose, ask: "Make all manifest fields editable? Anything else to add?"
No invented fieldsNever add an editor field that does not exist in manifest.json.
Keep in syncAdd to or remove from the editor when adding to or removing from manifest.json.

Load references/configuration_editor_example.md for the canonical paired example.

6. Analytical cards

Load references/analytical_chart_types.md for the full chart-type catalog (UIDs and per-type examples).

RuleDetail
Set chartTypesap.card/content/chartType is required.
Match feeds to chart typemeasures, dimensions, and feeds must match the UIDs the chart type expects. The reference file lists them per chart.
Each feed needs three keystype (Dimension|Measure), uid, values.
chartPropertiesUse it for labels, colors, legend, etc. Do not invent keys. Omit entirely if defaults are fine.

Minimal feeds example (donut/pie):

"feeds": [
  { "type": "Dimension", "uid": "color", "values": ["Store Name"] },
  { "type": "Measure", "uid": "size", "values": ["Revenue"] }
]

7. Card Explorer (reference)

Comments

Markdown supported