원클릭으로
appdb
Toolkit-first AppDB document CRUD, query operators, and collection wiring.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Toolkit-first AppDB document CRUD, query operators, and collection wiring.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Step-by-step orchestrator for building Domo App Studio apps with native KPI cards via community-domo-cli. Sequences app creation, pages, theme, hero metrics, native charts, filter cards, layout assembly, and navigation. CLI-first — no raw API calls.
Domo KPI card CRUD via community-domo-cli — body schema, column mapping, beast modes, chart type index with on-demand reference files, and gotchas.
**Generating sample data for Domo** -- invoke when a user needs to create realistic sample datasets and upload them to a Domo instance. Primary signals: requests for sample data, demo data, test data, fake data for Domo; mentions of Salesforce, Google Analytics, QuickBooks, NetSuite, Google Ads, Facebook Ads, HubSpot, Marketo, or Health Portal sample data; questions about the datagen CLI or domo_data_generator. Covers: generating datasets, uploading to Domo, creating datasets in Domo, rolling dates, entity pools, connector icons, catalog management, and adding new dataset definitions. Skip for: real connector setup, production data pipelines, data transformations (Magic ETL), or Domo App Platform.
Create AppDB collections via CLI-first workflows where collection creation also provisions the required datastore, then returns collection identifiers for manifest wiring and document-write follow-up. Use when an agent must initialize new AppDB storage for a Domo app, not just list/get collections or create documents.
Create Domo Code Engine packages from CLI workflows with deterministic payload contracts, automatic function parameter datatype mapping, and manifest packagesMapping follow-up guidance. Use when an agent must create a new package/versioned package container rather than only invoke an existing function from app runtime code.
Update Domo Code Engine packages through CLI-driven versioned lifecycle workflows with compatibility checks, datatype contract safeguards, and manifest mapping drift synchronization. Use when an agent must update package code or create a new package version and keep app mappings aligned.
| name | appdb |
| description | Toolkit-first AppDB document CRUD, query operators, and collection wiring. |
This rule is toolkit-first. Use AppDBClient instead of raw domo.get/post/put/delete endpoints.
yarn add @domoinc/toolkit
import { AppDBClient } from '@domoinc/toolkit';
type Task = {
title: string;
status: 'active' | 'completed';
priority: 'Low' | 'High' | 'Urgent';
};
const tasksClient = new AppDBClient.DocumentsClient<Task>('TasksCollection');
const created = await tasksClient.create({
title: 'New Task',
status: 'active',
priority: 'High'
});
const task = created.body;
const all = await tasksClient.get();
const active = await tasksClient.get({ status: { $eq: 'active' } });
const highOpen = await tasksClient.get({
$and: [{ status: { $ne: 'completed' } }, { priority: { $in: ['High', 'Urgent'] } }]
});
Documents returned by .get() are wrapped with metadata and your fields live inside doc.content.
What .create() accepts:
{ vendor: 'Acme', riskLevel: 'High', notes: 'Late payments' }
What .get() returns (shape):
[
{
"id": "04b1756e-7b6d-4d77-842f-7975a6474d8a",
"datastoreId": "a3b85171-...",
"collectionId": "ba194a7d-...",
"syncRequired": true,
"owner": 767612617,
"createdOn": "2026-03-22T02:22:42.030Z",
"updatedOn": "2026-03-22T02:22:42.030Z",
"updatedBy": 767612617,
"content": {
"vendor": "Acme",
"riskLevel": "High",
"notes": "Late payments"
}
}
]
Key points:
doc.content, not at the top level.doc.id is the document ID used for .update() and .delete().datastoreId, collectionId, owner, createdOn, etc.) are top-level.response.body or directly the array.Required parsing pattern:
const response = await tasksClient.get();
const rawDocs = response.body || response;
const docs = Array.isArray(rawDocs) ? rawDocs : [];
const parsed = docs.map((doc) => ({
id: doc.id,
...doc.content
}));
Common mistake:
// WRONG: fields are inside content
const docs = response.body || response;
docs[0].vendor; // undefined
// CORRECT
docs[0].content.vendor; // "Acme"
await tasksClient.update({
id: 'document-uuid',
content: { title: 'Updated', status: 'completed', priority: 'Low' }
});
await tasksClient.partialUpdate(
{ status: { $eq: 'active' } },
{ $set: { status: 'archived' } }
);
await tasksClient.delete('document-uuid');
await tasksClient.delete(['uuid-1', 'uuid-2']);
Collections still must exist in manifest.json under collections.
{
"collections": [
{
"name": "TasksCollection",
"schema": {
"columns": [
{ "name": "title", "type": "STRING" },
{ "name": "status", "type": "STRING" }
]
}
}
]
}
collections mapping exists in manifestAppDBClient.DocumentsClient used for CRUD.get() results are unwrapped from doc.content before UI/use$eq, $in, $set, $inc, etc.) used correctly