Если вы не разработчик и пробуете Codex, не начинайте с промптов. Начните с нормального набора скиллов.

Я бы начал с базового набора скиллов.

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

Минимальный набор, который я бы поставил:

1. Graphify — чтобы Codex понял проект

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

Установка:

uv tool install graphifyy graphify codex install

Если uv не стоит:

pipx install graphifyy graphify codex install

Как использовать:

/graphify .

После этого можно спрашивать Codex не “где тут авторизация?”, а нормально:

Используй Graphify и объясни, как устроена авторизация в проекте. Какие файлы за нее отвечают?

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

2. Context7 — чтобы Codex не выдумывал документацию

Модели часто помнят старые версии библиотек. Особенно когда речь про Next.js, Supabase, Stripe, Tailwind, Prisma и всё такое.

Context7 подтягивает актуальные доки.

Установка:

npx ctx7 setup

Как использовать:

Используй Context7 и актуальную документацию Next.js. Проверь, как правильно сделать middleware для авторизации.

Или:

Используй Context7 для Supabase и объясни, как правильно настроить login через email.

Это снижает шанс, что Codex напишет красивый, но уже нерабочий код.

3. Create-plan — чтобы не кодить всё одним куском

Главная ошибка в вайбкодинге: попросить “сделай личный кабинет” или “добавь оплату”.

Codex радостно полезет менять половину проекта.

Лучше сначала поставить планировщик.

В Codex можно установить skill через встроенный $skill-installer:

$skill-installer install https://github.com/openai/skills/tree/main/skills/.experimental/create-plan

Как использовать:

Используй create-plan. Разбей задачу “добавить регистрацию и логин” на маленькие технические шаги. Не пиши код, пока я не подтвержу план.

Это прям мастхэв для нетеха.

План нужен не для красоты.Он нужен, чтобы вы понимали, что вообще сейчас будет происходить.

4. Playwright MCP — чтобы проверять сайт в браузере

Многие останавливаются на моменте “код написан”.Но код написан — это не значит, что форма открывается, кнопка работает, а после логина пользователь попадает куда надо.

Playwright дает Codex возможность открыть сайт в браузере и пройти сценарий как пользователь.

Установка в MCP-конфиг:

{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] } } }

Как использовать:

Запусти проект локально. Открой http://localhost:3000/login через Playwright. Пройди сценарий логина, проверь ошибки в консоли и пришли короткий отчет.

Это особенно полезно, если вы делаете лендинг, кабинет, форму заявки, оплату, онбординг — всё, где важен реальный пользовательский сценарий.

5. Webapp-testing — чтобы Codex не просто “посмотрел”, а проверил

Этот skill помогает превращать ручную проверку в нормальные тестовые сценарии: формы, клики, ошибки, адаптив, консоль, переходы между страницами.

Как использовать:

Используй webapp-testing. Составь smoke-тесты для главного сценария: регистрация → логин → переход в личный кабинет.

Для MVP этого уже достаточно, чтобы не жить в иллюзии “вроде работает”.

Мой базовый порядок такой:

И вот только после этого можно говорить, что вы “навайбкодили” что-то более-менее осознанно.

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