back to docs
[guides]modulesauthoringvscodeailow-code

Create Modules with the VsCode Extension

Build dForge modules from your editor. The VsCode extension connects an AI assistant to the dForge tool surface and walks you through designing entities, views, actions, and roles — then packs and installs the module into a tenant.

published ·updated

Why the extension

The dForge VsCode extension is the primary way to build custom modules. Instead of hand-writing metadata JSON, you describe what you need in plain language and an AI assistant — connected to dForge’s authoring tools right inside your editor — drafts each piece of the module, shows you a preview, and writes the files once you approve.

It’s a co-pilot, not a generator: you stay in control at every step. The assistant proposes, you confirm, and only then are files written. The same flow scaffolds a brand-new module, extends one you already have, and packs and installs the result into a real tenant.

Not a VS Code user? The same authoring tools run in Claude Code, Cursor, or Zed via the MCP server — see Connect Your AI Agent (MCP).

Don’t want to install anything? The same flow runs in your browser with no setup — the browser-based template opens a ready-made cloud workspace with the assistant and dForge tools already wired up. Best place to start if you’re new.

Before you start

  1. Install the extension from the VS Code Marketplace (search for “dForge”).
  2. Install the CLI — packing and installing need dforge-cli on your PATH: 
    npm install -g @dforge-core/dforge-cli
  3. Sign in to a tenant — installing needs a target tenant. Sign in once; it opens your browser and saves the session locally: 
    dforge-cli auth login --url https://your-tenant.dforge.app
    You pass only your tenant’s web address — no API token to copy.

Open the folder where your module lives (or an empty folder for a new one) and start a chat with the assistant.

How a session flows

The extension exposes dForge’s authoring tools to the assistant and runs a guided, six-phase workflow. You can stop, resume, and backtrack at any point — the assistant re-reads the current module state at the start of every session, so a half-built module picks up where you left off.

1. Intake

The assistant asks, in plain language, what the module is for: its purpose, who uses it and what each person does with it, which existing modules it builds on, and which languages it ships. This is captured as a short brief you confirm before any files exist.

2. Domain — entities and fields

From the brief, the assistant proposes the entity inventory — the business objects the module manages (e.g. ticket, supplier, invoice). Once you approve the list, it scaffolds the module and adds fields, traits, and references to each entity, one at a time.

Already have a database? The assistant can import an existing schema (DBML/SQL) to bootstrap entities, then refine the rough cut with you.

3. Behavior — actions, triggers, jobs, webhooks

Optional, and only what you ask for:

  • Actions run when a user clicks a button (bulk operations, workflows).
  • Triggers fire on a database event — “when X happens, do Y.”
  • Scheduled jobs run on a cron timer (nightly cleanup, daily summaries).
  • Webhooks POST to an external service on an event (Slack, Zapier, dashboards).

Pure CRUD modules can skip this phase entirely.

4. Views and reports

Every entity gets a default grid view first. Then, where it makes sense, the assistant proposes specialized views — kanban for a status field, calendar for a scheduled date, tree-grid for self-referencing records — and reports for aggregated, printable summaries.

5. Polish — settings, translations, seed data

Configurable values become module settings; declared locales get translation files; reference data the module needs on install becomes seed data.

6. Security — roles and rights

The assistant derives roles from the user types and verbs captured at intake — not a generic admin/viewer template — and shows a rights matrix (Select / Insert / Update / Delete / Clone per entity, Execute per action) for you to sign off before granting anything.

7. Verify — pack and install

Finally the module is packed into a .dforge package and installed into your tenant. Install runs the full server-side validator — it’s the real test that the module is correct. If something’s off, the error points to which phase to revisit.

What you end up with

A versioned, installable .dforge module — the same format as the system and community modules in the catalog, running on the same engine. You can install it into any tenant, extend it later from the same editor, and commit its metadata to source control like any other code.

Prefer a visual, browser-based designer?

A visual alternative — Module Studio — lets you design modules in the browser with no editor or CLI. It covers the same building blocks (entities, views, menus, roles, actions) through a point-and-click UI. See the Studio Guide if that fits your workflow better.

previousConnect Your AI Agent (MCP)nextDashboards
/ was this helpful?

Stuck on something?
Tell us.

We read every message and update the docs based on what readers ask. The fastest way to improve the docs is to write to us.

Contact supportAll docs