Create Component

AEM Component Creation Skill

Creates complete AEM components following Adobe best practices.

Configuration Gate Check — Do This First

This configuration check needs to happen first because without it, the skill will use incorrect project paths and package names, causing every generated file to be wrong.

First tool call: Read .aem-skills-config.yaml in the project root (same level as pom.xml).

Check: Does the file exist and does it have configured: true?

If NOT configured, Display This Message and Stop:

Project configuration required!

Before creating components, configure your project settings in:
`.aem-skills-config.yaml` (in your project root, same level as pom.xml)

Open the file and update:
- project: Your AEM project name (e.g., 'mysite', 'wknd')
- package: Your Java package (e.g., 'com.mysite.core')
- group: Your component group (e.g., 'MySite Components')
- configured: true

After updating, ask me to create the component again.

Why you should not explore the codebase when unconfigured:

Doing any of the following before configuration is set will lead to incorrect assumptions and wasted effort:

• Reading any other repository files
• Listing directories to "understand the project"
• Checking existing components for patterns
• Looking at pom.xml, Java files, or folder structures
• Inferring values from any source

The config file is the single source of truth for project values — skipping it leads to wrong paths and package names in every generated file.

No Hallucination Rule

Only create the exact fields the user specified — adding extra fields creates authoring confusion and maintenance burden, and renaming fields breaks content contracts.

Load reference for full rules: references/no-hallucination-rules.md

Workflow Overview

Step 0: Configuration Validation

0.1 Read Configuration

1. Read .aem-skills-config.yaml from the project root
2. Check that configured: true
3. Read project, package, and group values

0.2 Validate — Use Only the Config File

Do not infer project values from the file system, existing components, Java files, pom.xml, or prior knowledge. These sources may be outdated or inconsistent — .aem-skills-config.yaml is the single source of truth because the user explicitly sets it.

0.3 Load Conventions

1. Read references/aem-conventions.md for file structure templates, naming conventions, and patterns

0.4 Project State Analysis (after configuration validated)

1. Check Component Name Uniqueness - Look in /apps/[project]/components/
2. Check Model Class Conflicts - Look in core/src/main/java/[package-path]/models/
3. Analyze Existing Patterns - Review 1-2 recent components for style reference

Step 1: Extract & Validate Component Name

• Parse component name from user's message (ask if not provided)
• Normalize to lowercase kebab-case (e.g., My Component -> my-component)
• Validate: starts with letter, only letters/numbers/hyphens, no consecutive hyphens

Step 1.5: Component Extension Decision

When user says "extend {component}":

Tier 1: Check Project Components First

• Search /apps/{project}/components/{component}
• If found -> Use as sling:resourceSuperType

Tier 2: Check Core Components

Tier 3: Not Found - Ask user for clarification.

For extension patterns, load: references/extending-core-components.md

Step 1.6: Core Component Extension Requirements

Required when extending with "hide", "remove", "add custom field", or "override" (these operations need Sling Resource Merger patterns to work correctly):

Load reference: references/extending-core-components.md

When extending Core Components:

• Use @Self @Via(type = ResourceSuperType.class) for model delegation
• Implement ComponentExporter interface
• Add resourceType to @Model annotation
• Use sling:hideResource in dialog for inherited tabs/fields

Note: If the parent component is a project component (not a Core Component), use direct Java class extension (extends ParentModel) instead of the delegation pattern. The @Self @Via(type = ResourceSuperType.class) pattern is only for Core Components. Load references/extending-core-components.md for the decision table.

Step 2: Gather Requirements

2.1 Parse Dialog Specification

Echo back EXACTLY what you understood before creating:

Dialog Specification Confirmed:
I will create exactly {N} fields:
| # | Field Label | Field Type | Property Name |
|---|-------------|------------|---------------|
| 1 | {label1}    | {type1}    | {name1}       |
No additional fields will be added.
Is this correct?

2.2 Mockup Image Handling

• Both mockup AND spec provided: Dialog spec takes precedence. Mockup for HTML/CSS only.
• Only mockup provided: Propose fields and ASK for confirmation.

2.3 Figma Design Input

Load: references/figma-design-rules.md

When user provides a Figma URL (figma.com/design/..., figma.com/make/..., or figma.com/board/...):

1. Parse the URL to extract fileKey and nodeId (see references/figma-design-rules.md Rule 1)

• Convert - to : in the node-id query parameter
• Use branchKey as fileKey for branch URLs

1. **Call **get_design_context via the plugin-figma-figma MCP server (see Rule 2):{ "server": "plugin-figma-figma", "toolName": "get_design_context", "arguments": { "nodeId": "<extracted-node-id>", "fileKey": "<extracted-file-key>", "clientLanguages": "html,css,javascript", "clientFrameworks": "htl" } }
2. Extract design tokens from the response — colors, fonts, sizes, spacing, layout (see Rules 3-4)
3. Use the Figma output for HTL structure, CSS styling, and JS behavior — NOT for dialog fields

Precedence when BOTH dialog spec AND Figma URL are provided:

• Dialog specification → determines dialog fields (absolute precedence, no hallucination)
• Figma design → determines HTML structure, CSS styling, JS behavior only

When ONLY Figma URL is provided (no dialog spec):

• Analyze the design and PROPOSE dialog fields to the user
• ASK for confirmation before proceeding

Figma response handling:

• The response is React+Tailwind — treat as a REFERENCE, not production code
• Convert JSX to semantic HTL with BEM classes (see Rule 5)
• Extract all CSS values to the component clientlib (see Rule 6)
• Create JS only if interactivity is implied (see Rule 7)
• Do not hardcode Figma temporary image URLs — they expire and will break in production (see Rule 8)