AI Integration Notes
This page extends the quick-start guide in AI Integration: Build a Generator with Cursor with the default rules, old-generator refactor guidance, self-check prompts, release notes, and common mistakes.
Shortest Prompt
If you only want to bootstrap the first runnable version, you can ask:
Help me develop a new pendant generator. Follow the default standard path from creating-generators and build a minimal runnable demo first.The skill should fill in the defaults:
generator-workbenchstarter-html-runtimefull/embed- standard runtime exposure
auth,credits,billing,export, andtemplate- after
generator-workbenchis integrated on the defaulthtmlpath, business UI should preferatomm-uiand stay CDN-based - when runtime business UI uses
atomm-ui, the AI should also ensure styles are injected into the actual runtime mount root instead of relying only on page-level<head>CSS
If You Want to Keep the Scope Tight
If you only want the standard skeleton first and do not want extra platform capabilities yet, add:
For now, keep the default standard path and do not extend to `cloud` / `history`.
Please finish the minimal runnable skeleton first so we can iterate on business logic later.This keeps the task small without downgrading it into a generic page.
The Default Rule First
For a new standard generator, you usually do not need to pre-specify:
- the
appKey - the framework
- whether to use
generator-workbench - whether to support
full/embed - whether to include
auth,billing,export, ortemplate
Once MCP and the skill are installed, the AI should default to this path:
- Recognize that this is a generator task
- Use
html+starter-html-runtimeby default - Mount
generator-workbenchinshellmode by default so the runtime owns the full workspace layout - Generate both
fullandembed - Expose
window.__GENERATOR_RUNTIME__,getPanelSchema(), and the standard runtime interface - Enable
auth,credits,billing,export, andtemplate - After
generator-workbenchis integrated on the defaulthtmlpath, default business UI toatomm-ui+ CDN - If runtime business UI uses
atomm-ui, add runtime-side style-host handling that works for Shadow Root and normal DOM mounts - Auto-generate a development
appKeyinstead of blocking on configuration questions
The AI should only ask follow-up questions when you explicitly deviate from that default path, for example:
- you explicitly want
vue - you explicitly want a reduced-scope build
- you explicitly want a custom shell
- you explicitly want runtime-only delivery
- you explicitly want
cloudorhistory - you explicitly say this is an old-generator refactor
How to Ask for an Existing Generator
If you already have a generator project, do not ask the AI to recreate it. Tell it clearly that this is an incremental refactor.
With the current skill, the most important thing for an old generator is not the appKey first. It is the task framing:
compatibility refactorstandardization refactor
You can start with:
This is an existing generator project. Do not rebuild it from scratch. Refactor the current codebase.
Task framing: standardization refactor
Known information:
1. The project already has a pendant preview and parameter panel
2. Please inspect the current structure first before deciding where to integrate generator-sdk
3. I want it to converge to the standard generator shape
Please start by:
1. Deciding whether this should be handled as a compatibility refactor or a standardization refactor
2. Integrating generator-sdk
3. Adding runtime, `full` / `embed`, and `PanelSchema`
4. Telling me which files you plan to modify and what information is still missingOnly when this is an old project and real production configuration must be reused should appKey become a follow-up question. It should no longer be the default starting barrier for a new project.
What the AI Actually Does
With MCP and the skill installed, the AI typically works in this order:
- Determine whether this is a generator task
- Determine whether it is a new build or an old-project refactor
- For new generators, default to
generator-workbench+ a runtime starter - Generate the standard runtime instead of hand-writing a custom full shell
- Add
full/embed,window.__GENERATOR_RUNTIME__, andgetPanelSchema() - Only ask more configuration questions if you explicitly deviate from the default path
- Report the current stage, completed items, incomplete items, and risks
Let the AI Self-Check
After generation, ask the AI to self-check:
Please verify whether this generator now satisfies the default creating-generators standard path, and report using these fields:
1. Task framing
2. Current stage
3. Completed items
4. Incomplete items
5. Whether standardization completion can be claimed
6. Risks and blockers
7. MCP path used
8. Whether the official `generator-workbench` was usedIf you only want to confirm the minimal demo is in place, you can also ask:
Please confirm whether the current project already has:
1. `generator-workbench`
2. `full` / `embed`
3. `window.__GENERATOR_RUNTIME__`
4. `getPanelSchema()`
5. a runnable minimal pendant demoCMS and Upload Come Later
If your current goal is just to let the AI bootstrap the first version, you can leave this for later.
Only when you are ready to publish or connect to the platform should you handle CMS and upload:
Typical release-stage actions:
- Fill in the generator name and platform-side configuration in CMS
- Build the project and package it as a zip
- Upload the build output
This belongs to the release stage and should not dominate the quick-start AI workflow.
Suggested Prompt Template
If you want a reusable template, use this:
Help me develop a new pendant generator.
Please follow the default standard path from creating-generators and do not block on `appKey`, shell, or feature selection first.
Goals:
1. Use `generator-workbench` by default
2. Generate a standard runtime with `full` / `embed`
3. Keep `PanelSchema` and the standard runtime interface
4. After `generator-workbench` is integrated, use `atomm-ui` for business UI and load it by CDN
5. Do not stop at loading CSS in page-level `<head>`; if runtime business UI uses `atomm-ui`, handle the actual runtime style host too
6. Finish a minimal runnable demo first
Pendant requirements:
- preview on the left
- parameter panel on the right
- minimalist rectangular pendant
- only the word generator inside
After that, please report:
1. Current stage
2. Completed items
3. Incomplete items
4. Risks and next-step suggestionsCommon Mistakes
Asking the AI to write integration code before MCP is installed
The AI may guess APIs from memory and get generator-sdk usage wrong.
Asking the AI to "just build a generator" before the skill is installed
The AI may generate only a page and miss full / embed, runtime structure, and PanelSchema.
Starting a new generator by asking for appKey first
The current skill already allows the AI to generate a development appKey by default, so this should not block the first implementation pass.
Treating generator-workbench as a later enhancement
For a new standard generator, generator-workbench should be the default host shell, and shell mode should be the first choice unless you explicitly need the classic split sidebar layout.
Starting from generate_code or a hand-written demo instead of a starter
That often pulls the task back toward snippet-level examples or a custom shell instead of the standard generator path.
Assuming atomm-ui CSS in index.html automatically styles runtime business UI
When generator-workbench mounts the runtime, the runtime business UI may live inside a Shadow Root or another isolated root. Page-level CSS alone is not enough in that case, so the AI should verify the runtime-side style host strategy as well.
One-Sentence Principle
Do not ask the AI to "just generate a page." First configure MCP and the skill, then let the AI follow the default creating-generators standard path to generate a generator skeleton that already mounts generator-workbench.