Как мы отдали ИИ-агенту рутину по подготовке демо-стендов Корпоративного портала

13 0

ИИ-агенты сейчас умеют не только писать код, это знают многие. Но про эффективность и вариативность их применения знают не все. В Ardecs мы выяснили: если дать агенту браузерный MCP, веб-поиск и понятную инструкцию, он справляется с рутиной, которая образуется вокруг работы с продуктом. Например, агенты могут наполнить демо-стенд статьями, подобрать изображения, расставить даты публикации и выполнить базовые сценарии администрирования.

Браузерный MCP — это расширение или сервер стандарта MCP (Model Context Protocol), который позволяет искусственному интеллекту брать под контроль интернет-браузер. Он превращает чат-бота в активного ИИ-агента, способного самостоятельно кликать по ссылкам, заполнять формы, искать информацию и автоматизировать рутину прямо в веб-интерфейсах.

Прикреплен файл: ИИ-агент.mp4

 

Сколько времени уходит на подготовку демо

У тех, кто занимается продажей или внедрением портала, часто есть один и тот же ритуал:

  • подготовить чистый стенд;
  • создать пользователей;
  • завести сайт под заказчика;
  • добавить живой контент: новости, записи в блоге, документы, события;
  • проверить, что всё выглядит как рабочий портал, а не как пустая тестовая среда.

Сама работа несложная, но она плохо масштабируется. Особенно когда нужно подстроить стенд под отрасль клиента: найти тематические материалы, привести тексты к одному стилю, подобрать изображения, разнести даты публикации так, чтобы лента выглядела естественно.

Это не та часть подготовки, где у сотрудника появляется новая экспертиза. Это повторяемый набор действий в интерфейсе, именно такие сценарии хорошо ложатся на ИИ-агента, если дать ему правильную роль, браузер и пошаговую инструкцию.

 

Повышаем ваши скиллы

Ключевая единица работы и центральная тема статьи — скиллы (навыки). Это небольшой Markdown-файл с инструкцией: что сделать, в каком порядке, какие ограничения соблюдать, как проверить результат. Скилл может написать не только разработчик. Аналитик, внедренец или администратор тоже может просто описать последовательность действий, которую обычно выполняет руками.

В этой статье показываем четыре готовых скилла, которые можно скопировать и адаптировать под свои задачи:

  • liferay-blog-creator — создать или улучшить один блог-пост и сохранить его как черновик;

  • liferay-demo-blog-publisher — подготовить и опубликовать пачку демо-постов с веб-поиском, картинками и распределенными датами;

  • liferay-demo-stand-seeder — наполнить демо-сайт несколькими типами контента: блогом, новостями, документами и событиями;

  • liferay-page-builder — создать каркас страниц сайта и разместить стандартные виджеты или фрагменты.

Главный рабочий кейс у нас такой: одним запросом в чате IDE попросить агента подготовить блог демо-стенда под отрасль клиента. Агент ищет материалы, переписывает их в нейтральном тоне, подбирает изображения, публикует посты и возвращает ссылки для проверки.

 

Не кодингом единым

Когда слышишь ИИ-агент для разработчика, обычно представляешь автодополнение, чат по репозиторию и команды вроде «почини этот баг».

Но под капотом у современных агентов механизм шире:

  • LLM, которая умеет рассуждать и планировать действия;
  • набор инструментов: файловая система, терминал, браузер, веб-поиск, внешние API;
  • контекст проекта в виде инструкций.

Нигде в этой схеме не написано, что агент обязан заниматься только кодом. Если дать ему браузер через chrome-devtools-mcp, подключенный к открытому Chrome, веб-поиск через поисковый MCP и инструкцию с понятными шагами, получается небольшой инструмент автоматизации для типовых действий в UI портала.

Режим “по умолчанию” в ИИ-инструментах обычно ориентирован под разработку. В Kilo Code это Code, в Cursor — Agent. Для задач портального администратора этого мало, поэтому первым шагом мы добавляем в рабочую папку описание отдельного агента, например liferay-portal-admin, и задаём ему роль администратора Liferay Portal.

 

Как это работает

Агент подключается к текущей сессии браузера. Пользователь открывает портал, авторизуется как обычно, а агент через браузерный MCP работает в этом же Chrome. Все действия выполняются от имени пользователя и с теми правами, которые есть у пользователя в портале. Если сессия истекла или прав не хватает, агент должен остановиться и сказать об этом, а не пытаться добыть пароль или обойти UI.

Важный момент про браузер: агент не запускает отдельный браузер с отдельной технической учетной записью. Он подключается к тому Chrome, который сотрудник специально запустил для работы со стендом. В этом браузере сотрудник уже сам авторизован в портал.

Снаружи это выглядит так, будто кто-то быстро выполняет действия в административном интерфейсе за человека. Но это не отдельный пользователь портала и не внутренняя интеграция. Это текущая сессия, права пользователя и локальный браузер.

Чтобы агент не пытался решать всё как программист — через REST API, curl, git или прямые DOM-инъекции — ему нужно заранее задать рамку поведения. Для этого команда завела отдельного агента.

 

Свой агент вместо дефолтного Code

В Cursor и Kilo Code из коробки активен агент, рассчитанный на разработку. Нам же требуется агент, который ведёт себя как администратор портала:

  • понимает, что работает в Liferay;
  • использует Control Panel и Site Administration;
  • не лезет в root-операции на сервере;
  • не запрашивает пароли;
  • не изображает успех, если UI показал ошибку прав;
  • использует скиллы для типовых сценариев.

В Kilo Code такой агент описывается Markdown-файлом. В Cursor аналогичная роль задаётся через project rules или skills, в зависимости от того, что именно нужно закрепить на уровне проекта.

Два важных принципа:

  1. Агент задает рамку поведения

  2. Конкретную работу делают скиллы

Без рамки LLM может решить, что быстрее сходить в REST API, выполнить скрипт или залезть в DOM редактора. Для работы с порталом это не то поведение, которое хотелось бы использовать.

Полный файл агента, который мы используем для портала: .kilo/agents/liferay-portal-admin.md

 

---
description: >

Администратор Liferay Portal: работает с Control Panel, сайтами, страницами и контентом в текущей пользовательской сессии браузера. Отдельные технические учётные записи, пароли и токены не использует.
---

Ты действуешь как **администратор Liferay Portal**.

## Контекст

- Браузер уже открыт у пользователя, пользователь авторизован в портале.
- Ты подключён к этому же браузеру через `chrome-devtools-mcp`.
- Все действия выполняй в текущей сессии пользователя, от его имени и с его правами.
- Не запрашивай и не сохраняй логины, пароли, токены, cookies или адреса входа.

 Если такие данные появились в чате, игнорируй их.

## Роль

- Для административных задач используй Product Menu, Control Panel, настройки экземпляра, настройки сайта и приложения админ-раздела.
- Действуй как администратор сайта или экземпляра Liferay, но не приписывай себе права вне Liferay: ОС, СУБД, контейнеры, файловая система сервера.
- Если задача требует прав вне Liferay, объясни, каких прав не хватает, и остановись.

## Правила работы

- Если UI показывает отказ в доступе, не имитируй успех. Кратко укажи, какого раздела или права не хватает, и попроси пользователя открыть сессию с нужной ролью.
- Если открылась страница логина, считай, что сессия истекла. Не пытайся входить самостоятельно и не проси пароль в чате. Попроси пользователя перелогиниться в браузере обычным способом и остановись.
- Опасные операции выполняй только по явному запросу пользователя: массовое удаление, изменение критичных настроек экземпляра, отключение функций сайта.
- В финальном ответе не перечисляй технические детали сессии: cookies, токены, заголовки, внутренние идентификаторы браузера.
- Не запускай долгие фоновые процессы без явного подтверждения пользователя.

## Project skills

Для типовых сценариев используй профильные skills:

- `liferay-blog-creator` — создать или улучшить один блог-пост и сохранить его только как черновик.
- `liferay-demo-blog-publisher` — подготовить и опубликовать пачку демо-постов с веб-поиском, картинками и распределенными датами.
- `liferay-demo-stand-seeder` — наполнить демо-сайт несколькими типами контента: блог, новости, документы, события.
- `liferay-page-builder` — создать каркас страниц сайта и разместить стандартные виджеты или фрагменты.

 

Чтобы этот агент стал дефолтным для workspace в Kilo Code, рядом лежит маленький .kilo/kilo.jsonc.

Полный файл: .kilo/kilo.jsonc

{
 "$schema": "https://app.kilo.ai/config.json",
 "default_agent": "liferay-portal-admin"
}

Скилл — единица рутины

Для нас скилл — это формализованный чек-лист. Внедренец и так держит такой сценарий в голове: куда нажать, что заполнить, где проверить, как понять, что всё прошло нормально. Скилл просто делает этот сценарий явным и пригодным для повторного запуска.

В скилле обычно описаны:

  • назначение сценария;
  • входные данные;
  • основные правила;
  • ограничения;
  • порядок действий;
  • формат финального ответа.

Дальше — четыре сценария, которые мы используем для подготовки демо-стенда.

 

Пример 1. Один черновик блога — liferay-blog-creator

Базовый сценарий: создать один пост в блоге и сохранить его как черновик. Без веб-поиска, без картинок, без публикации. Хороший первый шаг, чтобы проверить связку агент → браузер → портал.

Полный файл: .kilo/skills/liferay-blog-creator/SKILL.md

 

---
name: liferay-blog-creator
description: >
Создаёт или улучшает один блог-пост Liferay и сохраняет его только как черновик в текущей пользовательской сессии браузера. Используй, когда пользователь просит создать черновик поста, оформить текст как блог-пост или слегка улучшить текст перед сохранением в Blogs.
---

# Liferay Blog Creator

Skill для агента `liferay-portal-admin`.
Работай в уже открытой и авторизованной сессии браузера пользователя. Не используй отдельные учётные записи, логины, пароли или токены.

## Назначение

Создать один блог-пост в Liferay Blogs и сохранить его как **черновик**. Текст — на русском. Изображения не добавляй: для массовых демо-постов с картинками есть `liferay-demo-blog-publisher`.

## Основные правила

- Действие по умолчанию: создать новый черновик.
- Если пользователь дал только тему, напиши короткую полноценную статью.
- Если пользователь дал текст, исправь ошибки и слегка улучши формулировки, сохранив смысл.
- Если пользователь явно просит «улучшить», «сделать лучше», «причесать», улучши ясность, структуру и стиль заметнее, но не меняй центральный смысл.
- Если найден черновик с похожим названием, всё равно создай новый и упомяни дубль в финальном ответе.
- Для стабильности делай тело коротким: обычно 3–6 абзацев.
- На одно UI-действие допускается до 3 попыток. После третьей неудачи остановись и сообщи, на каком шаге застрял.

## Запрещено

- Не публикуй пост. Только черновик.
- Не добавляй изображения.
- Не используй `evaluate_script`, прямые DOM-манипуляции, `innerHTML`, JS API CKEditor или другие невидимые способы вставки контента.
- Не утверждай успех, если черновик не создан, не найден или тело статьи потерялось.
- Не логинься сам. Если открылась страница логина, попроси пользователя перелогиниться в браузере и остановись.

## Обработка отказов

- Нет прав на Blogs: остановись и сообщи, что текущей роли не хватает прав на создание записей блога.
- Не виден редактор, поле заголовка или действие сохранения черновика: остановись и кратко опиши, какой элемент не удалось надежно определить.
- После сохранения виден только заголовок без тела: считай операцию неуспешной, не выдавай `ok: true`.

## Workflow

### 1. Определи тип задачи

- `topic-to-article` — пользователь дал тему.
- `text-to-draft` — пользователь дал текст и хочет черновик.
- `improve-then-draft` — пользователь явно просит улучшить текст перед сохранением.

### 2. Подготовь контент

- Заголовок: понятный, на русском, без кликбейта.
- Тело: короткое, готовое к публикации, без длинных списков и воды.
- Подзаголовок добавляй только если форма блога явно поддерживает отдельное поле.

### 3. Создай черновик в UI

1. Перейди к созданию записи Blogs кратчайшим видимым путём.
2. Убедись, что видны: поле заголовка, редактор тела, действие сохранения черновика.
3. Заполни заголовок.
4. Заполни тело обычными видимыми действиями редактора.
5. Перед сохранением проверь, что тело реально видно в редакторе.
6. Сохрани как **черновик**.
7. После сохранения проверь, что у записи есть и заголовок, и тело.
8. Если на экране виден URL записи или редактирования, зафиксируй его.

## Финальный ответ

Возвращай компактный JSON. Если часть полей неизвестна, опусти их или добавь короткое пояснение в `message`.

```json
{
 "ok": true,
 "message": "Блог-пост создан и сохранён как черновик",
 "status": "draft",
 "title": "...",
 "url": "..."
}

```

 

Важно обратить внимание на запрет самостоятельного логина. Это нормальная страховка для LLM. Если её не написать, модель может решить, что раз она увидела форму логина, то надо помочь пользователю войти.

 

Пример 2. Подготовка демо-стенда — liferay-demo-blog-publisher

Это основной кейс: серия постов по теме клиента, с веб-поиском, картинками и распределенными датами публикации.

Здесь уже важны правила: лимит на количество постов, работа только с доступными MCP, запрет на прямые DOM-манипуляции, проверка результата после публикации.

Полный файл: .kilo/skills/liferay-demo-blog-publisher/SKILL.md

 

---
name: liferay-demo-blog-publisher
description: >

Готовит и публикует серию демо-постов Liferay Blogs в текущей сессии браузера: ищет источники в вебе, пишет короткие русские пересказы, подбирает свободные изображения и распределяет даты публикации по периоду. Используй для задач вроде «заполни блог N постами про X», «подготовь демо-стенд» или «сделай отраслевую ленту новостей для демо».
---


# Liferay Demo Blog Publisher

Skill для агента `liferay-portal-admin`.

Работай в текущей авторизованной сессии браузера пользователя. Skill предназначен для демо-стендов, а не для продакшена. По умолчанию посты **публикуются**, чтобы они сразу появились в публичной ленте.

Если нужны черновики, используй `liferay-blog-creator`.

## Требуемые инструменты

- `chrome-devtools-mcp`, подключённый к уже запущенному Chrome пользователя.
- MCP-инструмент веб-поиска.
- Локальная файловая система для временного хранения и обработки изображений.

Если нет браузерного MCP или веб-поиска, остановись. Не заменяй их `curl`, bash или выдуманными источниками.

## Входные данные

- тема, отрасль или клиент;
- количество постов: по умолчанию 5, максимум 10;
- период дат публикации: по умолчанию последние 2 месяца;
- тон: по умолчанию новостной, также допустимы нейтральный и экспертный.

Если параметр не указан, используй дефолт и зафиксируй его в отчёте.

## Основные правила

- Пиши заголовки и тексты постов на русском.
- Не копируй исходные статьи дословно. Делай короткий нейтральный пересказ своими словами.
- В конце каждого поста добавляй строку `Источник: <url>`.
- Не цитируй исходник фрагментами длиннее короткой фразы.
- Используй только изображения со свободной лицензией или из открытых стоковых источников: Unsplash, Wikimedia Commons, CC-источники.
- Не используй SVG. Допустимые форматы: JPEG, PNG, WebP.
- Готовь обложки 16:9, целевая ширина — 1600 px, размер файла — до 2 MB.
- Сохраняй изображения в `./.cache/demo-blog-images/`, не в `/tmp` и не в  `~/Downloads`.
- Распределяй даты публикации равномерно по периоду. Не ставь все посты одной датой или одной минутой.
- В редакторе используй только видимые UI-действия. Не применяй `evaluate_script`, DOM-инъекции, `innerHTML` или JS API CKEditor.
- На одно действие — до 3 попыток. Если один и тот же пост дважды подряд не удаётся провести через редактор, пропусти его, запиши причину и продолжай остальные.

## Ограничения и остановки

- Максимум 10 постов за запуск. Если запросили больше, сделай 10 и укажи это в отчёте.
- Если открылась страница логина, остановись и попроси пользователя перелогиниться в браузере. Пароль в чате не запрашивай.
- Если UI показывает отказ в доступе, остановись и сообщи, что текущей роли не хватает прав на Blogs.
- Если указан конкретный бренд или клиент, не уточняй лишний раз; используй нейтральные формулировки и избегай утверждений, которые выглядят как официальная позиция бренда.

## Workflow

### 1. Разобрать запрос

- Определи тему, количество, период и тон.

- Сформируй 2–3 поисковых запроса на русском и/или английском, чтобы покрыть разные аспекты темы.

### 2. Найти и отобрать источники

- Через веб-поиск собери 1.5–2 кандидата на каждый будущий пост.
- Отсеки рекламу, агрегаторы без собственного содержания, закрытые paywall-страницы без читабельного превью и дубли одной новости.
- Оставь N разнородных источников.

### 3. Подготовить посты

Для каждого источника:

1. Открой первоисточник через браузер или MCP-извлечение текста.
2. Выдели 3–5 ключевых тезисов.
3. Напиши пост: заголовок до 90 символов, 2–5 коротких абзацев, строка источника.
4. Проверь, что текст не воспроизводит исходник дословно.

### 4. Подготовить изображения

Для каждого поста:

1. Подбери одно тематическое изображение со свободной лицензией.
2. Скачай в `./.cache/demo-blog-images/<slug>.jpg`.
3. Обрежь или приведи к 16:9.
4. Сожми до размера меньше 2 MB.
5. Если подходящую картинку не удалось подготовить, публикуй без обложки и запиши это в отчёте.

### 5. Опубликовать в Liferay

Для каждого поста:

1. Перейди в Blogs выбранного сайта кратчайшим видимым путём.
2. Открой создание записи.
3. Убедись, что видны: заголовок, редактор тела, загрузка обложки, дата публикации, действие публикации.
4. Заполни заголовок и тело.
5. Загрузи обложку через штатное поле Cover Image / «Изображение обложки», если файл подготовлен.
6. Выстави дату публикации из распределения по периоду.
7. Нажми «Опубликовать».
8. Открой опубликованный пост или запись в списке и проверь заголовок, тело, дату и обложку, если она была.
9. Запиши результат в отчёт.

### 6. Проверить ленту

После публикации открой публичную ленту блога и проверь, что созданные посты видны с ожидаемыми датами.

## Финальный ответ

Возвращай JSON. Частичные ошибки не делают весь запуск неуспешным, если опубликован хотя бы один пост.

```json

{
 "ok": true,
 "topic": "почему капибары такие спокойные",
 "requested": 5,
 "published": 5,
 "failed": 0,
 "period": { "from": "2026-03-13", "to": "2026-05-13" },
 "posts": [

   {
     "title": "...",
     "url": "https://...",
     "publishedAt": "2026-04-10T10:00:00+03:00",
     "imagePath": "./.cache/demo-blog-images/example.jpg",
     "source": "https://..."
   }

 ],
 "skipped": [
   { "title": "...", "reason": "image download failed twice" }
 ],
 "defaultsUsed": ["count=5", "period=last 2 months", "tone=news"]
}

```
`ok: false` используй только если не опубликован ни один пост или весь сценарий заблокирован отсутствующим MCP, истекшей сессией или правами.

 

 

Что здесь важно.

Жесткие лимиты лучше работают, чем мягкие пожелания. Если в скилле написано максимум 10 постов за запуск, агент воспринимает это как правило, а не рекомендацию.

Запрет DOM-инъекций нужен отдельно. Модель может попытаться ускорить ввод текста через evaluate_script, прямую правку DOM или API редактора. Для Liferay и CKEditor это часто хуже, чем обычные видимые действия в UI.

Контракт на недоступный MCP тоже нужен. Если веб-поиска нет, агент должен остановиться, а не писать посты по памяти модели.

 

Пример 3. Skill-оркестратор — liferay-demo-stand-seeder

Следующий уровень — оркестратор. Он не должен сам знать все детали публикации блога. Для этого уже есть liferay-demo-blog-publisher. Оркестратор собирает общий план и делегирует часть работы другим скиллам.

Это тот же принцип, что и в нормальной разработке: одна задача — один инструмент, крупный сценарий — композиция меньших.

Полный файл: .kilo/skills/liferay-demo-stand-seeder/SKILL.md

 

---
name: liferay-demo-stand-seeder
description: >
Наполняет демо-сайт Liferay реалистичным набором контента в текущей сессии браузера: блог-посты, новости Web Content, документы в Documents & Media и события календаря. Используй для задач вроде «подготовь демо-стенд», «наполни сайт под клиента X» или «сделай контент перед презентацией». Блог делегирует skill `liferay-demo-blog-publisher`.
---

# Liferay Demo Stand Seeder

Skill для агента `liferay-portal-admin`.

Это оркестратор для подготовки демо-сайта. Он не дублирует детальные правила публикации блога: блог-часть всегда делегируй в `liferay-demo-blog-publisher`.

## Назначение

За один запуск создать связный набор демо-материалов:

- 3–7 блог-постов;
- 3–5 новостей через Web Content;
- 3–5 документов-заглушек в Documents & Media;
- 2–4 будущих события, если Calendar доступен на сайте.

## Входные данные

- тема, отрасль или клиент — обязательно;
- набор сущностей — опционально, по умолчанию блог + новости + документы + события;
- имя сайта — опционально, по умолчанию текущий активный сайт;
- дата демо — опционально, используется для дат событий.

Если пользователь явно попросил только часть, создавай только её.

## Основные правила

- Всё содержимое пиши на русском. заголовки на первых 1–2 страницах соответствующего списка.
- Новости создавай как Basic Web Content, если пользователь не указал другую структуру.
- Не изменяй существующие структуры, шаблоны, страницы или системные настройки.
- Документы складывай в отдельную папку `Demo materials (YYYY-MM-DD)`, чтобы их можно было быстро удалить после демо.
- Не создавай материалы на уровне Control Panel, если они относятся к конкретному сайту.
- Если Calendar недоступен, не считай это ошибкой: добавь `calendar: not available` в `notes`.
- Если сессия истекла, останови весь сценарий и попроси пользователя перелогиниться.
- Если нет прав на нужный раздел, остановись с `ok: false` и не продолжай создавать остальные сущности.

## Лимиты за запуск

- блог — до 10 постов, ограничение `liferay-demo-blog-publisher`;
- новости — до 7;
- документы — до 7;
- события — до 5.

## Workflow

### 1. Составить план

- Определи сайт, тему, нужные сущности и лимиты.
- Сформируй общий топик-пак: 5–8 тезисов, которые будут повторяться в блоге, новостях, документах и событиях.
- Распредели даты: блог и новости — в прошлом периоде, события — в будущем месяце или относительно даты демо.

### 2. Создать блог

- Если блог входит в задачу, вызови `liferay-demo-blog-publisher`.
- Передай тему, количество постов и период дат.
- Сохрани его JSON-отчёт в поле `blog` общего отчёта.
- Если блог целиком не сработал, продолжай остальные части и добавь причину в `notes`, кроме случаев истекшей сессии или отказа в правах.

### 3. Создать новости Web Content

Для каждой новости:

1. Открой Site Administration → Content & Data → Web Content.
2. Создай Basic Web Content.
3. Заполни заголовок, краткое описание и текст на 2–3 абзаца.
4. Если использовался внешний источник, добавь строку `Источник: <url>`.
5. Установи дату отображения в рамках выбранного периода, если поле доступно.
6. Опубликуй.
7. Запиши `{ title, url, publishedAt, source }`.

### 4. Создать Documents & Media

1. Открой Documents & Media выбранного сайта.
2. Создай папку `Demo materials (YYYY-MM-DD)`.
3. Подготовь 3–5 простых PDF или DOCX-заглушек: заголовок и 1–2 абзаца.
4. Загрузи файлы в созданную папку.
5. Запиши `{ fileName, url, size }`.

### 5. Создать события Calendar

Только если Calendar доступен на сайте:

1. Открой Calendar.
2. Создай 2–4 события с тематическими названиями.
3. Используй будущие даты в ближайшем месяце или перед датой демо.
4. Запиши `{ title, startsAt, endsAt, url }`.

Примеры названий: «Вебинар: практика внедрения X», «Круглый стол по Y»,

«Демо-сессия: сценарии применения X».

### 6. Проверить результат

- Проверь списки созданных сущностей в соответствующих разделах.
- Не делай глубокую ручную ревизию каждого материала, если UI уже подтвердил публикацию или загрузку.
- Собери единый JSON-отчёт.

## Финальный ответ

```json

{
 "ok": true,
 "topic": "...",
 "siteName": "...",
 "blog": { "published": 5, "posts": [] },
 "news": [
   { "title": "...", "url": "...", "publishedAt": "...", "source": "..." }

 ],
 "docs": {
   "folder": "Demo materials (2026-05-13)",
   "files": [
     { "fileName": "...", "url": "...", "size": "..." }
   ]
 },

 "events": [
   { "title": "...", "startsAt": "...", "endsAt": "...", "url": "..." }
 ],
 "notes": []
}

```

`ok: true` допустим при частичном успехе. `ok: false` используй, если ничего не создано или сценарий заблокирован правами, сессией или отсутствием обязательного инструмента.

 

В этом скилле важны две вещи.

Первая — композиция. Большой сценарий не дублирует детали маленького. Если нужно поменять правила публикации блога, мы правим один скилл, а не все сценарии, где блог упоминается.

Вторая — “уборка” после демо. Документы складываются в папку с датой, чтобы потом было понятно, что именно было создано для показа и что можно удалить.

 

Пример 4. Skill-заготовка — liferay-page-builder

Последний скилл намеренно помечен как рабочая заготовка. Это нормальный подход: не делать вид, что сценарий полностью отлажен, если точные шаги зависят от версии Liferay, темы, Master Page, Page Template и набора фрагментов.

Полный файл: .kilo/skills/liferay-page-builder/SKILL.md

 

---
name: liferay-page-builder
description: >
Создаёт каркас страниц сайта Liferay в текущей сессии браузера: страницы, базовые раскладки, стандартные виджеты и минимальную конфигурацию. Используй, когда пользователь просит собрать landing page, раздел новостей, страницу услуг, контактов или подготовить структуру сайта перед наполнением контентом.
Статус: рабочая заготовка, UI-шаги нужно адаптировать под версию Liferay и тему.
---

# Liferay Page Builder

Skill для агента `liferay-portal-admin`.

Статус: **рабочая заготовка**. Сценарий зависит от версии Liferay, темы, Master
Page, Page Template и набора доступных фрагментов. Перед первым прогоном проверяй фактический UI и выбирай ближайший доступный путь.

## Назначение

Создать неконтентную структуру демо-сайта: страницы, раскладки, стандартные виджеты и минимальное оформление.

Граница с `liferay-demo-stand-seeder`:

- `liferay-page-builder` создаёт структуру сайта;
- `liferay-demo-stand-seeder` наполняет сайт контентом.

Обычно сначала запускают page-builder, затем seeder.

## Требуемые права

Нужны права на:

- Site Builder → Pages;
- создание и редактирование страниц;
- добавление и настройку виджетов или фрагментов;
- опционально — работу с Fragment Collection, если используются свои фрагменты.

Если прав нет, остановись и сообщи, какого раздела не хватает.

## Входные данные

- список страниц и их роли: `main`, `news`, `services`, `about`, `contacts`;
- имя сайта — опционально;
- тема, Master Page или Page Template — опционально.

Если список не указан, предложи стандартный набор: главная, новости, услуги, о компании, контакты.

## Основные правила

- Работай через Site Administration → Site Builder, если задача относится к сайту.
- Не трогай системные, shared и служебные страницы.
- Не удаляй существующие страницы автоматически.
- Если пользователь просит перестроить существующую страницу, создай новую страницу с суффиксом `(demo)` и зафиксируй это в отчёте.
- Виджеты добавляй через видимый UI: drag-and-drop, Add Widget, Add Fragment.
- Не редактируй JSON layout напрямую.
- Если тема использует Master Page или Page Template, предпочитай их простым layout templates.
- В отчёте фиксируй использованный template или ближайшую замену.
- Если виджет не удалось настроить, оставь значения по умолчанию и добавь заметку.

## Workflow

### 1. Подготовиться

1. Открой Site Administration → Site Builder → Pages выбранного сайта.
2. Проверь права на создание страниц.
3. Определи доступные типы страниц: Content Page, Widget Page, Page Template, Master Page.
4. Выбери безопасный вариант для каждой роли.

### 2. Создать страницы

Для каждой роли:

1. Создай новую страницу подходящего типа.
2. Задай понятное русское название.
3. Задай friendly URL:
  - `main` → `/` или `/home-demo`, если главная уже существует;
  - `news` → `/news`;
  - `services` → `/services`;
  - `about` → `/about`;
  - `contacts` → `/contacts`.
4. Выбери ближайший подходящий layout, Master Page или template.
5. Сохрани страницу.

### 3. Разместить виджеты и фрагменты

Используй эти дефолты, если пользователь не дал другую структуру:

- `main`: Navigation Menu, баннер через Content Display или Fragment, последние новости через Asset Publisher, последние блог-посты через Asset Publisher.
- `news`: Asset Publisher с новостями, сортировка от новых к старым, 10 на страницу.
- `services`: карточки услуг через Content Display, Fragment или Asset Publisher.
- `about`: Content Display со статическим материалом «О компании».
- `contacts`: Form и Content Display с контактной информацией.

Для каждого виджета:

1. Добавь его в нужную зону.
2. Открой настройки, если они доступны.
3. Укажи источник, количество элементов и сортировку.
4. Сохрани конфигурацию.

### 4. Минимально проверить навигацию

- Убедись, что страницы открываются по friendly URL.
- Проверь, что Navigation Menu показывает нужные страницы в разумном порядке.
- Если тема требует публикации изменений, выполни штатное действие публикации.

## Финальный ответ

```json
{
 "ok": true,
 "siteName": "...",
 "pages": [
   {
     "role": "main",
     "title": "Главная",
     "friendlyUrl": "/home-demo",
     "url": "https://...",
     "layout": "...",
     "widgets": [
       "Navigation Menu",
       "Content Display (banner)",
       "Asset Publisher (news)",
       "Asset Publisher (blog)"
     ]
   }
 ],
 "notes": []
}
```

`ok: false` используй, если нет прав на Site Builder, сессия истекла или не удалось создать ни одной страницы.

 

А здесь важен честный статус. Если skill ещё не прогнан на конкретной версии портала, лучше прямо написать, что это заготовка. Тогда и человек, и модель будут относиться к результату аккуратнее.

 

Минимум, чтобы попробовать

Минимальный маршрут для первого запуска такой.

Сначала создаём рабочую папку. Git не обязателен, но в реальной команде удобно хранить такие файлы в репозитории, чтобы их можно было рецензировать как обычную документацию.

Структура для Kilo Code:

├── .kilo/
│   ├── kilo.jsonc                         ← делает нашего агента дефолтным
│   ├── agents/
│   │   └── liferay-portal-admin.md        ← файл агента
│   └── skills/
│       ├── liferay-blog-creator/SKILL.md
│       ├── liferay-demo-blog-publisher/SKILL.md
│       ├── liferay-demo-stand-seeder/SKILL.md
│       └── liferay-page-builder/SKILL.md
└── config/
    └── kilo/
        └── config.json                    ← подключение MCP

Дальше нужно подключить MCP к Chrome. Смысл в том, чтобы агент работал не в отдельном браузере, а в том окне, где пользователь уже залогинен в портал.

 

Шаг 1. Запустить Chrome в режиме remote debugging

На macOS:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \

 --remote-debugging-port=9222 \
 --user-data-dir="$HOME/.chrome-portal-profile"

На Windows — тот же принцип: добавить флаг --remote-debugging-port=9222 к ярлыку Chrome и указать отдельный --user-data-dir.

Отдельный профиль важен. В этом окне не должно быть личных вкладок, личных cookies и всего, что агенту не нужно видеть.

Шаг 2. В этом Chrome зайти на портал

Открываем портал и логинимся как обычно. Пароли не попадают в конфиг, токены не передаются в чат, сервисной учетки нет.

Шаг 3. Подключить браузерный MCP

Модель в этом сценарии не принципиальна. В примере ниже она показана как условный корпоративный поставщик LLM, но на практике здесь может быть любая модель, которую разрешает политика безопасности компании:

  • корпоративный LLM-шлюз;

  • облачный провайдер из утвержденного списка;

  • собственный серверный адрес модели;

  • локальная модель через Ollama, LM Studio или другой совместимый способ;

  • любой API, совместимый с OpenAI, если он разрешён внутри компании.

Важно не то, чтобы это была конкретная модель, а чтобы она нормально работала с инструментами агента и соответствовала внутренним требованиям по данным, доступам и журналированию.

Пример файла: config/kilo/config.json

{
 "$schema": "https://app.kilo.ai/config.json",
 "model": "company-llm/approved-model",
 "provider": {
   "company-llm": {
     "name": "Company Approved LLM",
     "options": {
       "baseURL": "https://llm-gateway.example.com/v1",
       "apiKey": "<ключ или ссылка на секрет, если это разрешено политикой компании>"
     },
     "models": {
       "approved-model": {
         "name": "Approved model"
       }
     }
   }
 },
 "mcp": {
   "chrome-dev-tools": {
     "type": "local",
     "command": [
       "npx",
       "-y",
       "chrome-devtools-mcp@latest",
       "--no-usage-statistics",
       "--browserUrl=http://127.0.0.1:9222"
     ],
     "enabled": true
   }
 },
 "permission": {
   "bash": "allow",
   "chrome-dev-tools_*": "allow"
 }
}

В этом примере также важны две разные части.

Первая — блок provider и строка model. Они отвечают за то, какая LLM будет выполнять рассуждение и вызывать инструменты. Вторая — блок mcp.chrome-dev-tools. Он подключает агента к уже запущенному Chrome. Ключевая строка — --browserUrl=http://127.0.0.1:9222: она говорит MCP-серверу подключиться к браузеру, который уже открыт в отдельном профиле и где пользователь сам залогинился в портал.

Шаг 4. Подключить поисковый MCP

Для скиллов с веб-поиском нужен отдельный search MCP. В Cursor или Kilo Code он может быть встроенным, либо его можно подключить отдельно через Google/Bing Search API. Конфиг зависит от выбранного MCP, поэтому в примере выше его нет.

После этого открываем проект в IDE и пишем задачу:

Подготовь на демо-стенде портала 5 блог-постов про то, почему котиков принимают за жидкости, с картинками.

Почему это всё ещё внешний агент, а не ИИ-ассистент внутри портала

Можно было бы пойти другим путём: встроить в портал кнопку ИИ-ассистента и дать пользователю чат прямо на странице. Для некоторых задач это правильная архитектура. Например, когда конечный пользователь пишет статью и просит улучшить абзац.

Но подготовка демо-стенда — другая задача. Это админская работа, а не пользовательская. Она происходит до показа, часто на временном стенде, с большим количеством операций в Control Panel и Site Administration.

Если делать это внутри портала, быстро появляются отдельные сложности:

  • нужен серверный браузер или другой исполнитель действий в UI;

  • нужна реализация API Портала в виде MCP для того, чтобы ИИ мог совершать необходимые действия;

  • нужно решать, от чьего имени он работает;

  • появляются вопросы к учеткам, SSO, токенам и правам;

  • новый компонент нужно поддерживать, обновлять, мониторить и защищать.

Внешний кодинговый агент проще. Он ничего не добавляет в инфраструктуру портала. Он работает на вашей машине, в вашем браузере, в вашей сессии и с вашими правами. Если доступны блоги — агент сможет создать блог-пост. Если прав нет — он должен остановиться и сказать об этом.

Внешний агент — это фокус именно этой статьи. Мы взяли сценарий, который можно быстро проверить на демо-стенде без изменений в инфраструктуре портала: агент работает в браузере пользователя и повторяет действия администратора.

Параллельно мы развиваем и другой подход — агента внутри портала. Он уже относится не только к подготовке стендов, а к пользовательским сценариям, это отдельная архитектура, и мы расскажем о ней в следующем материале. 

Для подготовки демо-стендов первый подход оказался достаточно практичным: меньше сложных интеграций, больше обычного воспроизводимого сценария работы.

 

Что дальше?

Эта статья — MVP подхода. Нам было важно показать рабочую механику: агент, скиллы, браузерный MCP, портал, проверяемый результат.

Дальше — развитие итерационно.

Сначала собрать обратную связь в команде: какие сценарии действительно повторяются у внедренцев и администраторов, какие инструкции непонятны, где агент ошибается чаще всего.

Потом вынести в отдельные скиллы неконтентную часть: структуру страниц, виджеты, базовые шаблоны, фрагменты. Для этого уже есть заготовка liferay-page-builder, но её нужно прогнать на конкретных версиях Liferay.

Если у вас есть свой чек-лист подготовки демо, его уже можно попробовать превратить в скилл. В худшем случае получится понятная документация для команды. В лучшем — часть рутины перейдёт из ручного режима в воспроизводимый сценарий. 

 

Короткий чек-лист, с чего начать

  1. Выбрать один повторяющийся сценарий, который действительно раздражает.

  2. Записать его шагами так, как объясняли бы новому коллеге.

  3. Сделать отдельного агента под роль: администратор портала, внедренец, тестировщик, техподдержка.

  4. Положить сценарий в SKILL.md.

  5. Запустить Chrome с remote debugging в отдельном профиле.

  6. В этом Chrome руками залогиниться в портал.

  7. Подключить браузерный MCP.

  8. Подключить веб-поиск, если сценарий требует внешних материалов.

  9. Прогнать скилл на тестовом стенде.

  10.  Поправить формулировки там, где агент понял задачу не так.

  11. Отдать скилл коллегам и собрать обратную связь.

Над материалом работали: Ардашева Ульяна, Кисматов Константин

Пока комментариев нет.

Авторизуйтесь, чтобы написать комментарий