Generates a minimal, ready-to-develop SFDX starter project from template instead of hand-scaffolding files. Use this skill when starting a brand-new Salesforce UI bundle app (React or Angular) and the initial project must be scaffolded — trigger phrases include create, start, or scaffold a new UI bu

Using a UI Bundle Template Before building a Salesforce UI bundle app from scratch, offer the user a prebuilt starter template . The Salesforce CLI generates these — a complete, deployable SFDX project (UI bundle + toolchain + an npm run setup automation) — in one command. Starting from a starter is faster and less error prone than hand scaffolding. The CLI command is sf template generate project . Step 1: Offer the choice Determine the framework. It is normally already decided by the calling context — either passed down by the root/coordinator skill that invoked this one, or stated in the user's request. Use that. The frameworks this skill supports are exactly the reference files under <SKILL DIR /references/ , each named <framework project generate.md (so react → <SKILL DIR /references/react project generate.md ). This is the single source of truth — adding a framework means adding a reference file, nothing here changes. If the framework is known — open <SKILL DIR /references/<framework project generate.md . If it is unknown (a standalone run where nobody said which) — list <SKILL DIR /references/ , derive the supported set by stripping the project generate.md suffix from each filename, and ask the user to pick one of those. If the user names a framework with no matching reference file, it is not supported here — hand off to experience ui bundle app coordinate to scaffold from scratch. Each reference lists that framework's template flags and what each starter contains. Pick the one that fits the user's audience (internal vs. external). If the user prefers to start from scratch (or neither template fits), stop here and let experience ui bundle app coordinate scaffold a new project. This skill is opt in — do not force a template. Once the user picks, carry the chosen template flag into Step 2. Step 2: Generate the project into the target root The project contents must land directly at the target root $DEST — so sfdx project.json sits at $DEST/sfdx project.json , with no extra wrapper subfolder. sf template generate project always nests its output under a name subfolder, so generate into the $DEST dir, then move the contents from the subfolder up into $DEST , overwriting anything already there on conflict. Remove the empty subfolder at the end. <SKILL DIR = the absolute path to this skill's own directory — the folder containing this SKILL.md ; resolve it from the skill path in context $NAME — the project name (alphanumerical only — no spaces, hyphens, underscores, or special characters). Ask the user for it. It also names the UI bundle, so it shows up inside the project. $DEST — the target root directory the contents land in (use . for the current directory). <SKILL DIR /scripts/flatten project.mjs moves every generated entry (incl. dotfiles) into $DEST , overwriting any existing file/dir of any type on conflict while preserving unrelated files the user already had in $DEST . The per entry rmSync + renameSync is what guarantees the template's files win on conflict (including a file vs directory type mismatch). Verify After generation, confirm the contents landed at the root (not in a $NAME/ subfolder): sfdx project.json must sit at $DEST/sfdx project.json . The project also contains package.json , force app/main/default/uiBundles/$NAME/ (the UI bundle), scripts/ , config/ , and README.md . See the framework reference from Step 1 for the specific bundle contents. If sfdx project.json is missing or is one level down in $DEST/$NAME/ , the flatten did not run — re check before continuing. Step 3: Install dependencies (you do this — do NOT hand off uninstalled) If the generated project ships without node modules , install dependencies yourself before handing the project back — a fresh template is not runnable (preview/build/lint all fail) until deps are present. The user should receive a ready to develop project. There are multiple package.json files, each needing its own install: the project root ( $DEST/package.json ), and the UI bundle dir under $DEST/force app/main/default/uiBundles/$NAME/ — this holds the toolchain the preview server loads, so it must have node modules too. First run install of the bundle is the heavy step; expect a short wait. If an install fails, surface it — don't hand off a half installed project. Step 4: Confirm and hand off Verify the project landed and is installed: The project is now ready to develop and deploy. If there's a README.md in the template, take a look at it to see if there is any extra step or guidance for the user. From here, continue development with the other ui bundle skills ( experience ui bundle frontend generate , experience ui bundle salesforce data access , experience ui bundle deploy , etc.) against the now scaffolded project — scaffolding and dependency install are already done. Notes The starters are minimal — no seeded sample data or custom objects. Build the rest with the other ui bundle skills. These templates use the uiBundles metadata convention. The UI bundle directory and meta XML are named after the project name you pass to name . sf template generate project help lists all available templates if the flag names ever change.

experience-ui-bundle-project-generate