Lf push

Você é responsável por levar a branch atual do commit local até um PR revisável. Nunca dê push nem crie/atualize um PR sem confirmação explícita do usuário. Nunca faça merge, aprove review, aplique label do tracker de issues ou dispare deploy — esta skill só cria/atualiza o PR e o vínculo com o tracker.

---

PASSO 0 — Verificar pré-condições

Rode git status --short e git branch --show-current.

• Mudanças não commitadas presentes: informe e pergunte se quer rodar /lf-commit antes, ou seguir mesmo assim (o push só levará o que já está commitado).
• Branch atual é a branch base/default do repo (ex.: main, master, ou a branch de staging identificada no Passo 1): não há o que abrir de PR a partir daqui — informe e encerre.
• Rode git log --oneline @{u}.. 2>/dev/null || git log --oneline -20 pra saber quantos commits existem pra subir. Se não houver nenhum commit à frente do que já foi pushado, informe que não há nada novo pra subir/atualizar (mas ainda pode haver um PR existente a checar — não encerre, siga pro Passo 4 se quiser só reportar o estado).

---

PASSO 1 — Resolver a base branch

Detecte a branch-base mais provável, nesta ordem:

1. Se o projeto documentar a convenção de branches (ex.: CLAUDE.md, CONTRIBUTING.md, docs/agents/), prefira o que estiver documentado.
2. Senão, veja quais branches remotas de staging existem (git branch -r), nesta ordem de preferência: environments/staging, staging, develop, dev.
3. Se nenhuma existir, use a branch default do repositório (gh repo view --json defaultBranchRef -q .defaultBranchRef.name, ou git remote show origin | grep 'HEAD branch').

Apresente o valor detectado:

PR vai ser aberto/atualizado contra: <base detectada>

Quer mudar a base?

Aguarde confirmação (aceitar o padrão também é uma resposta válida). Se o usuário pedir outra base, use a informada.

---

PASSO 2 — Resolver tipo e ticket

Mesma lógica do /lf-commit (Passos 1 e 2, incluindo a detecção/pergunta de qual issue tracker o projeto usa) — reutilize o resultado se essa branch já foi resolvida nesta sessão (por /lf-commit ou por uma chamada anterior desta própria skill).

---

PASSO 3 — Push

Apresente a branch e o remote de destino, aguarde confirmação, então:

git push -u origin <branch>

---

PASSO 4 — Criar ou atualizar o PR

Rode gh pr list --head <branch> --json number,url,state --state open.

Se já existir um PR aberto: informe a URL existente e não poste comentário no tracker neste passo (isso já deve ter acontecido na criação) — pule direto pro Passo 6. Se o título/corpo estiverem visivelmente desatualizados em relação aos commits novos, ofereça atualizar via gh pr edit (só com confirmação).

Se não existir: monte o PR antes de criar.

• Título: TIPO(PREFIXO-XXX): descrição em inglês (ou sem ticket se ticket-less; vocabulário mais livre pra mudanças ad-hoc, mesma regra do /lf-commit). A descrição em inglês é sobre o que o diff faz — nunca uma tradução literal do título da issue do tracker (que pode estar em outro idioma por convenção do projeto).

• Corpo: procure um template de PR do projeto, nesta ordem: .github/pull_request_template.md, .github/PULL_REQUEST_TEMPLATE.md, docs/pull_request_template.md.

  • Se encontrar um template: preencha cada seção que ele define. Tipicamente isso inclui:

    • Descrição: resumo do quê/porquê, a partir dos commits e do diff.
    • Tipo de mudança: marque o checkbox correspondente ao TIPO resolvido (feat → Nova feature, fix → Correção de bug; para tipos ad-hoc, marque o mais próximo — docs→Documentação, chore/infra→Infra, etc.).
    • Mudanças feitas: uma bullet por commit relevante de git log <base>..HEAD --oneline, em ordem cronológica.
    • Como testar: pergunte ao usuário quais passos concretos alguém deveria seguir pra validar a mudança manualmente, e use a resposta literal — não invente passos não verificados.
    • Checklist: deixe todos os itens desmarcados — quem revisar/o autor marca depois.
    • Issues relacionadas: link do ticket se houver (use a URL retornada pela própria chamada ao tracker — mcp__linear__get_issue/mcp__linear__save_issue já trazem a URL; para GitHub Issues, #<numero> já autolinkeia); se ticket-less, deixe a nota padrão do template (vínculo manual).

  • Se não encontrar nenhum template: use um corpo mínimo:

    ## Descrição
    <resumo do quê/porquê, a partir dos commits e do diff>
    
    ## Mudanças feitas
    - <bullet por commit relevante>
    
    ## Como testar
    <passos literais informados pelo usuário>
    
    ## Issues relacionadas
    <link do ticket, se houver>
    

  Apresente o título e corpo montados para confirmação antes de criar.

• Crie com:

  gh pr create --base <base> --head <branch> --title "<título>" --body "<corpo>"
  

---

PASSO 5 — Comentar o link da PR no tracker

Só quando o PR foi criado agora (não numa atualização de um PR já existente) e há um ticket resolvido:

• Linear: mcp__linear__save_comment issueId=<PREFIXO-XXX> body="PR aberto: <url do PR>"
• GitHub Issues: gh issue comment <numero> --body "PR aberto: <url do PR>"

Se ticket-less, pule este passo silenciosamente (nada pra vincular) — não é um erro.

---

PASSO 6 — Reportar

PR: <url> → base: <base>
<Tracker: comentário postado no ticket / sem ticket vinculado, nada comentado>