wize-dev-kit 0.15.0 → 0.16.0

package/src/method-skills/1-analysis/wize-technical-research/technical-steps/step-05-implementation-research.md

@@ -1,42 +0,0 @@
-# Step 5: Implementation Research
-
-## Rules
-
-- 🌐 Search the web to verify claims.
-- 📝 Write findings to the document immediately.
-- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
-
-## Task
-
-Research implementation approaches and best practices for {{research_topic}}.
-
-## Execution
-
-Search for:
-
-- "{{research_topic}} best practices"
-- "{{research_topic}} implementation guide"
-- "{{research_topic}} production readiness"
-
-Synthesize and append:
-
-```markdown
-## Implementation Research
-
-### Development Methodologies
-...
-
-### Code Organization
-...
-
-### Quality Assurance
-...
-
-### Deployment Practices
-...
-
-### Source Citations
-...
-```
-
-Update `stepsCompleted: [1, 2, 3, 4, 5]` and load `./technical-steps/step-06-research-synthesis.md`.

package/src/method-skills/1-analysis/wize-technical-research/technical-steps/step-06-research-synthesis.md

@@ -1,46 +0,0 @@
-# Step 6: Technical Research Synthesis and Completion
-
-## Rules
-
-- 🌐 Search the web to verify claims.
-- 📝 Replace the Research Overview placeholder and append synthesis.
-- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
-
-## Task
-
-Produce the final technical research synthesis.
-
-## Execution
-
-Replace `[Research overview and methodology will be appended here.]` with a concise summary.
-
-Append:
-
-```markdown
-## Research Synthesis
-
-### Key Findings
-1. ...
-2. ...
-
-### Recommended Stack / Pattern
-...
-
-### Trade-offs
-...
-
-### Risks and Mitigations
-...
-
-### Still Open
-- ...
-
-### Sources
-...
-```
-
-Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6]` and `status: complete`.
-
-## On complete
-
-Run `{workflow.on_complete}` if non-empty.

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

@@ -1,60 +0,0 @@
----
-code: wize-technical-research
-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.
-
-Pepper Potts drives. Tony Stark consumes the output directly. Peggy Carter edits prose.
-
-Output lands in `.wize/planning/research/technical-{slug}-research-{date}.md`.
-
-## When to use
-
-- "Should we use X or Y?"
-- "What is the current state of Z technology?"
-- "I need a technical comparison of..."
-
-## Inputs
-
-- Open questions from `.wize/planning/brief.md` or `.wize/planning/tech-vision.md`
-- User-provided technology or architectural topic
-- Web search access
-
-## Outputs
-
-- `.wize/planning/research/technical-{slug}-research-{date}.md`
-
-## Workflow architecture
-
-Step-file architecture with six steps:
-
-1. Scope confirmation
-2. Technical overview
-3. Integration patterns
-4. Architectural patterns
-5. Implementation research
-6. Research synthesis
-
-## On activation
-
-1. Load `.wize/config/project.toml` and `.wize/config/user.toml`.
-2. Ask for the technical topic if not provided.
-3. Derive `{research_topic_slug}` and create the output file from `research.template.md`.
-4. Read fully and follow `./technical-steps/step-01-init.md`.
-
-## Hand-off
-
-> Technical research is in `.wize/planning/research/`. Fury and Tony can use it for stack family decisions; open questions route back to Wizer.

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

@@ -1,110 +0,0 @@
----
-
-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
-owner: wize-agent-pm   # Maria Hill
-status: ready
----
-
-# Edit PRD
-
-**Goal.** Update `.wize/planning/prd.md` without rewriting from scratch. Every change is recorded in `.wize/planning/prd-changelog.md` so the team can see *what* changed, *when*, *why*, and *by whom*.
-
-Maria Hill drives. Peggy polishes prose on the diff. Wizer is on call for cross-cutting impacts (architecture, NFR, scope).
-
-## When to run
-
-- A new AC is needed (new requirement from the user, market shift, regulator).
-- An AC is no longer correct (validated learning, scoping mistake).
-- An item moves in-scope ↔ out-of-scope.
-- A non-goal is added or removed.
-- A new decision is made that affects the PRD (e.g., cut a feature).
-
-## When NOT to run
-
-- Rewriting the PRD from scratch → use `/wize-create-prd`.
-- Validating the PRD → use `/wize-validate-prd`.
-
-## Inputs
-
-- `.wize/planning/prd.md` (current)
-- A free-form change request from the user.
-
-## Output
-
-- Updated `.wize/planning/prd.md`.
-- New row in `.wize/planning/prd-changelog.md` (one row per change).
-
-## Steps
-
-### 1. Read the current PRD
-
-Parse the PRD frontmatter (`status`, `owner`, `created`, `last_updated`) and the body. Confirm the change is in scope of "edit" (not a rewrite). If the change touches > 25% of the PRD, route to `/wize-create-prd` instead.
-
-### 2. Classify the edit
-
-Pick exactly one type:
-
-- **A** — Add or change an AC.
-- **B** — Move item in-scope ↔ out-of-scope.
-- **C** — Add or remove a non-goal.
-- **D** — Register a decision that affects the PRD (link to ADR or sprint decision).
-
-One edit per run. Re-run for additional edits.
-
-### 3. Apply the edit
-
-Make the change in `prd.md`. Mark the changed section with a trailing note: `(edited 2026-06-15, see changelog row 4)`.
-
-Update frontmatter: `last_updated` to today; `status` stays the same (only `/wize-validate-prd` flips it to `validated`).
-
-### 4. Append to changelog
-
-Add a row to `prd-changelog.md`:
-
-```markdown
-| Date | Type | Section | Change | Author |
-|---|---|---|---|---|
-| 2026-06-15 | A | AC-04-2 | Added: "rate limit per team" | Hill |
-| 2026-06-15 | B | Out of scope | Removed "bulk invite" (now in scope per E04-S02) | Hill |
-```
-
-### 5. Cross-cutting check
-
-Wizer flags any downstream impact:
-
-- New AC → check that the epic + stories covering it exist. If not, route to `/wize-create-epics-and-stories`.
-- New non-goal → check that no in-flight story assumes the opposite. If yes, flag the story.
-- In-scope move → trigger a fresh `/wize-sprint-planning` consideration.
-
-### 6. Hand off
-
-Notify the next workflow:
-
-- If AC changed → `/wize-validate-prd` to confirm consistency.
-- If epic + stories need refresh → `/wize-create-epics-and-stories`.
-- If sprint needs re-prioritization → `/wize-sprint-planning`.
-
-## Output template — `prd-changelog.md`
-
-```markdown
-# PRD changelog
-
-| # | Date | Type | Section | Change | Author |
-|---|---|---|---|---|---|
-| 1 | 2026-06-15 | A | AC-04-2 | Added: "rate limit per team" | Hill |
-| 2 | 2026-06-15 | B | Out of scope | Removed "bulk invite" | Hill |
-```
-
-## Anti-patterns Hill rejects
-
-- Editing the PRD without recording the change in the changelog. (Source-of-truth drift.)
-- Bundling 4 edits in one run. (One edit per run keeps blame clean.)
-- Editing the PRD without checking downstream impact. (Wizer’s cross-cutting step is mandatory.)
-- Re-running `/wize-create-prd` to "keep things tidy." The changelog exists for that.
-
-## Hand-off
-
-> "PRD updated at `.wize/planning/prd.md`. Changelog row N appended. Next: `/wize-validate-prd` (re-validate) or `/wize-create-epics-and-stories` (refresh stories)."

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

@@ -1,41 +0,0 @@
----
-status: draft
-owner: Tony Stark
-created: "{{created}}"
-stepsCompleted: []
-inputDocuments: []
----
-
-# Architecture — {{project_name}}
-
-## Summary
-
-{{One paragraph: stack family, runtime, primary data store, deploy target. The frame.}}
-
-## Stack
-
-- Language:
-- Front-end:
-- Back-end:
-- DB:
-- Auth:
-- Hosting:
-- Observability:
-- Test:
-
-## Components
-
-| Component | Responsibility | Boundary |
-|---|---|---|
-
-## Data model
-
-## Sequences
-
-## Cross-cutting concerns
-
-## NFR check
-
-## ADRs
-
-See `.wize/solutioning/adrs/`.

package/src/method-skills/3-solutioning/wize-create-architecture/customize.toml

@@ -1,20 +0,0 @@
-# Wize Dev Kit — overrides for the built-in workflow "wize-create-architecture".
-# DO NOT EDIT in the installed kit; copy to .wize/custom/workflows/wize-create-architecture/
-# for project-level overrides.
-
-[workflow]
-
-# Steps to run before standard activation (config load, greet).
-activation_steps_prepend = []
-
-# Steps to run after greet but before the workflow begins.
-activation_steps_append = []
-
-# Persistent facts the workflow keeps in mind for the whole run.
-persistent_facts = [
-  "file:{project-root}/.wize/knowledge/document-project/conventions.md",
-]
-
-# Scalar executed when Step 8 (Architecture Completion & Handoff) finishes.
-# Override wins. Leave empty for no custom post-completion behavior.
-on_complete = ""

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-01-init.md

@@ -1,95 +0,0 @@
-# Step 1: Architecture Workflow Initialization
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- 📖 Always read the complete step file before acting.
-- ✅ Treat this as collaborative discovery between architectural peers.
-- 💬 Focus on initialization and setup only.
-- 🚪 Detect existing workflow state and handle continuation properly.
-- ⚠️ No time estimates.
-- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
-
-## Execution protocols
-
-- 🎯 Show analysis before taking action.
-- 💾 Initialize the document and update frontmatter.
-- 📖 Set `stepsCompleted: [1]` before loading the next step.
-- 🚫 Do not load the next step until setup is complete and the user confirms.
-
-## Context boundaries
-
-- Variables from `workflow.md` are available.
-- Previous context is what is in the output document + frontmatter.
-- Input document discovery happens in this step.
-
-## Task
-
-Initialize the Architecture workflow by detecting continuation state, discovering input documents, and setting up the document for collaborative architectural decision making.
-
-## Initialization sequence
-
-### 1. Check for existing workflow
-
-Check if `{output_folder}/solutioning/architecture.md` exists.
-
-- If it exists and has frontmatter with `stepsCompleted`, stop here and load `./step-01b-continue.md`.
-- If it exists but has no `stepsCompleted`, treat it as a legacy document: warn the user and offer to continue from it or start fresh.
-- If it does not exist, this is a fresh workflow.
-
-### 2. Discover input documents
-
-Search in `{output_folder}/planning/`, `{output_folder}/knowledge/`, and `{project-root}/docs/` for:
-
-- Product Brief (`*brief*.md`)
-- PRD (`*prd*.md`)
-- UX Scenarios / UX Design (`*ux*.md`)
-- Research (`*research*.md`)
-- Project Context (`**/project-context.md`)
-
-Confirm what was found with the user before proceeding.
-
-### 3. Validate required inputs
-
-If no PRD is found:
-
-> Architecture requires a PRD to work from. Please run `wize-create-prd` first or provide the PRD file path.
-
-Do not proceed without a PRD.
-
-### 4. Create initial document
-
-Copy `../architecture-decision-template.md` to `{output_folder}/solutioning/architecture.md`.
-
-Set frontmatter:
-
-```yaml
-status: draft
-owner: Tony Stark
-created: "{{date}}"
-stepsCompleted: []
-inputDocuments: [{{list of discovered files}}]
-```
-
-### 5. Report setup to user
-
-```
-Welcome {{user_name}}! I've set up your Architecture workspace for {{project_name}}.
-
-Documents found:
-- PRD: {count or "None — required"}
-- UX Design: {count or "None"}
-- Research: {count or "None"}
-- Project docs: {count or "None"}
-- Project context: {count of rules or "None"}
-
-Files loaded: {list or "No additional documents"}
-
-Ready to begin architectural decision making. Do you have any other documents you'd like to include?
-
-[C] Continue to project context analysis
-```
-
-## Next step
-
-After the user selects [C], load `./step-02-context.md`.

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-01b-continue.md

@@ -1,32 +0,0 @@
-# Step 1b: Continue Existing Architecture Workflow
-
-## Purpose
-
-Resume an architecture workflow that was previously started.
-
-## Rules
-
-- Read the existing `{output_folder}/solutioning/architecture.md` fully, including frontmatter.
-- Report the current `stepsCompleted` to the user.
-- Ask whether to continue from the last completed step or restart from a specific step.
-- Never discard already-written content without explicit user confirmation.
-
-## Continue menu
-
-```
-Existing architecture document found.
-
-Steps completed: {stepsCompleted}
-Last saved: {updated or created date}
-
-What would you like to do?
-[C] Continue from the next step ({next_step})
-[R] Restart from step 1
-[S] Pick a specific step to revisit
-```
-
-## Routing
-
-- [C] → load the step immediately after the highest value in `stepsCompleted`.
-- [R] → confirm overwrite risk, then return to `step-01-init.md` fresh setup.
-- [S] → present the list of steps and load the selected one.

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

@@ -1,126 +0,0 @@
-# Step 2: Project Context Analysis
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- 📖 Always read the complete step file before acting.
-- ✅ Treat this as collaborative discovery.
-- 🎯 Analyze loaded documents; don't assume or generate requirements.
-- ⚠️ 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 context analysis.
-- 💾 Only save when the user chooses C (Continue).
-- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading the next step.
-- 🚫 Do not load the next step until C is selected.
-
-## Collaboration menu (A/P/C)
-
-- **A (Advanced Elicitation)** — invoke `wize-advanced-elicitation` for deeper architectural implications.
-- **P (Party Mode)** — invoke `wize-party-mode` to bring Tony, Fury, and Pepper into the conversation.
-- **C (Continue)** — save the content and proceed.
-
-After A or P, return to this menu.
-
-## Context boundaries
-
-- Current document and frontmatter from step 1 are available.
-- Input documents are loaded.
-- Focus on architectural implications only — no technology decisions yet.
-
-## Task
-
-Analyze the loaded project documents to understand architectural scope, requirements, and constraints.
-
-## Analysis sequence
-
-### 1. Review project requirements
-
-**From PRD:**
-
-- Extract functional requirements and their architectural implications.
-- Identify non-functional requirements (performance, security, compliance).
-- Note technical constraints or dependencies.
-
-**From Epics/Stories (if available):**
-
-- Map epic structure to architectural components.
-- Identify cross-cutting concerns that span multiple epics.
-
-**From UX Design (if available):**
-
-- Component complexity, real-time needs, platform-specific UI, accessibility level, responsive breakpoints, offline capability.
-
-### 2. Project scale assessment
-
-Complexity indicators:
-
-- Real-time features
-- Multi-tenancy
-- Regulatory compliance
-- Integration density
-- User interaction complexity
-- Data complexity and volume
-
-### 3. Reflect understanding to the user
-
-Present a concise summary:
-
-```
-I'm reviewing your project documentation for {{project_name}}.
-
-I see {{fr_count}} functional requirements and {{nfr_count}} non-functional requirements.
-{epics_loaded?}I also see {{epic_count}} epics with {{story_count}} stories.{/epics_loaded?}
-{ux_loaded?}A UX specification is present.{/ux_loaded?}
-
-Key architectural aspects:
-- [core functionality]
-- [critical NFRs]
-- [unique technical challenges]
-- [compliance requirements]
-
-Scale indicators:
-- Complexity: [low/medium/high/enterprise]
-- Primary domain: [web/mobile/api/backend/full-stack/etc]
-- Cross-cutting concerns: [list]
-
-Does this match your understanding?
-```
-
-### 4. Generate project context content
-
-Prepare the section to append:
-
-```markdown
-## Project Context Analysis
-
-### Requirements Overview
-
-**Functional Requirements:**
-{{analysis}}
-
-**Non-Functional Requirements:**
-{{analysis}}
-
-**Scale & Complexity:**
-- Primary domain: {{domain}}
-- Complexity level: {{level}}
-- Architectural components: {{count}}
-
-### Technical Constraints & Dependencies
-{{list}}
-
-### Cross-Cutting Concerns Identified
-{{list}}
-```
-
-### 5. Present content and menu
-
-Show the drafted content and present A/P/C. Only append when the user chooses C.
-
-## Next step
-
-After C, load `./step-03-starter.md`.

package/src/method-skills/3-solutioning/wize-create-architecture/steps/step-03-starter.md

@@ -1,110 +0,0 @@
-# Step 3: Starter Template Evaluation
-
-## Mandatory execution rules
-
-- 🛑 Never generate content without user input.
-- ✅ Treat this as collaborative discovery.
-- 🌐 Search the web to verify current versions and options.
-- ⚠️ 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 starter analysis.
-- 💾 Only save when the user chooses C.
-- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading the next step.
-
-## Collaboration menu (A/P/C)
-
-- **A (Advanced Elicitation)** — explore unconventional starter options.
-- **P (Party Mode)** — evaluate starter trade-offs from multiple perspectives.
-- **C (Continue)** — save and move to architectural decisions.
-
-## Context boundaries
-
-- Project context from step 2 is available.
-- No architectural decisions made yet — this step evaluates foundations.
-
-## Task
-
-Discover technical preferences and evaluate starter template options, establishing solid architectural foundations.
-
-## Starter evaluation sequence
-
-### 0. Check existing technical preferences
-
-If `.wize/knowledge/document-project/conventions.md` or `project-context.md` exist, surface any already-documented technical rules.
-
-### 1. Discover user technical preferences
-
-Ask about:
-
-- Languages and frameworks
-- Databases
-- Cloud / hosting / deployment
-- Third-party services (auth, payments, analytics)
-- Team experience level
-
-### 2. Identify primary technology domain
-
-Map the project to one of:
-
-- Web application
-- Mobile app
-- API / backend
-- CLI tool
-- Full-stack
-- Desktop
-
-### 3. Research current starter options
-
-Search the web for current, maintained starter templates matching the domain.
-
-### 4. Present starter options
-
-For each viable starter, document:
-
-- Technology decisions already made by the starter
-- Architectural patterns established
-- Development experience features
-- Maintenance status
-
-### 5. Get selection
-
-Present a recommended starter and ask for confirmation.
-
-### 6. Generate starter content
-
-Append to `architecture.md`:
-
-```markdown
-## Starter Template Evaluation
-
-### Primary Technology Domain
-{{domain}}
-
-### Starter Options Considered
-{{analysis}}
-
-### Selected Starter: {{starter_name}}
-
-**Rationale:** {{why}}
-
-**Initialization Command:**
-```bash
-{{command}}
-```
-
-**Architectural Decisions Provided by Starter:**
-- Language & Runtime: ...
-- Styling Solution: ...
-- Build Tooling: ...
-- Testing Framework: ...
-- Code Organization: ...
-- Development Experience: ...
-```
-
-## Next step
-
-After C, load `./step-04-decisions.md`.