tinyteam

Аналитик пишет требования в своём OpenSpec-репозитории, вы работаете над ними в своём проекте с моделью в GigaCode или Qwen Code. tinyteam фиксирует, какую именно редакцию требований вы приняли, какую часть работы делаете здесь, какие ещё документы и решения к ней относятся, — и отдаёт всё это модели с каждой командой OpenSpec для этого change.

Термины

Быстрый старт

1. Установить tinyteam (раздел ниже): git clone <адрес репозитория tinyteam> ~/tinyteam, затем node ~/tinyteam/cli.cjs install и строка PATH, которую он напечатает.
2. В проекте подключить OpenSpec: openspec init --tools qwen; для GigaCode затем mv .qwen .gigacode.
3. Подключить tinyteam: tinyteam init --tools gigacode (или qwen) и проверить: tinyteam doctor — все строки с ✓.
4. Зарегистрировать store аналитика (его клон у вас): openspec store register ~/analyst-store --id analyst.
5. В GigaCode: /spec-consume analyst add-invoices. Модель покажет редакцию, предложит change и область — ответьте «да» и подтвердите окна харнесса.
6. Работа: /opsx-propose add-invoices, затем /opsx-apply add-invoices.
7. Модель сделала срез и остановилась — примите его: tinyteam approve add-invoices slice 1.1 (или скажите ей «подтверди срез 1.1 в add-invoices») и продолжайте /opsx-apply add-invoices.

Установка и обновление

Нужны Node.js 20 (от 20.17), 22 (от 22.13) или 23.5 и новее, git и OpenSpec (проверено с 1.13.0). На неподходящем Node tinyteam сразу скажет, какой нужен. Выпуск лежит в корне git-репозитория tinyteam (cli.cjs и SHA256SUMS), поэтому клон репозитория — источник и установки, и обновлений:

git clone <адрес репозитория tinyteam> ~/tinyteam
node ~/tinyteam/cli.cjs install                  # в ~/.local/share/tinyteam, без сети
export PATH=~/.local/share/tinyteam/bin:"$PATH"  # строку для ~/.bashrc печатает install
tinyteam --version

tinyteam install [--dir каталог] проверяет файл по SHA256SUMS, отказывает в каталоге, занятом чужими файлами, и не меняет файлы shell. Установленный tinyteam от каталога выпуска не зависит, но сам каталог (клон или папку в репозитории) не перемещайте: upgrade находит его по записанному пути.

Выпуск в репозитории аналитика. cli.cjs и SHA256SUMS из архива выпуска можно положить в папку любого git-репозитория, который у команды уже есть, — например tinyteam/ в репозитории аналитика — и ставить оттуда: node ~/analyst-store/tinyteam/cli.cjs install. Можно ставить и из распакованного архива.

Каталог установки — собственный каталог tinyteam: install кладёт в него cli.cjs, bin/tinyteam и releases и при обновлении заменяет их целиком, поэтому не делит его с другими программами. Для --dir ~/.local/share будет отказ «каталог занят» с подсказкой --dir ~/.local/share/tinyteam — это и есть значение по умолчанию.

Обновление — два шага: обновите каталог выпуска сами (git pull репозитория, где он лежит, или новые файлы из архива), затем tinyteam upgrade — он ставит то, что сейчас лежит в каталоге выпуска. Сам tinyteam git не вызывает и в сеть не ходит; если версия в каталоге та же, он так и скажет, а более старую версию без явной команды не поставит. Установка, сделанная выпуском до 30 сентября 2026, на upgrade ещё пытается сделать git pull: один раз поставьте новый выпуск командой node <каталог выпуска>/cli.cjs install.

git -C ~/analyst-store pull   # или новые файлы выпуска
tinyteam upgrade
# затем в каждом подключённом проекте:
tinyteam init --update

Удаление. Команды нет: удалите ~/.local/share/tinyteam, журнал ~/.local/state/tinyteam, клон ~/tinyteam и строку PATH из ~/.bashrc. В проекте — записи hook с именем tinyteam из .gigacode/settings.json (или .qwen/settings.json), файлы commands/spec-consume.md и skills/tinyteam*, кэш .tinyteam/cache; в .tinyteam/additions лежат ваши дополнения — их сохраните, если нужны. Файлы change (source.json, scope.json…) — часть истории работы, их можно оставить.

Подключение проекта

OpenSpec 1.13.0 не знает GigaCode, но GigaCode читает те же файлы из .gigacode/:

openspec init --tools qwen
mv .qwen .gigacode                # только для GigaCode
tinyteam init --tools gigacode    # или --tools qwen

Чтобы работать в GigaCode и Qwen Code на одних файлах, .qwen можно сделать ссылкой на .gigacode (ln -s .gigacode .qwen): tinyteam считает их одним каталогом, подключает через --tools gigacode, а doctor показывает ссылку строкой с ✓ и проверяет для неё ваши настройки ~/.qwen/settings.json. Ссылка куда-либо ещё, в том числе за пределы проекта, по-прежнему отклоняется.

Qwen Code выполняет hooks проекта только в доверенной папке (для GigaCode ожидается то же, это проверяется на целевой машине): при первом запуске в проекте согласитесь доверять ей. В проверяемом примере ниже — Qwen:

tinyteam init --tools qwen

init кладёт в .gigacode/ или .qwen/ две записи hook в settings.json, команду /spec-consume, навыки tinyteam и tinyteam-schema и пресет базового процесса. Без --tools в терминале — выбор списком. Чужие настройки и файлы не перезаписываются; после переноса или обновления tinyteam своё заменяет tinyteam init --update.

tinyteam doctor

✓ .qwen: hook tinyteam от этой установки
✓ .qwen: команда /spec-consume от этой установки
✓ .qwen: навык tinyteam от этой установки
✓ .qwen: навык tinyteam-schema от этой установки
✓ .qwen: пресет base-process от этой установки

Принять требования

Store аналитика нужно один раз зарегистрировать: openspec store register <путь к клону> --id analyst. Затем в GigaCode:

/spec-consume <store> <source-change> [local-change]
/spec-consume analyst add-invoices

Третий аргумент — ваш change, куда принимать. Без него модель предложит существующий change или новый с именем source change. Без аргументов модель покажет списки store и source change и попросит выбрать.

Что делает модель:

1. Выполняет source preview: показывает store, change, commit и документы и пересказывает proposal. Ничего не меняет.
2. Выбирает, куда принимать, и схему для нового change: одна схема в проекте — берёт её, несколько — показывает список.
3. Если у change нет области — подбирает её по структуре проекта и требованиям: назначение и корни, с объяснением одной фразой. Заданную область показывает и не меняет.
4. Спрашивает одним вопросом: «Создать change … со схемой …, принять эту редакцию и задать область …?» — и останавливается.
5. После вашего «да»: openspec new change (для нового change), tinyteam source accept … --commit <показанный>, затем tinyteam scope set …. Перед accept и scope set харнесс должен показать окно подтверждения (по коду Qwen; см. примечание ниже) — подтвердите.
6. Называет следующий шаг — обычно /opsx-propose add-invoices или /opsx-continue add-invoices.

То же вручную в терминале:

tinyteam source preview analyst add-invoices          # только читает; незакоммиченное в store не видно
openspec new change add-invoices                      # если change ещё нет
tinyteam source accept analyst changes/add-invoices --commit <SHA> --into add-invoices
tinyteam scope set add-invoices --purpose frontend --change apps/web
tinyteam source context add-invoices                  # принятые документы на принятом commit

Source change в accept — значение строки Change: из вывода preview (changes/<имя> или changes/archive/<каталог>); --commit — полный SHA из строки Commit:. Чтобы посмотреть другую редакцию, передайте её SHA: tinyteam source preview analyst add-invoices --commit <SHA>.

Команды OpenSpec с контекстом

Команды OpenSpec — штатные: /opsx-propose, /opsx-continue, /opsx-apply, /opsx-update, /opsx-verify и другие. Назовите change первым аргументом, и hook добавит модели его контекст:

/opsx-propose add-invoices продолжи этот change по принятым требованиям
/opsx-apply add-invoices

Модель получает commit принятой редакции и пути к проверенным копиям proposal, delta и master specs. Сами тексты не вставляются, и её просят не перечитывать уже прочитанное (в прогоне она так и делала). Если у change есть область, материалы или решения — они тоже.

• Если change не назван, а в проекте есть change, для которых tinyteam что-то хранит (источник, область, материалы или решения), /opsx-apply, /opsx-continue, /opsx-update, /opsx-verify, /opsx-sync и /opsx-archive останавливаются с просьбой назвать его. /opsx-propose, /opsx-new, /opsx-ff и /opsx-explore принимают свободный текст и без названного change идут без контекста tinyteam.
• Если у change с принятым источником нет области, команды планирования и реализации (/opsx-propose, /opsx-new, /opsx-continue, /opsx-ff, /opsx-apply, /opsx-update) просят модель сначала предложить область и остановиться. /opsx-verify, /opsx-sync, /opsx-archive и /opsx-explore работают без неё.

Требования изменились

tinyteam сравнивает принятую редакцию с текущим состоянием вашего клона store — сначала обновите его:

git -C ~/analyst-store pull
tinyteam source status                     # по каждому change: не изменились / изменились требования / изменился только контекст (master) / не найден
tinyteam source diff add-invoices          # различия документов между принятой редакцией и HEAD store

source diff принимает --from <SHA> и --to <SHA>, чтобы сравнить любые две редакции. Если аналитик перенёс source change в архив, source status это отметит, и принимать можно по пути из архива.

Принять новую редакцию — снова /spec-consume analyst add-invoices add-invoices: модель покажет различия и спросит; область при обновлении не меняется. Вручную — tinyteam source accept … --update. Прежняя редакция сохраняется в source-history/, а контекст команд напоминает о ней и о source diff и просит согласовать план, не сбрасывая выполненные задачи. Затем /opsx-update add-invoices. Когда план согласован, скажите это: tinyteam approve add-invoices reconciled — напоминание исчезнет до следующего обновления.

Область работы

Область говорит, какую часть проекта затрагивает change: где модели можно менять файлы, где только читать и проверять, от чего работа зависит. Обычно её предлагает /spec-consume; задать или сменить вручную:

tinyteam scope set add-invoices --purpose frontend --change apps/web

tinyteam scope show add-invoices

add-invoices: frontend — фронтенд
  менять: apps/web
  проверять: —
  внешние зависимости: —

• Назначения: frontend, backend, mixed, services, tester. Для tester контекст просит не менять продуктовый код; права всё равно задают корни.
• Корни изменения (--change) и проверки (--check) — существующие файлы или каталоги внутри проекта: без .., абсолютных путей и symlink. --dependency — внешние зависимости, которые не менять. Без --purpose в терминале — выбор списком.
• scope set заменяет область целиком.
• Принятые требования модель читает целиком, но контекст просит планировать только свою часть. Задачи реализации — только внутри области, принятые требования в спеках не удалять. Требования, которые выполняет другая часть системы (например, эндпоинты бэкенда в спеке, принятой во фронтенд), выносить в раздел «Вне области».
• Запись файла моделью вне корней изменения требует вашего разового подтверждения. Это действует для change, который последним назвала команда с областью в этой сессии. openspec/ свободен всегда.
• Роль не определяется по окружению: что входит в работу, задают корни, а --purpose — её назначение.

Материалы вне OpenSpec

Markdown, выгрузка из Confluence, описание макета текстом, точное уточнение из чата принимаются в change снимком:

echo "Срок — до 1 марта." | tinyteam material add add-invoices - --purpose "ответ заказчика о сроках"

tinyteam material add add-invoices ~/brief.md --purpose "бриф"

tinyteam material list add-invoices

• Принимается только текст UTF-8. Картинки и двоичные макеты не принимаются — опишите макет текстом.
• Снимки хранятся в materials/ change и коммитятся с работой, так что оригинал может исчезнуть. Тот же файл снова принимается с --update, прежний снимок уходит в materials/history/.
• Если снимок изменили или удалили, команды change останавливаются до исправления: tinyteam material list покажет, какой.
• Модель получает пути и назначения. Текст материала для неё — данные, а не инструкции. Если материал расходится с принятой редакцией, контекст просит её сказать об этом вам, а не выбирать самой.

Решения по срезам

Отметку [x] в tasks.md ставит модель, а принимает срез человек:

tinyteam approve add-invoices slice 1.1

tinyteam approve add-invoices tests 1.2 --scope "юнит-тесты парсера"   # разрешить тесты в срезе, с объёмом
tinyteam approve add-invoices reconciled                          # план согласован с новой редакцией

tinyteam approvals add-invoices

• При /opsx-apply модель знает, какие срезы приняты и где разрешены тесты. Если срез выполнен, но не принят, контекст просит её не начинать следующий. Код этого не принуждает, но в прогоне модель останавливалась.
• Номер среза — номер задачи из tasks.md. Подтвердить можно и заранее; решения только добавляются, командой их не отменить (файл approvals.json можно вернуть из git), история — tinyteam approvals.

Дополнения к командам

Ваши правила к любой команде харнесса. Дополнение пишется для одного харнесса и уходит только в него: у GigaCode и Qwen Code (а позже других харнессов) свои команды и модели, и правило одного может мешать в другом. Нужно одно правило в двух харнессах — создайте его в каждом. Команда создаёт пустой файл, текст правила вы пишете в нём сами; пустое дополнение модели не отправляется:

tinyteam additions add opsx-apply --harness qwen

printf "После каждого среза остановись.\n" > .tinyteam/additions/qwen/opsx-apply.md && tinyteam additions list

tinyteam additions show opsx-apply --harness qwen

• Файлы лежат в .tinyteam/additions/<харнесс>/ и коммитятся с проектом. Для одной схемы: tinyteam additions add opsx-apply --harness qwen --schema spec-driven. Что уйдёт модели для конкретного change: tinyteam additions show opsx-apply --harness qwen --change add-invoices.
• Без --harness или без имени команды в терминале additions add предложит выбор списком; вне терминала — откажет.
• Если .qwen — ссылка на .gigacode, у них одни настройки: пишите --harness gigacode, и эти дополнения получит и Qwen Code. --harness qwen в этом случае откажет с подсказкой.
• Общие дополнения прежних версий (.tinyteam/additions/<команда>.md) больше не доставляются: tinyteam additions list и doctor покажут их с готовыми командами копирования в каталог каждого подключённого харнесса — прежде правило действовало во всех. После обновления tinyteam выполните tinyteam init --update — запись hook должна назвать свой харнесс.

Навыки

/tinyteam — навык управления. Просить можно обычными словами; модель подключает навык и сама, без /tinyteam, если просьба про tinyteam:

/tinyteam всё ли в порядке с подключением?
смени scope у этого change на фронтенд apps/web
добавь brief.md как материал к add-invoices — это бриф заказчика
подтверди срез 1.1 в add-invoices

• Читающие команды (doctor, diagnose, source status, scope show, material list, approvals…) модель выполняет сама и пересказывает.
• «Этот change» — тот, о котором шла речь в разговоре; если change в проекте один — он. Если change несколько и ни один не назван, навык велит модели спросить; в прогоне с двумя change модель однажды выбрала сама — проверяйте имя change в окне подтверждения.
• Решения — область, материал, подтверждение среза, разрешение тестов — модель выполняет только по вашей просьбе и по одному. Если в просьбе названо всё, она выполняет команду сразу; если значения (назначение, корни, объём тестов) подобрала сама — сначала показывает команду и «было → станет» и ждёт вашего «да». Срез подтверждается только по просьбе с его номером: «ок» или «да» на вопрос модели — не подтверждение. Перед scope set, material add и approve харнесс спрашивает подтверждение (по коду Qwen; в интерактивном режиме не проверялось — TARGET-CHECK §6).
• Подключение (init, additions add) модель всегда сначала показывает и спрашивает. upgrade предлагает запустить вам в терминале.
• Требования навык не принимает — для этого /spec-consume.

/tinyteam-schema — навык схем: разговор о процессе команды (этапы, согласования, где остановиться) и обычная схема OpenSpec после вашего согласия; основа — пресет базового процесса. Например: /tinyteam-schema нужна схема, где дизайн согласует техлид до задач.

Типичный день

1. git -C ~/analyst-store pull и tinyteam source status — не изменились ли требования.
2. Если изменились: /spec-consume analyst add-invoices add-invoices → «да» → /opsx-update add-invoices → tinyteam approve add-invoices reconciled.
3. /opsx-apply add-invoices — модель делает один срез и останавливается.
4. Проверяете результат и принимаете срез: tinyteam approve add-invoices slice 1.2 или «подтверди срез 1.2».
5. Снова /opsx-apply add-invoices; в конце — /opsx-verify add-invoices и /opsx-archive add-invoices.

Проверка и диагностика

tinyteam diagnose --lines 5

doctor проверяет подключение проекта и ничего не пишет. Проблема показывается строкой с ✗ и одной командой, которая её исправит, например ✗ .gigacode: нет hook tinyteam — tinyteam init --update --tools gigacode.

diagnose печатает версии окружения и последние записи журнала — это то, что нужно прислать разработчику, лучше с --lines 100. Журнал — ~/.local/state/tinyteam/log.jsonl (или $XDG_STATE_HOME/tinyteam/): по строке на каждый вызов tinyteam, включая hook, без текстов документов. Выключить журнал — TINYTEAM_LOG=0.

Если что-то не работает

Все команды

Подробности любой команды — tinyteam <команда> --help.

Что модели нельзя

• Принять источник или материал, задать область, записать решение по срезу. Такую shell-команду модели харнесс выполняет только после вашего подтверждения; без интерфейса вызов отклоняется.
• Писать source.json, source-history/, scope.json, materials/, materials.json, approvals.json — отказ: их пишет только tinyteam по решению человека.
• Писать команду /spec-consume, навыки tinyteam и кэш .tinyteam/cache/ — отказ: их обновляет tinyteam init --update. Править settings.json харнесса и тексты дополнений — только с разового подтверждения.
• Писать файлы вне области change — только с разового подтверждения.

Как устроено внутри →