Garmin Coach
Uma ponte entre um LLM e um relógio Garmin: cola um plano de treino, recebe treinos estruturados no pulso. Sem redigitar nada na mão.
- ~2k
- Linhas de código
- Automated
- Refresh de token
- MIT
- Licença
Desafio
Eu planejo minhas semanas de corrida com o Claude num chat à parte. A saída é texto puro, e o caminho dali até o meu Garmin era manual: ler a prosa, abrir o app, tocar em cada intervalo na mão. Fiz isso vezes suficientes pra deixar de ser mania e virar irritação.
O formato do dado não é difícil: a API interna do Garmin expõe um formato de treino. O buraco era que ninguém tinha construído a ponte, e fazer um LLM preencher esse JSON sem inventar nome de campo significava que o próprio schema tinha que ser a primeira coisa a acertar.
Abordagem
Comecei pelo contrato JSON: aquecimento, intervalo, recuperação, desaquecimento, repetição, cada um com uma duração e um alvo tipados. Rígido, mas curto o bastante pra colar no prompt. Com o schema estável, veio a CLI. Ela lê o JSON, confere com o Pydantic e chama a API. Depois veio o web app, mobile-first em cima do FastAPI, pra eu conseguir mandar um plano do celular.
A última peça de verdade era manter o login vivo. Os tokens do Garmin expiram em minutos, então mantenho uma linha no Supabase que se atualiza sozinha. O app simplesmente funciona quando pego o celular no meio da preparação da corrida.
Resultado
No ar como web app hospedado na Vercel, com a CLI rodando localmente. O pipeline inteiro (plano no Claude, JSON pra fora, envio pra um Forerunner 165) tem cerca de 2 mil linhas. Não estou treinando tanto quanto no começo de 2026, mas a infraestrutura é estável e recorro a ela sempre que volto pras corridas estruturadas.
Pra quem eu desenhei
Eu mesmo, e mais ninguém. Eu corro com um Garmin, planejo com o Claude e não queria redigitar intervalo na mão.
Construir uma ferramenta da qual você é o único usuário é outra disciplina. Sem fase de pesquisa, sem personas, e o ciclo de feedback dura dez minutos. Se o schema é chato de escrever prompt, eu sinto na hora. Essa compressão é todo o sentido de um projeto paralelo.
A decisão-chave: o schema primeiro
A tentação era começar pela API ou pela UI. Comecei pelo schema JSON, e essa foi a decisão certa.
Um LLM tem que preencher o schema sem uma explicação campo a campo toda vez, então o formato tinha que ser óbvio: chaves previsíveis, alvos tipados, sem aninhamento ambíguo. Fui iterando num único arquivo markdown, colando no Claude e refinando até a saída voltar válida sem precisar de correção. Depois disso o resto foi encanamento. O parser é só validação do Pydantic, e trocar o modelo é uma mudança de config.
O que não foi bem
O deploy serverless deu trabalho. A biblioteca cliente do Garmin depende do curl_cffi, que não compila na Vercel, então rodo dois caminhos: a biblioteca completa na CLI, e requests diretas com um token exportado no web. Funciona, mas é deselegante.
A autenticação também é meio castelo de cartas. Ela se apoia num endpoint não oficial que o Garmin pode mudar sem avisar. Quando a biblioteca em que comecei quebrou depois que o Garmin adicionou fingerprinting do Cloudflare, tive que migrar no meio do projeto. A visão de calendário no web ainda está incompleta porque o endpoint de listagem devolve 404 por lá. É uma ferramenta que eu uso, não um produto que eu entregaria pra um estranho.
Telas selecionadas
" Projetos paralelos deixam você entregar a API que quer consumir, não a que sobreviveu a um comitê. O schema é exatamente o formato de que eu precisava, a autenticação é exatamente a quantidade que eu estava disposto a manter, e a UI é tão mínima quanto uma ferramenta que uso sozinho pode ser. "
Mosey
→Um app de viagem pessoal pra 27 dias entre Dinamarca e Noruega. iOS nativo, anti-itinerário, planejamento gerado por IA no próprio aparelho.