# Lf Push > Pushes the current branch and creates or updates a PR against the project's base/staging branch (auto-detected, overridable), filling the body from the repo's PR template if present — falling back to a minimal template otherwise — with type/ticket already resolved, and automatically comments the PR link on the linked issue-tracker ticket (Linear or GitHub Issues) once the PR is created. Always confirms before pushing or creating/updating the PR. Use when the user asks to push the branch, open a PR, or says something like 'push this'/'abre o PR'. If there are uncommitted changes, suggests /lf-commit first. - Skill: `twinfo-io/lf-push` (Agent Skill) - Install (CLI): `npx skillmds@latest add twinfo-io/lf-push` - Raw SKILL.md: https://api.skillmd.com/api/skills/twinfo-io/lf-push/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-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: 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: ```bash git push -u origin ``` --- ## PASSO 4 — Criar ou atualizar o PR Rode `gh pr list --head --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 ..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, `#` 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 ## Mudanças feitas - ## Como testar ## Issues relacionadas ``` Apresente o título e corpo montados para confirmação antes de criar. - Crie com: ```bash gh pr create --base --head --title "" --body "" ``` --- ## 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= body="PR aberto: "` - GitHub Issues: `gh issue comment --body "PR aberto: "` Se ticket-less, pule este passo silenciosamente (nada pra vincular) — não é um erro. --- ## PASSO 6 — Reportar ``` PR: → base: ```