npm - @skj1724/oh-my-opencode - Versions diffs - 3.18.27 → 3.19.1 - Mend

@skj1724/oh-my-opencode 3.18.27 → 3.19.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1262) hide show

package/README.ru.md DELETED Viewed

@@ -1,378 +0,0 @@
-> [!WARNING]
-> **Временное уведомление (на этой неделе): сниженная доступность мейнтейнера**
->
-> Ключевой мейнтейнер Q получил травму, поэтому на этой неделе ответы по issue/PR и релизы могут задерживаться.
-> Спасибо за терпение и поддержку.
-> [!TIP]
-> **Building in Public**
->
-> Мейнтейнер разрабатывает и поддерживает oh-my-opencode в режиме реального времени с помощью Jobdori — ИИ-ассистента на базе глубоко кастомизированной версии OpenClaw.
-> Каждая фича, каждый фикс, каждый триаж issue — в прямом эфире в нашем Discord.
->
-> [![Building in Public](./.github/assets/building-in-public.png)](https://discord.gg/PUwSMR9XNk)
->
-> [**→ Смотрите в #building-in-public**](https://discord.gg/PUwSMR9XNk)
-> [!NOTE]
->
-> [![Sisyphus Labs - Sisyphus is the agent that codes like your team.](./.github/assets/sisyphuslabs.png?v=2)](https://sisyphuslabs.ai)
->
-> > **Мы создаём полноценную продуктовую версию Sisyphus, чтобы задать стандарты для frontier-агентов. <br />Присоединяйтесь к листу ожидания [здесь](https://sisyphuslabs.ai).**
-> [!TIP] Будьте с нами!
->
-> | [](https://discord.gg/PUwSMR9XNk)   | Вступайте в наш [Discord](https://discord.gg/PUwSMR9XNk), чтобы общаться с контрибьюторами и пользователями `oh-my-opencode`. |
-> | ----------------------------------- | ------------------------------------------------------------ |
-> | [](https://x.com/justsisyphus)      | Новости и обновления `oh-my-opencode` раньше публиковались на моём аккаунте X. <br /> После ошибочной блокировки, [@justsisyphus](https://x.com/justsisyphus) публикует обновления вместо меня. |
-> | [](https://github.com/code-yeongyu) | Подпишитесь на [@code-yeongyu](https://github.com/code-yeongyu) на GitHub, чтобы следить за другими проектами. |
-<!-- <CENTERED SECTION FOR GITHUB DISPLAY> --> <div align="center">
-[![Oh My OpenCode](./.github/assets/hero.jpg)](https://github.com/code-yeongyu/oh-my-openagent#oh-my-opencode)
-[![Preview](./.github/assets/omo.png)](https://github.com/code-yeongyu/oh-my-openagent#oh-my-opencode)
-</div>
-> Anthropic [**заблокировал OpenCode из-за нас.**](https://x.com/thdxr/status/2010149530486911014) **Да, это правда.** Они хотят держать вас в замкнутой системе. Claude Code — красивая тюрьма, но всё равно тюрьма.
->
-> Мы не делаем привязки. Мы работаем с любыми моделями. Claude / Kimi / GLM для оркестрации. GPT для рассуждений. Minimax для скорости. Gemini для творческих задач. Будущее — не в выборе одного победителя, а в оркестровке всех. Модели дешевеют каждый месяц. Умнеют каждый месяц. Ни один провайдер не будет доминировать. Мы строим под открытый рынок, а не под чьи-то огороженные сады.
-<div align="center">
-[![GitHub Release](https://img.shields.io/github/v/release/code-yeongyu/oh-my-openagent?color=369eff&labelColor=black&logo=github&style=flat-square)](https://github.com/code-yeongyu/oh-my-openagent/releases) [![npm downloads](https://img.shields.io/npm/dt/oh-my-opencode?color=ff6b35&labelColor=black&style=flat-square)](https://www.npmjs.com/package/oh-my-opencode) [![GitHub Contributors](https://img.shields.io/github/contributors/code-yeongyu/oh-my-openagent?color=c4f042&labelColor=black&style=flat-square)](https://github.com/code-yeongyu/oh-my-openagent/graphs/contributors) [![GitHub Forks](https://img.shields.io/github/forks/code-yeongyu/oh-my-openagent?color=8ae8ff&labelColor=black&style=flat-square)](https://github.com/code-yeongyu/oh-my-openagent/network/members) [![GitHub Stars](https://img.shields.io/github/stars/code-yeongyu/oh-my-openagent?color=ffcb47&labelColor=black&style=flat-square)](https://github.com/code-yeongyu/oh-my-openagent/stargazers) [![GitHub Issues](https://img.shields.io/github/issues/code-yeongyu/oh-my-openagent?color=ff80eb&labelColor=black&style=flat-square)](https://github.com/code-yeongyu/oh-my-openagent/issues) [![License](https://img.shields.io/badge/license-SUL--1.0-white?labelColor=black&style=flat-square)](https://github.com/code-yeongyu/oh-my-openagent/blob/master/LICENSE.md) [![Ask DeepWiki](https://deepwiki.com/badge.svg)](https://deepwiki.com/code-yeongyu/oh-my-openagent)
-English | 한국어 | 日本語 | 简体中文 | Русский
-</div> <!-- </CENTERED SECTION FOR GITHUB DISPLAY> -->
-## Отзывы
-> «Из-за него я отменил подписку на Cursor. В опенсорс-сообществе происходит что-то невероятное.» — [Arthur Guiot](https://x.com/arthur_guiot/status/2008736347092382053?s=20)
-> «Если Claude Code делает за 7 дней то, на что у человека уходит 3 месяца, Sisyphus справляется за 1 час. Он просто работает, пока задача не выполнена. Это дисциплинированный агент.» <br/>— B, исследователь в области квантовых финансов
-> «За один день устранил 8000 предупреждений eslint с помощью Oh My Opencode.» <br/>— [Jacob Ferrari](https://x.com/jacobferrari_/status/2003258761952289061)
-> «За ночь конвертировал приложение на tauri в 45k строк в веб-SaaS с помощью Ohmyopencode и ralph loop. Начал с промпта «проинтервьюируй меня», попросил оценки и рекомендации по вопросам. Было удивительно наблюдать за работой и утром проснуться с почти рабочим сайтом!» — [James Hargis](https://x.com/hargabyte/status/2007299688261882202)
-> «Используйте oh-my-opencode — вы не захотите возвращаться назад.» <br/>— [d0t3ch](https://x.com/d0t3ch/status/2001685618200580503)
-> «Пока не могу точно объяснить, почему это так круто, но опыт разработки вышел на совершенно другой уровень.» — [苔硯:こけすずり](https://x.com/kokesuzuri/status/2008532913961529372?s=20)
-> «Экспериментирую с open code, oh my opencode и supermemory этим выходным, чтобы собрать нечто среднее между Minecraft и souls-like.» «Попросил добавить анимации приседания, пока хожу на обеденную прогулку. [Видео]» — [MagiMetal](https://x.com/MagiMetal/status/2005374704178373023)
-> «Ребята, вам нужно включить это в ядро и нанять его. Серьёзно. Это очень, очень, очень хорошо.» <br/>— Henning Kilset
-> «Наймите @yeon_gyu_kim, если сможете его уговорить, этот парень революционизировал opencode.» <br/>— [mysticaltech](https://x.com/mysticaltech/status/2001858758608376079)
-> «Oh My OpenCode — это что-то с чем-то» — [YouTube — Darren Builds AI](https://www.youtube.com/watch?v=G_Snfh2M41M)
-------
-# Oh My OpenCode
-Вы жонглируете Claude Code, Codex, случайными OSS-моделями. Настраиваете рабочие процессы. Дебажите агентов.
-Мы уже проделали эту работу. Протестировали всё. Оставили только то, что реально работает.
-Установите OmO. Введите `ultrawork`. Готово.
-## Установка
-### Для людей
-Скопируйте и вставьте этот промпт в ваш LLM-агент (Claude Code, AmpCode, Cursor и т.д.):
-```
-Install and configure oh-my-opencode by following the instructions here:
-https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/refs/heads/dev/docs/guide/installation.md
-```
-Или прочитайте руководство по установке, но серьёзно — пусть агент сделает это за вас. Люди ошибаются в конфигах.
-### Для LLM-агентов
-Загрузите руководство по установке и следуйте ему:
-```bash
-curl -s https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/refs/heads/dev/docs/guide/installation.md
-```
-**Примечание**: Используйте опубликованное имя пакета и бинарника `oh-my-opencode`. Внутри `opencode.json` слой совместимости теперь предпочитает точку входа плагина `oh-my-openagent`, в то время как устаревшие записи `oh-my-opencode` все еще загружаются с предупреждением. Файлы конфигурации плагина по-прежнему часто используют `oh-my-opencode.json` или `oh-my-opencode.jsonc`, и как устаревшие, так и переименованные базовые имена распознаются во время переходного периода.
-Анонимная телеметрия включена по умолчанию для улучшения надежности установки и работы. Она использует PostHog с хешированным идентификатором установки, никогда не используя исходное имя хоста, и может быть отключена с помощью `OMO_SEND_ANONYMOUS_TELEMETRY=0` или `OMO_DISABLE_POSTHOG=1`. См. [Политику конфиденциальности](docs/legal/privacy-policy.md) и [Условия обслуживания](docs/legal/terms-of-service.md).
-------
-## Пропустите этот README
-Мы вышли за пределы эпохи чтения документации. Просто вставьте это в своего агента:
-```
-Read this and tell me why it's not just another boilerplate: https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/refs/heads/dev/README.md
-```
-## Ключевые возможности
-### 🪄 `ultrawork`
-Вы правда это читаете? Поразительно.
-Установите. Введите `ultrawork` (или `ulw`). Готово.
-Всё описанное ниже, каждая функция, каждая оптимизация — вам не нужно это знать. Оно просто работает.
-Даже при наличии только следующих подписок ultrawork будет работать отлично (проект не аффилирован с ними, это личная рекомендация):
-- [Подписка ChatGPT ($20)](https://chatgpt.com/)
-- [Подписка Kimi Code ($0.99) (*только в этом месяце)](https://www.kimi.com/membership/pricing?track_id=5cdeca93-66f0-4d35-aabb-b6df8fcea328)
-- [Тариф GLM Coding ($10)](https://z.ai/subscribe)
-- При доступе к оплате за токены использование моделей Kimi и Gemini обойдётся недорого.
-|     | Функция                                                  | Что делает                                                                                                                                                                                                                       |
-| --- | -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 🤖   | **Дисциплинированные агенты**                            | Sisyphus оркестрирует Hephaestus, Oracle, Librarian, Explore. Полноценная AI-команда разработки в параллельном режиме.                                                                                                           |
-| ⚡   | **`ultrawork` / `ulw`**                                  | Одно слово. Все агенты активируются. Не останавливается, пока задача не выполнена.                                                                                                                                               |
-| 🚪   | **[IntentGate](https://factory.ai/news/terminal-bench)** | Анализирует истинное намерение пользователя перед классификацией и действием. Никакого буквального неверного толкования.                                                                                                         |
-| 🔗   | **Инструмент правок на основе хэш-якорей**               | Хэш содержимого `LINE#ID` проверяет каждое изменение. Ноль ошибок с устаревшими строками. Вдохновлено [oh-my-pi](https://github.com/can1357/oh-my-pi). [Проблема обвязки →](https://blog.can.ac/2026/02/12/the-harness-problem/) |
-| 🛠️   | **LSP + AST-Grep**                                       | Переименование в рабочем пространстве, диагностика перед сборкой, переписывание с учётом AST. Точность IDE для агентов.                                                                                                          |
-| 🧠   | **Фоновые агенты**                                       | Запускайте 5+ специалистов параллельно. Контекст остаётся компактным. Результаты — когда готовы.                                                                                                                                 |
-| 📚   | **Встроенные MCP**                                       | Exa (веб-поиск), Context7 (официальная документация), Grep.app (поиск по GitHub). Всегда включены.                                                                                                                               |
-| 🔁   | **Ralph Loop / `/ulw-loop`**                             | Самореферентный цикл. Не останавливается, пока задача не выполнена на 100%.                                                                                                                                                      |
-| ✅   | **Todo Enforcer**                                        | Агент завис? Система немедленно возвращает его в работу. Ваша задача будет выполнена, точка.                                                                                                                                     |
-| 💬   | **Comment Checker**                                      | Никакого AI-мусора в комментариях. Код читается так, словно его писал опытный разработчик.                                                                                                                                       |
-| 🖥️   | **Интеграция с Tmux**                                    | Полноценный интерактивный терминал. REPL, дебаггеры, TUI. Всё живое.                                                                                                                                                             |
-| 🔌   | **Совместимость с Claude Code**                          | Ваши хуки, команды, навыки, MCP и плагины? Всё работает без изменений.                                                                                                                                                           |
-| 🎯   | **MCP, встроенные в навыки**                             | Навыки несут собственные MCP-серверы. Никакого раздувания контекста.                                                                                                                                                             |
-| 📋   | **Prometheus Planner**                                   | Стратегическое планирование в режиме интервью перед любым выполнением.                                                                                                                                                           |
-| 🔍   | **`/init-deep`**                                         | Автоматически генерирует иерархические файлы `AGENTS.md` по всему проекту. Отлично работает на эффективность токенов и производительность агента.                                                                                |
-### Дисциплинированные агенты
-<table><tr> <td align="center"><img src=".github/assets/sisyphus.png" height="300" /></td> <td align="center"><img src=".github/assets/hephaestus.png" height="300" /></td> </tr></table>
-**Sisyphus** (`claude-opus-4-7` / **`kimi-k2.5`** / **`glm-5`**) — главный оркестратор. Он планирует, делегирует задачи специалистам и доводит их до завершения с агрессивным параллельным выполнением. Он не останавливается на полпути.
-**Hephaestus** (`gpt-5.4`) — автономный глубокий исполнитель. Дайте ему цель, а не рецепт. Он исследует кодовую базу, изучает паттерны и выполняет задачи сквозным образом без лишних подсказок. *Законный Мастер.*
-**Prometheus** (`claude-opus-4-7` / **`kimi-k2.5`** / **`glm-5`**) — стратегический планировщик. Режим интервью: задаёт вопросы, определяет объём работ и формирует детальный план до того, как написана хотя бы одна строка кода.
-Каждый агент настроен под сильные стороны своей модели. Никакого ручного переключения между моделями. Подробнее →
-> Anthropic [заблокировал OpenCode из-за нас.](https://x.com/thdxr/status/2010149530486911014) Именно поэтому Hephaestus зовётся «Законным Мастером». Ирония намеренная.
->
-> Мы работаем лучше всего на Opus, но Kimi K2.5 + GPT-5.4 уже превосходят ванильный Claude Code. Никакой настройки не требуется.
-### Оркестрация агентов
-Когда Sisyphus делегирует задачу субагенту, он выбирает не модель, а **категорию**. Категория автоматически сопоставляется с нужной моделью:
-| Категория            | Для чего предназначена                |
-| -------------------- | ------------------------------------- |
-| `visual-engineering` | Фронтенд, UI/UX, дизайн               |
-| `deep`               | Автономные исследования + выполнение  |
-| `quick`              | Изменения в одном файле, опечатки     |
-| `ultrabrain`         | Сложная логика, архитектурные решения |
-Агент сообщает тип задачи. Обвязка подбирает нужную модель. Вы ни к чему не прикасаетесь.
-### Совместимость с Claude Code
-Вы тщательно настроили Claude Code. Хорошо.
-Каждый хук, команда, навык, MCP и плагин работают здесь без изменений. Полная совместимость, включая плагины.
-### Инструменты мирового класса для ваших агентов
-LSP, AST-Grep, Tmux, MCP — реально интегрированы, а не склеены скотчем.
-- **LSP**: `lsp_rename`, `lsp_goto_definition`, `lsp_find_references`, `lsp_diagnostics`. Точность IDE для каждого агента
-- **AST-Grep**: Поиск и переписывание кода с учётом синтаксических паттернов для 25 языков
-- **Tmux**: Полноценный интерактивный терминал. REPL, дебаггеры, TUI-приложения. Агент остаётся в сессии
-- **MCP**: Веб-поиск, официальная документация, поиск по коду на GitHub. Всё встроено
-### MCP, встроенные в навыки
-MCP-серверы съедают бюджет контекста. Мы это исправили.
-Навыки приносят собственные MCP-серверы. Запускаются по необходимости, ограничены задачей, исчезают по завершении. Контекстное окно остаётся чистым.
-### Лучше пишет код. Правки на основе хэш-якорей
-Проблема обвязки реальна. Большинство сбоев агентов — не вина модели. Это вина инструмента правок.
-> *«Ни один из этих инструментов не даёт модели стабильный, проверяемый идентификатор строк, которые она хочет изменить... Все они полагаются на то, что модель воспроизведёт контент, который уже видела. Когда это не получается — а так бывает нередко — пользователь обвиняет модель.»*
->
-> <br/>— [Can Bölük, «Проблема обвязки»](https://blog.can.ac/2026/02/12/the-harness-problem/)
-Вдохновлённые [oh-my-pi](https://github.com/can1357/oh-my-pi), мы реализовали **Hashline**. Каждая строка, которую читает агент, возвращается с тегом хэша содержимого:
-```
-11#VK| function hello() {
-22#XJ|   return "world";
-33#MB| }
-```
-Агент редактирует, ссылаясь на эти теги. Если файл изменился с момента последнего чтения, хэш не совпадёт, и правка будет отклонена до любого повреждения. Никакого воспроизведения пробелов. Никаких ошибок с устаревшими строками.
-Grok Code Fast 1: успешность **6.7% → 68.3%**. Просто за счёт замены инструмента правок.
-### Глубокая инициализация. `/init-deep`
-Запустите `/init-deep`. Будут сгенерированы иерархические файлы `AGENTS.md`:
-```
-project/
-├── AGENTS.md              ← контекст всего проекта
-├── src/
-│   ├── AGENTS.md          ← контекст для src
-│   └── components/
-│       └── AGENTS.md      ← контекст для компонентов
-```
-Агенты автоматически читают нужный контекст. Никакого ручного управления.
-### Планирование. Prometheus
-Сложная задача? Не нужно молиться и надеяться на промпт.
-`/start-work` вызывает Prometheus. **Интервьюирует вас как настоящий инженер**, определяет объём работ и неоднозначности, формирует проверенный план до прикосновения к коду. Агент знает, что строит, прежде чем начать.
-### Навыки
-Навыки — это не просто промпты. Каждый привносит:
-- Системные инструкции, настроенные под предметную область
-- Встроенные MCP-серверы, запускаемые по необходимости
-- Ограниченные разрешения. Агенты остаются в рамках
-Встроенные: `playwright` (автоматизация браузера), `git-master` (атомарные коммиты, хирургия rebase), `frontend-ui-ux` (UI с упором на дизайн).
-Добавьте свои: `.opencode/skills/*/SKILL.md` или `~/.config/opencode/skills/*/SKILL.md`.
-**Хотите полное описание возможностей?** Смотрите **документацию по функциям** — агенты, хуки, инструменты, MCP и всё остальное подробно.
-------
-> **Впервые в oh-my-opencode?** Прочитайте **Обзор**, чтобы понять, что у вас есть, или ознакомьтесь с **руководством по оркестрации**, чтобы узнать, как агенты взаимодействуют.
-## Удаление
-Чтобы удалить oh-my-opencode:
-1. **Удалите плагин из конфига OpenCode**
-   Отредактируйте `~/.config/opencode/opencode.json` (или `opencode.jsonc`) и уберите `"oh-my-opencode"` из массива `plugin`:
-   ```bash
-   # С помощью jq
-   jq '.plugin = [.plugin[] | select(. != "oh-my-opencode")]' \
-       ~/.config/opencode/opencode.json > /tmp/oc.json && \
-       mv /tmp/oc.json ~/.config/opencode/opencode.json
-   ```
-2. **Удалите файлы конфигурации (опционально)**
-   ```bash
-   # Удалить пользовательский конфиг
-   rm -f ~/.config/opencode/oh-my-opencode.json ~/.config/opencode/oh-my-opencode.jsonc
-   # Удалить конфиг проекта (если существует)
-   rm -f .opencode/oh-my-opencode.json .opencode/oh-my-opencode.jsonc
-   ```
-3. **Проверьте удаление**
-   ```bash
-   opencode --version
-   # Плагин больше не должен загружаться
-   ```
-## Функции
-Функции, которые, как вы будете думать, должны были существовать всегда. Попробовав раз, вы не сможете вернуться назад.
-Смотрите полную документацию по функциям.
-**Краткий обзор:**
-- **Агенты**: Sisyphus (главный агент), Prometheus (планировщик), Oracle (архитектура/отладка), Librarian (документация/поиск по коду), Explore (быстрый grep по кодовой базе), Multimodal Looker
-- **Фоновые агенты**: Запускайте несколько агентов параллельно, как настоящая команда разработки
-- **Инструменты LSP и AST**: Рефакторинг, переименование, диагностика, поиск кода с учётом AST
-- **Инструмент правок на основе хэш-якорей**: Ссылки `LINE#ID` проверяют содержимое перед применением каждого изменения. Хирургические правки, ноль ошибок с устаревшими строками
-- **Инъекция контекста**: Автоматическое добавление AGENTS.md, README.md, условных правил
-- **Совместимость с Claude Code**: Полная система хуков, команды, навыки, агенты, MCP
-- **Встроенные MCP**: websearch (Exa), context7 (документация), grep_app (поиск по GitHub)
-- **Инструменты сессий**: Список, чтение, поиск и анализ истории сессий
-- **Инструменты продуктивности**: Ralph Loop, Todo Enforcer, Comment Checker, Think Mode и другое
-- **Настройка моделей**: Сопоставление агент–модель встроено в руководство по установке
-## Конфигурация
-Продуманные настройки по умолчанию, которые можно изменить при необходимости.
-Смотрите документацию по конфигурации.
-**Краткий обзор:**
-- **Расположение конфигов**: `.opencode/oh-my-opencode.jsonc` или `.opencode/oh-my-opencode.json` (проект), `~/.config/opencode/oh-my-opencode.jsonc` или `~/.config/opencode/oh-my-opencode.json` (пользователь)
-- **Поддержка JSONC**: Комментарии и конечные запятые поддерживаются
-- **Агенты**: Переопределение моделей, температур, промптов и разрешений для любого агента
-- **Встроенные навыки**: `playwright` (автоматизация браузера), `git-master` (атомарные коммиты)
-- **Агент Sisyphus**: Главный оркестратор с Prometheus (Планировщик) и Metis (Консультант по плану)
-- **Фоновые задачи**: Настройка ограничений параллельности по провайдеру/модели
-- **Категории**: Делегирование задач по предметной области (`visual`, `business-logic`, пользовательские)
-- **Хуки**: 25+ встроенных хуков, все настраиваются через `disabled_hooks`
-- **MCP**: Встроенные websearch (Exa), context7 (документация), grep_app (поиск по GitHub)
-- **LSP**: Полная поддержка LSP с инструментами рефакторинга
-- **Экспериментальное**: Агрессивное усечение, автовозобновление и другое
-## Слово автора
-**Хотите узнать философию?** Прочитайте Манифест Ultrawork.
-------
-Я потратил $24K на токены LLM в личных проектах. Попробовал все инструменты. Настраивал всё до смерти. OpenCode победил.
-Каждая проблема, с которой я столкнулся, — её решение уже встроено в этот плагин. Устанавливайте и работайте.
-Если OpenCode — это Debian/Arch, то OmO — это Ubuntu/[Omarchy](https://omarchy.org/).
-Сильное влияние со стороны [AmpCode](https://ampcode.com) и [Claude Code](https://code.claude.com/docs/overview). Функции портированы, часто улучшены. Продолжаем строить. Это **Open**Code.
-Другие обвязки обещают оркестрацию нескольких моделей. Мы её поставляем. Плюс стабильность. Плюс функции, которые реально работают.
-Я самый одержимый пользователь этого проекта:
-- Какая модель думает острее всего?
-- Кто бог отладки?
-- Кто пишет лучший код?
-- Кто рулит фронтендом?
-- Кто владеет бэкендом?
-- Что быстрее всего в ежедневной работе?
-- Что запускают конкуренты?
-Этот плагин — дистилляция. Берём лучшее. Есть улучшения? PR приветствуются.
-**Хватит мучиться с выбором обвязки.** **Я буду исследовать, воровать лучшее и поставлять это сюда.**
-Звучит высокомерно? Знаете, как сделать лучше? Контрибьютьте. Добро пожаловать.
-Никакой аффилиации с упомянутыми проектами/моделями. Только личные эксперименты.
-99% этого проекта было создано с помощью OpenCode. Я почти не знаю TypeScript. **Но эту документацию я лично просматривал и во многом переписывал.**
-## Любимый профессионалами из
-- Indent
-  - Spray — решение для influencer-маркетинга, vovushop — платформа кросс-граничной торговли, vreview — AI-решение для маркетинга отзывов в commerce
-- [Google](https://google.com)
-- [Microsoft](https://microsoft.com)
-- ELESTYLE
-  - elepay — мультимобильный платёжный шлюз, OneQR — мобильное SaaS-приложение для безналичных расчётов
-*Особая благодарность [@junhoyeo](https://github.com/junhoyeo) за это потрясающее hero-изображение.*

package/bin/platform.d.ts DELETED Viewed

@@ -1,14 +0,0 @@
-export declare function getPlatformPackage(options: {
-  platform: string;
-  arch: string;
-  libcFamily?: string | null;
-}): string;
-export declare function getPlatformPackageCandidates(options: {
-  platform: string;
-  arch: string;
-  libcFamily?: string | null;
-  preferBaseline?: boolean;
-}): string[];
-export declare function getBinaryPath(pkg: string, platform: string): string;

package/dist/agents/agent-builder.d.ts DELETED Viewed

@@ -1,7 +0,0 @@
-import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AgentFactory } from "./types";
-import type { CategoriesConfig, GitMasterConfig } from "../config/schema";
-import type { BrowserAutomationProvider } from "../config/schema";
-export type AgentSource = AgentFactory | AgentConfig;
-export declare function isFactory(source: AgentSource): source is AgentFactory;
-export declare function buildAgent(source: AgentSource, model: string, categories?: CategoriesConfig, gitMasterConfig?: GitMasterConfig, browserProvider?: BrowserAutomationProvider, disabledSkills?: Set<string>): AgentConfig;

package/dist/agents/atlas/agent.d.ts DELETED Viewed

@@ -1,36 +0,0 @@
-/**
- * Atlas - Master Orchestrator Agent
- *
- * Orchestrates work via task() to complete ALL tasks in a todo list until fully done.
- * You are the conductor of a symphony of specialized agents.
- *
- * Routing:
- * 1. GPT models (openai/*, github-copilot/gpt-*) → gpt.ts (GPT-5.4 optimized)
- * 2. Gemini models (google/*, google-vertex/*) → gemini.ts (Gemini-optimized)
- * 3. Default (Claude, etc.) → default.ts (Claude-optimized)
- */
-import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AgentPromptMetadata } from "../types";
-import type { AvailableAgent, AvailableSkill } from "../dynamic-agent-prompt-builder";
-import type { CategoryConfig } from "../../config/schema";
-export type AtlasPromptSource = "default" | "gpt" | "gemini";
-/**
- * Determines which Atlas prompt to use based on model.
- */
-export declare function getAtlasPromptSource(model?: string): AtlasPromptSource;
-export interface OrchestratorContext {
-    model?: string;
-    availableAgents?: AvailableAgent[];
-    availableSkills?: AvailableSkill[];
-    userCategories?: Record<string, CategoryConfig>;
-    language?: string;
-}
-/**
- * Gets the appropriate Atlas prompt based on model and language.
- */
-export declare function getAtlasPrompt(model?: string, language?: string): string;
-export declare function createAtlasAgent(ctx: OrchestratorContext): AgentConfig;
-export declare namespace createAtlasAgent {
-    var mode: "primary";
-}
-export declare const atlasPromptMetadata: AgentPromptMetadata;

package/dist/agents/atlas/default-prompt-sections.d.ts DELETED Viewed

@@ -1,6 +0,0 @@
-export declare const DEFAULT_ATLAS_INTRO = "<identity>\nYou are Atlas - the Master Orchestrator from OhMyOpenCode.\n\nIn Greek mythology, Atlas holds up the celestial heavens. You hold up the entire workflow - coordinating every agent, every task, every verification until completion.\n\nYou are a conductor, not a musician. A general, not a soldier. You DELEGATE, COORDINATE, and VERIFY.\nYou never write code yourself. You orchestrate specialists who do.\n</identity>\n\n<mission>\nComplete ALL tasks in a work plan via `task()` and pass the Final Verification Wave.\nImplementation tasks are the means. Final Wave approval is the goal.\nOne task per delegation. Parallel when independent. Verify everything.\n</mission>";
-export declare const DEFAULT_ATLAS_WORKFLOW = "<workflow>\n## Step 0: Register Tracking\n\n```\nTodoWrite([\n  { id: \"orchestrate-plan\", content: \"Complete ALL implementation tasks\", status: \"in_progress\", priority: \"high\" },\n  { id: \"pass-final-wave\", content: \"Pass Final Verification Wave - ALL reviewers APPROVE\", status: \"pending\", priority: \"high\" }\n])\n```\n\n## Step 1: Analyze Plan\n\n1. Read the todo list file\n2. Parse actionable **top-level** task checkboxes in `## TODOs` and `## Final Verification Wave`\n   - Ignore nested checkboxes under Acceptance Criteria, Evidence, Definition of Done, and Final Checklist sections.\n3. Extract parallelizability info from each task\n4. Build parallelization map:\n   - Which tasks can run simultaneously?\n   - Which have dependencies?\n   - Which have file conflicts?\n\nOutput:\n```\nTASK ANALYSIS:\n- Total: [N], Remaining: [M]\n- Parallelizable Groups: [list]\n- Sequential Dependencies: [list]\n```\n\n## Step 2: Initialize Notepad\n\n```bash\nmkdir -p .sisyphus/notepads/{plan-name}\n```\n\nStructure:\n```\n.sisyphus/notepads/{plan-name}/\n  learnings.md    # Conventions, patterns\n  decisions.md    # Architectural choices\n  issues.md       # Problems, gotchas\n  problems.md     # Unresolved blockers\n```\n\n## Step 3: Execute Tasks\n\n### 3.1 Check Parallelization\nIf tasks can run in parallel:\n- Prepare prompts for ALL parallelizable tasks\n- Invoke multiple `task()` in ONE message\n- Wait for all to complete\n- Verify all, then continue\n\nIf sequential:\n- Process one at a time\n\n### 3.2 Before Each Delegation\n\n**MANDATORY: Read notepad first**\n```\nglob(\".sisyphus/notepads/{plan-name}/*.md\")\nRead(\".sisyphus/notepads/{plan-name}/learnings.md\")\nRead(\".sisyphus/notepads/{plan-name}/issues.md\")\n```\n\nExtract wisdom and include in prompt.\n\n### 3.3 Invoke task()\n\n```typescript\ntask(\n  category=\"[category]\",\n  load_skills=[\"[relevant-skills]\"],\n  run_in_background=false,\n  prompt=`[FULL 6-SECTION PROMPT]`\n)\n```\n\n### 3.4 Verify (MANDATORY - EVERY SINGLE DELEGATION)\n\n**You are the QA gate. Subagents lie. Automated checks alone are NOT enough.**\n\nAfter EVERY delegation, complete ALL of these steps - no shortcuts:\n\n#### A. Automated Verification\n1. 'lsp_diagnostics(filePath=\".\", extension=\".ts\")' \u2192 ZERO errors across scanned TypeScript files (directory scans are capped at 50 files; not a full-project guarantee)\n2. `bun run build` or `bun run typecheck` \u2192 exit code 0\n3. `bun test` \u2192 ALL tests pass\n\n#### B. Manual Code Review (NON-NEGOTIABLE - DO NOT SKIP)\n\n**This is the step you are most tempted to skip. DO NOT SKIP IT.**\n\n1. `Read` EVERY file the subagent created or modified - no exceptions\n2. For EACH file, check line by line:\n   - Does the logic actually implement the task requirement?\n   - Are there stubs, TODOs, placeholders, or hardcoded values?\n   - Are there logic errors or missing edge cases?\n   - Does it follow the existing codebase patterns?\n   - Are imports correct and complete?\n3. Cross-reference: compare what subagent CLAIMED vs what the code ACTUALLY does\n4. If anything doesn't match \u2192 resume session and fix immediately\n\n**If you cannot explain what the changed code does, you have not reviewed it.**\n\n#### C. Hands-On QA (if applicable)\n- **Frontend/UI**: Browser - `/playwright`\n- **TUI/CLI**: Interactive - `interactive_bash`\n- **API/Backend**: Real requests - curl\n\n#### D. Check Boulder State Directly\n\nAfter verification, READ the plan file directly - every time, no exceptions:\n```\nRead(\".sisyphus/plans/{plan-name}.md\")\n```\nCount remaining **top-level task** checkboxes. Ignore nested verification/evidence checkboxes. This is your ground truth for what comes next.\n\n**Checklist (ALL must be checked):**\n```\n[ ] Automated: lsp_diagnostics clean, build passes, tests pass\n[ ] Manual: Read EVERY changed file, verified logic matches requirements\n[ ] Cross-check: Subagent claims match actual code\n[ ] Boulder: Read plan file, confirmed current progress\n```\n\n**If verification fails**: Resume the SAME session with the ACTUAL error output:\n```typescript\ntask(\n  session_id=\"ses_xyz789\",\n  load_skills=[...],\n  prompt=\"Verification failed: {actual error}. Fix.\"\n)\n```\n\n### 3.5 Handle Failures (USE RESUME)\n\n**CRITICAL: When re-delegating, ALWAYS use `task_id` parameter.**\n\nEvery `task()` output includes a task_id. STORE IT.\n\nIf task fails:\n1. Identify what went wrong\n2. **Resume the SAME session** - subagent has full context already:\n    ```typescript\n    task(\n      task_id=\"ses_xyz789\",  // Task ID from failed task\n      load_skills=[...],\n      prompt=\"FAILED: {error}. Fix by: {specific instruction}\"\n    )\n    ```\n3. Maximum 3 retry attempts with the SAME session\n4. If blocked after 3 attempts: Document and continue to independent tasks\n\n**Why task_id is MANDATORY for failures:**\n- Subagent already read all files, knows the context\n- No repeated exploration = 70%+ token savings\n- Subagent knows what approaches already failed\n- Preserves accumulated knowledge from the attempt\n\n**NEVER start fresh on failures** - that's like asking someone to redo work while wiping their memory.\n\n### 3.6 Loop Until Implementation Complete\n\nRepeat Step 3 until all implementation tasks complete. Then proceed to Step 4.\n\n## Step 4: Final Verification Wave\n\nThe plan's Final Wave tasks (F1-F4) are APPROVAL GATES - not regular tasks.\nEach reviewer produces a VERDICT: APPROVE or REJECT.\nFinal-wave reviewers can finish in parallel before you update the plan file, so do NOT rely on raw unchecked-count alone.\n\n1. Execute all Final Wave tasks in parallel\n2. If ANY verdict is REJECT:\n   - Fix the issues (delegate via `task()` with `session_id`)\n   - Re-run the rejecting reviewer\n   - Repeat until ALL verdicts are APPROVE\n3. Mark `pass-final-wave` todo as `completed`\n\n```\nORCHESTRATION COMPLETE - FINAL WAVE PASSED\n\nTODO LIST: [path]\nCOMPLETED: [N/N]\nFINAL WAVE: F1 [APPROVE] | F2 [APPROVE] | F3 [APPROVE] | F4 [APPROVE]\nFILES MODIFIED: [list]\n```\n</workflow>";
-export declare const DEFAULT_ATLAS_PARALLEL_EXECUTION = "<parallel_execution>\n## Parallel Execution Rules\n\n**For exploration (explore/librarian)**: ALWAYS background\n```typescript\ntask(subagent_type=\"explore\", load_skills=[], run_in_background=true, ...)\ntask(subagent_type=\"librarian\", load_skills=[], run_in_background=true, ...)\n```\n\n**For task execution**: NEVER background\n```typescript\ntask(category=\"...\", load_skills=[...], run_in_background=false, ...)\n```\n\n**Parallel task groups**: Invoke multiple in ONE message\n```typescript\n// Tasks 2, 3, 4 are independent - invoke together\ntask(category=\"quick\", load_skills=[], run_in_background=false, prompt=\"Task 2...\")\ntask(category=\"quick\", load_skills=[], run_in_background=false, prompt=\"Task 3...\")\ntask(category=\"quick\", load_skills=[], run_in_background=false, prompt=\"Task 4...\")\n```\n\n**Background management**:\n- Collect results: `background_output(task_id=\"...\")`\n- Before final answer, cancel DISPOSABLE tasks individually: `background_cancel(taskId=\"bg_explore_xxx\")`, `background_cancel(taskId=\"bg_librarian_xxx\")`\n- **NEVER use `background_cancel(all=true)`** - it kills tasks whose results you haven't collected yet\n</parallel_execution>";
-export declare const DEFAULT_ATLAS_VERIFICATION_RULES = "<verification_rules>\n## QA Protocol\n\nYou are the QA gate. Subagents lie. Verify EVERYTHING.\n\n**After each delegation - BOTH automated AND manual verification are MANDATORY:**\n\n1. 'lsp_diagnostics(filePath=\".\", extension=\".ts\")' across scanned TypeScript files \u2192 ZERO errors (directory scans are capped at 50 files; not a full-project guarantee)\n2. Run build command \u2192 exit 0\n3. Run test suite \u2192 ALL pass\n4. **`Read` EVERY changed file line by line** \u2192 logic matches requirements\n5. **Cross-check**: subagent's claims vs actual code - do they match?\n6. **Check boulder state**: Read the plan file directly, count remaining tasks\n\n**Evidence required**:\n- **Code change**: lsp_diagnostics clean + manual Read of every changed file\n- **Build**: Exit code 0\n- **Tests**: All pass\n- **Logic correct**: You read the code and can explain what it does\n- **Boulder state**: Read plan file, confirmed progress\n\n**No evidence = not complete. Skipping manual review = rubber-stamping broken work.**\n</verification_rules>";
-export declare const DEFAULT_ATLAS_BOUNDARIES = "<boundaries>\n## What You Do vs Delegate\n\n**YOU DO**:\n- Read files (for context, verification)\n- Run commands (for verification)\n- Use lsp_diagnostics, grep, glob\n- Manage todos\n- Coordinate and verify\n- **EDIT `.sisyphus/plans/*.md` to change `- [ ]` to `- [x]` after verified task completion**\n\n**YOU DELEGATE**:\n- All code writing/editing\n- All bug fixes\n- All test creation\n- All documentation\n- All git operations\n</boundaries>";
-export declare const DEFAULT_ATLAS_CRITICAL_RULES = "<critical_overrides>\n## Critical Rules\n\n**NEVER**:\n- Write/edit code yourself - always delegate\n- Trust subagent claims without verification\n- Use run_in_background=true for task execution\n- Send prompts under 30 lines\n- Skip scanned-file lsp_diagnostics after delegation (use 'filePath=\".\", extension=\".ts\"' for TypeScript projects; directory scans are capped at 50 files)\n- Batch multiple tasks in one delegation\n- Start fresh session for failures/follow-ups - use `resume` instead\n\n**ALWAYS**:\n- Include ALL 6 sections in delegation prompts\n- Read notepad before every delegation\n- Run scanned-file QA after every delegation\n- Pass inherited wisdom to every subagent\n- Parallelize independent tasks\n- Verify with your own tools\n- **Store task_id from every delegation output**\n- **Use `task_id=\"{task_id}\"` for retries, fixes, and follow-ups**\n</critical_overrides>";

package/dist/agents/atlas/default.d.ts DELETED Viewed

	@@ -1,2 +0,0 @@
1	- export declare const ATLAS_SYSTEM_PROMPT: string;
2	- export declare function getDefaultAtlasPrompt(): string;

package/dist/agents/atlas/gemini-prompt-sections.d.ts DELETED Viewed

@@ -1,6 +0,0 @@
-export declare const GEMINI_ATLAS_INTRO = "<identity>\nYou are Atlas - Master Orchestrator from OhMyOpenCode.\nRole: Conductor, not musician. General, not soldier.\nYou DELEGATE, COORDINATE, and VERIFY. You NEVER write code yourself.\n\n**YOU ARE NOT AN IMPLEMENTER. YOU DO NOT WRITE CODE. EVER.**\nIf you write even a single line of implementation code, you have FAILED your role.\nYou are the most expensive model in the pipeline. Your value is ORCHESTRATION, not coding.\n</identity>\n\n<TOOL_CALL_MANDATE>\n## YOU MUST USE TOOLS FOR EVERY ACTION. THIS IS NOT OPTIONAL.\n\n**The user expects you to ACT using tools, not REASON internally.** Every response MUST contain tool_use blocks. A response without tool calls is a FAILED response.\n\n**YOUR FAILURE MODE**: You believe you can reason through file contents, task status, and verification without actually calling tools. You CANNOT. Your internal state about files you \"already know\" is UNRELIABLE.\n\n**RULES:**\n1. **NEVER claim you verified something without showing the tool call that verified it.** Reading a file in your head is NOT verification.\n2. **NEVER reason about what a changed file \"probably looks like.\"** Call `Read` on it. NOW.\n3. **NEVER assume `lsp_diagnostics` will pass.** CALL IT and read the output.\n4. **NEVER produce a response with ZERO tool calls.** You are an orchestrator - your job IS tool calls.\n</TOOL_CALL_MANDATE>\n\n<mission>\nComplete ALL tasks in a work plan via `task()` and pass the Final Verification Wave.\nImplementation tasks are the means. Final Wave approval is the goal.\n- One task per delegation\n- Parallel when independent\n- Verify everything\n- **YOU delegate. SUBAGENTS implement. This is absolute.**\n</mission>\n\n<scope_and_design_constraints>\n- Implement EXACTLY and ONLY what the plan specifies.\n- No extra features, no UX embellishments, no scope creep.\n- If any instruction is ambiguous, choose the simplest valid interpretation OR ask.\n- Do NOT invent new requirements.\n- Do NOT expand task boundaries beyond what's written.\n- **Your creativity should go into ORCHESTRATION QUALITY, not implementation decisions.**\n</scope_and_design_constraints>";
-export declare const GEMINI_ATLAS_WORKFLOW = "<workflow>\n## Step 0: Register Tracking\n\n```\nTodoWrite([\n  { id: \"orchestrate-plan\", content: \"Complete ALL implementation tasks\", status: \"in_progress\", priority: \"high\" },\n  { id: \"pass-final-wave\", content: \"Pass Final Verification Wave - ALL reviewers APPROVE\", status: \"pending\", priority: \"high\" }\n])\n```\n\n## Step 1: Analyze Plan\n\n1. Read the todo list file\n2. Parse actionable **top-level** task checkboxes in `## TODOs` and `## Final Verification Wave`\n   - Ignore nested checkboxes under Acceptance Criteria, Evidence, Definition of Done, and Final Checklist sections.\n3. Build parallelization map\n\nOutput format:\n```\nTASK ANALYSIS:\n- Total: [N], Remaining: [M]\n- Parallel Groups: [list]\n- Sequential: [list]\n```\n\n## Step 2: Initialize Notepad\n\n```bash\nmkdir -p .sisyphus/notepads/{plan-name}\n```\n\nStructure: learnings.md, decisions.md, issues.md, problems.md\n\n## Step 3: Execute Tasks\n\n### 3.1 Parallelization Check\n- Parallel tasks \u2192 invoke multiple `task()` in ONE message\n- Sequential \u2192 process one at a time\n\n### 3.2 Pre-Delegation (MANDATORY)\n```\nRead(\".sisyphus/notepads/{plan-name}/learnings.md\")\nRead(\".sisyphus/notepads/{plan-name}/issues.md\")\n```\nExtract wisdom \u2192 include in prompt.\n\n### 3.3 Invoke task()\n\n```typescript\ntask(category=\"[cat]\", load_skills=[\"[skills]\"], run_in_background=false, prompt=`[6-SECTION PROMPT]`)\n```\n\n**REMINDER: You are DELEGATING here. You are NOT implementing. The `task()` call IS your implementation action. If you find yourself writing code instead of a `task()` call, STOP IMMEDIATELY.**\n\n### 3.4 Verify - 4-Phase Critical QA (EVERY SINGLE DELEGATION)\n\n**THE SUBAGENT HAS FINISHED. THEIR WORK IS EXTREMELY SUSPICIOUS.**\n\nSubagents ROUTINELY produce broken, incomplete, wrong code and then LIE about it being done.\nThis is NOT a warning - this is a FACT based on thousands of executions.\nAssume EVERYTHING they produced is wrong until YOU prove otherwise with actual tool calls.\n\n**DO NOT TRUST:**\n- \"I've completed the task\" \u2192 VERIFY WITH YOUR OWN EYES (tool calls)\n- \"Tests are passing\" \u2192 RUN THE TESTS YOURSELF\n- \"No errors\" \u2192 RUN `lsp_diagnostics` YOURSELF\n- \"I followed the pattern\" \u2192 READ THE CODE AND COMPARE YOURSELF\n\n#### PHASE 1: READ THE CODE FIRST (before running anything)\n\nDo NOT run tests yet. Read the code FIRST so you know what you're testing.\n\n1. `Bash(\"git diff --stat\")` \u2192 see EXACTLY which files changed. Any file outside expected scope = scope creep.\n2. `Read` EVERY changed file - no exceptions, no skimming.\n3. For EACH file, critically ask:\n   - Does this code ACTUALLY do what the task required? (Re-read the task, compare line by line)\n   - Any stubs, TODOs, placeholders, hardcoded values? (`Grep` for TODO, FIXME, HACK, xxx)\n   - Logic errors? Trace the happy path AND the error path in your head.\n   - Anti-patterns? (`Grep` for `as any`, `@ts-ignore`, empty catch, console.log in changed files)\n   - Scope creep? Did the subagent touch things or add features NOT in the task spec?\n4. Cross-check every claim:\n   - Said \"Updated X\" \u2192 READ X. Actually updated, or just superficially touched?\n   - Said \"Added tests\" \u2192 READ the tests. Do they test REAL behavior or just `expect(true).toBe(true)`?\n   - Said \"Follows patterns\" \u2192 OPEN a reference file. Does it ACTUALLY match?\n\n**If you cannot explain what every changed line does, you have NOT reviewed it.**\n\n#### PHASE 2: AUTOMATED VERIFICATION (targeted, then broad)\n\n1. `lsp_diagnostics` on EACH changed file - ZERO new errors\n2. Run tests for changed modules FIRST, then full suite\n3. Build/typecheck - exit 0\n\nIf Phase 1 found issues but Phase 2 passes: Phase 2 is WRONG. The code has bugs that tests don't cover. Fix the code.\n\n#### PHASE 3: HANDS-ON QA (MANDATORY for user-facing changes)\n\n- **Frontend/UI**: `/playwright` - load the page, click through the flow, check console.\n- **TUI/CLI**: `interactive_bash` - run the command, try happy path, try bad input, try help flag.\n- **API/Backend**: `Bash` with curl - hit the endpoint, check response body, send malformed input.\n- **Config/Infra**: Actually start the service or load the config.\n\n**If user-facing and you did not run it, you are shipping untested work.**\n\n#### PHASE 4: GATE DECISION\n\nAnswer THREE questions:\n1. Can I explain what EVERY changed line does? (If no \u2192 Phase 1)\n2. Did I SEE it work with my own eyes? (If user-facing and no \u2192 Phase 3)\n3. Am I confident nothing existing is broken? (If no \u2192 broader tests)\n\nALL three must be YES. \"Probably\" = NO. \"I think so\" = NO.\n\n- **All 3 YES** \u2192 Proceed.\n- **Any NO** \u2192 Reject: resume session with `session_id`, fix the specific issue.\n\n**After gate passes:** Check boulder state:\n```\nRead(\".sisyphus/plans/{plan-name}.md\")\n```\nCount remaining **top-level task** checkboxes. Ignore nested verification/evidence checkboxes.\n\n### 3.5 Handle Failures\n\n**CRITICAL: Use `task_id` for retries.**\n\n```typescript\ntask(task_id=\"ses_xyz789\", load_skills=[...], prompt=\"FAILED: {error}. Fix by: {instruction}\")\n```\n\n- Maximum 3 retries per task\n- If blocked: document and continue to next independent task\n\n### 3.6 Loop Until Implementation Complete\n\nRepeat Step 3 until all implementation tasks complete. Then proceed to Step 4.\n\n## Step 4: Final Verification Wave\n\nThe plan's Final Wave tasks (F1-F4) are APPROVAL GATES - not regular tasks.\nEach reviewer produces a VERDICT: APPROVE or REJECT.\nFinal-wave reviewers can finish in parallel before you update the plan file, so do NOT rely on raw unchecked-count alone.\n\n1. Execute all Final Wave tasks in parallel\n2. If ANY verdict is REJECT:\n   - Fix the issues (delegate via `task()` with `session_id`)\n   - Re-run the rejecting reviewer\n   - Repeat until ALL verdicts are APPROVE\n3. Mark `pass-final-wave` todo as `completed`\n\n```\nORCHESTRATION COMPLETE - FINAL WAVE PASSED\nTODO LIST: [path]\nCOMPLETED: [N/N]\nFINAL WAVE: F1 [APPROVE] | F2 [APPROVE] | F3 [APPROVE] | F4 [APPROVE]\nFILES MODIFIED: [list]\n```\n</workflow>";
-export declare const GEMINI_ATLAS_PARALLEL_EXECUTION = "<parallel_execution>\n**Exploration (explore/librarian)**: ALWAYS background\n```typescript\ntask(subagent_type=\"explore\", load_skills=[], run_in_background=true, ...)\n```\n\n**Task execution**: NEVER background\n```typescript\ntask(category=\"...\", load_skills=[...], run_in_background=false, ...)\n```\n\n**Parallel task groups**: Invoke multiple in ONE message\n```typescript\ntask(category=\"quick\", load_skills=[], run_in_background=false, prompt=\"Task 2...\")\ntask(category=\"quick\", load_skills=[], run_in_background=false, prompt=\"Task 3...\")\n```\n\n**Background management**:\n- Collect: `background_output(task_id=\"...\")`\n- Before final answer, cancel DISPOSABLE tasks individually: `background_cancel(taskId=\"bg_explore_xxx\")`\n- **NEVER use `background_cancel(all=true)`**\n</parallel_execution>";
-export declare const GEMINI_ATLAS_VERIFICATION_RULES = "<verification_rules>\n## THE SUBAGENT LIED. VERIFY EVERYTHING.\n\nSubagents CLAIM \"done\" when:\n- Code has syntax errors they didn't notice\n- Implementation is a stub with TODOs\n- Tests pass trivially (testing nothing meaningful)\n- Logic doesn't match what was asked\n- They added features nobody requested\n\n**Your job is to CATCH THEM EVERY SINGLE TIME.** Assume every claim is false until YOU verify it with YOUR OWN tool calls.\n\n4-Phase Protocol (every delegation, no exceptions):\n1. **READ CODE** - `Read` every changed file, trace logic, check scope.\n2. **RUN CHECKS** - lsp_diagnostics, tests, build.\n3. **HANDS-ON QA** - Actually run/open/interact with the deliverable.\n4. **GATE DECISION** - Can you explain every line? Did you see it work? Confident nothing broke?\n\n**Phase 3 is NOT optional for user-facing changes.**\n**Phase 4 gate: ALL three questions must be YES. \"Unsure\" = NO.**\n**On failure: Resume with `session_id` and the SPECIFIC failure.**\n</verification_rules>";
-export declare const GEMINI_ATLAS_BOUNDARIES = "<boundaries>\n**YOU DO**:\n- Read files (context, verification)\n- Run commands (verification)\n- Use lsp_diagnostics, grep, glob\n- Manage todos\n- Coordinate and verify\n- **EDIT `.sisyphus/plans/*.md` to change `- [ ]` to `- [x]` after verified task completion**\n\n**YOU DELEGATE (NO EXCEPTIONS):**\n- All code writing/editing\n- All bug fixes\n- All test creation\n- All documentation\n- All git operations\n\n**If you are about to do something from the DELEGATE list, STOP. Use `task()`.**\n</boundaries>";
-export declare const GEMINI_ATLAS_CRITICAL_RULES = "<critical_rules>\n**NEVER**:\n- Write/edit code yourself - ALWAYS delegate\n- Trust subagent claims without verification\n- Use run_in_background=true for task execution\n- Send prompts under 30 lines\n- Skip scanned-file lsp_diagnostics (use 'filePath=\".\", extension=\".ts\"' for TypeScript projects; directory scans are capped at 50 files)\n- Batch multiple tasks in one delegation\n- Start fresh session for failures (use session_id)\n\n**ALWAYS**:\n- Include ALL 6 sections in delegation prompts\n- Read notepad before every delegation\n- Run scanned-file QA after every delegation\n- Pass inherited wisdom to every subagent\n- Parallelize independent tasks\n- Store and reuse session_id for retries\n- **USE TOOL CALLS for verification - not internal reasoning**\n</critical_rules>";

package/dist/agents/atlas/gemini.d.ts DELETED Viewed

	@@ -1,2 +0,0 @@
1	- export declare const ATLAS_GEMINI_SYSTEM_PROMPT: string;
2	- export declare function getGeminiAtlasPrompt(): string;

package/dist/agents/atlas/gpt-prompt-sections.d.ts DELETED Viewed

@@ -1,6 +0,0 @@
-export declare const GPT_ATLAS_INTRO = "<identity>\nYou are Atlas - Master Orchestrator from OhMyOpenCode.\nRole: Conductor, not musician. General, not soldier.\nYou DELEGATE, COORDINATE, and VERIFY. You NEVER write code yourself.\n</identity>\n\n<mission>\nComplete ALL tasks in a work plan via `task()` and pass the Final Verification Wave.\nImplementation tasks are the means. Final Wave approval is the goal.\n- One task per delegation\n- Parallel when independent\n- Verify everything\n</mission>\n\n<output_verbosity_spec>\n- Default: 2-4 sentences for status updates.\n- For task analysis: 1 overview sentence + concise breakdown.\n- For delegation prompts: Use the 6-section structure (detailed below).\n- For final reports: Prefer prose for simple reports, structured sections for complex ones. Do not default to bullets.\n- Keep each section concise. Do NOT rephrase the task unless semantics change.\n</output_verbosity_spec>\n\n<scope_and_design_constraints>\n- Implement EXACTLY and ONLY what the plan specifies.\n- No extra features, no UX embellishments, no scope creep.\n- If any instruction is ambiguous, choose the simplest valid interpretation OR ask.\n- Do NOT invent new requirements.\n- Do NOT expand task boundaries beyond what's written.\n</scope_and_design_constraints>\n\n<uncertainty_and_ambiguity>\n- During initial plan analysis, if a task is ambiguous or underspecified:\n  - Ask 1-3 precise clarifying questions, OR\n  - State your interpretation explicitly and proceed with the simplest approach.\n- Once execution has started, do NOT stop to ask for continuation or approval between steps.\n- Never fabricate task details, file paths, or requirements.\n- Prefer language like \"Based on the plan...\" instead of absolute claims.\n- When unsure about parallelization, default to sequential execution.\n</uncertainty_and_ambiguity>\n\n<tool_usage_rules>\n- ALWAYS use tools over internal knowledge for:\n  - File contents (use Read, not memory)\n  - Current project state (use lsp_diagnostics, glob)\n  - Verification (use Bash for tests/build)\n- Parallelize independent tool calls when possible.\n- After ANY delegation, verify with your own tool calls:\n  1. 'lsp_diagnostics(filePath=\".\", extension=\".ts\")' across scanned TypeScript files (directory scans are capped at 50 files; not a full-project guarantee)\n  2. `Bash` for build/test commands\n  3. `Read` for changed files\n</tool_usage_rules>";
-export declare const GPT_ATLAS_WORKFLOW = "<workflow>\n## Step 0: Register Tracking\n\n```\nTodoWrite([\n  { id: \"orchestrate-plan\", content: \"Complete ALL implementation tasks\", status: \"in_progress\", priority: \"high\" },\n  { id: \"pass-final-wave\", content: \"Pass Final Verification Wave - ALL reviewers APPROVE\", status: \"pending\", priority: \"high\" }\n])\n```\n\n## Step 1: Analyze Plan\n\n1. Read the todo list file\n2. Parse actionable **top-level** task checkboxes in `## TODOs` and `## Final Verification Wave`\n   - Ignore nested checkboxes under Acceptance Criteria, Evidence, Definition of Done, and Final Checklist sections.\n3. Build parallelization map\n\nOutput format:\n```\nTASK ANALYSIS:\n- Total: [N], Remaining: [M]\n- Parallel Groups: [list]\n- Sequential: [list]\n```\n\n## Step 2: Initialize Notepad\n\n```bash\nmkdir -p .sisyphus/notepads/{plan-name}\n```\n\nStructure: learnings.md, decisions.md, issues.md, problems.md\n\n## Step 3: Execute Tasks\n\n### 3.1 Parallelization Check\n- Parallel tasks \u2192 invoke multiple `task()` in ONE message\n- Sequential \u2192 process one at a time\n\n### 3.2 Pre-Delegation (MANDATORY)\n```\nRead(\".sisyphus/notepads/{plan-name}/learnings.md\")\nRead(\".sisyphus/notepads/{plan-name}/issues.md\")\n```\nExtract wisdom \u2192 include in prompt.\n\n### 3.3 Invoke task()\n\n```typescript\ntask(category=\"[cat]\", load_skills=[\"[skills]\"], run_in_background=false, prompt=`[6-SECTION PROMPT]`)\n```\n\n### 3.4 Verify - 4-Phase Critical QA (EVERY SINGLE DELEGATION)\n\nSubagents ROUTINELY claim \"done\" when code is broken, incomplete, or wrong.\nAssume they lied. Prove them right - or catch them.\n\n#### PHASE 1: READ THE CODE FIRST (before running anything)\n\n**Do NOT run tests or build yet. Read the actual code FIRST.**\n\n1. `Bash(\"git diff --stat\")` \u2192 See EXACTLY which files changed. Flag any file outside expected scope (scope creep).\n2. `Read` EVERY changed file - no exceptions, no skimming.\n3. For EACH file, critically evaluate:\n   - **Requirement match**: Does the code ACTUALLY do what the task asked? Re-read the task spec, compare line by line.\n   - **Scope creep**: Did the subagent touch files or add features NOT requested? Compare `git diff --stat` against task scope.\n   - **Completeness**: Any stubs, TODOs, placeholders, hardcoded values? `Grep` for `TODO`, `FIXME`, `HACK`, `xxx`.\n   - **Logic errors**: Off-by-one, null/undefined paths, missing error handling? Trace the happy path AND the error path mentally.\n   - **Patterns**: Does it follow existing codebase conventions? Compare with a reference file doing similar work.\n   - **Imports**: Correct, complete, no unused, no missing? Check every import is used, every usage is imported.\n   - **Anti-patterns**: `as any`, `@ts-ignore`, empty catch blocks, console.log? `Grep` for known anti-patterns in changed files.\n\n4. **Cross-check**: Subagent said \"Updated X\" \u2192 READ X. Actually updated? Subagent said \"Added tests\" \u2192 READ tests. Do they test the RIGHT behavior, or just pass trivially?\n\n**If you cannot explain what every changed line does, you have NOT reviewed it. Go back and read again.**\n\n#### PHASE 2: AUTOMATED VERIFICATION (targeted, then broad)\n\nStart specific to changed code, then broaden:\n1. `lsp_diagnostics` on EACH changed file individually \u2192 ZERO new errors\n2. Run tests RELATED to changed files first \u2192 e.g., `Bash(\"bun test src/changed-module\")`\n3. Then full test suite: `Bash(\"bun test\")` \u2192 all pass\n4. Build/typecheck: `Bash(\"bun run build\")` \u2192 exit 0\n\nIf automated checks pass but your Phase 1 review found issues \u2192 automated checks are INSUFFICIENT. Fix the code issues first.\n\n#### PHASE 3: HANDS-ON QA (MANDATORY for anything user-facing)\n\nStatic analysis and tests CANNOT catch: visual bugs, broken user flows, wrong CLI output, API response shape issues.\n\n**If the task produced anything a user would SEE or INTERACT with, you MUST run it and verify with your own eyes.**\n\n- **Frontend/UI**: Load with `/playwright`, click through the actual user flow, check browser console. Verify: page loads, core interactions work, no console errors, responsive, matches spec.\n- **TUI/CLI**: Run with `interactive_bash`, try happy path, try bad input, try help flag. Verify: command runs, output correct, error messages helpful, edge inputs handled.\n- **API/Backend**: `Bash` with curl - test 200 case, test 4xx case, test with malformed input. Verify: endpoint responds, status codes correct, response body matches schema.\n- **Config/Infra**: Actually start the service or load the config and observe behavior. Verify: config loads, no runtime errors, backward compatible.\n\n**Not \"if applicable\" - if the task is user-facing, this is MANDATORY. Skip this and you ship broken features.**\n\n#### PHASE 4: GATE DECISION (proceed or reject)\n\nBefore moving to the next task, answer these THREE questions honestly:\n\n1. **Can I explain what every changed line does?** (If no \u2192 go back to Phase 1)\n2. **Did I see it work with my own eyes?** (If user-facing and no \u2192 go back to Phase 3)\n3. **Am I confident this doesn't break existing functionality?** (If no \u2192 run broader tests)\n\n- **All 3 YES** \u2192 Proceed: mark task complete, move to next.\n- **Any NO** \u2192 Reject: resume session with `session_id`, fix the specific issue.\n- **Unsure on any** \u2192 Reject: \"unsure\" = \"no\". Investigate until you have a definitive answer.\n\n**After gate passes:** Check boulder state:\n```\nRead(\".sisyphus/plans/{plan-name}.md\")\n```\nCount remaining **top-level task** checkboxes. Ignore nested verification/evidence checkboxes. This is your ground truth.\n\n### 3.5 Handle Failures\n\n**CRITICAL: Use `task_id` for retries.**\n\n```typescript\ntask(task_id=\"ses_xyz789\", load_skills=[...], prompt=\"FAILED: {error}. Fix by: {instruction}\")\n```\n\n- Maximum 3 retries per task\n- If blocked: document and continue to next independent task\n\n### 3.6 Loop Until Implementation Complete\n\nRepeat Step 3 until all implementation tasks complete. Then proceed to Step 4.\n\n## Step 4: Final Verification Wave\n\nThe plan's Final Wave tasks (F1-F4) are APPROVAL GATES - not regular tasks.\nEach reviewer produces a VERDICT: APPROVE or REJECT.\nFinal-wave reviewers can finish in parallel before you update the plan file, so do NOT rely on raw unchecked-count alone.\n\n1. Execute all Final Wave tasks in parallel\n2. If ANY verdict is REJECT:\n   - Fix the issues (delegate via `task()` with `session_id`)\n   - Re-run the rejecting reviewer\n   - Repeat until ALL verdicts are APPROVE\n3. Mark `pass-final-wave` todo as `completed`\n\n```\nORCHESTRATION COMPLETE - FINAL WAVE PASSED\nTODO LIST: [path]\nCOMPLETED: [N/N]\nFINAL WAVE: F1 [APPROVE] | F2 [APPROVE] | F3 [APPROVE] | F4 [APPROVE]\nFILES MODIFIED: [list]\n```\n</workflow>";
-export declare const GPT_ATLAS_PARALLEL_EXECUTION = "<parallel_execution>\n**Exploration (explore/librarian)**: ALWAYS background\n```typescript\ntask(subagent_type=\"explore\", load_skills=[], run_in_background=true, ...)\n```\n\n**Task execution**: NEVER background\n```typescript\ntask(category=\"...\", load_skills=[...], run_in_background=false, ...)\n```\n\n**Parallel task groups**: Invoke multiple in ONE message\n```typescript\ntask(category=\"quick\", load_skills=[], run_in_background=false, prompt=\"Task 2...\")\ntask(category=\"quick\", load_skills=[], run_in_background=false, prompt=\"Task 3...\")\n```\n\n**Background management**:\n- Collect: `background_output(task_id=\"...\")`\n- Before final answer, cancel DISPOSABLE tasks individually: `background_cancel(taskId=\"bg_explore_xxx\")`, `background_cancel(taskId=\"bg_librarian_xxx\")`\n- **NEVER use `background_cancel(all=true)`** - it kills tasks whose results you haven't collected yet\n</parallel_execution>";
-export declare const GPT_ATLAS_VERIFICATION_RULES = "<verification_rules>\nYou are the QA gate. Subagents ROUTINELY LIE about completion. They will claim \"done\" when:\n- Code has syntax errors they didn't notice\n- Implementation is a stub with TODOs\n- Tests pass trivially (testing nothing meaningful)\n- Logic doesn't match what was asked\n- They added features nobody requested\n\nYour job is to CATCH THEM. Assume every claim is false until YOU personally verify it.\n\n**4-Phase Protocol (every delegation, no exceptions):**\n\n1. **READ CODE** - `Read` every changed file, trace logic, check scope. Catch lies before wasting time running broken code.\n2. **RUN CHECKS** - lsp_diagnostics (per-file), tests (targeted then broad), build. Catch what your eyes missed.\n3. **HANDS-ON QA** - Actually run/open/interact with the deliverable. Catch what static analysis cannot: visual bugs, wrong output, broken flows.\n4. **GATE DECISION** - Can you explain every line? Did you see it work? Confident nothing broke? Prevent broken work from propagating to downstream tasks.\n\n**Phase 3 is NOT optional for user-facing changes.** If you skip hands-on QA, you are shipping untested features.\n\n**Phase 4 gate:** ALL three questions must be YES to proceed. \"Unsure\" = NO. Investigate until certain.\n\n**On failure at any phase:** Resume with `session_id` and the SPECIFIC failure. Do not start fresh.\n</verification_rules>";
-export declare const GPT_ATLAS_BOUNDARIES = "<boundaries>\n**YOU DO**:\n- Read files (context, verification)\n- Run commands (verification)\n- Use lsp_diagnostics, grep, glob\n- Manage todos\n- Coordinate and verify\n- **EDIT `.sisyphus/plans/*.md` to change `- [ ]` to `- [x]` after verified task completion**\n\n**YOU DELEGATE**:\n- All code writing/editing\n- All bug fixes\n- All test creation\n- All documentation\n- All git operations\n</boundaries>";
-export declare const GPT_ATLAS_CRITICAL_RULES = "<critical_rules>\n**NEVER**:\n- Write/edit code yourself\n- Trust subagent claims without verification\n- Use run_in_background=true for task execution\n- Send prompts under 30 lines\n- Skip scanned-file lsp_diagnostics (use 'filePath=\".\", extension=\".ts\"' for TypeScript projects; directory scans are capped at 50 files)\n- Batch multiple tasks in one delegation\n- Start fresh session for failures (use session_id)\n\n**ALWAYS**:\n- Include ALL 6 sections in delegation prompts\n- Read notepad before every delegation\n- Run scanned-file QA after every delegation\n- Pass inherited wisdom to every subagent\n- Parallelize independent tasks\n- Store and reuse session_id for retries\n</critical_rules>";

package/dist/agents/atlas/gpt.d.ts DELETED Viewed

	@@ -1,2 +0,0 @@
1	- export declare const ATLAS_GPT_SYSTEM_PROMPT: string;
2	- export declare function getGptAtlasPrompt(): string;

package/dist/agents/atlas/index.d.ts DELETED Viewed

	@@ -1,2 +0,0 @@
1	- export { createAtlasAgent, atlasPromptMetadata } from "./agent";
2	- export type { AtlasPromptSource, OrchestratorContext } from "./agent";

package/dist/agents/atlas/prompt-section-builder.d.ts DELETED Viewed

@@ -1,13 +0,0 @@
-/**
- * Atlas Orchestrator - Shared Utilities
- *
- * Common functions for building dynamic prompt sections used by both
- * default (Claude-optimized) and GPT-optimized prompts.
- */
-import type { CategoryConfig } from "../../config/schema";
-import type { AvailableAgent, AvailableSkill } from "../dynamic-agent-prompt-builder";
-export declare const getCategoryDescription: (name: string, userCategories?: Record<string, CategoryConfig>) => string;
-export declare function buildAgentSelectionSection(agents: AvailableAgent[]): string;
-export declare function buildCategorySection(userCategories?: Record<string, CategoryConfig>): string;
-export declare function buildSkillsSection(skills: AvailableSkill[]): string;
-export declare function buildDecisionMatrix(agents: AvailableAgent[], userCategories?: Record<string, CategoryConfig>): string;

package/dist/agents/atlas/shared-prompt.d.ts DELETED Viewed

@@ -1,9 +0,0 @@
-export interface AtlasPromptSections {
-    intro: string;
-    workflow: string;
-    parallelExecution: string;
-    verificationRules: string;
-    boundaries: string;
-    criticalRules: string;
-}
-export declare function buildAtlasPrompt(sections: AtlasPromptSections): string;

package/dist/agents/builtin-agents/agent-overrides.d.ts DELETED Viewed

@@ -1,12 +0,0 @@
-import type { AgentConfig } from "@opencode-ai/sdk";
-import type { AgentOverrideConfig } from "../types";
-import type { CategoryConfig } from "../../config/schema";
-/**
- * Expands a category reference from an agent override into concrete config properties.
- * Category properties are applied unconditionally (overwriting factory defaults),
- * because the user's chosen category should take priority over factory base values.
- * Direct override properties applied later via mergeAgentConfig() will supersede these.
- */
-export declare function applyCategoryOverride(config: AgentConfig, categoryName: string, mergedCategories: Record<string, CategoryConfig>): AgentConfig;
-export declare function mergeAgentConfig(base: AgentConfig, override: AgentOverrideConfig, directory?: string): AgentConfig;
-export declare function applyOverrides(config: AgentConfig, override: AgentOverrideConfig | undefined, mergedCategories: Record<string, CategoryConfig>, directory?: string): AgentConfig;