technical-stories

name

technical-stories

description

Creates technical stories (`story.md` and subtasks) inside the `stories/` folder and manages dev tracking using the local system time. Ensures `stories/` exists at project root; each story lives in `stories/Story-XX-Name/`. Story number (XX) must be sequential: always use the next number (max existing + 1) unless the user explicitly asks for a different number. Use when the user asks to create a story, write a story, create a technical story, or when developing a story (DEV records start on begin; QA records end time, total duration and conclusion on approval).

Historias Tecnicas - Criacao e Rastreamento

Regra obrigatoria: pasta stories/

Todas as stories devem ficar dentro da pasta stories/.

1. Antes de criar qualquer story, verificar se existe a pasta stories/ na raiz do projeto.
2. Cada story e criada dentro de stories/, no formato stories/Story-XX-Descricao_Breve/.

Estrutura esperada:

<raiz do projeto>/
└── stories/
    ├── Story-01-Implementar_Autenticacao/
    │   ├── story.md
    │   └── subtask/
    │       ├── Subtask-01-Nome.md
    │       └── ...
    └── Story-02-Outra_Historia/
        ├── story.md
        └── subtask/

Nunca criar stories fora de stories/.

---

Parte 1 - Criar uma story

Quando o usuario pedir para criar uma story: apenas criar story.md e subtasks. Nao desenvolver nem executar subtasks automaticamente.

Passos

1. Garantir que existe stories/; criar se faltar.
2. Definir o numero da story:
   • Regra padrao: listar pastas stories/Story-*, extrair os numeros e usar o maior + 1 com 2 digitos.
   • Excecao: usar outro numero apenas se o usuario pedir explicitamente.
3. Nome da pasta: Story-XX-Descricao_Com_Underscore.
4. Criar story.md e a pasta subtask/ com um arquivo por subtask.
5. Minimo 3 subtasks, maximo 8; minimo 5 criterios de aceite no story.md.
6. Se a story envolver codigo, incluir subtasks e criterios de aceite para testes unitarios e registrar dependencias com nome e versao.

Checklist rapido

• Pasta stories/ existe.
• Numero XX e o proximo sequencial.
• Story em stories/Story-XX-Descricao/.
• story.md e pasta subtask/ criados.
• Descricao no formato Como..., quero..., para....

---

Parte 2 - Desenvolver uma story (dev tracking)

Aplica-se quando estivermos desenvolvendo uma story ja existente.

Regra de horario

• Sempre obter o horario atual do sistema usando powershell -Command "Get-Date -Format 'dd/MM/yyyy HH:mm'" ou equivalente.
• Nunca inventar horarios.
• Se o usuario informar explicitamente um horario, usar o horario informado.
• O DEV registra apenas Inicio.
• O QA registra Fim, Tempo total de desenvolvimento e a conclusao ao aprovar.

Ao iniciar o desenvolvimento (DEV)

1. Como primeira acao, obter o horario atual do sistema.
2. Registrar no story.md a secao Rastreamento (dev tracking):
   • Inicio: DD/MM/AAAA HH:mm
   • Fim: -
   • Tempo total de desenvolvimento: -
3. Se Inicio ja estiver preenchido, nao sobrescrever.

Ao concluir a story tecnica (QA)

1. Obter o horario atual do sistema.
2. Marcar a story como concluida no story.md.
3. Marcar todas as subtasks como prontas.
4. Preencher a secao Rastreamento (dev tracking):
   • Fim: DD/MM/AAAA HH:mm
   • Tempo total de desenvolvimento: calculado corretamente a partir de Inicio e Fim
5. Perguntar ao usuario: Deseja que eu gere o commit das alteracoes desta story?
   • Nunca executar git push automaticamente.

Formato do tempo total

• Menor que 1 hora: Xmin
• Igual ou maior que 1 hora: Xh Ymin
• Exatamente X horas: Xh

---

Regra de conclusao (commit)

Quando o usuario solicitar o commit das mudancas de uma historia, a story deve ja estar aprovada e concluida. Se o fechamento tecnico ainda nao tiver sido feito, o fluxo correto passa por QA antes do commit.

---

Referencia completa

• Estrutura do story.md, formato das subtasks, nomenclatura, exemplos e checklist detalhado: reference.md