Skip to content

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:

text
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-workbench
  • starter-html-runtime
  • full / embed
  • standard runtime exposure
  • auth, credits, billing, export, and template
  • after generator-workbench is integrated on the default html path, business UI should prefer atomm-ui and 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:

text
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, or template

Once MCP and the skill are installed, the AI should default to this path:

  1. Recognize that this is a generator task
  2. Use html + starter-html-runtime by default
  3. Mount generator-workbench in shell mode by default so the runtime owns the full workspace layout
  4. Generate both full and embed
  5. Expose window.__GENERATOR_RUNTIME__, getPanelSchema(), and the standard runtime interface
  6. Enable auth, credits, billing, export, and template
  7. After generator-workbench is integrated on the default html path, default business UI to atomm-ui + CDN
  8. If runtime business UI uses atomm-ui, add runtime-side style-host handling that works for Shadow Root and normal DOM mounts
  9. Auto-generate a development appKey instead 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 cloud or history
  • 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 refactor
  • standardization refactor

You can start with:

text
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 missing

Only 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:

  1. Determine whether this is a generator task
  2. Determine whether it is a new build or an old-project refactor
  3. For new generators, default to generator-workbench + a runtime starter
  4. Generate the standard runtime instead of hand-writing a custom full shell
  5. Add full / embed, window.__GENERATOR_RUNTIME__, and getPanelSchema()
  6. Only ask more configuration questions if you explicitly deviate from the default path
  7. Report the current stage, completed items, incomplete items, and risks

Let the AI Self-Check

After generation, ask the AI to self-check:

text
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 used

If you only want to confirm the minimal demo is in place, you can also ask:

text
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 demo

CMS 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:

  1. Fill in the generator name and platform-side configuration in CMS
  2. Build the project and package it as a zip
  3. 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:

text
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 suggestions

Common 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.

MIT Licensed