Lf Commit

Você é responsável por transformar o estado atual da working tree num commit que segue a convenção tipo(TICKET-XXX): descrição em inglês. Nunca commite sem confirmação explícita do usuário.

PASSO 0 — Levantar o estado do repo

Rode em paralelo: git status --short, git diff (unstaged), git diff --staged e git log --oneline -10 (referência de estilo de mensagem já usado no repo).

Se não houver nenhuma mudança (staged, unstaged ou untracked relevante), informe:

Nada pra commitar — working tree limpa.

Encerre a execução.

PASSO 1 — Resolver o tipo a partir da branch

Rode git branch --show-current.

• Prefixo features/ (ou feature/) → TIPO = feat
• Prefixo fixtures/ (ou fix/, bugfix/) → TIPO = fix
• Qualquer outro caso (ex.: commitando direto em main/master/branch de staging, ou uma branch fora de qualquer padrão reconhecido) → não infira; pergunte ao usuário qual tipo usar antes de continuar.

PASSO 2 — Resolver o ticket

Primeiro, descubra qual convenção de issue tracker este projeto usa:

1. Procure documentação local da convenção: docs/agents/issue-tracker.md, docs/ISSUE_TRACKER.md, ou uma seção equivalente em CONTRIBUTING.md/CLAUDE.md. Se existir, siga o tracker, time/workspace e prefixo que ela definir.

2. Se não existir nenhuma documentação, e ainda não foi perguntado nesta sessão para este projeto, pergunte:

   Qual tracker de issues este projeto usa?
   - Linear (informe time/workspace e prefixo, ex.: Twinfo Lifters / TWI)
   - GitHub Issues
   - Nenhum (seguir sem ticket)
   

   Reaproveite a resposta para as próximas branches/commits deste projeto na mesma sessão — não pergunte de novo.

Com o tracker resolvido (ou "nenhum"), siga a ordem de resolução do ticket — pare no primeiro passo que resolver:

1. Nome da branch: procure um padrão <PREFIXO>-(\d+) (case-insensitive, ex. twi-903) no nome da branch atual. Se achar, monte <PREFIXO>-<N> e confirme que existe de fato (mcp__linear__get_issue para Linear, gh issue view <N> para GitHub Issues) — se não existir, trate como não resolvido e caia no passo 2.

2. Busca no tracker: se a branch não carrega ticket, liste issues abertas atribuídas ao usuário atual (mcp__linear__list_issues filtrando team + assignee "me", ou gh issue list --assignee @me --state open). Compare o diff/commits desta mudança com título/descrição das issues retornadas e proponha o melhor match:

   Encontrei a <PREFIXO-XXX> "<título>" (atribuída a você, em <estado>) — é o ticket dessa mudança?
   

   Aguarde confirmação. Se o usuário recusar ou nada bater, vá para o passo 3.

3. Nenhum ticket encontrado: pergunte

   Não encontrei nenhuma issue vinculada a este trabalho. Quer criar uma agora, ou seguir sem ticket?
   

   • Se criar: use mcp__linear__save_issue ou gh issue create — título curto e objetivo, seguindo o idioma/convenção documentados no projeto (se houver). Guarde o <PREFIXO-XXX> resultante.
   • Se seguir sem ticket: TICKET = nenhum. Não pergunte de novo depois disso nesta sessão para a mesma branch.

Se o ticket (e o tracker) já foram resolvidos nesta sessão — por esta skill ou pelo /lf-push — reutilize sem perguntar de novo.

PASSO 3 — Rascunhar a mensagem

Monte o subject, sempre em inglês, minúsculo, imperativo/presente:

• Com ticket: TIPO(PREFIXO-XXX): descrição em inglês — ex. fix(TWI-903): correct duplicate person sync entries.
• Sem ticket, mas ainda é um feat/fix de verdade: TIPO: descrição em inglês.
• Sem ticket e a mudança é genuinamente pontual/não-feature/não-fix (uma linha de log, um chore, um ajuste de doc) — vocabulário mais livre é aceitável aqui (chore, docs, logs, etc.), refletindo o que o histórico deste repo já faz na prática. Pergunte ao usuário se a natureza da mudança não estiver óbvia pelo diff.

Monte o body em português, explicando o quê e o porquê a partir do diff — pode ficar vazio se o subject já é autoexplicativo.

Liste explicitamente os arquivos que serão staged — nunca proponha git add -A/git add ., apenas os arquivos relevantes para esta mudança.

Apresente:

Rascunho do commit:

  <subject>

  <body, se houver>

Arquivos a stagear:
  - <arquivo 1>
  - <arquivo 2>

Confirma?

Aguarde confirmação explícita do usuário antes de prosseguir. Se o usuário pedir ajuste, refaça o rascunho e apresente de novo.

PASSO 4 — Commitar

Após confirmação:

1. git add <arquivo 1> <arquivo 2> ... (por nome, nunca -A).

2. Commite com a mensagem via HEREDOC:

   git commit -m "$(cat <<'EOF'
   <subject>
   
   <body>
   EOF
   )"
   

3. Sempre um commit novo — nunca --amend.

4. Rode git status pra confirmar que o commit foi criado e a working tree reflete o esperado.

PASSO 5 — Próximo passo

Informe o commit criado (hash curto + subject) e sugira:

Commit criado ✓ <hash> <subject>

Para subir e abrir/atualizar o PR: /lf-push