TaskinSuas tarefas, onde você quiser que elas morem.

O que é o Taskin ​

O Taskin é a camada entre você e a sua fila de trabalho. Ele dá um vocabulário único — criar, começar, pausar, revisar, terminar — e um conjunto de ferramentas em cima dele: uma CLI, um dashboard em tempo real, um servidor MCP para agentes de IA e métricas tiradas do histórico do git.

Onde as tarefas ficam guardadas é uma decisão sua, tomada uma vez:

taskin init

? Escolha o provider de tarefas
❯ 📁 File System   — markdown num diretório TASKS/ do próprio repositório
  🔴 Redmine       — issues via REST API
  🔵 Jira          — issues via REST API
  🐙 GitHub Issues — issues do repositório

A escolha vai para o provider.type no .taskin.json, e todos os comandos a respeitam. O provider é um pacote separado, instalado sob demanda — você não carrega o cliente do Jira para usar markdown local, nem o contrário.

O dashboard ​

O taskin dashboard abre um painel que lê as tarefas do provider configurado e acompanha as mudanças por WebSocket — quando alguém roda taskin finish no terminal, ou quando um agente chama finish_task pelo MCP, o card muda de estado sem recarregar.

Os nomes aí são de exemplo — inclusive o agente, que aparece como responsável de propósito: pelo servidor MCP, ele pega tarefa na mesma fila que o resto do time.

O contrato que faz isso funcionar ​

Um provider responde por seis operações. É só isso que o Taskin precisa saber sobre o seu backend:

interface ITaskProvider<TTask extends Task = Task> {
  initialize: () => Promise<void>;
  findTask: (taskId: TaskId) => Promise<TTask | undefined>;
  getAllTasks: () => Promise<TTask[]>;
  updateTask: (task: TTask) => Promise<void>;
  createTask: (options: CreateTaskOptions) => Promise<CreateTaskResult<TTask>>;
  lint: (fix?: boolean) => Promise<LintResult>;
}

O TTask genérico é o detalhe que evita vazamento: o provider de arquivos acrescenta content e filePath à tarefa, um de Redmine acrescentaria o issueId e o histórico de notas, e nada disso aparece no pacote agnóstico. Quem consome apenas Task continua funcionando com qualquer provider.

O ITaskManager fica em cima, com as transições de estado e as operações nomeadas — startTask, finishTask, assignToGroup, setPriority, moveBefore, moveToTop, moveGroupToTop, nestGroup, setDifficulty e as demais — e é genérico sobre a mesma forma. A CLI, o servidor MCP e o dashboard passam todos por ele: o WebSocket do dashboard manda set-priority ou assign-to-group, nunca uma tarefa inteira para sobrescrever. No quadro de priorização, as setas, o topo, o fim e o arrastar mandam move-before / move-after (ou move-group-before / move-group-after) tendo como referência a linha visível vizinha, a primeira ou a última — com filtro, o topo é o do que se está vendo — e os números novos voltam do domínio, a mesma regra do taskin priority --before. Desfazer reenvia os valores anteriores só das tarefas que o movimento alterou. Soltar uma tarefa sobre outra do mesmo grupo cria um subgrupo de verdade, e soltar um grupo sobre outro cria um pai com os dois dentro — enviados como create-group e nest-group, então o aninhamento sobrevive a recarregar a página, até quatro níveis. Uma tabela, SUPERFICIES_DAS_OPERACOES, diz onde cada operação aparece — e acrescentar uma operação sem decidir as três superfícies não compila.

O provider de arquivos, que é o padrão ​

Se você não usa um rastreador de issues, ou quer a tarefa viajando junto com o código, o provider de File System guarda cada uma como um markdown no seu repositório:

# Task 042 — Contraste dos tokens de status

Status: in-progress
Type: chore
Assignee: sidartaveloso

## Description

Os tokens `--status-*-bg` com texto branco falham WCAG AA.

## Tasks

- [x] Medir o contraste de cada par cor/texto
- [ ] Decidir entre escurecer o token ou trocar a cor do texto

A linha Assignee guarda o id do usuário em .taskin/.taskin-users.json, e não o nome de exibição; taskin lint --fix reescreve um nome de exibição para o id.

Sendo arquivo no repositório, algumas coisas vêm de graça: a mudança de escopo aparece no diff do PR, a tarefa acompanha o ramo onde o trabalho está, conflito se resolve com as ferramentas que você já usa, e busca é grep.

Nada disso é requisito do Taskin — é o que esse provider oferece. Com o Jira, você troca essas propriedades pelas que o Jira dá.

Para quem escreve código com um agente ​

O servidor MCP expõe a fila de trabalho como ferramentas, e o agente que já lê o seu repositório passa a mexer nela:

Três filtros, iguais em todas as superfícies: open (tudo que não terminou), closed, e active — começou e não terminou, que é o que interessa na tela enquanto o trabalho acontece.

Sem filtro nenhum, a lista mostra só as abertas — na CLI, no list_tasks e no dashboard, porque a pergunta de quem abre a lista é o que falta fazer. Para ver todas, fechadas inclusive: taskin list --all, all: true no MCP, ou o botão All no dashboard. Um filtro de status explícito (--status done, --closed, --active) substitui esse padrão em vez de se somar a ele — e, como já é um recorte, não se combina com --all.

Outros dois separam a fila pela dificuldade: scored (já pontuada — o que se prioriza) e unscored (a fila do que ainda falta pontuar). No dashboard eles são um controle próprio na barra do topo, ao lado da busca e do modo de ordenação, e valem para as duas telas, o Board e a Priorização.

O texto livre — taskin list fix, text no MCP, a busca do dashboard — casa id, título, tipo, status e responsável, a mesma regra em todo lugar. O dashboard guarda o que se escolheu na URL (?q=, ?sort=, ?score=, ao lado de ?view= e ?filter=), e recarregar ou compartilhar o link mostra a mesma lista na mesma ordem. A fila do unscored se trabalha de qualquer lugar: taskin difficulty 042 3 no terminal, set_difficulty para um agente, ou o próprio quadro — de 1 (trivial) a 5 (muito difícil).

você:    "termina a task 042"
agente:  → finish_task(taskId: "042")
         → a tarefa muda de estado, o commit sai, o dashboard atualiza

O agente não sabe — nem precisa saber — se aquilo virou um arquivo alterado ou uma chamada REST. Quem resolve isso é o provider.

O agente também organiza a fila que ele mesmo executa. set_priority coloca uma tarefa por número, logo before ou after de outra, ou no top ou no bottom da fila, join_group / leave_group a movem entre grupos, e move_group move um grupo inteiro, com os membros juntos. create_group, nest_group e unnest_group põem um grupo dentro de outro, ou o tiram. O terminal tem as mesmas operações — taskin priority 042 --before 017, taskin priority 042 --top, taskin group join 042 g-cli, taskin group move g-cli --top, taskin group nest g-auth g-cli — e ninguém precisa editar o bloco de metadados à mão.

Registrar o servidor é um comando:

taskin mcp-install

Ele escreve o .mcp.json na raiz do projeto, funde com o que já estiver configurado ali e depois sobe o servidor para conferir que a entrada funciona — um comando que alcança outro taskin responde normalmente, com o conjunto errado de ferramentas, e responder não é o mesmo que responder certo.

O monorepo ​

Dá para usar só a CLI. Ou só o task-manager, com um provider seu, dentro da sua própria ferramenta.

O mascote, e o ui-sense por trás dele ​

Ele é um polvo porque o Taskin faz muitas coisas ao mesmo tempo com o mesmo corpo. E o que está no topo da página não é imagem: é o componente Taskin do design system, rodando de verdade — pisca sozinho e acompanha o seu cursor.

Ele também sabe espelhar um rosto. O @opentask/ui-sense faz detecção de face, pose e gestos no próprio navegador, e o mascote é só um consumidor disso:

Os outros 16 humores dele estão na