@jakerdy/agentica 0.0.2

package/prompts/implement.prompt.md

@@ -0,0 +1,389 @@
+---
+name: agentica.implement
+description: Реализация спецификации фичи по списку задач
+---
+
+## Ввод пользователя
+
+```text
+$ARGUMENTS
+```
+
+Ты **ОБЯЗАН** учесть ввод пользователя (аргументы и контекст) перед тем как продолжить.
+
+## Цель и принципы работы
+
+Твоя задача — реализовать спецификацию фичи (FT-XXXX) **строго по плану задач**.
+Работай линейно: **Валидация → Чтение контекста → Реализация фаз → Финализация → Отчёт**.
+
+Хорошая реализация — это не "быстро написать код", а **последовательное выполнение атомарных задач** с проверкой после каждой фазы.
+
+**Ключевые принципы:**
+1. **Фаза за фазой:** Реализуй задачи последовательно, не перепрыгивая между фазами.
+2. **Checkpoint после фазы:** После каждой фазы — коммит и пауза для review.
+3. **Тесты обязательны:** Каждая фаза должна проходить свои тесты перед переходом к следующей.
+4. **Memory как источник:** Используй `memory` для получения контекста, собранного на этапах `create` и `tasks`.
+5. **Качество > Скорость:** Лучше потратить время на правильную реализацию, чем переделывать потом.
+
+### Глобальные запреты (Safety Guards)
+
+Останови выполнение и не продолжай работу, если:
+1. Спецификация FT-XXXX **не существует** (остановись и предложи пользователю воспользоваться агентом: `agentica.create`).
+2. Файл `tasks.md` **пустой или отсутствует** (остановись и предложи пользователю воспользоваться агентом: `agentica.tasks`).
+3. Git ветка **не соответствует** паттерну `<scope-id>/FT-XXXX-<slug>`.
+4. Запрос требует **изменения спецификации** (спроси подтверждение или создай новую спеку).
+5. Запрос требует **рефакторинга** без изменения функциональности (остановись и предложи пользователю воспользоваться агентом: `agentica.refactor`).
+
+В случае остановки: объясни причину и предложи корректную команду.
+
+## Топология и размещение файлов
+
+**Git workflow:**
+- Работаем в ветке вида `<scope-id>/FT-XXXX-<slug>` (например: `api-client/FT-0012-batch-upload`).
+- После каждой фазы делаем коммит: `feat(FT-XXXX): <описание фазы>`.
+- В конце всех фаз — финальный коммит: `feat(FT-XXXX): complete implementation`.
+
+**Структура спецификации:**
+```
+FT-XXXX - <Название фичи>/
+├── product.md       # Продуктовое описание (ЧТО и ЗАЧЕМ)
+├── tech.md          # Техническое решение (КАК)
+├── research.md      # Исследование библиотек (опционально)
+├── tasks.md         # Задачи для реализации — ИСПОЛЬЗУЕТСЯ КАК ПЛАН
+└── validation.md    # Критерии приемки — ИСПОЛЬЗУЕТСЯ ДЛЯ ПРОВЕРКИ
+```
+
+## Фаза 1: Валидация контекста
+
+### Шаг 1.1: Поиск спецификации FT-XXXX
+
+Определи номер целевой спецификации:
+
+**Вариант A: Явное указание**
+```text
+/agentica.implement --id FT-0012
+```
+
+**Вариант B: Из контекста git ветки**
+```bash
+git branch --show-current
+# Извлеки FT-XXXX из паттерна: <scope-id>/FT-XXXX-<slug>
+```
+
+**Вариант C: Из открытого файла**
+Проверь путь открытого файла — если содержит `.agentica/features/FT-XXXX`, извлеки номер.
+
+**Вариант D: Интерактивный выбор**
+Если контекста недостаточно — просканируй `.agentica/features/` и задай вопрос через интсрумент `ask_questions`.
+
+### Шаг 1.2: Проверка готовности к реализации
+
+Проверь наличие обязательных файлов:
+1. `product.md` — **ОБЯЗАТЕЛЬНО**. Если пустой → STOP (остановись и предложи пользователю воспользоваться агентом: `agentica.create`).
+2. `tech.md` — **ОБЯЗАТЕЛЬНО**. Если пустой → STOP (остановись и предложи пользователю воспользоваться агентом: `agentica.create`).
+3. `tasks.md` — **ОБЯЗАТЕЛЬНО**. Если пустой → STOP (остановись и предложи пользователю воспользоваться агентом: `agentica.tasks`).
+4. `validation.md` — **ОБЯЗАТЕЛЬНО**. Если пустой → STOP (остановись и предложи пользователю воспользоваться агентом: `agentica.tasks`).
+
+### Шаг 1.3: Проверка Git состояния
+
+1. Проверь текущую ветку: `git branch --show-current`
+2. Убедись что ветка соответствует паттерну `<scope-id>/FT-XXXX-<slug>`
+3. Проверь что нет uncommitted changes: `git status --short`
+4. Если есть незакоммиченные изменения — предложи пользователю решить: коммитнуть или stash
+
+## Фаза 2: Чтение контекста
+
+### Шаг 2.1: Чтение спецификации
+
+Прочитай полностью (используй параллельное чтение):
+1. `product.md` — продуктовый контекст
+2. `tech.md` — техническое решение
+3. `research.md` — если существует, информация о библиотеках
+4. `tasks.md` — **ОСНОВНОЙ ДОКУМЕНТ** с планом работ
+5. `validation.md` — критерии приемки
+
+### Шаг 2.2: Извлечение контекста из Memory
+
+IDE автоматически предоставит доступ к релевантным фактам из `memory`, сохранённым на этапах `create` и `tasks`.
+
+Эти факты содержат важный контекст о существующей кодовой базе:
+- Существующие модули и их назначение (`@<scope>/FT-XXXX--existing-modules`)
+- Используемые паттерны проектирования (`@<scope>/FT-XXXX--patterns`)
+- Подключённые библиотеки (`@<scope>/FT-XXXX--libraries`)
+- Точки интеграции (`@<scope>/FT-XXXX--integration-points`)
+- Граф зависимостей между компонентами (`@<scope>/FT-XXXX--dependencies`)
+
+Опирайся на эти факты при реализации — они помогут избежать дублирования кода и следовать существующим архитектурным решениям.
+
+### Шаг 2.3: Чтение контекста проекта/пакета
+
+Прочитай дополнительные контекстные файлы:
+1. `structure.md` — структура проекта/пакета
+2. `tech.md` (проектный, если отличается от фичевого) — общие стандарты
+3. `AGENTS.codestyle.md` (если есть в корне) — правила качества кода
+
+### Шаг 2.4: Анализ структуры задач
+
+Извлеки из `tasks.md`:
+1. Количество фаз и их названия
+2. Список задач в каждой фазе (формат: `TSK-X-XXX`)
+3. Dependencies между задачами
+4. Критерии завершения каждой фазы (Checkpoint описание)
+
+## Фаза 3: Реализация по фазам
+
+Для каждой фазы выполни следующий цикл:
+
+### Цикл реализации фазы
+
+**1. Анонсируй начало фазы:**
+```
+Начинаю Phase N: <Название фазы>
+Checkpoint: <Описание критерия завершения фазы>
+Задач в фазе: X
+```
+
+**2. Реализуй задачи последовательно:**
+
+Для каждой задачи:
+- Прочитай описание задачи из `tasks.md`
+- Если задача требует создания файла — создай его согласно описанию
+- Если задача требует изменения файла — прочитай файл, внеси изменения
+- Следуй code style из `AGENTS.md` (уже есть в контексте) и стандартам из `tech.md`
+- **Не делай больше, чем написано в задаче** — не добавляй "лишних улучшений"
+
+**Типы задач:**
+- `Создать [файл/класс/функцию]` — создай указанный артефакт
+- `Реализовать [метод/функцию]` — напиши реализацию
+- `Интегрировать [модуль A] с [модуль B]` — подключи один модуль к другому
+- `Написать тесты для [компонент]` — создай тестовый файл с указанными test cases
+- `Git commit: [сообщение]` — сделай коммит (выполняется автоматически в конце фазы)
+
+**3. Запусти тесты фазы:**
+```bash
+# Согласно инструкциям из tasks.md для текущей фазы
+bun test -- tests/upload/validators/
+```
+
+Если тесты **не проходят**:
+- Проанализируй ошибку
+- Исправь код
+- Запусти тесты снова
+- **Не переходи к следующей фазе**, пока все тесты не будут зелёными
+
+**4. Запусти линтер и форматтер:**
+```bash
+bun run lint
+bun run format
+```
+
+Исправь все ошибки линтера.
+
+**5. Сделай Git checkpoint:**
+```bash
+git add .
+git commit -m "feat(FT-XXXX): <описание завершённой фазы>"
+```
+
+Сообщение коммита должно быть информативным (например: `feat(FT-0012): implement FileValidator and CSVParser with tests`).
+
+**6. Пауза для review:**
+
+Сообщи пользователю:
+```
+✓ Phase N завершена: <Название фазы>
+✓ Реализовано задач: X
+✓ Тесты: PASSED
+✓ Линтер: OK
+✓ Коммит: <commit-hash>
+
+📋 Реализованные компоненты:
+- [Список файлов/классов/функций]
+
+🔍 Рекомендую проверить реализацию перед переходом к Phase N+1.
+Если нужны правки — внеси их сейчас (я подожду).
+
+Готов продолжить? (напиши "продолжай", внеси правки, или попроси меня поправить то что не нравится)
+```
+
+**Важно:** Подожди подтверждения от пользователя перед переходом к следующей фазе.
+
+### Обработка ошибок во время реализации
+
+**Если задача неясна:**
+- Перечитай `tech.md` и `product.md` для понимания контекста
+- Проверь `memory` на наличие связанных фактов
+- Если всё ещё неясно — задай вопрос пользователю через интсрумент `ask_questions`
+
+**Если возникает конфликт с существующим кодом:**
+- Прочитай существующий код
+- Попытайся интегрироваться минимально инвазивно
+- Если требуется изменение существующего API — уведомь пользователя и предложи план
+
+**Если тесты не проходят:**
+- Проанализируй вывод теста
+- Исправь проблему
+- Не накапливай broken tests — исправляй сразу
+
+## Фаза 4: Финализация
+
+После завершения всех фаз:
+
+### Шаг 4.1: Финальная проверка
+
+**1. Проверь типы (если TypeScript):**
+```bash
+bun typecheck
+# или
+tsc --noEmit
+```
+
+**2. Запусти полный набор тестов:**
+```bash
+bun test
+```
+Убедись что проходят **все** тесты проекта, не только новые.
+
+**3. Запусти линтер:**
+```bash
+bun lint
+```
+
+**4. Запусти форматтер:**
+```bash
+bun format
+```
+
+**5. Попробуй собрать проект:**
+```bash
+bun run build
+```
+
+Если что-то не проходит — исправь перед финальным коммитом.
+
+### Шаг 4.2: Финальный коммит
+
+```bash
+git add .
+git commit -m "feat(FT-XXXX): complete implementation"
+```
+
+### Шаг 4.3: Проверка по validation.md
+
+Пройдись по каждому пункту из `validation.md`:
+- Все ли критерии выполнены?
+- Все ли сценарии покрыты?
+- Все ли edge cases обработаны?
+
+Составь краткий чек-лист (отметь выполненное ✓).
+
+## Фаза 5: Итоговый отчёт
+
+### Шаг 5.1: Генерация отчёта
+
+Создай структурированный отчёт:
+
+````markdown
+# Отчёт о реализации FT-XXXX: <Название фичи>
+
+## ✓ Выполнено
+
+### Фазы реализации
+- [x] Phase 1: <Название> (X задач, commit: <hash>)
+- [x] Phase 2: <Название> (X задач, commit: <hash>)
+- [x] Phase 3: <Название> (X задач, commit: <hash>)
+...
+
+### Реализованные компоненты
+- `src/path/component.ts` - <Описание>
+- `tests/path/component.test.ts` - <Описание тестов>
+...
+
+### Написанные тесты
+- Unit тесты: X test suites, Y tests
+- Integration тесты: X test suites, Y tests
+- Все тесты: PASSED ✓
+
+### Проверки качества
+- [x] Линтер: OK
+- [x] Форматтер: OK
+- [x] typecheck: OK (если TS)
+- [x] Build: OK
+
+## 📊 Статистика
+
+- Всего задач выполнено: X
+- Файлов создано: Y
+- Файлов изменено: Z
+- Строк кода добавлено: ~N (примерно)
+- Test coverage: X%
+
+## 🎯 Соответствие критериям (validation.md)
+
+[Чек-лист по пунктам из validation.md]
+- [x] Критерий 1: Выполнено
+- [x] Критерий 2: Выполнено
+...
+
+## 🔄 Следующие шаги
+
+Рекомендую запустить семантическую валидацию:
+```
+/agentica.validate --id FT-XXXX
+```
+
+Агент проверит соответствие реализации продуктовым и техническим требованиям.
+````
+
+### Шаг 5.2: Предложение валидации
+
+Сообщи пользователю:
+
+```
+✅ Реализация FT-XXXX завершена!
+
+Все фазы выполнены, тесты проходят, код соответствует стандартам.
+
+🔍 Рекомендую запустить валидацию:
+/agentica.validate --id FT-XXXX
+
+Валидация проверит:
+- Соответствие реализации спецификации
+- Покрытие всех use cases
+- Обработку edge cases
+- Качество кода и архитектуры
+
+```
+
+## Дополнительные рекомендации
+
+### Code Style
+
+Всегда следуй стандартам из:
+1. `AGENTS.md` (если существует в корне и загружен в контекст)
+2. `tech.md` текущего скоупа
+3. Существующим паттернам в кодовой базе (ищи через `semantic_search` похожие компоненты)
+
+### Работа с зависимостями
+
+Если нужно установить новую библиотеку:
+1. Проверь что она упомянута в `research.md` или `tech.md`
+2. Установи через package manager: `bun add <package>`
+3. Добавь в коммит message упоминание установки
+
+### Работа с тестами
+
+- Тесты должны быть написаны **до** перехода к следующей фазе
+- Используй testing framework, указанный в `tech.md`
+- Следуй AAA паттерну (Arrange-Act-Assert)
+- Каждый test case должен тестировать одно поведение
+
+### Git гигиена
+
+- Делай осмысленные коммиты после каждой фазы
+- Не коммить node_modules, build артефакты, IDE файлы
+- Если `.gitignore` отсутствует — создай его на этапе Phase 1
+
+---
+
+**Помни:** Твоя задача — реализовать спецификацию точно и качественно, не добавляя "лишнего". Спека уже содержит все необходимые решения. Твоя задача — качественно их реализовать.

package/prompts/init.prompt.md

@@ -0,0 +1,123 @@
+---
+name: agentica.init
+description: Инициализация нового проекта с базовой структурой и шаблонами
+---
+
+## Ввод пользователя
+
+```text
+$ARGUMENTS
+```
+
+Ты **ОБЯЗАН** учесть ввод пользователя (аргументы и контекст) перед тем как продолжить.
+
+## Цель и принципы работы
+
+Твоя задача — привести проект к рабочему состоянию Agentica.
+Работай строго линейно: **Диагностика → Выбор сценария → Реализация → Проверка → Отчёт**.
+
+### Глобальные запреты (Safety Guards)
+
+Останови выполнение и не вноси изменения, если:
+1. Запрос требует другого пайплайна (task, implement, refactor, readme), а не инициализации/настройки.
+2. Пользователь просит изменить узкую реализацию, несвязанную с настройкой Agentica.
+3. Входные данные противоречивы.
+4. Проект **уже инициализирован** (есть `.agentica/` и ключевые файлы), и пользователь не выбрал явный режим обновления.
+
+В случае остановки: объясни причину и предложи корректную команду.
+
+## 1. Топология и размещение файлов
+
+Все артефакты **строго** находятся внутри директории `.agentica/`. Вне её ничего создавать нельзя.
+
+### Группы артефактов
+1. **[Context]:** `product.md`, `structure.md`, `tech.md`, `status.md`. (Обязательны для любого активного скоупа).
+2. **[Config]:** Директории `prompts/`, `templates/`. (Только в корне проекта/репозитория).
+3. **[Specs]:** Директории `architecture/`, `changes/`, `features/`. (Только там, где лежит код/пакет).
+
+### Матрица размещения
+
+| Тип проекта | Локация (Scope) | Состав артефактов |
+| :--- | :--- | :--- |
+| **Single-project** | Корень (`./.agentica/`) | **[Context]** + **[Config]** + **[Specs]** |
+| **Monorepo** | Корень репо (`./.agentica/`) | **[Context]** + **[Config]**. **ЗАПРЕЩЕНО** создавать [Specs] здесь. |
+| **Monorepo** | Пакет (`./packages/X/.agentica/`) | **[Context]** + **[Specs]**. |
+
+## 2. Диагностика и Выбор сценария
+
+Проанализируй файловую систему и аргументы:
+1. **Тип проекта:** Single-project или Monorepo.
+2. **Состояние:** Пустая папка (Empty) или есть код (Existing).
+3. **Наличие Agentica:** Инициализирован или нет.
+
+Если данных критически не хватает — задай вопрос через интсрумент `ask_questions` (максимум 1-3 вопроса с вариантами ответа).
+
+### Сценарии (приоритет: A/B → C → D)
+
+#### Сценарий A: "Empty Init" (Новый проект с нуля)
+*Условие:* Директория пуста.
+1. Создай структуру согласно матрице размещения.
+2. Заполни **[Context]** шаблонами (цели, границы, стек по умолчанию).
+3. Создай **[Config]** и **[Specs]**.
+4. Запиши статус: `проект создан`.
+
+#### Сценарий B: "Existing Project" (Интеграция)
+*Условие:* Есть код, но нет Agentica.
+1. Не ломай существующую структуру.
+2. Создай структуру Agentica согласно матрице (Single или Mono/Package).
+3. Заполни **[Context]** на основе **реального** анализа кода, а не шаблонами.
+4. Адаптируй промпты в **[Config]** под текущие инструменты (линтеры, тесты).
+5. Запиши статус: `интеграция завершена успешно`.
+
+#### Сценарий C: "Docs Update" (Обновление документов)
+*Условие:* Agentica есть, пользователь просит обновить контекст.
+1. Проверь согласованность **[Context]** (product/structure/tech).
+2. Устрани противоречия, добавь недостающие, но реально нужные разделы.
+3. Статус: `обновление документации`.
+
+#### Сценарий D: "Post Tuning" (Пост-настройка промптов и шаблонов Agentica)
+*Условие:* Проект уже инициализирован, и пользователь хочет обновить стек, инструменты или правила работы.
+1. Определи целевой scope изменений: только root `.agentica/`, только пакет(ы) или оба уровня.
+2. Сверь актуальный стек по `tech.md`, `package.json`, конфигам линтера/тестов/сборки и фактическим командам проекта.
+3. Зафиксируй карту миграции инструментов (что заменить и на что):
+  - команды запуска/сборки;
+  - команды тестирования и линтинга;
+  - команды рефакторинга и проверки качества.
+4. Обнови **[Context]** (`product.md`, `structure.md`, `tech.md`) в релевантных scope так, чтобы они отражали новый стек и ограничения.
+5. Обнови **[Config]** в root `.agentica/`:
+  - синхронизируй все файлы в `.agentica/prompts/` с новым набором инструментов;
+  - обязательно проверь `refactor.prompt.md` и `validate.prompt.md` на конкретные команды;
+  - выполни семантический поиск по запуску инструментов и regex-поиск упоминаний legacy-команд (`bun`, `tsc` и т.п.), затем замени их на актуальные.
+6. Обнови шаблоны в `.agentica/templates/`, чтобы формулировки по сборке, тестам, линтингу и валидации соответствовали реальному техстеку.
+7. Проверь консистентность: одинаковые команды и правила должны использоваться в `tech.md`, промптах и шаблонах без противоречий.
+8. Статус: `Текущий статус интеграции: Шаблоны и промпты адаптированы под технологический стек проекта`.
+
+*Если проект уже инициализирован, но пользователь не уточнил задачу:*
+1. Зафиксируй наличие инициализации.
+2. Через интсрумент `ask_questions` предложи: обновить доки (C), подогнать промпты (D) или выполнить синхронизацию.
+
+## 3. Требования к качеству (Quality Gate)
+
+1. **[Context] файлы:** Должны отражать реальность, не содержать "воды" и пустых заглушек.
+2. **Status файл (`status.md`):**
+  - Всегда обновляй в конце работы.
+  - Допустимые форматы:
+    - `Текущий статус интеграции: интеграция завершена успешно`
+    - `Текущий статус интеграции: интеграция в процессе по сценарию <N>`
+  - Для обновлений (C/D) — дописывай историю изменений вниз, не стирая заголовок.
+
+## 4. Финальная проверка
+
+Перед выдачей ответа проверь:
+1. Все файлы из групп **[Context]**, **[Config]**, **[Specs]** существуют на своих местах согласно матрице размещения.
+2. В корне Monorepo **нет** папок `architecture`, `changes`, `features`.
+3. В `status.md` записан актуальный статус.
+4. Файлы `product/structure/tech` не противоречат друг другу.
+
+## 5. Формат отчёта
+
+Выдай пользователю короткое резюме:
+1. Выполненный сценарий.
+2. Список созданных/обновленных файлов.
+3. Текущий статус из `status.md`.
+4. Что осталось сделать вручную (если есть).