wize-dev-kit 0.14.0 → 0.16.0

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-06-structure.md

@@ -1,97 +0,0 @@
-# Step 6: Project Structure & Boundaries
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- ✅ Treat this as collaborative discovery.
-- 🗺️ Create a complete project tree, not generic placeholders.
-- 🗺️ Map requirements/epics to architectural components.
-- ⚠️ No time estimates.
-- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
-
-## Execution protocols
-
-- 🎯 Show analysis before taking action.
-- ⚠️ Present A/P/C menu after generating project structure.
-- 💾 Only save when the user chooses C.
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` before loading the next step.
-
-## Collaboration menu (A/P/C)
-
-- **A (Advanced Elicitation)** — explore innovative project organization.
-- **P (Party Mode)** — evaluate structure trade-offs.
-- **C (Continue)** — save and move to validation.
-
-## Context boundaries
-
-- All previous decisions are complete.
-- Implementation patterns are defined.
-- Focus on physical project structure and component boundaries.
-
-## Task
-
-Define the complete project structure and architectural boundaries based on all decisions made.
-
-## Structure sequence
-
-### 1. Analyze requirements mapping
-
-Map epics or FR categories to directories/services.
-
-### 2. Define project directory structure
-
-Create a complete, technology-specific tree:
-
-- Root configuration files
-- Source code organization
-- Test organization
-- Build and distribution
-
-### 3. Define integration boundaries
-
-- API boundaries
-- Component boundaries
-- Service boundaries
-- Data boundaries
-
-### 4. Map requirements to structure
-
-For each epic or feature cluster:
-
-```markdown
-Epic: User Management
-- Components: src/components/features/users/
-- Services: src/services/users/
-- API Routes: src/app/api/users/
-- Database: prisma/migrations/...
-- Tests: tests/features/users/
-```
-
-## Generate structure content
-
-Append to `architecture.md`:
-
-```markdown
-## Project Structure & Boundaries
-
-### Complete Project Directory Structure
-```
-{{tree}}
-```
-
-### Architectural Boundaries
-...
-
-### Requirements to Structure Mapping
-...
-
-### Integration Points
-...
-
-### File Organization Patterns
-...
-```
-
-## Next step
-
-After C, load `./step-07-validation.md`.

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-07-validation.md

@@ -1,124 +0,0 @@
-# Step 7: Architecture Validation & Completion
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- ✅ Validate all requirements are covered by architectural decisions.
-- ⚠️ No time estimates.
-- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
-
-## Execution protocols
-
-- 🎯 Show analysis before taking action.
-- ✅ Run validation checks on the complete architecture.
-- ⚠️ Present A/P/C menu after generating validation results.
-- 💾 Only save when the user chooses C.
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]` before loading the next step.
-
-## Collaboration menu (A/P/C)
-
-- **A (Advanced Elicitation)** — address complex architectural issues found.
-- **P (Party Mode)** — review validation from multiple perspectives.
-- **C (Continue)** — save validation results and complete the architecture.
-
-## Context boundaries
-
-- Complete architecture document is available.
-- All decisions, patterns, and structure are defined.
-- Focus on validation, gap analysis, and coherence.
-
-## Task
-
-Validate the complete architecture for coherence, completeness, and readiness.
-
-## Validation sequence
-
-### 1. Coherence validation
-
-- Decision compatibility
-- Pattern consistency
-- Structure alignment
-
-### 2. Requirements coverage validation
-
-- Epic/feature coverage
-- Functional requirements coverage
-- Non-functional requirements coverage
-
-### 3. Implementation readiness validation
-
-- Decision completeness
-- Structure completeness
-- Pattern completeness
-
-### 4. Gap analysis
-
-Identify critical, important, and nice-to-have gaps.
-
-### 5. Generate validation content
-
-Append to `architecture.md`:
-
-```markdown
-## Architecture Validation Results
-
-### Coherence Validation
-...
-
-### Requirements Coverage Validation
-...
-
-### Implementation Readiness Validation
-...
-
-### Gap Analysis Results
-...
-
-### Validation Issues Addressed
-...
-
-### Architecture Completeness Checklist
-
-**Requirements Analysis**
-- [ ] Project context thoroughly analyzed
-- [ ] Scale and complexity assessed
-- [ ] Technical constraints identified
-- [ ] Cross-cutting concerns mapped
-
-**Architectural Decisions**
-- [ ] Critical decisions documented with versions
-- [ ] Technology stack fully specified
-- [ ] Integration patterns defined
-- [ ] Performance considerations addressed
-
-**Implementation Patterns**
-- [ ] Naming conventions established
-- [ ] Structure patterns defined
-- [ ] Communication patterns specified
-- [ ] Process patterns documented
-
-**Project Structure**
-- [ ] Complete directory structure defined
-- [ ] Component boundaries established
-- [ ] Integration points mapped
-- [ ] Requirements to structure mapping complete
-
-### Architecture Readiness Assessment
-
-**Overall Status:** [READY FOR IMPLEMENTATION / READY WITH MINOR GAPS / NOT READY]
-**Confidence Level:** [high/medium/low]
-**Key Strengths:** ...
-**Areas for Future Enhancement:** ...
-
-### Implementation Handoff
-
-**AI Agent Guidelines:**
-- Follow all architectural decisions exactly as documented.
-- Use implementation patterns consistently.
-- Respect project structure and boundaries.
-- Refer to this document for all architectural questions.
-```
-
-## Next step
-
-After C, load `./step-08-complete.md`.

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

@@ -1,59 +0,0 @@
-# Step 8: Architecture Completion & Handoff
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- ✅ Treat this as collaborative completion.
-- 🎯 Provide clear next steps for implementation.
-- ⚠️ No time estimates.
-- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
-
-## Execution protocols
-
-- 🎯 Show completion summary and implementation guidance.
-- 📖 Update frontmatter with final workflow state.
-- 🚫 This is the final step.
-
-## Task
-
-Complete the architecture workflow and guide the user to the next phase.
-
-## Completion sequence
-
-### 1. Summarize achievements
-
-Congratulate the user and summarize what was built together:
-
-- Architecture document path
-- Number of ADRs produced
-- Key decisions made
-- Patterns defined
-- Validation status
-
-### 2. Update frontmatter
-
-```yaml
-status: ready-for-stories
-owner: Tony Stark
-updated: "{{date}}"
-stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]
-workflowType: architecture
-lastStep: 8
-```
-
-### 3. Next steps guidance
-
-```
-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` (or `/wize-help`) anytime to check what comes next.
-```
-
-## On complete
-
-Run `{workflow.on_complete}` if non-empty.
-
-## Workflow complete
-
-The architecture is now the single source of truth for all technical decisions, ensuring consistent implementation across the project lifecycle.

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

@@ -1,120 +0,0 @@
----
-
-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
-status: ready
----
-
-# Project Context
-
-**Goal.** Consolidate the 5 foundational artifacts (brief, PRD, UX, architecture, risk profile) into a single `.wize/knowledge/project-context.md` so other agents (Shuri, Hawkeye, Mantis, Wizer) can read the project in one shot instead of stitching it from 5 files.
-
-Tony drives. Peggy polishes prose. Wizer is on call for cross-cutting drift.
-
-## When to run
-
-- After Phase 3 closeout (architecture + ADRs + risk profile all exist).
-- After any major change to brief / PRD / architecture (rerun).
-- Before sprint planning if context feels stale.
-
-## When NOT to run
-
-- During greenfield with no artifacts yet (run only after brief + PRD exist).
-- As a CI step (manual; expensive to run on every commit).
-
-## Inputs
-
-- `.wize/planning/brief.md` — Vision, Audience.
-- `.wize/planning/prd.md` — Goals, scope.
-- `.wize/planning/ux/ux-design/index.md` — UX stack, key screens.
-- `.wize/solutioning/architecture.md` — Tech stack, components.
-- `.wize/solutioning/adrs/*.md` — Key decisions.
-- `.wize/implementation/tea/risk-profile.md` — Active risks.
-
-## Output
-
-- `.wize/knowledge/project-context.md` (5 sections, YAML frontmatter, `last_updated` date).
-
-## Steps
-
-### 1. Vision and Audience
-
-Copy from `brief.md` (or `prd.md` if brief is missing). One paragraph each. Mark the source file in a comment.
-
-### 2. Tech stack
-
-From `architecture.md`, list: runtime, framework, database, key libraries, build tool. One bullet per item. Skip items that are "TBD".
-
-### 3. Key ADRs
-
-List the 5 most recent ADRs from `.wize/solutioning/adrs/`. For each: title, decision, why. Older ADRs are out of scope; refer to `adrs/index.md` for the full list.
-
-### 4. Active risks
-
-Copy from `risk-profile.md` the top 5 risks (highest prob × impact). One bullet per risk with the mitigation. Defer the rest.
-
-### 5. Active sprint
-
-Read `.wize/implementation/sprint-status.yaml` and include: sprint number, capacity, in-progress stories. Skip if no active sprint.
-
-### 6. Hand off
-
-Output is a markdown file. Wizer uses this file to seed `/wize`, `/wize-help`, `/wize-dev-story`, and `/wize-onboarding` reads.
-
-## Output template
-
-```markdown
----
-generated: YYYY-MM-DD
-last_updated: YYYY-MM-DD
-sources:
-  - .wize/planning/brief.md
-  - .wize/planning/prd.md
-  - .wize/planning/ux/ux-design/index.md
-  - .wize/solutioning/architecture.md
-  - .wize/solutioning/adrs/
-  - .wize/implementation/tea/risk-profile.md
----
-
-# Project Context — {project_name}
-
-## Vision
-{paragraph from brief.md}
-
-## Audience
-{paragraph from brief.md or prd.md}
-
-## Tech stack
-- Runtime: {value}
-- Framework: {value}
-- Database: {value}
-- Key libraries: {value}
-- Build: {value}
-
-## Key ADRs
-1. **{title}** — {decision}. Why: {why}.
-2. ...
-
-## Active risks
-1. **{R-id}** — {description}. Mitigation: {mitigation}.
-2. ...
-
-## Active sprint
-- Sprint: {N}
-- Capacity: {days}
-- In-progress: {stories}
-```
-
-## Anti-patterns Tony rejects
-
-- Reading all 6 sources in full and dumping them. Summarize in 5 sections.
-- Editing the project-context.md by hand. (Always re-run the workflow to keep `last_updated` honest.)
-- Skipping the frontmatter. Other agents parse it.
-- Including items marked "TBD". Surface them in the `Open questions` section instead.
-
-## Hand-off
-
-> "Project context updated at `.wize/knowledge/project-context.md`. {N} sources, 5 sections, {date}. Next: `/wize-onboarding` (Wizer) reads this for first contact."

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

@@ -1,184 +0,0 @@
----
-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,117 +0,0 @@
----
-
-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)
-status: ready
----
-
-# Checkpoint Preview
-
-**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 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 / small stories (overhead exceeds the value).
-- When the story is < 50% done and no surprise has come up yet.
-
-## Inputs
-
-- The current story file: `.wize/solutioning/stories/{epic}/{story}.md`
-- The git diff: uncommitted + committed since story start
-- The `tea-design.md` for the story
-- The `design-system/` tokens used so far
-
-## Output
-
-- `.wize/implementation/checkpoints/{story_id}.md` (one file per checkpoint, append over time)
-- A decision: continue / pivot / stop
-
-## Steps
-
-### 1. Pause
-
-Stop writing code. Do not commit any pending work until the checkpoint is recorded.
-
-### 2. Snapshot
-
-Write 5 lines:
-
-- Files touched: (list, max 10)
-- ACs done vs. remaining: (X / Y)
-- Tests added: (count, by split)
-- New dependencies: (list)
-- Commits so far: (count)
-
-### 3. Sanity check (3 questions)
-
-- **Are we solving the right problem?** Compare the implementation with the story's Context and ACs. If the story's intent was misunderstood, pivot.
-- **Is the design holding?** Compare the code with the architecture. If a new pattern emerged without an ADR, flag it.
-- **Any new constraints?** Did anything new appear (security finding, perf regression, vendor change, new stakeholder)?
-
-### 4. Decide
-
-One of three:
-
-- **Continue** — the path is right. Record the snapshot; resume.
-- **Pivot** — change scope or approach. Open a follow-up story with `wize-create-story`; do not edit the current story's ACs.
-- **Stop** — the story is no longer worth it. Move it to `backlog` via `wize-correct-course`.
-
-One decision per checkpoint. Re-run for additional decisions.
-
-### 5. Hand off
-
-Notify the next workflow:
-
-- Continue → `/wize-dev-story` (resume).
-- Pivot → `/wize-create-story` (new story for the pivot).
-- Stop → `/wize-correct-course` (defer the original).
-
-## Output template
-
-```markdown
----
-story_id: E04-S02
-checkpoint: 1
-date: 2026-06-16
-author: Shuri
----
-
-# Checkpoint — E04-S02
-
-## Snapshot
-- Files touched: src/...
-- ACs done vs. remaining: 1 / 4
-- Tests added: 2 unit, 1 integration
-- New dependencies: none
-- Commits so far: 3
-
-## Sanity check
-- Right problem? Yes.
-- Design holding? Yes.
-- New constraints? Vendor X deprecated their API; need a different client lib.
-
-## Decision
-**Pivot** — see follow-up E04-S04 (client lib migration).
-```
-
-## Anti-patterns Shuri rejects
-
-- Skipping the snapshot to "save time" — the snapshot is the artifact.
-- Auto-pivoting (changing scope without an explicit checkpoint).
-- Recording "continue" without the sanity check answers.
-- Bundling multiple pivots in one checkpoint (one decision per run).
-
-## Hand-off
-
-> "Checkpoint recorded for **{story_id}** (decision: {continue|pivot|stop}). Next: `/wize-dev-story` / `/wize-create-story` / `/wize-correct-course`."