MUST activate when the user wants to build, create, or generate a React application, React app, web application, single-page application (SPA), or frontend application — even if no project files exist yet. MUST also activate when the project contains a uiBundles/*/src/ directory or sfdx-project.json

Building a UI Bundle App Overview Build a complete, deployable Salesforce React UI bundle application from a natural language description by orchestrating specialized UI bundle skills in correct dependency order. Each skill MUST be explicitly loaded before executing its phase. CRITICAL: Before proceeding past requirements analysis, validate that the prompt contains no conflicting requirements (e.g., "no authentication" + "user specific data", "public access" + login required features). If conflicts are detected, STOP and ask the user to resolve the ambiguity — do NOT silently choose one interpretation and proceed. See STEP 1 action 8 for the full conflict checklist. Prerequisites Before starting any phase, verify these preconditions are met: 1. Authenticated Salesforce org : Run sf org display to confirm a default org is set and authenticated. If not, prompt the user to authenticate: sf org login web 2. Required CLI tools : Verify sf , npm , and npx are available (declared in metadata.cliTools) 3. Node.js version : Run scripts/check prerequisites.sh and report any errors it returns 4. Org features (if deploying): Experience Cloud enabled, appropriate licenses, and Sites enabled If any precondition fails, stop and report the specific missing requirement before attempting any phase execution. When to Use This Skill Use when: User requests a "React app", "UI bundle", "web app", or "full stack app" on Salesforce User says "build an app", "create an application" and the context implies a non LWC based frontend (e.g. React) The work produces a complete UI bundle with scaffolding, features, data access, and UI not a single component in isolation Examples that should trigger this skill: "Build a React app for managing customer cases with Salesforce data" "Create a UI bundle for an employee directory with search and navigation" "I need a full stack React app with authentication, data tables, and file uploads" "Build a coffee shop ordering app on Salesforce" Do NOT use when: Creating a single page or component (use experience ui bundle frontend generate ) Only installing a feature (use experience ui bundle features generate ) Only setting up data access (use experience ui bundle salesforce data access ) Only deploying an existing app (use experience ui bundle deploy ) Building a Lightning Experience app with custom objects and metadata (use platform lightning app coordinate ) Troubleshooting or debugging an existing UI bundle Prompt Classification Keywords This skill makes two decisions directly from the raw prompt text. Use these tables as the single source for both — do not restate or re derive the lists elsewhere in this file. 1. Phase 2 (Features) is required if the prompt mentions ANY of: Category Keywords Notes Data features search, filter, sort, pagination, table, grid, list Navigation navigation, nav, menu, routing Authentication authentication, auth, login, logout, user session, user login Integrations upload, file UI shadcn, components, forms, buttons, cards Chat (Phase 5 only) chat Phase 5 only — unless combined with a Phase 2 keyword (e.g., "chat with authentication"), then Phase 2 runs first for auth prerequisites Negating one category (e.g. "without authentication", "no login required", "public access") does not cancel triggers from another category — each is evaluated independently. Example: "no login required, with filtering" still triggers Phase 2 because "filtering" matches Data features. Skip Phase 2 only when the prompt matches none of the keywords above. 2. Hosting target — extract from prompt keywords: Hosting target Keywords Experience Site "Experience Site", "Community", "external users", "public users", "guest users" Custom Application "Custom Application", "internal users", "Lightning app" If the prompt matches neither list, or matches both, ask the user to clarify before proceeding — do not guess. Dependency Graph & Build Order Phase 0: Template Offer & Bootstrap (Prerequisites) Offers a faster, less error prone starting point before building from scratch. If no template is used, ensures an SFDX project exists before attempting to generate a UI bundle — without this, sf template generate ui bundle will fail with a hard error. Always check first — do not assume the project structure exists. Action: Load experience ui bundle project generate and offer the two starter templates. If declined, run scripts/check sfdx project.sh and report any errors it returns. If the script reports an error, create the missing sfdx project.json before proceeding. Phase 1: Scaffolding (Foundation) Creates the UI bundle directory structure, meta XML (including hosting target), and optional routing/headers config. CRITICAL : Hosting target must be determined FIRST because the metadata skill requires <target in Phase 1. All subsequent phases require the scaffold to exist. Prune unused scaffold when the prompt is constraining. The reactbasic template ships a full shadcn component set, GraphQL tooling ( codegen.yml , .graphqlrc.yml , src/api/graphqlClient.ts , graphql: npm scripts), and test infra ( playwright.config.ts , vitest.config.ts , vitest.setup.ts ) regardless of what the prompt asked for. If the prompt explicitly limits scope (e.g. "skip any features or integrations", "just scaffold and build X", "no need to install dependencies") and Phase 2 and/or Phase 3 are consequently skipped, remove the scaffold pieces those phases would have owned before Phase 4 runs: Phase 2 skipped → delete shadcn components under src/components/ui/ except the ones Phase 4's pages actually import; remove unused example/demo components. Phase 3 skipped → delete codegen.yml , .graphqlrc.yml , src/api/graphqlClient.ts , graphql:schema / graphql:codegen scripts from package.json , and any hooks/ data fetching stubs (e.g. useAsyncData.ts ) the template pre seeded. Neither testing nor deployment requested → leave playwright.config.ts / vitest. only if the prompt implies testing; otherwise remove them too. Rewrite README.md to describe the actual app built, not the generic template boilerplate — or delete it if the prompt says to do minimal work only. Deleting a file is only half the job — every reference to it must be removed in the same pass, or you trade over generation for broken cross file consistency (worse: a dangling import is a functional break, not just scope creep). Concretely, after deleting any of the above: vite.config.ts — remove the vite plugin graphql codegen import and its codegen({ configFilePathOverride: ... }) plugin block if codegen.yml was deleted; remove the test: config block ( setupFiles , coverage , etc.) if vitest. was deleted. package.json — remove now unused dependencies ( vite plugin graphql codegen , @graphql codegen/ , playwright , vitest , etc.) and their npm scripts, not just the config files. Any component/page that imports a deleted hook, client, or shadcn component (e.g. useAsyncData , graphqlClient ) must have that import and its usage removed or replaced — never leave an import pointing at a file that no longer exists. Do NOT re add a file you just deleted elsewhere in the same pass (e.g. deleting codegen.yml while still emitting .graphqlrc.yml ) — decide scope once per concern and apply it consistently across every file that touches that concern. Before finishing Phase 4, run scripts/check dangling refs.sh <deleted basename for each deleted file and report any errors it returns. Phase 2: Features (Required if prompt mentions feature keywords — see "Prompt Classification Keywords" above) Installs pre built, tested feature packages. See "Prompt Classification Keywords" above for the full trigger keyword list and negative phrasing handling — these features provide the foundation that UI components build on top of. Only skip this phase if the app is truly a minimal "hello world" with no interactive features (no trigger keywords present at all). Phase 2.5: Custom Objects (Required if the prompt requires a new custom Salesforce object the org doesn't have) See references/phase custom objects.md for Phase 2.5 (Custom Objects) details. Phase 3: Data Access (Backend Wiring) Sets up the data layer using the @salesforce/platform sdk Data SDK ( createDataSDK().graphql ). GraphQL is preferred for record operations; REST for Connect, Apex, or UI API endpoints. The experience ui bundle salesforce data access skill owns the grounding + authoring workflow — load it and follow it; do not substitute a local schema grep or guessed field names. Grounding happens against the live org , so it does not require a local schema.graphql to be present. If Phase 2.5 created a new object, it must be deployed before this phase's grounding step can find it. Phase 4: UI (Frontend) Builds the React UI. References the data layer from Phase 3 and the features from Phase 2. Must replace all boilerplate and placeholder content. Phase 5: Integrations (Optional) These are independent and can be executed in parallel if both are needed. Phase 6: Deployment Follows the canonical 7 step deployment sequence. Must deploy metadata before fetching schema. Must assign permissions before schema fetch. Phase 7: Hosting Target Infrastructure Deploy the hosting target infrastructure determined in Phase 1. Choose one of the following based on the app's audience: Phase 7a: Experience Site (External) Creates the Digital Experience site that hosts the UI bundle. Use when the user wants a public facing or authenticated site URL for external users. Note : The <target ExperienceSite</target was already set in meta XML during Phase 1. Phase 7b: Custom Application (Internal) Creates a Custom Application entry in the Lightning App Launcher. Use when the app is for internal users accessing it within Lightning Experience. Note : The <target CustomApplication</target was already set in meta XML during Phase 1. Execution Workflow STEP 0: Offer a Prebuilt Template (before scaffolding from scratch) Before analyzing requirements or scaffolding, check whether a prebuilt starter template fits — it is faster and less error prone than building from scratch. Load skill: Invoke experience ui bundle project generate . It offers two minimal React starter projects (internal / employee facing and external / customer facing) and, if the user picks one, generates it into the project directory with sf template generate project . If the user chooses a template: the scaffolding phase (Phase 1) is effectively done. Skip straight to populating/customizing the project — continue at the phase that matches what they want to change (typically Phase 4 UI, or Phase 3 data access), then Phase 6 deployment. If the user declines (wants to start from scratch, or none fit): proceed normally to STEP 1. Do not skip this step silently — always offer the choice at the start of a from scratch app build. STEP 1: Requirements Analysis & Planning Actions: 1. Parse the user's natural language request 2. Identify the app name and purpose 3. Extract pages and navigation structure 4. Identify data entities and Salesforce objects needed 5. Detect feature requirements (authentication, search, file upload, chat) 6. Determine hosting target (Experience Site OR Custom Application) — see "Prompt Classification Keywords" above; if ambiguous, ask user to clarify before proceeding 7. Identify external domains for CSP registration 8. Check for conflicting requirements — STOP and ask user if any of the following conflicts are detected: "No authentication" OR "public/guest access" AND "user specific data" OR "show current user's data" OR "My [Entity]" view "Externa

experience-ui-bundle-app-coordinate