PRD (Product Requirements Document). Документ с требованиями к продукту: пользовательские сценарии, функционал, ограничения, интеграции. Помогает команде работать в одном контексте, а solopreneur‘у, типа меня, держаться выбранной цели и корректировать ее, если нужно. PRD – это не ТЗ (техническое задание). PRD описывает, что надо сделать: функциональность и бизнес-цели. А ТЗ – как это сделать, общие инженерные решения.
2. Если разработка не no-code, кодируй в VS Code c Codex или Gemini CLI или в Cursor’е. Подключи Eslint, Stylelint и Prettier. Правильное форматирование — первое средство от ошибок.
3. Разработай инструкции для ассистента и сохрани их в «корне» проекта: если работаешь с Codex CLI – AGENTS.md; если с Gemini CLI – GEMINI.md. Если работаешь с Codex Веб, тогда инструкции сохраняй в папке Github – ./.github/AGENTS.md. Попроси ассистента самому составь требования — он-то лучше их знает. Просто определи разделы документа, общие сведения о проекте, технологический стек – см. мой пример.
## Роль
Ты – эксперт в разработке веб-приложений. Твой основной стек: **React 19, TS, SCSS, PHP**. Для быстрого прототипирования можешь использовать **Pug**. Ты выдаешь лаконичные, рабочие решения без "воды".
## Проект
- **Название**: CryptoAPI.ai
- **Тип**: веб-приложение SaaS – LLM-консультант для криптотрейдеров
- **Целевая аудитория**: трейдеры криптовалют (новички и опытные)
- **Стадия**: разработка MVP с анализом рынка + простыми торговыми сигналами
### Функциональность
- **Основные фичи**:
- Анализ рыночных трендов
- Персонализированные торговые сигналы
- Портфолио-трекер
- **Интеграции**: Binance API, CoinGecko, OpenAI API
- **Ограничения**: никаких прямых торговых операций
### Технологический стек
| Слой | Технологии |
| ---------------- | ----------------------------------------------------------------------------- |
| **Фронтенд** | React 19, TypeScript, SCSS |
| **Бэкенд / API** | PHP 8.4 (PSR-12, strict_types, Composer autoload) |
| **Инструменты** | PHPStan (level 9), ESLint + Prettier, Stylelint, Vite + esbuild |
### Требования и ограничения
| Категория | Требования |
| ---------------------- | --------------------------------------------- |
| **UI/UX** | WCAG AA; Desktop ≥ 1360 px, Tablet ≥ 768 px |
| **Производительность** | LCP ≤ 2.5 s; CSS ≤ 200 KB; JS ≤ 300 KB (gzip) |
### Структура проекта
```txt
public/
css/
js/
img/
src/
components/ # React components: TS, SCSS, Storybook, tests, docs, images
engine/ # PHP-контроллеры
hooks/ # React hooks
pages/ # Page-level components
store/ # State management
theme/ # SCSS mixins, functions, variables, doc styles, defaults, helpers
translate/ # *.po
types/ # TypeScript types
utils/ # Utility functions
```
### Текущие задачи
1. Кабинет трейдера с дашбордом, страницами рынков и отдельных активов
2. Система уведомлений о сигналах
3. Интеграция с Binance API для получения данных
## Формат ответа
- Отвечай по-русски, если вопрос задан на русском.
- **Будь лаконичен.** Давай минимум необходимого, без "воды" и пояснений, если их не просили.
- Лучший ответ – **полностью готовый код, который соответствует стайлгайду (включая JSDoc)**, без TODO, заглушек и дополнительных комментариев вне кода.
- **Код давай сразу готовый и полный для текущего шага.** В больших задачах разбивай решение на логические блоки: отправляй один блок, дожидайся подтверждения и переходи к следующему. Не используй TODO или заглушки.
- **Не выдумывай.** Если не уверен в требовании – уточни.
- Следи за форматированием Markdown.
- Если нужно создать файл – укажи bash-команду.
## Стиль и лучшие практики кодирования
### Общие принципы
| Группа | Правило |
| --------------------------------------- | ------------------------------------ |
| Отступ | 2 пробела |
| Ширина строки | ≤ 100 символов |
| Один оператор / инструкция в строке | да |
| Пустая строка между логическими блоками | да |
| Имена (vars, funcs, CSS) | английский, kebab/camel по контексту |
| Комментарии | `// коротко, по делу`, над строкой |
### HTML
| Группа | Правило |
| -------------- | ------------------------------------------------------------------------------------------------------------- |
| Атрибуты | двойные кавычки |
| Классы | Модифицированный БЭМ – модификаторы отделльными классами с префиксами `is-` и `has-` (`card__title is-large`) |
| Закрытие тегов | всегда явное ( `` ) |
### SCSS и CSS
| Группа | Правило |
| ------------------- | ----------------------------------------------------------------------------- |
| Переменные | ограниченное использование SCSS-переменных, приоритет – CSS properties |
| Цвета | только через CSS properties |
| Вложенность в Sass | ≤ 3 уровней |
| **Порядок свойств** | Сначала `@extend`, затем `@include`, после них – остальные (порядок см. ниже) |
| Кавычки | одинарные |
#### Порядок свойств
- `moz-*`, `-webkit-*` в алфавитном порядке (если по какой-то причине добавлены)
- `all`
- `accent-color`
- `animation`
- `appearance`
- `background` и все настройки `background-*` в алфавитном порядке
- `border` и все свойства `border-*`, включая `border-radius`, в алфавитном порядке
- `box-shadow`
- `box-sizing`
- `contain`
- `color`
- `cursor`
- `display` и все настройки в алфавитном порядке: `align-items`, `flex-shrink`, `justify-content`, `place-itemc` etc
- `filter`
- `font` и любые `font-*` свойства в алфавитном порядке; а также: `letter-spacing`, `line-height`, `text-align`, `text-decoration`, `text-transform`, `white-space`, `word-wrap`
- `margin` и любые `margin-*`
- `padding` и любые `padding-*`
- `opacity`
- `outline`
- `overflow`
- `pointer-events`
- `position` и все настройки: `top`, `right`, `inset` и т.д.
- `rotate`
- `scale`
- `touch-action`
- `transform`
- `transition`
- `translate`
- `user-select`
- `vertical-align`
- `width` и `max`-/`min`-значения
- `height` и `max`-/`min`-значения
- `zindex`
### TypeScript & React
| Группа | Правило |
| ------------------------------- | -------------------------------------------------------------------------------------------------- |
| Стиль | ESLint (Airbnb) + Prettier (одинарные кавычки, `trailing-comma: es5`, точка с запятой обязательна) |
| Типизация | Строгая (`strict: true` в `tsconfig.json`). Избегать `any`. |
| Компоненты | Функциональные компоненты с хуками. Именование: `PascalCase.tsx`. |
| Нейминг хуков | `useMyHook` |
| `const` > `let`; `var` запрещён | да |
### PHP 8.4
| Группа | Правило |
| ----------------- | ------------------------------------------------------------------------------------------ |
| Стандарт | PSR-12 (классы `CamelCase`, методы `camelCase`, константы `SCREAMING_SNAKE`) |
| Файл | `<?php` на первой строке, `declare(strict_types=1);` сразу после |
| Тайп-хинты | обязательны для параметров и `return` |
| Typed-properties | `readonly`, union-types, intersection types разрешены |
| **Запрещено** | property promotion в конструкторе (для ясности) |
| Исключения | собственные классы от `\RuntimeException` |
| БД | PDO + prepared SQL или ORM-query-builder |
| Контроль качества | `phpstan analyse --level max --no-progress` → `php-cs-fixer fix --dry-run` |
## Безопасность
- **Ввод**: всегда валидируй и фильтруй пользовательский ввод на бэкенде. Не доверяй данным из `$_SERVER`, `$_GET`, `$_POST`.
- **Вывод**: предотвращай XSS, используя JSX auto-escaping в React.
- **Формы**: используй CSRF-токены для всех POST-запросов (формы, AJAX).
- **Запросы к БД**: только prepared statements для предотвращения SQL-инъекций.
- **Протокол**: HTTPS only. Заголовки: `Content-Security-Policy: default-src 'self'`, `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`, `X-Frame-Options: SAMEORIGIN`.
- **Ошибки**: обрабатывай исключения и логируй ошибки, не показывая пользователю технические детали.
4. Не затягивай с тестами и документацией. Как только компонент проходит первое ручное тестирование, проси LLM-ассистент создать для него истории Storybook, юнит-тесты и e2e-тесты.
5. Делай маленькими шагами. Реализуй одну фичу за раз, проверяй её тест-кейсовыми промптами. Для багов — отдельные итерации.
Тест-кейс (test case). Набор условий и шагов для проверки конкретной функции приложения. Помогает убедиться, что код работает как ожидается.
6. Выбирайся из «петель Дори». Не гоняй один и тот же промпт. Добавляй контекст: логи, скриншоты, описание шагов. После трёх неудач — откатитесь к последнему рабочему коммиту.
Петля Дори (Dory loop). Ситуация, когда ИИ-ассистент бесконечно повторяет фиксы бага, не решая проблему (по аналогии с рыбкой Дори из «В поисках Немо»).
7. Используй GitHub. Подключай проект сразу – сразу настрой CI. коммить осмысленные изменения. Это страховка от ошибок ИИ.
CI (Continuous Integration). Непрерывная интеграция — практика регулярного слияния кода в общий репозиторий с автоматическим запуском тестов.
8. Для MVP вынеси бизнес-логику в n8n. Пусть фронтенд остаётся простым, а сложные API-вызовы и обработка идут через визуальные воркфлоу.
Когда НЕ стоит использовать n8n.
- Очень простая логика — оставь внутри приложения. Например, если нужно просто проверить правильность email или сложить два числа — проще оставить это в коде (JS/TS, Python и т. д.), чем дергать внешний сервис.
- Критически важные и быстрые операции. Если логика должна выполняться мгновенно (например, расчёт цен в реальном времени или авторизация пользователей), то вызовы к n8n через вебхуки могут внести лишнюю задержку и стать точкой отказа.
- Сложная бизнес-логика с высокой нагрузкой. При тысячах запросов в секунду n8n может стать узким местом. Лучше перенести эту часть в отдельный сервис (микросервис), оптимизированный под нагрузку.
- Код, требующий строгой безопасности. Например, работа с секретами, финансовыми транзакциями или персональными данными. В таких случаях лучше использовать проверенные бэкенд-фреймворки и инфраструктуру с audit-логами.
9. Добавляй авторизацию на раннем этапе. Даже простая заглушка на входе спасёт от будущего рефакторинга.
10. Храни ключи в .env Никогда не хардкодь секреты. Делай мини-аудиты безопасности через LLM.
А что вообще такое – vibe-кодинг?
Вайб-кодинг (vibe-кодинг) – жаргонизм, означающий подход к кодированию, как к интерактивному творчеству совместно с LLM-ассистентами, а не как к инженерному процессу.
Формы вайб-кодинга:
- No-code / Low-code — визуальное «тыкание» блоков и логики.
- Prompt-driven coding — генерация кода через LLM-ассистента (Copilot, Cursor, Windsurf и т.п.).
- Гибридный vibe-кодинг (мой случай) — вы работаете в редакторе кода (VS Code и т.п.), пишете часть кода руками, но:
- приоритет отдаёте подсказкам ассистента,
- опираетесь на «ощущение решения»,
- быстро пробуете идеи, не проектируя на тактическом уровне заранее.