pr-status

Mata o "conferir PR diariamente". Lê o índice, cruza com o GitHub, e diz exatamente o que precisa de você.

1. Projeto e índice

source ~/.claude/bin/get-project.sh
PROJECT_NAME="$(get-project-name)"
WF_DIR="$HOME/.claude/workflow/$PROJECT_NAME"
~/.claude/bin/pr-registry.sh list

2. Bootstrap se vazio

Se prs.json não tem PRs (índice novo), ofereça popular a partir das suas PRs abertas:

gh pr list --state open --author @me --json number,title,baseRefName,headRefName,url

Para cada uma, extraia o card da referência que o /pr-open grava (python3 ~/.claude/bin/tracker.py resolve diz o kind da org):

gh pr view <n> --json title,body -q '.title + "\n" + .body' > "$WF_DIR/.pr-text"
grep -oiE 'AB#[0-9]+' "$WF_DIR/.pr-text" | grep -oE '[0-9]+' | head -1            # ado
grep -oE "\b$PREFIX-[0-9]+\b" "$WF_DIR/.pr-text" | head -1                         # jira / linear

PREFIX é o project (Jira) ou o team (Linear) do tracker. Linear sem team: procure [A-Z][A-Z0-9]*-[0-9]+ e confirme a chave com o usuário (casa também UTF-8, ISO-9001).

Com o ID, REF=$(python3 ~/.claude/bin/tracker.py ref "<id>") dá kind e url. Registre com pr-registry.sh register <n> <branch> <base> <título> <url> <kind> <id> <card_url> (sem card, sem os três últimos). Avise quais PRs entraram vinculadas e quais ficaram sem card (referência ausente — normal em PRs antigas).

3. Inspecionar cada PR

Para cada PR do índice:

# se o PR sumiu (merged/closed), remova do indice e registre no digest
STATE=$(gh pr view <pr> --json state -q .state 2>/dev/null || echo GONE)

• MERGED → pr-registry.sh remove <pr>, marque no digest como concluída.
• CLOSED → idem, marque como fechada sem merge.
• Aberta → ~/.claude/bin/pr-inspect.sh <pr> e derive o stage:

Atualize o índice: pr-registry.sh set-stage <pr> <stage>.

4. Digest

Ordene por urgência (o que precisa de você primeiro). Formato:

PRs em voo — PROJECT_NAME

🔴 #<n> <título> — changes_requested · <card> 2 comentários não resolvidos · CI: ✓ · base: release/3.11.0/main → resolver comentários

🟡 #<n> <título> — awaiting_review · <card> aguardando review · CI: ✓

🟢 #<n> <título> — merge_ready · <card> aprovada, CI verde → pronta pra merge

(concluídas nesta rodada: #<n> merged)

Use ✓/✗/⏳ para checks (SUCCESS/FAILURE/PENDING). <card> vem do tracker do índice: AB#<id> no ADO, a chave no Jira/Linear; tracker null → "sem card".

5. Resolver comentários (gate)

Se houver PRs em changes_requested, pergunte: "Quer que eu resolva os comentários da PR #<n>?"

Se sim, para essa PR:

1. git fetch && git checkout <branch da PR do índice>.
2. Liste os unresolved do pr-inspect (path/line/author/body). Para cada um, entenda o pedido lendo o código real no path:line.
3. Aplique as correções com a menor superfície possível. Rode testes relevantes do pacote afetado (make test PKG=<pkg>).
4. Pare e mostre o diff. Não commite nem faça push sem OK explícito do usuário — regra de compliance.
5. Após aprovação: commit (conventional) + push. Ao responder na thread, use mcp azure-devops/gh só se o usuário pedir; por padrão o push já dispara a notificação nativa GitHub→Slack.

Nunca resolva a thread no GitHub por conta própria — quem resolve é o revisor.

6. Merge

Nunca mergeie automaticamente. Para PRs em merge_ready, apenas sinalize. Se o usuário pedir explicitamente o merge, confirme base e método antes.