AEM development is repetitive in ways that shouldn’t require an expert. Creating a new component, scaffolding a template, wiring up a policy — these tasks follow consistent patterns that every developer on your team has to rediscover or look up each time. Junior developers spend hours on setup that should take minutes. Senior developers spend time reviewing setup work instead of the logic that actually matters.
AEM Copilot is a VS Code extension that addresses this directly. It brings a set of slash commands into your editor — each one with a single clear job, named parameters for unambiguous input, and output that’s ready to use.
Why Slash Commands
Slash commands are the right interface for this kind of tooling. They’re low friction — you stay in your editor, you type what you need, you get a result. They’re discoverable — the command list is self-documenting. And they’re composable — each command does one thing well, which means you can run them in sequence as a project builds up.
The alternative — a configuration UI, a wizard, a separate CLI — all require context switching. Slash commands don’t.
The Command Set
The commands are split into two groups based on when in a project lifecycle you use them.
Project Setup Commands
These three commands are typically run once at the start of a project, roughly in order.
/aem-new-site site=<name>
Scaffolds a complete AEM site structure. Generates the initial project layout, base configuration, and the foundational files your team needs before any page or component work begins. Run this once when a new site project kicks off.
/aem-new-template site=<name> template=<name>
Creates a new editable template for the site. Generates the template definition, the initial structure node, and the policy container — wired to the correct paths for your site. Run this for each distinct page layout your site requires.
/aem-new-theme site=<name> theme=<name>
Scaffolds a client library theme for the site — the base CSS and JS structure, the category definition, and the configuration to load it correctly in the context of your site. Run this when establishing the visual foundation before component-level styling begins.
Build Cycle Commands
These commands get used repeatedly throughout the build as the site grows.
/aem-new-page site=<name> page=<name> template=<name>
Creates a new page structure tied to a specific template. Generates the JCR content structure, sets the correct template reference, and scaffolds the initial content nodes. Saves the lookup-and-copy cycle that most developers default to when adding new pages.
/aem-new-component site=<name> component=<name>
Scaffolds a complete AEM component — the component node definition, the HTL template, the Sling model stub, the dialog definition, and the clientlib structure. Everything in the right place, named consistently, ready for implementation. This is the command your team will run most.
/aem-new-policy site=<name> policy=<name> component=<name>
Creates a content policy definition for a component. Generates the policy node structure and wires it to the correct component. Eliminates the error-prone manual process of setting up policies through the Template Editor for teams that prefer to define them in code.
Utility Commands
These two commands are always available regardless of project phase.
/aem-explain concept=<term>
Explains an AEM concept in plain language. Particularly useful for junior developers who are still building their mental model of the platform — Sling resolution, OSGi service lifecycles, JCR node types, replication, dispatcher caching. Instead of sending a developer to documentation and waiting, they get a contextual explanation without leaving the editor.
/aem-debug error=<message>
Takes a CRX error, a Sling exception, or an OSGi console message and returns a plain-language diagnosis with a recommended fix. AEM error messages are notoriously cryptic — org.apache.sling.api.resource.LoginException, Could not resolve resource type, No adapter available — and the back-and-forth of debugging them slows every team down. /aem-debug cuts straight to the cause.
How It Works
Each slash command is registered in the VS Code extension’s package.json and handled by a dedicated handler file. A system prompt scoped to each command tells Copilot exactly how to respond — what format to produce, what files to generate, what naming conventions to follow.
Named parameters (site=my-brand, component=hero) give Copilot unambiguous inputs. There’s no guessing from workspace context, no relying on file names, no prompt engineering required from the developer. You type the command with its parameters and the output is consistent.
Who It’s Built For
AEM Copilot is designed for two audiences simultaneously.
For experienced AEM developers, it eliminates the setup tax — the scaffolding work that’s necessary but not where expertise adds value. Time that was going into boilerplate goes into the work that actually requires judgment.
For junior developers and engineers new to AEM, it removes the platform’s steep initial learning curve. /aem-explain and /aem-debug in particular mean that the first time you encounter an unfamiliar concept or a cryptic error, you don’t have to interrupt a senior colleague or spend an hour in documentation.
Download
AEM Copilot is available as a packaged VS Code extension. The ZIP includes the full extension source, the package.json command registrations, all handler files, and installation instructions.
To install: extract the ZIP, open VS Code, run Extensions: Install from VSIX from the command palette, and select the .vsix file from the extracted folder.
Feedback and contributions welcome — reach out via LinkedIn or open a discussion.