Refinar e aprofundar o backlog

Modo de interação

Modo de interação:

perguntas

. Antes de formular qualquer pergunta, leia e aplique o

Contrato de perguntas numeradas

.specsfy/Spec.md

Transforme uma entrada vaga em um item de backlog compreensível e, quando a intenção exigir especificação, aprofunde as decisões até produzir um brief testável. Esta é a segunda etapa sequencial do framework. Ela reúne registro, refinamento e descoberta sem transformar o backlog em fonte normativa.

Orquestrar a conversa

Ao concluir esta etapa ou detectar trabalho de outra etapa, anuncie

Pendência detectada: <descrição> — ação: resolvendo nesta etapa

e resolva-a quando pertencer ao próprio escopo. Quando houver troca de responsabilidade, anuncie

Transição automática: $specsfy-02-backlog → $<destino> — motivo: <motivo> — resultado esperado: <resultado>

e carregue imediatamente a skill de destino, sem pedir confirmação nem repetir o comando. Continue na mesma conversa.

Depois de uma correção necessária a esta etapa, anuncie

Retomada automática: $<destino> → $specsfy-02-backlog — pendência resolvida: <resultado>

e retome-a imediatamente. Reavalie o estado após cada handoff para evitar ciclos. O handoff não exige confirmação; ações sensíveis continuam exigindo autorização específica.

Buscar duplicatas e referências

Extraia termos derivados do pedido do usuário, incluindo nomes do domínio e equivalentes evidentes já usados na conversa.

Antes de criar ou atualizar o item, pesquise esses termos em:

```
specs/inbox/*.md
```
;
```
specs/backlog/*.md
```
;
```
specs/<estado>/*/spec.md
```
;
```
docs/**/*.md
```
.

Leia somente resultados plausíveis e classifique cada relação:
- possível duplicata: problema, pessoa, resultado e contexto substancialmente iguais;
- backlog relacionado: item complementar, dependência ou precedente;
- spec relacionada: comportamento definido ou entregue que limita o item;
- documentação relacionada: vocabulário, regra ou contexto do projeto.
Apresente correspondências materiais com seus caminhos. Diante de possível duplicata, confirme com o usuário se deve atualizar o item ou registrar uma diferença real.
Registre fontes úteis em
```
Referências relacionadas
```
, com caminho relativo e tipo de relação. Não transforme uma decisão encontrada em declaração do usuário.

Se uma resposta mudar materialmente os termos, o problema, a pessoa, o resultado ou o contexto, repita a busca.

Garantir a captura mínima

Preserve a formulação original recebida na conversa ou em
```
specs/inbox/<data-hora>-<slug>.md
```
. Separe declaração, inferência e aberto.
Confirme se o contexto esclarece:
- problema percebido;
- pessoa afetada ou beneficiada;
- resultado ou valor esperado;
- contexto suficiente para distinguir a entrada de pedidos semelhantes.
Se algo estiver ausente, vago, contraditório ou ambíguo, selecione três lacunas reais de maior impacto e monte uma rodada numerada.
Reavalie as lacunas depois de cada resposta. Não transforme os itens em questionário fixo nem repita informação já fornecida.
Não crie nem atualize o arquivo enquanto algum item essencial continuar ausente ou ambíguo. Se a pessoa não souber responder, explique a lacuna sem inventar conteúdo.

A captura mínima não exige solução técnica, critérios completos de aceitação ou prioridade. Esses dados podem amadurecer no aprofundamento.

Criar ou atualizar o item

Se a pessoa apenas quiser explorar sem registrar, converse e confirme antes de escrever.
Se existir item correspondente, atualize-o sem mudar seu ID e preserve a formulação anterior.
Se a origem for
```
specs/inbox/
```
, registre esse caminho em
```
Referências relacionadas
```
; não altere nem apague a captura.
Para criar um item novo, execute:

bash

node <diretório-da-skill>/scripts/iniciar_backlog.mjs \
  --title "<título curto>" \
  --idea "<formulação original>" \
  --problem "<problema percebido>" \
  --person "<pessoa afetada ou beneficiada>" \
  --result "<resultado ou valor esperado>" \
  --context "<contexto que distingue a ideia>" \
  [--slug <slug>] [--root <raiz>]

Use o caminho absoluto impresso pelo script. Ele prefere
```
.specsfy/templates/custom/Backlog.md
```
e recorre a
```
.specsfy/templates/Backlog.md
```
.

Organizar e priorizar

Leia

references/backlog-quality.md

ao estruturar, refinar, priorizar ou avaliar prontidão.

Classifique, quando conhecido, em Produto → Épico → Funcionalidade → item.
Use tipos como épico, história, regra, técnico e melhoria sem confundir tipo com prioridade.
Ordene por valor, risco, dependências, urgência, esforço, desbloqueios e incerteza; não marque tudo como prioridade alta.
Aprofunde campos conforme risco e complexidade. Autenticação, pagamentos, permissões, privacidade e operações assíncronas exigem mais cuidado.
Prefira comportamento observável a solução de interface.
Torne atributos de qualidade mensuráveis quando forem materiais.
Use listas, fluxos, cenários ou matrizes quando reduzirem ambiguidade.

Aprofundar para a especificação

Quando a pessoa pedir aprofundamento, promoção ou criação de uma spec:

Leia a entrada de
```
specs/inbox/
```
, o item de
```
specs/backlog/
```
ou a spec indicada. Se houver mais de um candidato, pergunte qual aprofundar.
Resuma em uma frase o problema, a pessoa e o resultado percebido.
Separe o que está decidido do que pode mudar escopo, experiência, segurança, dados, testes ou arquitetura.
Leia
```
references/discovery-map.md
```
para selecionar perguntas relevantes; não percorra o mapa mecanicamente.
Leia
```
../specsfy-03-specify/references/mcr-10.md
```
e faça a análise categorial silenciosamente antes da primeira pergunta.
Leia
```
references/specialists.md
```
somente quando tecnologia ou disciplina exigir contexto adicional.

Conduzir a descoberta adaptativa

Execute um ciclo sem limite máximo de rodadas:

Antes de cada rodada, releia a entrada, as decisões confirmadas, o contexto acumulado e as novas respostas, além da evidência aplicável.
Reclassifique lacunas e dependências. Continue enquanto existir lacuna aplicável; encerre quando cada uma estiver decidida, não aplicável ou resolvida por evidência.
Selecione pelo menos três lacunas reais por
```
impacto × incerteza
```
, priorizando P1, P2 e P3, e apresente a rodada conforme o contrato central.
Registre cada resposta original, a decisão normalizada e seus efeitos. Volte ao primeiro passo; não reutilize uma fila fixa.

Inclua

Avançar

em cada pergunta desde a primeira rodada. Se a pessoa escolher essa opção:

na rodada seguinte, confirme se ela encerra definitivamente as perguntas daquela área, responde depois ou volta a responder agora;
inclua a confirmação entre as três perguntas numeradas da rodada;
ao encerrar, registre
```
Área encerrada pelo usuário: <área>
```
e não pergunte novamente, salvo reabertura explícita;
ao adiar, registre
```
Área adiada pelo usuário: <área>
```
e preserve os pontos não respondidos para retomada;
não preencha respostas por inferência;
permita o handoff solicitado, mantendo
```
Status: Draft
```
e
```
Definition Gate: Pending
```
quando restarem lacunas aplicáveis.

Durante a conversa:

ofereça pelo menos três opções numeradas quando reduzirem o esforço e recomende uma com justificativa curta;
aceite respostas livres e use-as na reanálise;
preserve termos originais e diferencie declaração, inferência, hipótese, decisão, conflito e aberto;
confirme intenção operacional por síntese;
não recite as dez categorias nem transforme cada uma em pergunta.

Garanta cobertura suficiente de problema, atores, resultado, escopo, jornadas, falhas, limites, regras, dados, segurança, privacidade, desempenho, acessibilidade, restrições existentes e sinais objetivos de aceite e sucesso.

Manter o item

Use exatamente

specs/backlog/<NNNN>-<slug>.md

e mantenha:

```
Status: Captured
```
enquanto o item estiver apenas registrado;
```
Status: Refining
```
durante refinamento ou descoberta;
```
Status: Ready for specification
```
quando o brief estiver suficiente;
```
Status: Promoted
```
depois que uma spec derivada existir.

Mantenha as metainformações na tabela abaixo do título. Não invente prioridade, prazo, stakeholder, solução ou evidência. Use

Pronto para desenvolvimento

como diagnóstico, nunca como autorização de implementação.

Encerrar

Apresente um

Brief pronto para especificar

com:

Problema e objetivo.
Atores.
Escopo e fora de escopo.
Jornadas e regras essenciais.
Critérios de aceite em Given/When/Then.
Restrições técnicas e de qualidade.
Suposições.
Decisões abertas ou
```
Nenhuma lacuna aplicável
```
.
Vocabulário ambíguo e inferências confirmadas.

Atualize o item de backlog quando a pessoa autorizar esse registro. Quando o brief estiver suficiente ou a pessoa escolher

avançar

, retorne automaticamente para

$specsfy-update-spec

se a etapa foi chamada por mudança tardia em spec aprovada. Para criar ou consolidar a definição inicial, chame

$specsfy-03-specify

. No caso de

avançar

, entregue brief parcial e informe as lacunas que impedem o Definition Gate.

Limites

Não alterar nem apagar entradas de Inbox.
Não criar
```
spec.md
```
, tarefas, research, testes ou código.
Não inventar stakeholders, integrações, restrições ou decisões.
Não transformar hipótese técnica em requisito.
Não mover nem apagar item existente sem confirmação.

specsfy-02-backlog

NPX Install

Tags

SKILL.md Content