wize-dev-kit 0.11.0 → 0.12.1

package/src/method-skills/1-analysis/wize-research/workflow.md

@@ -4,113 +4,48 @@ name: Research
 phase: 1-analysis
 owner: wize-agent-analyst   # Pepper Potts
 status: ready
+description: "Use quando precisar pesquisar algo mas não souber qual tipo de pesquisa se aplica."
 ---
 
-# Research
+# Research (Dispatcher)
 
-**Goal.** Surface evidence that hardens the brief and trigger map. Frame the questions Pepper actually needs answered, do focused passes (market / competitors / analytics / interviews), and write the synthesis in a way Maria Hill can quote in the PRD.
+**Goal.** Classify the user's research question and delegate to the correct variant. This skill does NOT execute research directly — it routes to one of the specialized research skills.
 
-Pepper drives. Peggy edits prose. Output lands in `.wize/planning/research.md` with raw materials in `.wize/knowledge/research/`.
+## Classification guide
 
-## Inputs
+Analyze the user's question for these signals. Score each category by keyword hits; delegate to the highest-scoring category.
 
-- Open questions in `.wize/planning/brief.md`.
-- Hypotheses in `.wize/planning/ux/trigger-map.md`.
-- External access (browser, MCPs) and/or attached materials (decks, transcripts).
-
-## Outputs
-
-- `.wize/planning/research.md` — short synthesis (≤ 2 pages) referencing sources.
-- `.wize/knowledge/research/{slug}.md` — one file per major source (raw notes, links, attached PDFs).
+| Category | Keywords (pt-BR) | Keywords (EN) | Delegate to |
+|---|---|---|---|
+| **Market** | concorrência, concorrentes, mercado, competidor, pricing, preço, posicionamento, cliente, segmento, TAM, SAM, market share, G2, Capterra | competitor, market, pricing, positioning, customer, segment | `wize-market-research` |
+| **Domain** | domínio, indústria, setor, regulatório, regulação, compliance, legislação, lei, normativo, PESTLE, tendências do setor | domain, industry, sector, regulatory, compliance, legislation | `wize-domain-research` |
+| **Technical** | técnico, tecnologia, stack, biblioteca, framework, arquitetura, ferramenta, linguagem, banco de dados, API, protocolo, desempenho, escalabilidade | technical, technology, stack, library, framework, architecture, tool, language, database, API, protocol, performance, scalability | `wize-technical-research` |
 
 ## Steps
 
-### 1. Frame the questions
-
-Convert open questions + hypotheses into a numbered list. Each question is:
-- **Specific** — "What's the median onboarding time for the top 5 competitors?" not "How is onboarding usually done?".
-- **Answerable in a finite pass** — if it takes weeks, decompose.
-- **Tagged with category** — `market / competitive / analytics / interview / desk-research / regulatory`.
-
-### 2. Choose the framework that fits each question
-
-| Category | Recommended frame | Tools |
-|---|---|---|
-| Market sizing | TAM/SAM/SOM, top-down + bottom-up reconciled | Statista, public filings, gov registries |
-| Competitive | Porter's 5 + feature matrix + pricing scan | competitor sites, G2/Capterra, Pricing/Plans pages |
-| User research | Jobs-to-be-Done (Christensen / Klement) | 5–8 interviews (semi-structured, 30min) |
-| Behavioral | 5W2H + analytics funnel | product analytics (Amplitude/PostHog), session replays |
-| Compliance/legal | Reg list + clause map | gov sites, legal counsel review |
-| Macro context | PESTLE (political/economic/social/technological/legal/environmental) | desk research |
-
-### 3. Run focused passes
-
-One question, one pass. Don't bundle. For each:
-
-- Define what "enough evidence" looks like before starting.
-- Cite or it didn't happen. Links + access date.
-- When numbers conflict across sources, write down both and flag.
-
-### 4. Synthesize
-
-In `research.md`, for each original question, write:
-
-```markdown
-### Q1. {{the question}}
-**Finding:** one sentence answer.
-**Confidence:** high | medium | low
-**Why we believe it:** 2–3 lines + citations [1][2][3].
-**Implication for the brief/PRD:** what changes (or doesn't) because of this.
-```
-
-Don't include raw quotes here — link to `.wize/knowledge/research/{slug}.md`.
-
-### 5. Flag the gaps
-
-End the synthesis with a "Still open" section. List questions we couldn't answer + the cheapest next step (one interview / one analytics query / one expert call). Route back to Wizer with the gap.
-
-## Output template (synthesis)
-
-```markdown
----
-status: ready-for-prd
-owner: Pepper Potts
-created: YYYY-MM-DD
----
+### 1. Read the question
 
-# Research — {{project_name}}
+Extract the user's research topic or question. If the user provided a long message, identify the core research intent.
 
-## Q1. {{question}}
-**Finding:** …
-**Confidence:** medium
-**Why:** … [1]
-**Implication:** Brief constraint #3 holds; PRD scope can drop feature X.
+### 2. Classify
 
-## Q2. …
+Match keywords against the classification guide above. Score each category by keyword hits. Pick the highest-scoring category.
 
-## Still open
-- Q5: pricing elasticity in segment S — needs 1 hour with sales lead.
+### 3. Delegate or ask
 
-## Sources
-[1] {{title}} — {{url}} (accessed YYYY-MM-DD)
-[2] interview-acme-cto-2026-05-30 — see knowledge/research/acme-cto.md
-```
+- **Clear match (one category dominates):** Delegate to the corresponding variant. Load that skill and hand off the user's question intact — do not rephrase or summarize.
+- **Ambiguous (multiple categories tie or no clear signal):** Ask one clarifying question:
 
-## When to use which framework (heuristic)
+> Isso é pesquisa de mercado, domínio ou técnica?
 
-- **JTBD** when you're about to write personas; JTBD is sharper than archetypes.
-- **Porter** when picking a market to enter or a defensible moat.
-- **PESTLE** for projects with regulatory or geopolitical exposure.
-- **5 Whys + analytics funnel** when a metric is bad and the cause isn't obvious.
+Wait for the user's answer, then delegate to the chosen variant.
 
-## Anti-patterns Pepper rejects
+## Anti-patterns
 
-- Synthesis without citations.
-- "We surveyed users" with no n, no method, no script.
-- Single-source claims with high confidence ("everyone is using X" because of one blog post).
-- Using brand-name competitor research as user research — they're different.
-- Continuing to research when the decision is already made. Stop and ship.
+- Executing research directly instead of delegating.
+- Asking more than one clarifying question.
+- Guessing when the signal is ambiguous — ask, don't assume.
 
 ## Hand-off
 
-> Research is in `.wize/planning/research.md`. Q3 still open — sales lead has a slot tomorrow. Hill can start the PRD on what's confirmed.
+> Pesquisa classificada como {{category}}. Delegando para {{variant}}.

package/src/method-skills/1-analysis/wize-technical-research/workflow.md

@@ -4,8 +4,15 @@ name: Technical Research
 phase: 1-analysis
 owner: wize-agent-analyst   # Pepper Potts
 status: ready
+description: "Use quando precisar pesquisar tecnologias, stacks, bibliotecas ou decisões técnicas."
 ---
 
+> **Variante de pesquisa.** Para outros tipos de pesquisa, veja:
+> - Mercado/concorrência → `/wize-market-research`
+> - Domínio/indústria → `/wize-domain-research`
+> - Técnica/stack → `/wize-technical-research`
+> - Pesquisa geral (dispatcher) → `/wize-research`
+
 # Technical Research
 
 **Goal.** Conduct technical research on technologies, tools, and architecture patterns to inform stack decisions.

package/src/method-skills/1-analysis/wize-trigger-map/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-trigger-map
+description: "Use quando precisar mapear gatilhos psicológicos dos usuários para objetivos de negócio — a ponte entre o brief e o PRD."
 name: Trigger Map
 phase: 1-analysis
 owner: wize-agent-analyst   # Pepper Potts

package/src/method-skills/2-plan-workflows/wize-create-prd/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-create-prd
+description: "Use quando o brief + research + trigger map estiverem prontos e precisar convertê-los em um PRD com escopo e acceptance criteria."
 name: Create PRD
 phase: 2-plan
 owner: wize-agent-pm   # Maria Hill

package/src/method-skills/2-plan-workflows/wize-edit-prd/workflow.md

@@ -1,7 +1,9 @@
 ---
+
 code: wize-edit-prd
+description: "Use quando o PRD existir e precisar de alteração pontual com registro de changelog."
 name: Edit PRD
-phase: 2-plan-workflows
+phase: 2-plan
 owner: wize-agent-pm   # Maria Hill
 status: ready
 ---

package/src/method-skills/2-plan-workflows/wize-ux-design/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-ux-design
+description: "Use quando os cenários UX estiverem prontos e precisar produzir especificações página por página para arquitetura e implementação."
 name: UX Design
 phase: 2-plan
 owner: wize-agent-ux-designer   # Mantis

package/src/method-skills/2-plan-workflows/wize-ux-scenarios/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-ux-scenarios
+description: "Use quando o PRD estiver validado e precisar produzir o mapa de cenários UX que ancora todo o design."
 name: UX Scenarios
 phase: 2-plan
 owner: wize-agent-ux-designer   # Mantis (absorbs WDS Freya)

package/src/method-skills/2-plan-workflows/wize-validate-prd/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-validate-prd
+description: "Use quando o PRD estiver pronto para validação e precisar decidir se ele pode avançar para Solutioning."
 name: Validate PRD
 phase: 2-plan
 owner: wize-agent-pm   # Maria Hill (with Pepper, Mantis, Fury input)

package/src/method-skills/3-solutioning/wize-check-implementation-readiness/workflow.md

@@ -1,5 +1,7 @@
 ---
+
 code: wize-check-implementation-readiness
+description: "Use quando a arquitetura e as stories estiverem prontas e precisar verificar se o projeto está pronto para entrar em implementação."
 name: Check Implementation Readiness
 phase: 3-solutioning
 owner: wize-agent-architect   # Tony Stark (with Hawkeye + Hill)

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

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)

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

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

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