wize-dev-kit 0.10.1 → 0.12.0

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-02-context.md

@@ -108,7 +108,7 @@ Prepare the section to append:
 **Scale & Complexity:**
 - Primary domain: {{domain}}
 - Complexity level: {{level}}
-- Estimated architectural components: {{count}}
+- Architectural components: {{count}}
 
 ### Technical Constraints & Dependencies
 {{list}}

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-08-complete.md

@@ -47,7 +47,7 @@ lastStep: 8
 Architecture complete. Next:
 1. Hawkeye: run wize-tea-risk to build the global risk profile.
 2. Tony: run wize-create-epics-and-stories to slice the work.
-3. Use wize-help anytime to check what comes next.
+3. Use `/wize` (or `/wize-help`) anytime to check what comes next.
 ```
 
 ## On complete

package/src/method-skills/3-solutioning/wize-create-architecture/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-create-architecture
+description: "Use quando o PRD e UX design estiverem prontos e precisar projetar a arquitetura do sistema com componentes, sequências e ADRs."
 name: Create Architecture
 phase: 3-solutioning
 owner: wize-agent-architect   # Tony Stark

package/src/method-skills/3-solutioning/wize-create-epics-and-stories/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-create-epics-and-stories
+description: "Use quando a arquitetura estiver definida e precisar fatiar o escopo em epics e stories com acceptance criteria."
 name: Create Epics and Stories
 phase: 3-solutioning
 owner: wize-agent-architect   # Tony Stark
@@ -12,6 +14,8 @@ status: ready
 
 Tony drives. Output lands in `.wize/solutioning/epics/` and `.wize/solutioning/stories/`.
 
+> **No estimates.** Epics and stories never carry a time or effort estimate (hours, days, story points, S/M/L/XL) — at any step. AI development speed has made them noise that only burns time and tokens. The only sizing question is binary: **does a story fit one PR?** If not, slice it.
+
 When slicing raises decisions the PRD doesn't answer — priority order, sequencing, protected behaviors, what's out of a story — offer a short `wize-grill` pass with the user instead of guessing. Decisions land in the epic/story fields; unresolved ones become open questions with owners.
 
 ## Inputs
@@ -47,7 +51,6 @@ owner: Tony Stark + Maria Hill
 linked_prd: E01
 trigger_map_row: 1
 priority: 1
-estimate: M
 ---
 
 # Epic 01: Sign-up + first invite
@@ -76,8 +79,7 @@ Each story passes:
 - **I**ndependent — can be implemented without waiting for another in-flight story.
 - **N**egotiable — wording can move; intent stays.
 - **V**aluable — a real outcome to a real user (or a clear test path that proves a slice).
-- **E**stimable — Tony can size: S/M/L/XL.
-- **S**mall — fits in one PR (≤ 1 day for an experienced dev, including tests).
+- **S**mall — fits in one PR, tests included. This is the *only* sizing test; no time or point estimate (see **No estimates** above).
 - **T**estable — every AC is observable.
 
 If a story is XL, slice it before merging it to `stories/`.
@@ -101,7 +103,6 @@ story_id: E01-S03
 epic: 01-onboarding
 status: ready-for-dev
 priority: 2
-estimate: M
 linked_screens: [onboarding-step-1, invite-modal]
 linked_acs: [AC-02-1, AC-02-2]
 ---
@@ -163,9 +164,9 @@ Every story declares the AC IDs it advances (from PRD). The union of stories per
 
 Each story carries its own **sources of truth**, **restrictions** (out-of-scope + protected behaviors + compatibility + security), and a **validation contract** (AC → test map + required checks). These aren't optional prose — they are what makes AC → code → test → gate traceable. A story missing them is not ready for dev.
 
-### 4. Estimates
+### 4. Slice check (no estimates)
 
-Story estimates S/M/L/XL. XL gets sliced before merging. If everything is L, slicing pattern is too coarse; revisit.
+Don't estimate stories — size them by one question: does each fit a single PR? Anything that doesn't gets sliced before it lands in `stories/`. If most stories feel too big to slice cleanly, the slicing pattern is too coarse; revisit it.
 
 ### 5. Hand off
 

package/src/method-skills/3-solutioning/wize-design-system/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-design-system
+description: "Use quando o UX design estiver avançando e precisar estabelecer a baseline do design system (tokens, componentes, grids)."
 name: Design System
 phase: 3-solutioning
 owner: wize-agent-ux-designer   # Mantis (WDS Freya — Phase 7)

package/src/method-skills/3-solutioning/wize-nfr-principles/workflow.md

@@ -1,7 +1,9 @@
 ---
+
 code: wize-nfr-principles
+description: "Use quando o PRD estiver validado e precisar definir os princípios de NFR (perf, segurança, confiabilidade, acessibilidade, custo) que guiarão a arquitetura."
 name: NFR Principles
-phase: 2-to-3-boundary
+phase: 3-solutioning
 owner: wize-agent-solution-strategist   # Nick Fury
 status: ready
 ---

package/src/method-skills/3-solutioning/wize-project-context/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-project-context
+description: "Use quando precisar estabelecer ou atualizar o contexto do projeto (stack, convenções, restrições) para orientar a solução."
 name: Project Context
 phase: 3-solutioning
 owner: wize-agent-architect   # Tony Stark
@@ -60,7 +62,7 @@ Read `.wize/implementation/sprint-status.yaml` and include: sprint number, capac
 
 ### 6. Hand off
 
-Output is a markdown file. Wizer uses this file to seed `/wize-help`, `/wize-dev-story`, and `/wize-onboarding` reads.
+Output is a markdown file. Wizer uses this file to seed `/wize`, `/wize-help`, `/wize-dev-story`, and `/wize-onboarding` reads.
 
 ## Output template
 

package/src/method-skills/3-solutioning/wize-tech-vision/workflow.md

@@ -1,7 +1,9 @@
 ---
+
 code: wize-tech-vision
+description: "Use quando o PRD estiver validado e precisar definir o norte técnico: stack family, build-buy-borrow e non-negotiables."
 name: Tech Vision
-phase: 2-to-3-boundary
+phase: 3-solutioning
 owner: wize-agent-solution-strategist   # Nick Fury
 status: ready
 ---

package/src/method-skills/4-implementation/wize-changelog/workflow.md

@@ -0,0 +1,184 @@
+---
+code: wize-changelog
+description: "Use quando precisar gerar ou atualizar o changelog no formato Keep a Changelog a partir das stories concluídas."
+name: Changelog
+phase: 4-implementation
+owner: wize-agent-dev   # Shuri
+status: ready
+---
+
+# Changelog
+
+**Goal.** Gerar `CHANGELOG.md` no formato [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) a partir das stories concluídas no sprint, agrupadas por epic e categoria.
+
+Shuri executa. O changelog é gerado em pt-BR (texto voltado ao usuário) e segue a convenção do projeto.
+
+## Inputs
+
+- `.wize/implementation/sprint-status.yaml` — stories concluídas
+- `.wize/solutioning/stories/{epic}/*.md` — detalhes das stories
+- `.wize/solutioning/epics/*.md` — nomes legíveis dos epics
+- `CHANGELOG.md` — changelog existente (se houver)
+- `git tag --list 'v*' --sort=-v:refname | head -1` — última tag
+
+## Output
+
+- `CHANGELOG.md` criado ou atualizado com a nova entrada pré-pendida
+
+## Formato Keep a Changelog
+
+Seguir estritamente o formato [Keep a Changelog 1.1.0](https://keepachangelog.com/en/1.1.0/):
+
+```markdown
+# Changelog
+
+All notable changes to this project are documented here.
+Format inspired by [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
+
+## [Unreleased]
+
+## [0.12.0] — 2026-08-08
+
+### Added
+- **Epic 09 — UX / intent:** Release e changelog skills (`wize-release`, `wize-changelog`). #E09-S07
+
+### Changed
+- **Epic 09 — UX / intent:** Roteamento por intenção expandido com release/changelog. #E09-S03
+
+### Fixed
+- **Epic 09 — UX / intent:** Descrições de skill corrigidas (block scalars). #E09-S01
+
+### Security
+- (vazio se não houver stories de segurança)
+```
+
+### Regras de categoria
+
+| Categoria | Quando usar |
+|---|---|
+| **Added** | Nova feature, nova skill, nova funcionalidade |
+| **Changed** | Mudança em funcionalidade existente, alteração de comportamento |
+| **Deprecated** | Funcionalidade que será removida em breve |
+| **Removed** | Funcionalidade removida |
+| **Fixed** | Correção de bug |
+| **Security** | Correção de vulnerabilidade, melhoria de segurança |
+
+### Regras de agrupamento
+
+- Agrupar por **epic** dentro de cada categoria.
+- Cada linha começa com `- **Epic NN — Nome:**` seguido da descrição e `#story_id`.
+- Stories sem epic definido vão sob `- **Geral:**`.
+- Se uma categoria não tiver stories, escrever `- (vazio)` ou omitir (consistente com o changelog existente).
+
+## Steps
+
+### 1. Coletar stories concluídas
+
+Ler `sprint-status.yaml`. Para cada story com status `done`:
+
+1. Localizar o arquivo em `.wize/solutioning/stories/{epic}/{story}.md`
+2. Extrair do frontmatter: `story_id`, `epic`
+3. Extrair do corpo: título (linha `# Story:`) e primeira frase da seção `## Context` como sumário
+
+Se o arquivo da story não existir, usar apenas o `story_id` como referência.
+
+### 2. Classificar por categoria
+
+Para cada story, determinar a categoria com base no conteúdo:
+
+| Padrão no título/contexto | Categoria |
+|---|---|
+| "Adicionar", "Criar", "Novo", "Added", "Add" | Added |
+| "Corrigir", "Consertar", "Bug", "Fix", "Hotfix", "Correção" | Fixed |
+| "Alterar", "Mudar", "Refatorar", "Change", "Update" | Changed |
+| "Remover", "Deprecar" | Removed / Deprecated |
+| "Segurança", "Vulnerabilidade", "Security", "CVE" | Security |
+
+Se ambíguo, default `Added` para stories novas, `Changed` para alterações.
+
+### 3. Agrupar por epic
+
+Para cada story, resolver o nome do epic:
+
+1. Se o frontmatter tem `epic: NN-nome`, usar `Epic NN — Nome`
+2. Buscar em `.wize/solutioning/epics/{epic}.md` o título (`# Epic NN: Nome`)
+3. Fallback: `Epic {epic_id}`
+
+Agrupar stories por epic, depois por categoria.
+
+### 4. Gerar entrada do changelog
+
+Montar a entrada no formato:
+
+```markdown
+## [{version}] — {YYYY-MM-DD}
+
+{descrição curta do release — 1-2 frases sobre o que esta versão entrega}
+
+### Added
+- **{epic_nome}:** {descrição}. #{story_id}
+
+### Changed
+- **{epic_nome}:** {descrição}. #{story_id}
+
+### Fixed
+- **{epic_nome}:** {descrição}. #{story_id}
+
+### Security
+- **{epic_nome}:** {descrição}. #{story_id}
+```
+
+### 5. Atualizar CHANGELOG.md
+
+Se `CHANGELOG.md` não existir, criar com o cabeçalho padrão:
+
+```markdown
+# Changelog
+
+All notable changes to this project are documented here.
+Format inspired by [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
+
+> **Language:** entries are written in **Portuguese (pt-BR)**.
+
+## [Unreleased]
+```
+
+Se existir:
+1. Localizar a linha `## [Unreleased]`
+2. Inserir a nova entrada entre `## [Unreleased]` e a primeira `## [versão]` existente
+3. Se não houver `## [Unreleased]`, inserir após o cabeçalho
+
+### 6. Verificar formatação
+
+- A data está no formato `YYYY-MM-DD`
+- A versão segue semver (`X.Y.Z`)
+- Cada story tem referência ao `#story_id`
+- Categorias vazias foram omitidas
+- O link do Keep a Changelog está presente
+
+## Exemplo de saída
+
+```markdown
+## [0.12.0] — 2026-08-08
+
+Release do cluster de ship: skills de release e changelog para o perfil core, roteamento por intenção expandido.
+
+### Added
+- **Epic 09 — UX / intent:** Skill `wize-release` para bump de versão, changelog e tag git a partir das stories gated. #E09-S07
+- **Epic 09 — UX / intent:** Skill `wize-changelog` para geração de changelog no formato Keep a Changelog. #E09-S07
+
+### Changed
+- **Epic 09 — UX / intent:** Tabela de roteamento por intenção expandida com release, changelog, lançar, publicar, notas de versão. #E09-S03
+```
+
+## Anti-patterns
+
+- Changelog escrito à mão sem referência às stories — perde rastreabilidade.
+- Categoria "Added" para correção de bug — usar "Fixed".
+- Data fora do formato ISO — usar `YYYY-MM-DD`.
+- Pular stories concluídas — toda story `done` no sprint entra no changelog.
+- Escrever changelog em inglês quando o projeto usa pt-BR — seguir o idioma do changelog existente.
+
+## Hand-off
+
+> Changelog atualizado em `CHANGELOG.md`. {count} stories de {epic_count} epics registradas. Próximo: `/wize-release` para bump de versão e tag, ou revisão manual do changelog.

package/src/method-skills/4-implementation/wize-checkpoint-preview/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-checkpoint-preview
+description: "Use quando uma story estiver parcialmente implementada e precisar de preview de checkpoint para validar direção antes de continuar."
 name: Checkpoint Preview
 phase: 4-implementation
 owner: wize-agent-dev   # Shuri (+ wize-agent-architect Tony on call)
@@ -8,19 +10,19 @@ status: ready
 
 # Checkpoint Preview
 
-**Goal.** Pause mid-story to validate direction before continuing. For M/L stories where the cost of going off-rail is high, a quick checkpoint catches drift before it becomes rework.
+**Goal.** Pause mid-story to validate direction before continuing. For larger stories where the cost of going off-rail is high, a quick checkpoint catches drift before it becomes rework.
 
 Shuri drives. Tony on call for architectural drift. Hawkeye on call for test design drift.
 
 ## When to run
 
-- Manually, when a story is taking longer than expected.
-- After the first 2-3 commits of an M or L story.
+- Manually, when a story is running long or feels off-track.
+- After the first 2-3 commits of a larger story.
 - When a new constraint is mentioned (security review, perf budget, vendor change).
 
 ## When NOT to run
 
-- Quick-dev / S stories (overhead exceeds the value).
+- Quick-dev / small stories (overhead exceeds the value).
 - When the story is < 50% done and no surprise has come up yet.
 
 ## Inputs
@@ -49,7 +51,7 @@ Write 5 lines:
 - ACs done vs. remaining: (X / Y)
 - Tests added: (count, by split)
 - New dependencies: (list)
-- Time spent: (estimate)
+- Commits so far: (count)
 
 ### 3. Sanity check (3 questions)
 
@@ -92,7 +94,7 @@ author: Shuri
 - ACs done vs. remaining: 1 / 4
 - Tests added: 2 unit, 1 integration
 - New dependencies: none
-- Time spent: ~3h
+- Commits so far: 3
 
 ## Sanity check
 - Right problem? Yes.

package/src/method-skills/4-implementation/wize-code-review/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-code-review
+description: "Use quando um PR estiver aberto e precisar de revisão de código por pares focada em saúde do código."
 name: Code Review
 phase: 4-implementation
 owner: wize-agent-dev   # Shuri (peer review)

package/src/method-skills/4-implementation/wize-correct-course/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-correct-course
+description: "Use quando o projeto desviar do plano e precisar de correção de curso com decisão documentada."
 name: Correct Course
 phase: 4-implementation
 owner: wize-agent-pm   # Maria Hill, with wize-orchestrator
@@ -43,7 +45,7 @@ Wizer pulls the latest status file. If `last_updated` is older than 2 days, the
 
 Pick exactly one cause:
 
-- **Cut scope.** Story is bigger than estimated, or a non-essential AC can be deferred.
+- **Cut scope.** Story turned out larger than one PR, or a non-essential AC can be deferred.
 - **Re-route.** Story needs a different agent (e.g., Mantis for UX) or skill (e.g., `wize-investigate` for a regression).
 - **Escalate.** Story needs more hands, or a decision outside the team.
 

package/src/method-skills/4-implementation/wize-create-story/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-create-story
+description: "Use quando um epic estiver definido e precisar criar uma story individual com acceptance criteria detalhados."
 name: Create Story
 phase: 4-implementation
 owner: wize-agent-architect   # Tony writes; Shuri may refine
@@ -12,6 +14,8 @@ status: ready
 
 Tony drives. Shuri reads and proposes refinements before pulling the story.
 
+> **No estimates.** Never attach a time or effort estimate (hours, days, story points, S/M/L/XL) to a story — at any step. AI development speed has made them noise that only burns time and tokens. The only sizing question is binary: **does it fit one PR?** If not, slice it. Nothing else.
+
 ## When to use
 
 - New story splits from an epic (most common — done in `wize-create-epics-and-stories`).
@@ -47,7 +51,6 @@ story_id: E01-S03
 epic: 01-onboarding
 status: ready-for-dev
 priority: 2          # 1=now, 2=next, 3=later
-estimate: M          # S | M | L  (XL → slice further before merging here)
 linked_screens: [onboarding-step-1, invite-modal]
 linked_acs: [AC-02-1, AC-02-2]
 ---
@@ -95,20 +98,12 @@ Every story passes:
 - **I**ndependent.
 - **N**egotiable.
 - **V**aluable.
-- **E**stimable (Tony sizes).
-- **S**mall (≤ 1 PR).
+- **S**mall (≤ 1 PR) — the *only* sizing test; if it doesn't fit one PR, slice.
 - **T**estable.
 
-If any letter fails, fix before queueing.
-
-## Estimation rough guide
-
-- **S** ≤ 4h.
-- **M** 4h–1d.
-- **L** 1–2d.
-- **XL** > 2d → split.
+(INVEST's "Estimable" is dropped on purpose — see **No estimates** above. We don't size in time or points.)
 
-These are intervals, not commitments. Hill plans capacity against M-median.
+If any letter fails, fix before queueing.
 
 ## Full story template
 
@@ -118,7 +113,6 @@ story_id: E01-S03
 epic: 01-onboarding
 status: ready-for-dev
 priority: 2
-estimate: M
 linked_screens: [onboarding-step-1, invite-modal]
 linked_acs: [AC-02-1, AC-02-2]
 ---

package/src/method-skills/4-implementation/wize-dev-story/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-dev-story
+description: "Use quando uma story estiver pronta para implementação e precisar ser desenvolvida com TDD e commits rastreáveis."
 name: Dev Story
 phase: 4-implementation
 owner: wize-agent-dev   # Shuri
@@ -14,7 +16,7 @@ Shuri drives. Hawkeye observes (test design is binding). Tony stays available fo
 
 ## Operating contract
 
-I work inside a repo with WDK installed: `.wize/`, `AGENTS.md`, and the `wize-*` skills are my instructions and memory, not background reading. This section is the execution slice of the story's **mission contract** (see `/wize-help mission`).
+I work inside a repo with WDK installed: `.wize/`, `AGENTS.md`, and the `wize-*` skills are my instructions and memory, not background reading. This section is the execution slice of the story's **mission contract** (see `/wize mission` or `/wize-help mission`).
 
 - **Inspect before editing.** Read the story, its sources of truth, and the touched code first.
 - **Reuse ladder before new code** (see `wize-agent-dev` persona): needs to exist → already here → stdlib → framework feature → installed dep → one-liner → only then new code.

package/src/method-skills/4-implementation/wize-investigate/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-investigate
+description: "Use quando um bug ou comportamento inesperado surgir e precisar de investigação estruturada com root cause analysis."
 name: Investigate
 phase: 4-implementation
 owner: wize-agent-dev   # Shuri (+ wize-agent-test-architect Hawkeye on call)

package/src/method-skills/4-implementation/wize-quick-dev/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-quick-dev
+description: "Use quando a demanda for pequena e bem delimitada (bug fix, copy edit, refactor) e não justificar o ciclo completo."
 name: Quick Dev (lifecycle shortcut)
 phase: 4-implementation
 owner: wize-agent-dev   # Shuri

package/src/method-skills/4-implementation/wize-release/workflow.md

@@ -0,0 +1,162 @@
+---
+code: wize-release
+description: "Use quando todas as stories do sprint estiverem gated e você precisar gerar release: bump de versão, changelog e tag git."
+name: Release
+phase: 4-implementation
+owner: wize-agent-dev   # Shuri + Maria Hill
+status: ready
+---
+
+# Release
+
+**Goal.** Bump de versão, changelog a partir das stories gated e tag git. O release é o passo entre "todas as stories passaram no gate" e a retrospectiva.
+
+Shuri executa. Maria Hill confirma o escopo (quais epics entram).
+
+## Pré-requisitos
+
+Antes de iniciar, verificar:
+
+1. **Sprint ativo** — `sprint-status.yaml` deve ter `development_status` com stories.
+2. **Todas as stories gated** — cada story no sprint ativo deve estar `done` no `sprint-status.yaml`. Stories com gate `FAIL` bloqueiam o release. Stories com `CONCERNS` precisam de waiver documentado.
+3. **Git limpo** — `git status --porcelain` deve estar vazio (ou conter apenas arquivos não rastreados que não fazem parte do release).
+4. **Branch main** — releases saem da `main`. Se estiver em feature branch, abortar e orientar merge via PR.
+
+Se qualquer pré-requisito falhar, reportar o bloqueio e parar. Não fazer release parcial.
+
+## Inputs
+
+- `.wize/implementation/sprint-status.yaml` — stories concluídas
+- `.wize/solutioning/stories/{epic}/*.md` — detalhes das stories
+- `package.json` — versão atual
+- `CHANGELOG.md` — changelog existente (se houver)
+- `git tag --list 'v*'` — tags existentes
+
+## Outputs
+
+- `package.json` com versão atualizada
+- `CHANGELOG.md` atualizado com a nova versão
+- Tag git `v{semver}`
+- `sprint-status.yaml` atualizado (sprint marcado como concluído)
+- Resumo do release no terminal
+
+## Steps
+
+### 1. Verificar pré-requisitos
+
+```bash
+git status --porcelain  # deve estar vazio
+git branch --show-current  # deve ser main
+```
+
+Ler `sprint-status.yaml` e validar que todas as stories do sprint ativo estão `done`. Se houver stories `backlog`, `ready-for-dev`, `in-progress` ou `review`, listar cada uma e abortar.
+
+### 2. Coletar stories concluídas
+
+Varrer `development_status` no `sprint-status.yaml`. Para cada story com status `done`:
+
+1. Localizar o arquivo da story em `.wize/solutioning/stories/{epic}/{story}.md`
+2. Extrair do frontmatter: `story_id`, `epic`, `status`
+3. Extrair do corpo: título (linha `# Story:`), acceptance criteria
+
+Agrupar por epic. Se o epic tiver `epic_id` no `sprint-status.yaml`, usar o nome do arquivo do epic em `.wize/solutioning/epics/` para obter o título legível.
+
+### 3. Determinar o bump de versão
+
+Ler a versão atual de `package.json`:
+
+```
+Versão atual: 0.11.0
+Qual o bump?
+  1. patch (0.11.1) — correções, hotfix, docs
+  2. minor (0.12.0) — novas features compatíveis
+  3. major (1.0.0) — breaking changes
+```
+
+Em modo interativo, perguntar ao usuário. Em modo não-interativo, usar o primeiro argumento (`patch`, `minor` ou `major`). Se nenhum argumento for passado, default `patch`.
+
+Calcular a nova versão com `semver.inc(current, bump)` — usar Node built-in (regex parse + increment, sem dependência externa).
+
+### 4. Gerar changelog
+
+Delegar a geração do changelog ao `wize-changelog`:
+
+1. Invocar o fluxo do `wize-changelog` com a nova versão e a lista de stories coletadas no passo 2.
+2. O changelog é gerado no formato Keep a Changelog e pré-pendido ao `CHANGELOG.md`.
+
+Se `CHANGELOG.md` não existir, criar com o cabeçalho padrão.
+
+### 5. Bump de versão
+
+Atualizar o campo `version` em `package.json` com a nova versão. Preservar a formatação existente (indentação, aspas duplas).
+
+### 6. Commit e tag
+
+```bash
+git add package.json CHANGELOG.md
+git commit -m "chore: release v{version}"
+git tag v{version} -m "Release v{version}"
+```
+
+A mensagem de commit deve listar os epics incluídos no release.
+
+### 7. Atualizar sprint-status.yaml
+
+Adicionar ao `sprint-status.yaml`:
+
+```yaml
+release:
+  version: "{version}"
+  date: "{YYYY-MM-DD}"
+  sprint: "{active_cycle}"
+  stories_released: {count}
+```
+
+Marcar o sprint como concluído e adicionar entrada de retrospectiva pendente.
+
+### 8. Resumo
+
+Emitir no terminal:
+
+```
+✓ Release v{version} criado
+
+Epics incluídos:
+  - {epic_name} ({story_count} stories)
+
+Changelog: CHANGELOG.md
+Tag: v{version}
+Commit: {commit_hash}
+
+Próximos passos:
+  - git push origin main --tags
+  - /wize-retrospective
+```
+
+**Não executar `git push` automaticamente.** O push é sempre manual — o desenvolvedor revisa antes de publicar.
+
+## Bump semver (built-in, zero-dep)
+
+```js
+function bumpVersion(current, type) {
+  const [major, minor, patch] = current.split('.').map(Number);
+  switch (type) {
+    case 'major': return `${major + 1}.0.0`;
+    case 'minor': return `${major}.${minor + 1}.0`;
+    case 'patch': return `${major}.${minor}.${patch + 1}`;
+    default: throw new Error(`Tipo de bump inválido: ${type}. Use patch, minor ou major.`);
+  }
+}
+```
+
+## Anti-patterns
+
+- Fazer release com stories não gated — o gate existe para proteger a main.
+- Fazer release de feature branch — releases saem da main.
+- Push automático — o desenvolvedor revisa antes de publicar.
+- Pular o changelog — "depois eu escrevo" = nunca escreve.
+- Bump manual de versão — usar o bump semver para evitar off-by-one.
+
+## Hand-off
+
+> Release v{version} criado. Changelog atualizado, tag aplicada. Execute `git push origin main --tags` quando revisar. Depois: `/wize-retrospective`.