There are two ways to author an Application in CharmIQ. Start with whichever matches the size of the problem.

The fastest path: write HTML, CSS, and JavaScript directly into the application. No file management, no build step, no manifest. The Application appears in your workspace immediately.

 — is injected automatically. Your Application can read and write collaborative data in the document, connect to OAuth-protected APIs, call MCP servers, and communicate with other Applications in the same workspace. All of it is available from a single HTML file.

A Charm can produce a complete inline Application in one pass. Describe what you need; it writes the HTML, styles it all within the Application container in your document.

When the problem grows past what a single file handles cleanly, the right move is a folder-based Application. You create a folder in CharmIQ, put your source files in it as Source documents, and add a 

 that tells the build pipeline how to assemble them.

The build pipeline takes your source files, runs them through esbuild (TypeScript → JavaScript, SCSS → CSS), resolves all imports, bundles everything, and produces a single self-contained HTML document that runs in your workspace. No deploy step. No CI pipeline. Edit a file, reload the Application, see the result.

A Charm can build a folder-based Application entirely. That means: create the folder structure, write each source file, produce the manifest, and place the Application container referencing the folder. One prompt. A working, multi-file Application.

The same manifest-based pipeline is available through the 

. That is the path for external tools — VS Code, local scripts, CI-style checks — that already have source files and want CharmIQ to build them.

The MCP build surface returns a runnable artifact. It does not create a folder, write documents, place an Application container, or publish anything. The caller decides what to do with the output: write it to disk for preview, pass it into an iframe 

, or persist it through another CharmIQ API.

Start inline. It's faster, the feedback loop is tighter, and for many tools it's all you need.

Promoting an inline Application to a folder-based one is a natural step, not a rewrite. The HTML template and core logic move over intact — you're just adding structure around them.

<!DOCTYPE html>
<html>
<head>
  <style>
    body { font-family: sans-serif; padding: 24px; }
    .output { font-size: 1.25rem; margin-top: 16px; }
  </style>
</head>
<body>
  <div class="output" id="out">Loading...</div>

  <script>
    window.charmiq.appContent.onChange$().subscribe(change => {
      document.getElementById('out').textContent = change.content || 'Nothing yet.';
    });
  </script>
</body>
</html>

 is always available. No import, no setup — it's injected before your code runs.

) at the root of your Application folder. It tells the build system where to find your entry points and which external packages to load:

My Application

Everything else in the folder is discovered automatically. You don't need a 

 map unless you're pulling source from outside the folder.

My App (folder)
├── manifest.json
├── index.html
├── src/
│   ├── main.tsx
│   ├── App.tsx
│   └── styles.scss
└── components/
    └── Header.tsx

Virtual paths match the document names in your folder. 

import { Header } from './components/Header'

 — How Applications store data in the document.

 — How the manifest, virtual file system, and esbuild work together.

 — Build Applications from external tools and receive a runnable artifact.

From a single HTML file to a multi-file folder project — two ways to build, and when to use each.

Building Applications

The Inline Application

The Folder-Based Application

Building Outside the Workspace

Knowing When to Switch

In Practice

Inline: The Minimal Case

Folder-Based: The Manifest

Folder Structure

Patterns

Next Steps