# Lf Commit

> Builds and creates a commit following conventional-commit style: type (feat/fix) resolved from the current branch prefix, ticket ID resolved from the branch name or from the project's issue tracker (Linear or GitHub Issues — detected from project docs or asked once per project), English subject and Portuguese body. Always presents the draft and only commits after explicit confirmation. Use when the user asks to commit, generate/review the commit message, or says something like 'commit this'/'cria o commit'. Suggests running /lf-push afterward.

- Skill: `twinfo-io/lf-commit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add twinfo-io/lf-commit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/twinfo-io/lf-commit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: twinfo-io (https://skillmd.com/u/twinfo-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/twinfo-io/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:

   ```bash
   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
```