Здесь несколько моментов

1. В коде в некоторых местах происходит смешение кэмэл-кейса и нижнего подчеркивания - лучше придерживаться одного стиля: для внутренних сущностей - кэмэлКейс, для джейсонов - подчеркивания.
2. именования сущностей: нет необходимости дублировать имя даты внутри самой даты: если дата называется Attachment , не нужно поля этой даты начинать с attach_ , достаточно просто type , ну или если слово зарезервировано, то что-то иное придумать
3. комментарии: лучше избегать дублирующих код комментариев - то, для чего нужна сущность, должно быть понятно из ее имени, а не из комментария. Тем более странно, когда комментарий почти полностью дублирует имя сущности

В именах функций и переменных допускаются только английские слова или общепринятые сокращения в camelCase. Например hconfig лучше исправить на hConfig. Также есть некоторые ошибки и опечатки в коде - verbocity, Unsuccessfull и т. д.

Если у тебя vscode, то там есть удобное расширение code spell checker для проверки орфографии.

Не пойму, какой форматтер у тебя используется. В src есть fourmolu.yaml, но используется не он. Количество пробелов в некоторых файлах равно 4.
Нужно использовать ormolu и количество пробелов 2

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

модуль Bot.Vk.Parser.Data :

• дублирую коммент с Attachment лучше использовать тип сумму, а не произведение: аттачмент может быть только одним из вышеперечисленных типов (а не может содержать сразу несколько ), это логически определение типа суммы (а не произведения)
• список имеет поддержку нулевого значения - пустой список, нет необходимости оборачивать список в монаду Maybe

Замечания hlint не везде исправлены. Например в тех же тестах
https://github.com/LyuPo7/bot/blob/master/test/TestBot/Tele/Run.hs

Можешь объяснить предназначение класса Worker
class (MonadThrow m, Monad m) => Worker m api where
который имеет только один инстанс
instance (MonadThrow m, Monad m) => Worker m BotApi.Api where

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

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

Привет) Не везде используются списки импорта. Нужно использовать либо списки импорта, либо квалифицированные. Например, в тестах лучше написать import qualified.

Если ты используешь hls в vscode, то он сам предлагает сделать списки импорта где нужно

В тестах есть неиспользуемые импорты. Для тестов можно использовать команду stack test --ghc-options="-Wall -Werror"

Синонимы типов

type UserId = Integer
type ChatId = Integer

не добавляют безопасности коду, то есть мы можем вместо UserId всегда подставить ChatId. И вместе с тем, это уменьшает понимание, так как проверяющий не знает, что ChatId это не какой-то специфический тип, а просто Int.
Рекомендуется (на твое усмотрение) сделать newtype обертки, например
newtype UpdateId = UpdateId Int deriving newtype (Show, FromJSON, ToJSON, Convert, Num, Read, Ord, Eq)
механизм дерайва позволяет с ними работать, как с обычными типами, взамен мы получаем типобезопасность и никакого оверхеда в реалтайме

Люба, привет!
Первый вопрос по поводу билда - не билдится ни один из проектов - валится при попытке поставить пакет HDBC. Если в проекте есть зависимости, которые нужно устанавливать отдельно, процедура установки должна быть описана в ридми

Вот яркий пример, функция makeRequest явно имеет одинаковую структуру для обоих ботов. Значит ее нужно вынести в общий код, а какие-то специфические куски оставить в соответствующих модулях
https://github.com/LyuPo7/bot/blob/master/src/Bot/Api/Tele/Request/Requests.hs#L157
https://github.com/LyuPo7/bot/blob/master/src/Bot/Api/Vk/Request/Requests.hs#L222

Функции setHelpMessage и setStartMessage в Bot.Api.Tele.Request.Requests выглядят как абсолютно одинаковые.
Функции withHandleIO для Bot.Api.Vk.Parser.Parser Bot.Api.Tele.Parser.Parser тоже одинаковые.

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