Build With Liferay

Liferay offers you an extensible platform for launching digital experiences: public websites, customer and partner portals, unified commerce storefronts, employee workplaces, and more. Almost every layer is composable and built to be expanded.

Building on Liferay keeps getting easier. The characteristics that make Liferay flexible for developers also make it ready for AI agents, such as the open source architecture, clear extension points, declarative artifacts, and APIs for everything (including your custom functionality). You no longer need to start with studying documentation and setting up boilerplate code, instead, just use an AI agent to do that for you.

This tutorial shows you how to get started building on Liferay by prompting. By the end you will have a working event registration experience, with its own data model, pages, registration workflow, and brand, running on a Liferay DXP instance on your machine.

Liferay Workspace

Even though AI agents can write code, custom experiences still deserve real engineering and lifecycle management: version control, review, repeatable deployment, and testing. A local environment allows you to manage all of these directly. The full platform runs on your dev machine, so you can experiment freely and throw away what does not work. All your iterations live in a git repository, giving you long term management and traceability. This tutorial uses this discipline: each layer is committed, so the agent's work is history you can review, revert, and share.

Liferay Workspace is a set of scripts, standard directory structures, and AI skills providing everything you need to do real engineering on top of Liferay DXP. And, most of all, it is a local playground for you to try anything alongside your agents.

AI Hub vs Workspace

A quick note: Liferay also offers additional AI-driven solutions for building experiences. AI Hub is a standalone product that empowers even your business users to create and automate on top of Liferay or any platform you choose.

When you use each of these solutions:

• Choose AI Hub when you need AI intelligence inside your solution. It allows you to use Liferay-created and managed agents. You can even create your own agents operated by business and developers alike. These agents work on live content, workflows, and data at runtime.

• Choose a local Workspace environment when you need to build and manage custom experiences that extend core Liferay functionality: custom data models, frontends, and logic, developed with your own editor and your own agent, all under version control.

Many users will find value in leveraging both solutions for different use cases. But this tutorial focuses on Liferay Workspace and extending functionality.

The Magic: Liferay Dev Skills Pack

Our AI developer skills pack is included on Liferay Workspace initialization (blade init). Open a Workspace directory in Claude Code (or other AI agent) and it already knows how Liferay works.

2 kinds of context ship in the pack:

Always-applied rules. Loaded into every session. These train the agent how to use the Workspace and Liferay DXP, such as version detection, project paths, tooling conventions, documentation sources.

On-demand skills. You do not invoke skills by name. You describe the outcome ("create an object", "build a page", "change the site colors") and Claude matches the request to a skill, which supplies Liferay-correct patterns and the pitfalls to avoid. Skills can be invoked directly by name if needed (/skills)

What You Will Build in this Workspace Tutorial

An event registration experience, in four Liferay-native layers:

1. A data model with two related Liferay Objects

2. Three pages composed from reusable fragments

3. Custom visuals: a style book, plus a shared header and footer

4. A functional registration approval workflow, verified end to end by the agent

Each layer is one prompt to Claude Code. You need no prior Liferay development or Claude Code experience. You need a machine that can run a local Liferay bundle and a terminal interface (or agent app) you are comfortable in.

Claude is also not the only option. Any local AI coding agent platform will be able to use our skills and follow this tutorial.

Let’s get going.

Setup

You need the following:

1. A machine with at least 8GB of RAM

2. Java 21 JDK

3. Blade CLI

4. Git version control

5. DXP license (Download a Free license)

6. Claude Code (or your AI agent of choice)

Create the workspace. With Blade installed, initialize a workspace on a version that ships the skills pack:

blade init -v dxp-2026.q1.9-lts dev-events cd dev-events

Make it a repository. Everything you build in this tutorial lives as files, so put them under version control before you change anything:

git init && git add . && git commit -m "Initialize workspace"

The workspace ships a .gitignore that keeps the server bundle and build output out of the repository; what remains is exactly what you author. This is the last git command you type in this tutorial. From here, Claude commits each verified layer for you.

Download the bundle. Run this command to Tomcat bundle into bundles/

blade server init

Copy your activation xml to deploy directory (based on your xml name and environment)

cp C:\Users\MyUser\Downloads\activation-2026-q1.xml .\bundles\deploy\

No need to start the server yet, Claude will handle that for you.

Launch. Open the workspace folder in your terminal and open in claude code:

cd dev-events && claude

Claude Code starts at the workspace root and picks up the pack automatically. Confirm it with a question:

What Liferay skills are available in this workspace?

Claude answers from the skill index. If it does, you are ready to build.

Recommendation: Let Claude drive Git. An agent that changes your project should leave a trail. In this tutorial every prompt ends by asking Claude to commit the verified result, so each layer becomes a checkpoint you can diff, review, or roll back. You do not need to write a commit yourself.

The Build: An Event Registration Experience

The scenario: your organization runs a conference, people sign up for the sessions, every signup starts out pending review (the event manager approves sign ups), and the experience carries your brand. Four layers, four prompts, each verified against the running server and committed to the repository.

Prompts can be copied as written. Outcomes are described for you to verify since agent output varies run to run, and different models may produce different results.

Notice what the prompts do not say. They do not name a specific Liferay concept, skill, or file; they describe the outcome in plain business language and let the skills do their magic. They also sometimes state what not to do, so the agent stays focused.

Layer 1: The Data Model

Here is our first prompt:

I'm planning our annual tech conference and I want to put together a site for it, showing what events are happening and letting people sign up for individual events.

Start with the information we need to store. For each event: a name, a description, when it starts and ends, where it is, and how many people we can fit. For everyone who signs up: their name, email, company, any dietary requirement picked from a set list. Create multiple sample events, with every signup belonging to one event.

I also want a way to see the current list of signups in the control panel.

Set that up, commit it, and show me it's working. I want to see an event and a signup saved.

Expected outcome: Claude creates and publishes two related Liferay Objects, one for events and one for signups, with a one-to-many relationship and picklists for the dietary requirement and the signup status. It then proves the model works by saving one event and one signup, captures the definitions into the workspace as files, and commits them.

Test it: If you login to your running Liferay DXP at http://localhost:8080 then you should be able to see the Signups and Events as dedicated Objects in the Control Panel.

Default Login:

1. User: test@liferay.com

2. PW: test

If any of this is not working after the single prompt, explain to the agent what needs to be fixed, and verify before continuing.

Layer 2: The Pages

With the data in place, build what visitors see:

Now create the pages people will actually see.

A home page that opens with something eye-catching about the conference and then shows the events coming up. A page listing every event with its date, where it is, and how many places are left. And a signup page with a form asking for everything we need, where the person picks which event they want.

Build the pieces so my team can rearrange them or reuse them on other pages later. Then commit and show me the pages working.

Expected outcome: Claude creates three pages, a home page with a banner and an upcoming events list, an events listing showing date, location, and remaining capacity, and a signup page with form data stored in the signup object. The page elements are re-usable fragments rather than hardcoded markup. The pages should be navigated with Liferay’s out of the box page navigation header.

Layer 3: The Brand

Now replace the out-of-the-box look:

The site still looks like the software it was built with. Give it a look of its own: deep navy with amber accents, and a bold, heavy typeface for the headings.

Every page should carry the same branded header with the conference name and the menu, and a footer with our contact details.

Expected outcome: Claude applies the navy and amber palette and the heavy heading typeface through a style book and site-level CSS, so the branding lands across every page at once instead of page by page. The header carrying the conference name and menu, and the footer carrying contact details, are applied site wide so new pages inherit them automatically.

Bonus: Ask to spawn a sub-agent to review the branding on your website of choice and return, then your main agent can use that information to apply that branding to your site. Using a sub-agent helps to manage the context window.

Layer 4: The Registration Flow

The last prompt makes the form real and uses Liferay’s Workflow Engine.

Now make the signup form actually work.

When someone fills it in, their details should be saved against the event they picked and start out as pending, and they should land on a dedicated thank-you page. Don't build anything for sending email, we'll connect our mailing tool later. However, this sign up should end up in the platform's workflow system for review and approval of sign up by the Admin user.

Then run through it yourself from start to finish and tell me what worked and what didn't, including the workflow approval.

Expected outcome: Claude wires the form to save each submission against the chosen event with a pending status and redirects the visitor to a “Thank You” page. The admin user can then approve submissions in the Liferay DXP out-of-the-box “My Workflow Tasks” app. The agent verifies the whole flow and reports what worked and what did not.

Ideally you should be able to submit as a guest user (no login) and then use the admin user to approve.

Again, if something is not working at this point or you want to change the experience, continue to prompt the agent to refine your site.

What Is Next

Now that you have a functional event registration site, feel free to continue prompting. Move elements around, create more pages and functionality. There is so much you can build, iterate, and ship to your customers quickly with AI agents and Liferay.

Updating Skills

The skills pack is continuing to evolve and expand. If you have an existing workspace, run ./gradlew updateWorkspace to get the latest version of the skills files (Requires Blade 8.0.2 or later).

Please share your feedback over at Liferay Discuss. Your feedback helps decide which skills we build next.