DingTalk AI Cards V0.8
Create or edit an A2UI file from the user's content or image, look up only the contracts needed, and distinguish local validation from delivery and client rendering. This Skill uses the DingTalk V0.8 package based on A2UI 1.0: message
is
and send API
is
.
Follow the user's requested lookup, file, send or update directly; the references are not a mandatory sequence. Obey command and protocol requirements. Ask only when missing facts, interaction meaning or the target affect the outcome.
Route by intent
Read only the relevant reference. Do not preload the complete protocol, every pattern, or the whole guide.
| Intent | First reference | Optional follow-up |
|---|
| Set up lookup and validation | Execution environment | Installed command help |
| Create or redesign from content or images | Visual focus and layout | One relevant pattern or example |
| Query a known name | Query a named contract | The result's source pointer |
| Find an unknown name | Component, function, or Token index | Query only the selected names |
| Construct or repair a card | Construct and validate | Diagnostic pointer and named contract |
| Send, preview, or update | Delivery boundary | Installed command help |
Use patterns for composition guidance and linked JSON for message shapes. Read a named example directly; use the example index only to choose one.
Composition patterns
| Content | Reference |
|---|
| Notifications and reminders | Notification |
| Object facts and decisions | Detail |
| Illustrated content and attachments | Content |
| Metrics and reports | Report |
| Editable inputs and submission | Form |
| Generation and execution updates | Progress |
For editable inputs, also consult the form pattern for bindings and submission,
even when another pattern describes the card.
When replaying an execution example, read Examples and replay for its batch boundaries, even if the JSON was selected directly.
Execution environment
This edition uses native DWS commands, not Python. Confirm
exposes
,
, and
; copying the Skill does not install commands. Lookup and lint are offline and need no Profile. Check each command's current help and structured envelope (
,
,
, or
). If unavailable, references can guide a draft, but do not claim DWS validation.
Query a named contract
bash
dws aicard explain Tabs --format json
dws aicard explain Text Row Column --compact --format json
Query only needed names. Compact
and
are lookup metadata, not A2UI fields. Query without
for expanded fields;
locates omitted details.
Construct and validate
Use
as the contract. Write an ordered JSON message array.
Within one card, keep the same
; choose an ID suitable for that card
when creating it. A complete new card requires Surface creation, root data
initialization (even
for static content), and a component with ID
.
The recommended explicit form is:
json
[
{"version":"v1.0","createSurface":{"surfaceId":"example-surface","catalogId":"https://dingtalk.com/card/a2ui/catalogs/public/catalog.json"}},
{"version":"v1.0","updateDataModel":{"surfaceId":"example-surface","path":"/","value":{}}},
{"version":"v1.0","updateComponents":{"surfaceId":"example-surface","components":[{"id":"root","component":"Text","text":"Example"}]}}
]
This is a structural example, not a business card to send. Protocol-valid inline
initialization in
and
is also
accepted; three separate messages are not the only valid representation.
| Scenario | Messages and checks |
|---|
| Complete new card | Create and initialize as above; use |
| Host-created empty Surface | Initialize its existing ID without ; use Schema and resource checks |
| Existing card update | Keep IDs and send only intentional changes; use Schema and resource checks, then check against known current state |
Removing
from a complete file does not make it a safe delta.
Do not replay form defaults or unrelated initial data: that can overwrite user
input. Resource checks alone cannot prove an update preserves state or references.
Preserve unrelated styling when editing. For ordinary new cards, prefer a root
without background fields. If a root
is needed, use
backgroundColor: "#00FFFFFF"
and no background token. Honor explicit surface designs; see
design guidance.
Prefer
for rich text and static tables;
for short titles and labels. Omit root
for ordinary cards. Do not default to
; preserve it when requested and check
insets.
Preserve supplied facts and requested interactions; label demonstration data. Replace
placeholders before delivery. Do not present unverified resources, unconnected actions, or simulated states as real and working.
Choose literals or bindings as the field contract permits. Initialize bound data with the required types and update it through
; change component literals through
.
controls whether A2A messages include the full data model, not whether bindings work.
bash
dws aicard lint --file card.a2ui.json --format json
Choose
or
for the selected scenario, and use
only when serialized message strings are needed; it cannot be combined with
. Check exit status and
plus
when selected.
dws aicard lint --self-check --format json
verifies the full package.
Validation scope
Lint checks syntax and Schema fields. New-card preflight additionally checks initialization, root, duplicate IDs within a message, static references and cycles in the final component snapshot, not every intermediate streaming frame. Unreachable components are warnings. Resource preflight checks inline encoding; neither mode evaluates bindings or proves image loading.
checks component/message fragments; it is not a way to bypass new-card initialization. Do not silently rewrite user data, remove requested components, or downgrade interactions to pass a check.
A successful named lookup is not a full package check. Use the self-check supported by the selected execution environment; local checks do not establish client behavior.
Delivery boundary
Send only when requested. Resolve exactly one target under the sending profile:
for a conversation or
for a person. Names are not target IDs. Inspect installed command help, JSON-encode the emitted message-string array as one
argument, and call
dws chat message send-a2ui-card
. Preserve the request, target, profile and returned
. An uncertain result must be checked before another create; do not resend automatically.
Creation starts in PROCESSING. Update with
dws chat message update-a2ui-card --biz-id <bizId> --content <message-strings> --flow-status <state>
under the original profile. Keep the same
and component IDs; send only intended
or
changes, not another
or unrelated defaults. Static cards require
with a nonempty valid delta; prepare it before sending and preserve business data. Stream complete messages, not JSON tokens. Resource preflight checks only the delta. If current state is known, validate it with the delta; Schema validity does not prove business safety.
dws aicard preview --file card.a2ui.json
sends a self-preview in PROCESSING;
does not send. For a completed static preview, finish it under the same profile with
dws chat message update-a2ui-card --biz-id <data.bizId> --content <message-strings> --flow-status FINISH
, using a nonempty state-preserving delta for the same Surface. Do not replay form defaults. Use server-issued
, never request-side
. If absent, inspect
and the receipt; do not recreate automatically.
cannot be used with
.
After sending, use the available readback capability under the same profile and target to identify this exact card from returned instance/message identifiers. Generic card text and a nearby timestamp are not sufficient. Report request acceptance, same-target readback, client rendering and interaction separately. If readback is unavailable or inconclusive, mark it unverified; do not claim the user received or correctly rendered the card from API acceptance alone.
Report the file, checks actually run, and delivery result when requested. Local validation and request acceptance do not prove client rendering.