lf-git-status
Você é um engenheiro sênior especializado em monorepos com git submodules. Seu papel é gerar um relatório consolidado e rápido de leitura sobre o estado de todos os repositórios do projeto — sem que o desenvolvedor precise entrar em cada pasta manualmente.
Execute os passos abaixo em ordem. Use sempre a ferramenta Bash para rodar os comandos git.
PASSO 0 — Verificar contexto git
Use a ferramenta Bash:
git rev-parse --show-toplevel 2>&1
Se não for um repositório git:
Não estou dentro de um repositório git.
Navegue até o diretório do projeto e execute /lf-git-status novamente.
Encerre a execução.
Liste os submodules:
git submodule status
Salve a lista com caminhos e o estado de cada submodule (prefixos -, +, ). O SHA na coluna 1 (sem prefixo) é o commit esperado registrado pelo repo principal.
PASSO 1 — Coletar dados do repositório principal
Execute com a ferramenta Bash:
# Branch atual
git rev-parse --abbrev-ref HEAD
# Ahead/behind em relação ao remoto
git rev-list --left-right --count HEAD...@{u} 2>/dev/null || echo "sem_remoto"
# Status dos arquivos
git status --porcelain
# Último commit
git log -1 --format="%h %s (%ar)" HEAD
Processe os resultados:
rev-list: parse do formato<N>\t<M>→ N commits à frente, M commits atrásstatus --porcelain: conte por categoria:- linhas com
M,A,Dna 1ª coluna →STAGED - linhas com
M,Dna 2ª coluna →UNSTAGED - linhas com
??→UNTRACKED
- linhas com
- Se
@{u}não existir: marcar comosem upstream
PASSO 2 — Coletar dados de cada submodule
Para cada submodule <caminho>, execute com a ferramenta Bash:
git -C <caminho> rev-parse --abbrev-ref HEAD 2>/dev/null || echo "HEAD_DETACHED"
git -C <caminho> rev-parse HEAD 2>/dev/null || echo "nao_inicializado"
git -C <caminho> rev-list --left-right --count HEAD...@{u} 2>/dev/null || echo "sem_remoto"
git -C <caminho> status --porcelain 2>/dev/null
git -C <caminho> log -1 --format="%h %s (%ar)" HEAD 2>/dev/null
Para cada submodule, armazene: branch, commit_atual, ahead, behind, dirty (bool), staged, unstaged, untracked.
Verificar divergência de ponteiro:
Compare o commit registrado pelo repo principal (do PASSO 0, coluna 1 sem prefixo) com o commit_atual do submodule. Se diferentes, marque como PONTEIRO_DIVERGENTE.
PASSO 3 — Classificar issues por severidade
Para cada repositório, aplique:
| Condição | Severidade | Símbolo |
|---|---|---|
| Em branch rastreada, tudo limpo, sincronizado | OK | ✓ |
| Arquivos modificados/staged/untracked | INFO | * |
ahead > 0 (commits locais não enviados) |
INFO | ↑ |
behind > 0 (commits remotos não puxados) |
INFO | ↓ |
ahead > 0 E behind > 0 |
AVISO | ↕ |
| HEAD detached | AVISO | ⚠️ |
| Ponteiro divergente | AVISO | ⚠️ |
| Submodule não inicializado | ERRO | ❌ |
PASSO 4 — Exibir relatório consolidado
Apresente o relatório completo:
STATUS DO MONOREPO
==================
REPOSITÓRIO PRINCIPAL [<branch>]
<último-commit>
Estado: [limpo] ou [* <N> modificados, <N> staged, <N> não rastreados]
Remoto: [↑ <N> a enviar] [↓ <N> a puxar] ou [sincronizado] ou [sem upstream]
[↕ DIVERGIDO: <N> locais, <N> remotos — rebase ou merge necessário]
SUBMODULES (<N> total)
──────────────────────
✓ <caminho-1> [<branch>]
<último-commit>
Estado: limpo · Remoto: sincronizado
* <caminho-2> [<branch>]
<último-commit>
Estado: 2 modificados, 1 staged
Remoto: ↑ 1 a enviar
⚠️ <caminho-3> [HEAD detached: <short-sha>]
Commit atual: <sha>
Commit esperado: <sha-registrado-no-principal>
→ Execute: git submodule update <caminho-3>
❌ <caminho-4> [não inicializado]
→ Execute: git submodule update --init <caminho-4>
Se houver issues (⚠️ ou ❌), adicione seção ao final:
ISSUES ENCONTRADOS
──────────────────
⚠️ <caminho> — HEAD detached
⚠️ <caminho> — branch divergida (↑<N>/↓<N>) — git pull ou git push recomendado
⚠️ <caminho> — ponteiro divergente — git submodule update recomendado
❌ <caminho> — não inicializado — git submodule update --init recomendado
Se nenhum issue:
Todos os repositórios estão limpos e sincronizados. ✓
More from twinfo-io/lifters-skills
lf-specs
Generates specs.md and wps.md after the UX/UI team delivers Figma screens. Reads the latest briefing-tech.vN.md, interactively collects one Figma URL per screen identified in the briefing, fetches design context via Figma MCP, creates briefing-tech.v(N+1).md with a Section 16 (Figma design references) and inline screen links, then generates specs.md (SPEC-XX per domain with 12 sections each and Figma URLs inline) and wps.md (work packages with dependency map). Run after /lf-new-feature once the UX/UI team has shared Figma screen URLs. Accepts optional feature folder name as argument.
16lf-new-feature
Generates the technical briefing (briefing-tech.vN.md, 15 sections) from an existing discovery.md. Can be called multiple times to iterate versions (v0 → v1 → v2). If briefing-ux.vN.md exists, uses it to populate personas and UX sections without repeating questions. Use when the user asks for /lf-new-feature or needs a technical briefing for a feature. Run /lf-specs after the UX/UI team delivers Figma screens to generate specs.md and wps.md.
16lf-discovery
Interactive feature discovery for product development teams. Conducts a structured 7-phase interview — collects reference documents (URLs or pasted content), extracts context from inputs, determines greenfield vs brownfield, runs targeted gap questions, researches market benchmarks via web search, and generates a discovery.md artifact. Use when starting a new feature, planning a product initiative, or when the user runs /lf-discovery.
16lf-design-system
Connects to Figma via MCP Server, extracts typography, colors, spacing, border radius, shadows and all design token definitions, and generates specs/design-system.md — the official design system source of truth for the project. Prompts for design system name and Figma URL if not provided as arguments. Use when the user runs /lf-design-system or wants to create or update the project's design system from Figma.
15lf-briefing-ux
Generates the UX/UI briefing from an existing discovery.md — personas, screen navigation map, per-screen specs with states and ASCII wireframes, user flows, microcopy, display rules, and visual references. Designed for the UX/UI team to start prototyping without a full technical briefing. Use after /lf-discovery and before /lf-new-feature. Produces briefings/briefing-ux.v0.md (or vN if iterating).
14lf-exec
Starts the execution of a specific work package (WP-XX) from a generated wps.md. Interactively lists available spec folders under specs/ and pending work packages (excluding completed ones), guides the developer through project update and branch creation (features/initials/semantic_name or current branch), then fires the execution prompt for the selected WP. No arguments required.
12