<quick_start> Dispatch com base no tipo de $ARGUMENTS:

• Se $ARGUMENTS for um numero, trate como PR e siga o workflow a partir do Step 2 (branch PR).
• Se $ARGUMENTS for texto, trate como descricao e siga o workflow a partir do Step 2 (branch descricao).
• Se $ARGUMENTS estiver vazio, pergunte ao usuario via AskUserQuestion.

Em seguida, siga o <workflow> passo a passo. </quick_start>

<pre_conditions>

• Diretorio docs/adr/potential-adr/ deve existir (criar com mkdir -p se ausente)
• Template disponivel em docs/adr/0000-adr-template.md (usar estrutura MADR padrao se ausente) </pre_conditions>

<step_1 name="Determinar Proximo Numero"> Escanear tanto docs/adr/ quanto docs/adr/potential-adr/ para evitar numeros duplicados:

bash
1{ ls docs/adr/*.md 2>/dev/null; ls docs/adr/potential-adr/*.md 2>/dev/null; } | grep -oE '[0-9]{4}' | sort -n | tail -1

Incrementar em 1 (ex: 0012 -> 0013). Formatar com 4 digitos. </step_1>

<step_2 name="Identificar Contexto"> Se $ARGUMENTS for numero de PR:

bash
1gh pr view $ARGUMENTS --json title,body
2gh pr diff $ARGUMENTS --name-only

Analisar mudancas para identificar: decisao tomada, alternativas consideradas, justificativa.

Se $ARGUMENTS for descricao textual: usar como base para a secao "Contexto e Problema". Inferir alternativas provaveis a partir do dominio e marcar decisores: [] como pendente de preenchimento pelo usuario antes da aprovacao.

Se $ARGUMENTS estiver vazio: perguntar ao usuario se quer fornecer numero de PR ou descrever manualmente. </step_2>

<step_3 name="Gerar Titulo"> Formato: XXXX-titulo-em-kebab-case.md

Exemplos:

• 0013-integracao-oauth-google-drive.md
• 0014-arquitetura-sistema-notificacoes.md </step_3>

<step_4 name="Criar Conteudo"> Usar o template em docs/adr/0000-adr-template.md como base:

<adr_template>

markdown
1---
2status: proposto
3data: YYYY-MM-DD
4decisores: []
5---
6
7# XXXX-Titulo Descritivo
8
9## Contexto e Problema
10[2-3 frases descrevendo o contexto]
11
12## Fatores de Decisao
13* [Extraidos dos requisitos/discussoes]
14
15## Opcoes Consideradas
16* [Opcao implementada]
17* [Alternativa 1]
18* [Alternativa 2]
19
20## Resultado da Decisao
21**Opcao escolhida:** "[Opcao X]", porque [justificativa].
22
23### Consequencias
24**Positivas:**
25* [Beneficios]
26
27**Negativas:**
28* [Tradeoffs]
29
30## Confirmacao
31[Como validar a implementacao]
32
33## Mais Informacoes
34- PR: #$ARGUMENTS (se aplicavel)

</adr_template> </step_4>

<step_5 name="Salvar ADR"> Criar o arquivo em docs/adr/potential-adr/XXXX-titulo-kebab-case.md. </step_5>

<step_6 name="Atualizar README"> Adicionar entrada na secao "ADRs Pendentes" de docs/adr/README.md:

markdown
1| ADR-$ADR_NUM | [$ADR_TITLE](./potential-adr/$ADR_FILENAME) | $(date +%Y-%m-%d) | Proposto |

</step_6>

<step_7 name="Reportar ao Usuario"> Informar: arquivo criado, numero do ADR, resumo do conteudo. Sugerir revisao e aprovacao com /adr-approve XXXX. </step_7>

<error_handling>

• Se docs/adr/potential-adr/ nao existe: criar com mkdir -p docs/adr/potential-adr/
• Se PR nao encontrado: informar numero invalido e pedir novo input
• Se template nao existe: criar ADR com estrutura padrao MADR
• Se README.md nao tem secao de pendentes: criar a secao </error_handling>

<success_criteria>

• Numero do ADR determinado corretamente (proximo sequencial, sem conflito com potential-adr/)
• Contexto extraido do PR ou descricao
• ADR criado em docs/adr/potential-adr/ com status "proposto"
• README.md atualizado com entrada pendente
• Usuario informado com proximos passos (/adr-approve) </success_criteria>