Сделал open-source дашборд Slightly Parallel для мультипроектной разработки с агентами

Сделал прогу — Slightly Parallel (опенсорс, локальный сервер + веб-интерфейс), которая должна помогать, если работаешь с кучей проектов, в которых разработку ведут агенты.

Прога ориентирована на солобилдеров и тех, кто активно использует Claude Code, Codex, OpenCode (в планах добавить ZCode).
Работает на Windows, Linux и macOS.

Код здесь:
https://github.com/NMar33/slightly-parallel

Навигация по статье:

0. Введение

1. Принципы

2. Чаты

3. Канбан-доска

4. Решение проблемы отложенного проекта

5. Сохранение авторского видения проекта. Команда «vision»

6. Накопление знания между проектами

7. Тимлид агентов

8. Дополнительные команды и возможности

9. Как запустить

0. Введение

Путь от «вау, MVP» до «легаси, которое никто не понимает» сейчас проходится за день вайбкодинга, а проектов становится всё больше и больше.

В какой-то момент, когда добавился еще один проект, я осознал, что словно Алиса в стране чудес проваливаюсь в кроличью нору вайбкодинга. И уже больше не понимаю, что и где происходит, и без понятия, что я делал месяц назад. Тогда я и решил, что пора менять подход и из разработчика становиться тимлидом команды агентов.

Но есть нюанс: у тимлида есть доска, стендапы и история, у меня — только скроллбэк в уже закрытом терминале. Поэтому понадобился инструмент, который позволит эффективно работать в нескольких проектах с использованием агентов и при этом оставаться в контексте.

Тогда я и сделал Slightly Parallel.

Slightly Parallel

Знаю, что белая тема, используемая в статье, может не всем зайти, поэтому скины и язык можно переключать (Settings → Appearance) :)

Светлая и тёмная темы переключаются кнопкой в верхнем правом углу любой страницы.

1. Принципы

Продуктов сейчас стало очень много. Каждый требует внимания и топит пользователя в бесконечном потоке информации. Поэтому, когда я делал Slightly Parallel, у меня было три принципа, которых я старался придерживаться:

1. Минимум дисциплины.
   Продукт не должен создавать дополнительную когнитивную нагрузку и должен приносить пользу с первого запуска.

2. Антислоп.
   «Избыток информации порождает дефицит внимания» (Герберт Саймон, 1971).

3. Накопление знания.
   «Цивилизация развивается, увеличивая число важных операций, которые мы можем выполнять, не думая о них».(Альфред Норт Уайтхед, 1911).

Антислоп достигается за счёт того, что большая часть команд осуществляется только по запросу пользователя, чтобы сохранить полезный сигнал.

Что сохраняет сервер и что пишет агент

У #vision, #rule, #problem и #entrypoint сервер сохраняет исходное сообщение + агент дописывает интерпретацию или текст. #prompt сохраняется сервером как есть.

У #now тело задачи — сообщение оператора, агент пишет только заголовок до 80 символов.

А накопление знания достигается за счёт версионирования (всего и вся), связанности (задачи, чаты, агенты, вижн и т. д. — всё связано между собой), множественности точек входа (до того, что нужно, можно добраться разными путями) и межпроектного накопления знаний (скиллы, правила, вижн, проблемы и т. д.).

Где всё лежит

При необходимости записи можно открыть даже обычным редактором без интерфейса Slightly Parallel. Они хранятся в выбранной папке данных (см. Как запустить): CSV и Markdown, а переписка — в файлах chat.md.

P.S. Monitor — небольшое исключение, его телеметрия хранится отдельно в SQLite.

Основной функционал

Сначала я постараюсь максимально сжато рассказать, что есть внутри Slightly Parallel, но внутри каждой секции есть спойлеры, в которых расказывается более подробно.

Работает на Windows, Linux, macOS.

История проекта собирается в один поток, даже если работать в разных инструментах: поддерживаются Claude Code, Codex, OpenCode и Cursor.

Сам я сижу на линуксе, поэтому тестирование на живой машине осуществлялось только для Linux, другие ОС тестировались в CI/CD на виртуальных машинах GitHub (была имитация юзера с запросами к моделям по API, поэтому вроде должно работать). Не тестировался Codex с графическим интерфейсом, только терминал.

Итак, что внутри.

2. Чаты

После интеграции вашего проекта в Slightly Parallel (Setup) хуки начинают захватывать все чаты и приписывать их к проекту: потом чаты можно просматривать, искать, фильтровать, находить связи с агентами или тасками и т. д.

Длинную переписку можно читать по сессиям, сплошным потоком или открыть отдельный чат на весь экран в focus mode со своим размером текста. Сессии разделяются по паузам; у каждой видны агент, время, затронутые файлы и результат (см. GIF 01).

Если нужен конкретный день, месяц сверху позволяет к нему перейти. Агенты и чипы рядом с ними фильтруют список (см. гифку).

Если после интеграции проекта (в SP) вы полностью забросите Slightly Parallel, то чаты продолжат писаться (даже без запуска сервера Slightly Parallel), и их потом можно будет просмотреть, т. е. согласно принципу № 1 польза будет даже при нулевой дисциплине :)

А старые чаты можно забрать?

Чаты, которые были до подключения проекта, тоже можно импортировать (если они сохранились в собственной истории инструментов). Инструкция есть в docs/help.md, раздел «how to: import lost chats».

P.S. Эта фича всё ещё WIP, могут быть баги (21.10.26). + для OpenCode пока не реализована возможность импорта.

3. Канбан-доска

Есть немало инструментов с канбан-досками, но удобной интеграции в вайб-разработку не так много.

В Slightly Parallel можно создавать задачи как на самой доске, так и из терминала, с учётом контекста, доступного агенту (для этого к сообщению нужно добавить команду #task, сделанная задача попадает в колонку Agent).

Можно превращать текущее сообщение в задачу (команда #now), а также закрывать задачу (команда #done). Вне зависимости от того, создана задача через терминал или через GUI доски, отслеживается ее связь с сообщением, где есть ее упоминание (цепочкой сообщений, если задача была закрыта через #done), а также с агентом, который ее делал (принцип 3).

Подробнее про команды `#now`, `#task`, `#done`

3.1.1. Команда #task

отдает агенту приказ собрать задачу из доступного контекста.

Типичный воркфлоу для данной команды такой: у нас есть чат с агентом, в котором у агента достаточно контекста. Мы видим, что из того, что есть, можно создать задачу, но писать вручную нам лень. Тогда мы пишем команду #task и кратко указываем, что превратить в задачу.

Карточки от #task сначала попадают в колонку From agents (слева от To do), а дальше их нужно посмотреть и самому перенести в To do или другую колонку. (Сделано это для сохранения полезного сигнала — принцип №2).

На GIF продемонстрирована разница в работе команд #now и #task. Задача, созданная с помощью #task, оказалась в колонке From agents, а задача, созданная с помощью команды #now, оказалась во вкладке Doing.

3.1.2. Команда #now

В отличие от команды #task, при использовании команды #now задачу пишет оператор (агент пишет только заголовок до 80 символов, попытки написать тело таски отклоняются MCP).

По сути #now является альтернативным доступом к канбан-доске, поэтому сообщение закидывается без ограничений в любой столбец.

Если просто написать в терминале #now, то задача попадёт в строку Now, в колонку Doing, а агент приступит к её выполнению.

Если мы хотим, чтобы задача попала не в строку Now, а куда-то ещё, то нужно поменять assignee. Для этого пишем: #now-todo {ui}, где ui — это строчка лейна.

Чтобы поменять колонку, пишем #now-*, в этом случае сообщение записывается в указанную колонку без начала работы над ним.

Команды:

• #now — Doing, агент сразу работает;

• #now-todo / #now-to-do, #now-next, #now-backlog, #now-review, #now-parked, #now-done — задача сразу ложится в указанную командой колонку, агент её только записывает и не начинает выполнять.

• P.S. Assignee работает и тут: #now-todo {ui}…

3.1.3. Команда #done

Через неделю после закрытия задачи часто нужно вспомнить, где её делали и что в итоге изменили. Если начать работу через #now, а закончить через #done (переносит в Done последнюю открытую задачу у агента), у карточки сохранятся участок чата, его время, файлы и коммиты.

Из карточки можно перейти к этому участку переписки.

На данном GIF показывается, как просмотреть участок чата, связанный с задачей, закрытой через команду #done.

Для удобства реализовано три варианта канбана: 3-колоночный, 5-колоночный и 5-колоночный со swimlanes (см. GIF 02). + Все варианты содержат дополнительные скрытые колонки, которые позволяют разгружать доску.

Я обычно использую вариант с линиями и даю каждой линии название по типу задачи, в результате схожие задачи накапливаются вместе и их можно передать батчем агенту.

Пример того, как выглядит карточка на доске канбан, и того, какие поля у нее есть.

Дополнительные возможности доски канбан (6 возможностей).

3.2.1 Батчевая работа при использовании варианта swimlanes.

Замечания к продукту часто появляются, пока агент ещё делает предыдущую задачу. Их можно складывать в линии по темам, а после проверки результата выбрать оттуда следующий батч.

На GIF показан пример того, как задачи, собранные в одной ячейке, копируются и передаются агенту.

3.2.2 Батчевая работа через Shift.

Чтобы передать накопившиеся задачи агенту, выбираем карточки Shift-кликом в том порядке, в котором хотим их передать. Снизу появляется панель: копируем выбранное и вставляем в чат одним сообщением.

3.2.3 Создание очереди (разгрузка доски)

Для разгрузки доски, помимо разгрузочных колонок, предусмотрена возможность создания стопки из задач.
Для этого несколько карточек нужно выбрать Shift-кликом, а потом через нижнюю панель сгруппировать их в очередь за первой выбранной. Тогда будет показываться только самая первая задача, а остальные будут лежать под ней.

GIF показывает пример группировки задач в одну стопку (чтобы они не занимали место).

3.2.4 Создание плана на сегодня (приоритизация задач)

В бэклоге могут лежать задачи ещё на несколько месяцев, а на сегодня нужны три карточки из разных колонок.

Чтобы их выделить, достаточно Ctrl-кликнуть каждую, после чего они поднимутся вверх своих колонок. (В swimlanes это будет отдельная полоска).

Задачи, созданные с помощью команды #now, автоматически считаются запланированными на сегодня.

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

3.2.5 Оси приоритизации

Идеи на доске накапливаются быстрее, чем получается их делать, и в какой-то момент нужно разобраться, какие задачи важнее, какие дадут больше результата, а какие вообще посильны сейчас.

Для этого у карточек есть оценки по нескольким осям.

Значения этих осей можно увидеть на самой карточке (например, если вы отметили таску как киллер-фичу, у нее будет фиолетовый лейбл killer). + по осям можно упорядочить бэклог: например, посмотреть сначала задачи с большим влиянием или меньшими усилиями.

Оси, по которым можно сортировать: Priority — приоритет, impact — влияние, effort — усилия, novelty — новизна, tokens — токены.

Как и всегда (принцип 1), данную фичу использовать необязательно, все будет прекрасно работать и без нее :)

3.2.6 Общая канбан-доска.
Общая доска для нескольких проектов
Предусмотрен вариант, при котором может захотеться посмотреть объединенную доску от нескольких проектов сразу. Для этого нужно перейти в канбан на левом сайдбаре и создать new board. Также может быть создана доска вообще без проекта, при этом если потом дать проекту имя данной доски, то она должна интегрироваться в него.

Пример создания общей доски

4. Решение проблемы отложенного проекта

Когда я писал этот код, только Бог и я знали, как он работает. Теперь знает только Бог.

4.1. Автодневник

Одна из самых серьёзных болей при работе с несколькими проектами — попытка вернуться к «отложенному проекту» спустя пару недель / месяцев.

Чтобы попробовать ее решить, я сделал в SP автодневник проекта. Для этого каждый день по каждому проекту пишутся стендапы (название дурацкое, но что есть).

На первом сообщении нового дня хук проверяет, есть ли стендап за прошлый день, и, если нет, предлагает агенту запросить его написание.

На GIF видны элементы стендапа, которые записываются, — собственно сам стендап и анализ архитектуры проекта (вкладка map).

Как это работает + Ограничения

После напоминания от хука агент спрашивает разрешение на запуск двух сабагентов.

Первый сабагент получает все чаты (по проекту) и таски за прошлый день и пишет, что было сделано, затронуто и т. д. Второй анализирует архитектуру проекта и результат анализа пишет на вкладку архитектуры (вид #map). Стендап можно также отложить (откладывается на 4 часа) или записать по команде (#standup).

Модели для написания стендапа и анализа архитектуры можно выбирать. В клод коде это стандартный выбор из Opus, Sonnet и Haiku, в OpenCode чекаются доступные, а в Codex — модель самого чата или любая модель Codex по имени.

Дефолтную модель для записи стендапа и архитектуры можно поменять в настройках.

(!) Ограничения

Стендап — одна из немногих автоматических команд. Его (и архитектуру / map) пишут агенты только с инфой за прошлый день, поэтому возможен слоп (например, однажды на более дешёвой модели для стендапа kit превратился в кита 🤡).

Если нужно отредактировать поведение агента и то, как / что он должен писать, это легко сделать, т. к. все команды реализованы за счёт скиллов и их можно отредактировать на вкладке Skills.

Отдельный нюанс насчёт анализа архитектуры и линз, через которые можно смотреть: map — лишь одна из линз, она пишется, когда запускается стендап; другие линзы — page и changes — пишутся, когда пользователь вызывает команду (#scan). Их пишет агент, который сам работал над задачей, поэтому анализ архитектуры в page и ledger может быть более качественным, но если вызывать #scan нерегулярно, то неполным. Вот такой трейдофф между регулярностью и слопом.

4.2. Что изменилось за этап. Команда #scan

Агент закончил этап, файлов поменялось много, и пока ещё понятно, зачем всё это было. Через месяц по одному списку файлов восстановить происходившее будет сложнее.

Если в этот момент написать #scan, агент сохранит и опишет изменения со своего прошлого скана (вкладка scan). Объяснит значение важных файлов (вкладка files) и запишет изменения в архитектуре (линзы page и changes).

Конечно, вызывать команду имеет смысл, пока всё это ещё есть у него в контексте.

По своему опыту могу сказать, что сочетание сканов и автодневника позволяет достаточно быстро вспомнить, над чем работал, т. к. по автодневнику можно быстро найти нужный день, в который выполнялась работа, а по сканам — нужный этап работы. (Как и всегда, в соответствии с принципом №3, сканы связаны с задачами, агентами, чатом, скиллами, промптами и т. д., и vice versa.)

Подробнее про файлы и архитектуру, записанные с помощью команды скан

4.2.1. Вкладка файлы

Когда запускается скан, агент смотрит, какие файлы он трогал, а дальше кратко пишет, какие изменения и зачем были сделаны. + анализирует важность изменений, бласт-радиус изменений и т. д.

В целом я сделал эту вкладку для решения нескольких задач:

1) первая задача — понимать контекст сделанных изменений, т. е. что в каком файле и почему менялось. Это можно увидеть, если включить вариант просмотра story.

На скриншоте видно, какие изменения и почему делались в файле.

(!) Ограничение: к сожалению, не могу сказать, что это работает идеально, часть комментариев — откровенный слоп, но пока руки не дошли довести скилл, ответственный за это, до ума.

2) вторая задача, которую я пытался решить с помощью этой вкладки, — понимать, в каких файлах ведется в основном работа. Это можно было бы делать через гит, но не всегда количество измененных строк совпадает с важностью, для этого есть варианты просмотра weight и ranking, + продуманная система сортировки.

3) третья задача — понимать, что где менялось на каком-то участке работы, для этого есть вариант просмотра grid, по нему удобно смотреть, где происходили изменения от скана до скана. По умолчанию группируется по дню, но если щелкнуть на день (см. скриншот), то он раскрывается и видно, какие сканы были сделаны (подсветил красным прямоугольником). Если потом щелкнуть на скан, то появится всплывающее окно с информацией о данном скане.

4.2.2. Вкладка архитектура

За счет команды скан пишется два вида архитектуры:

1) архитектура, вид page
По сути это страница, которая помогает понять, что делает проект и на какой стадии развития находится прямо сейчас, что-то вроде архитектурного редми. Как и всегда, при записи нового скана старые версии сохраняются.

2) архитектура, вид changes
Честно говоря, это один из наиболее полезных взглядов на архитектуру, т. к. позволяет быстро оценить, что поменялось в архитектуре. Для этого во время скана агент (у которого есть контекст происходящего) записывает, что куда было задеплоено, какие новые фичи, интеграции, эндпоинты, долги и т. д. и т. п. появились.

Для удобства просмотра у этого варианта просмотра есть свои варианты просмотра 🤡, см. register, stream, codebase. Но про это уже писать не буду, т. к. статья и так получилась перегруженной.

(!) Важно: скан пишется только по команде пользователя (принцип №2). Если его не вызвать, автоматически такой записи не будет.

4.3. Команда #entrypoint

Наверное, стоит ещё упомянуть #entrypoint: эта команда тоже помогает бороться с проблемой отложенного проекта.

После перерыва мне часто сложно вспомнить, как что запускать, какие нюансы есть и где что лежит.

Если работаешь соло, то у тебя есть всё: от студии для генерации промовидео к проекту до самого проекта с разными энтрипоинтами для прода и дева.

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

5. Сохранение авторского видения проекта. Команда «vision»

Сейчас разработка сместилась от умения писать код к умению видеть то, что ты хочешь получить, и вкусу.

Чтобы сохранить видение проекта в Slightly Parallel, добавляем #vision к своему сообщению в терминале — оно сохраняется как вижн.

При этом происходит как дословное сохранение (Your words), так и интерпретация от агента.

Вижн можно редактировать, тогда будут сохраняться v1, v2 и т. д.

Для удобства управления разные вижны можно объединять в сеты (например, вижны, связанные с дизайном, можно объединить), а потом подключать их к разным проектам. На GIF ниже несколько вижнов сначала объединяются в сет, а потом перетаскиваются драг-энд-дропом на проект, при этом вижны прописываются в AGENTS.md (естественно, удалить их из AGENTS.md можно, просто отключив вижн от проекта).

6. Накопление знания между проектами

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

6.1. Правила. Команда #rule

Добавив эту команду к любому сообщению, можно превратить его в правило. Сохраняются оригинал и интерпретация правила агентом на основе контекста. Как и в случае с вижн, есть версионирование и возможность интегрировать правило в другие проекты одной кнопкой.

6.2. Проблемы. Команда #problem

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

Для этого есть #problem: сохраняем проблему и то, что уже пробовали. Сервер записывает сообщение, агент добавляет интерпретацию с учётом разговора.

Когда разобрались, пишем #problem solved и указываем проблему. Запись закрывается, а из найденного решения можно сделать правило.

6.3. Команда #prompt

Если добавить эту команду к сообщению, то оно записывается как промпт и появляется на вкладке промптов.

Если промпт уже дал хороший результат, его можно сохранить для повторной отправки. А когда появится другая формулировка — сравнить версии и посмотреть, в каких чатах их использовали.

6.4. Команда #skill

После решения какой-то серьёзной задачи, где агент наконец-то смог, есть смысл вызвать #skill: скилл будет писать агент, у которого есть контекст, и часто выходит достаточно неплохо.

На скриншоте ниже — скилл после того, как мы написали команду: сначала он записывается в черновики (см. Drafts слева).

Потом его можно сделать активным (см. Make active правее); под Make active можно увидеть, в какие проекты скилл интегрирован, и подключить / отключить его одной кнопкой.

Скилл можно отредактировать, при этом прошлая версия тоже сохраняется, а во всех проектах, куда скилл интегрирован, происходит автоматическое обновление.
(Если скилл был изменён на диске, а не через Slightly Parallel, то Slightly Parallel об этом напишет и перезатирать не будет.)

Естественно, скилл — это не один md-файл, а ещё куча всяких вспомогательных файлов. Они тоже трекаются, и часть из них можно открыть посмотреть.

Ну и, естественно, в соответствии с принципом № 1 можно ничего не менять и работать со скиллами так, как вы привыкли, просто игнорируя эту вкладку :)

Если скиллы уже есть на компьютере

Их не нужно заново создавать через #skill: Slightly Parallel подхватывает существующие папки скиллов. Установить скилл можно в один проект или для всех проектов.

6.5. Команда #artifact

После работы с агентом иногда стоит сохранить сам результат: документ, dataset, страницу или небольшое приложение. Для этого есть #artifact: указываем, что сохранить, агент пишет папку под проектом, а сервер регистрирует её.

Папка появляется на странице Artifacts, где можно посмотреть её файлы и предпросмотр.

7. Тимлид агентов

Тимлид не пишет и не держит в голове весь код команды — он смотрит важные изменения и понимает, что происходит в проекте, иначе всё пойдёт под откос.

Для управления и понимания есть следующие инструменты.

7.1. Вкладка Agents

Собственно, эта вкладка просто перечисляет агентов, которые были в проекте, и позволяет вспомнить, кто и что делал.

Для каждой сессии показаны инструмент, модель, чаты, задачи и время. Можно открыть связанный чат и посмотреть переписку и затронутые файлы.

7.2. Какие ваши доказательства?

Все мы иногда хотим получить доказательства того, что работа была сделана.

Если в задаче включить галочку evidence, то по выполнении данной задачи у агента будут запрошены подтверждения того, что задача сделана.

Доказательствами могут быть скриншоты, описания сделанных фич и т. д.

По умолчанию галочка выключена (принцип 2 — антислоп), но ее дефолтное состояние можно переключить в настройках. Также запросить доказательство можно через команду #evidence, в этом случае агент предоставит доказательства к последней выполняемой задаче.

Пример того, как выглядят доказательства

7.3. Мониторинг, или кто съел ноутбук

Когда одновременно работают несколько агентов, серверов, открыто много вкладок и т. д., компьютер может начать тормозить. В Monitor можно посмотреть CPU, память, диск, соединение и самые тяжёлые программы. + на эту же вкладку пишутся логи самого SP, что позволяет заметить, если что-то идет не так.

Несколько неожиданных примеров пользы этой вкладки и мониторинга

пример 1 — монитор сигнализирует об утечке памяти в Obsidian.

пример 2 — благодаря монитору удалось найти утечку памяти в самом SP, после ее фикса память стабильно находится в диапазоне 240–280 МБ.

(+) Там же видны необычные события за последние семь дней: можно посмотреть, что происходило с машиной и какие процессы работали в тот момент.

7.4. Таймлапс разработки

Просто прикольная фича, которая позволяет показать процесс разработки: как появлялись задачи, что отвечали агенты и какие были коммиты.
Она воспроизводит историю проекта, а получившийся фильм можно экспортировать в MP4.

Собственно, вот и сама история разработки Slightly Parallel в таймлапсе :)

На Хабре лимит на 8 МБ для изображений, поэтому качество немного шакалье, но из студии можно выгрузить в лучшем качестве.

8. Дополнительные команды и возможности

8.1. Команда #undo

Если случайно была добавлена лишняя запись (промпт, вижн, скилл и т. д.), то можно написать #undo. Агент получит инфу о недавних записях и спросит, что убрать. Отвечаем номерами, а после повторного запроса подтверждаем командой #undo-yes — ошибочные энтри архивируются.

8.2. Автозапуск и ярлык

Чтобы каждый раз не вспоминать команду запуска, в Setup или Settings → On this computer можно включить автозапуск + создать ярлык. Оба переключателя изначально выключены.

Ярлык вызывает sp open: если сервер ещё не запущен, команда запускает его, затем открывает страницу.

P.S. С ярлыком и автозапуском возможны баги: на живой машине я проверял только Linux, а в CI/CD нет настоящей пользовательской сессии (рабочего стола, входа в систему), поэтому там это не проверить. (Если кто-то установит и проверит, отпишитесь, буду очень благодарен).

8.3. Less is more, или что показывать в интерфейсе

Если какие-то страницы вам не нужны, их можно убрать из основной части сайдбара. Для этого открываем Settings › Sidebar (или наводим мышь на низ сайдбара и нажимаем Customise sidebar).

Там можно скрывать страницы, переименовывать их и перетаскивать между группами. + Можно сделать свои группы. Скрытые страницы остаются в свёрнутой группе Hidden внизу сайдбара.

Какие колонки показывать у Канбан доски, табы overview, и Task analytics

У доски есть отдельная шестерёнка — Board columns. Снимаем галочки с колонок, которые не хотим видеть. Таски из них никуда не удаляются: включаем колонку обратно, и они снова видны. Выбор сохраняется отдельно для каждой доски.

У страницы проекта похожая настройка называется Tabs. Выбираем нужные вкладки, остальные отключаем.

На самом Overview проекта есть Task analytics — несколько способов смотреть, как идут задачи. Через шестерёнку можно включать / отключать отдельные панели, в том числе выключить все. Здесь выбор уже отдельный для каждого проекта.

(!) Это относится только к Task analytics: плитки, Agent timeline, Sprints и Task timeline остаются видны. Секции главной страницы Overview тоже не отключаются.

8.4. Проверить, что всё работает

Проект подключили, агент запустился, но появились сомнения: все ли сообщения записались, видит ли он MCP, прочитал ли нужные инструкции.

Для проверки есть #sp (эта команда запускает проверку и сообщает информацию, а также где и что смотреть агенту). К команде можно добавить конкретную жалобу, например: #sp в истории нет последнего ответа.

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

Если вы установили, но что-то не работает / работает не так, скачайте файл логов (Monitor → Server, download report) и отправьте мне, я постараюсь пофиксить.

Что внутри и альтернативный способ получения отчета

Альтернативный способ получить отчет:

python sp.py report

Отчет — это Markdown-файл со сведениями о машине, памяти и нагрузке за день. Событиями, предупреждениями, ошибками хуков и размерами данных. Команда работает и при неотвечающем сервере: тогда отчёт строится из файлов.

Текста чатов и содержимого .env в отчёте нет.

8.6. Потенциальные вопросы

Нужен ли Git в проекте

К Slightly Parallel можно подключить обычную рабочую папку без Git. Если в проекте есть Git, сканы будут также перечислять коммиты и считать строки.

Git из требований установки нужен для скачивания самого Slightly Parallel, хотя и его можно скачать просто как папку.

9. Как запустить

9.1. Скачиваем репозиторий

Чтобы попробовать Slightly Parallel, нужны Python 3.11+ и Git.

На Linux и macOS:

git clone https://github.com/NMar33/slightly-parallel.git
cd slightly-parallel
./run.sh --prod

На Windows клонируем тот же репозиторий, переходим в его папку и вместо последней команды запускаем:

sp run --prod

Открываем http://127.0.0.1:8123. При первом запуске там появляется пример проекта с чатами, задачами и стендапами.

9.2. Setup

Дальше — Setup:

1. выбираем папку для записей, если не подходит предложенная (все записи Slightly Parallel будут сохраняться сюда), затем:

2. Указываем название проекта и папку его исходников.

3. Смотрим список файлов, которые запишет Setup, и подключаем проект.

4. Запускаем агента в папке проекта. Страницы обновляются по ходу чата.

Проект подключён, а чат не появился

Проект может быть подключён, но чаты конкретного инструмента записываются только при включённой для него интеграции. В Setup все инструменты отмечены по умолчанию.

У подключённых проектов видно, какие инструменты записываются. Если нужного нет, нажмите Connect рядом с ним и начните новый чат: хуки читаются при старте.

Итог

Ну вот и всё. Агенты уже хорошо пишут код, а работа сместилась к тому, что раньше делал тимлид: поставить задачу, проверить, принять решение и через месяц помнить, почему оно было таким.

Надеюсь, Slightly Parallel будет кому-то полезен и поможет не терять контекст в эпоху вайбкодинга.
https://github.com/NMar33/slightly-parallel