wize-dev-kit 0.3.1 → 0.4.1

package/CHANGELOG.md

@@ -5,6 +5,40 @@ Format inspired by [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [0.4.1] — 2026-06-13
+
+### Fixed
+
+- Installer no longer skips the "How should the agents call you?" prompt due to residual input from previous `prompts`-library questions.
+
+### Added
+
+- Interactive install now detects AI harness CLIs on PATH and offers to launch `/wize-orchestrator` directly, showing the exact command (e.g. `claude -p /wize-orchestrator`).
+
+## [0.4.0] — 2026-06-13
+
+Adapts four BMAD Method step-based flows into the Wize universe: spec, architecture, code review, and research.
+
+### Added
+
+- **`wize-spec`** (core skill) — distills any intent input into a canonical five-field `SPEC.md` (Why, Capabilities, Constraints, Non-goals, Success signal) plus optional companion files. Includes template and headless response schemas.
+- **Vertical research skills** under `src/method-skills/1-analysis/`:
+  - `wize-market-research` — 6-step competition and customer research.
+  - `wize-domain-research` — 6-step industry, regulatory, and trend research.
+  - `wize-technical-research` — 6-step technology and architecture research.
+- Registered new skills in `src/core-skills/module.yaml` and `src/method-skills/module.yaml`.
+
+### Changed
+
+- **`wize-create-architecture`** rewritten as an 8-step micro-file workflow: init → context → starter → decisions → patterns → structure → validation → complete. Old monolithic body archived in `.wize/knowledge/decisions/`.
+- **`wize-code-review`** rewritten as a 4-step adversarial triage workflow: gather-context → review (Blind Hunter, Edge Case Hunter, Acceptance Auditor) → triage → present. Integrates with existing `wize-review-adversarial` and `wize-review-edge-case-hunter`.
+- `README.md`, `DECISIONS.md`, and `.wize/knowledge/decisions/ADR-001-bmad-steps-import.md` document the import rationale and scope.
+- `test/workflow-bodies.test.js` allowlists the short research dispatcher workflows.
+
+### Tests
+
+- Total: **222 passing**.
+
 ## [0.3.1] — 2026-06-13
 
 Expands `wize-document-project` from a single lightweight baseline into a multi-mode documentation engine with project-type classification, resume state, and BMAD-equivalent templates.

package/DECISIONS.md

@@ -136,6 +136,19 @@
 - **D7.5 — Localização das custom:** `.wize/custom/agents/{code}/`, `.wize/custom/skills/{code}/`, `.wize/custom/workflows/{code}/`. Estrutura espelha a do kit core.
 - **D7.6 — Ponto de entrada:** `wize-dev-kit agent create` no CLI + skill nativo `wize-create-agent` chamável pelo Wizer dentro do IDE.
 
+### Fase 8 — Importação de fluxos Steps do BMAD
+
+- **D8.1 — Seleção:** dos fluxos de Steps do BMAD ainda não importados, selecionamos quatro para adaptação imediata:
+  - `bmad-spec` → `wize-spec` (core skill).
+  - `bmad-create-architecture` → `wize-create-architecture` reescrito em 8 steps (micro-file architecture).
+  - `bmad-code-review` → `wize-code-review` reescrito em 4 steps com triagem adversarial.
+  - Research do BMAD (`bmad-market-research`, `bmad-domain-research`, `bmad-technical-research`) → três skills verticais Wize em `src/method-skills/1-analysis/`.
+- **D8.2 — Micro-file architecture:** workflows substituídos por step files auto-contidos em `steps/` ou `{vertical}-steps/`. Cada step controla frontmatter `stepsCompleted` e só avança com confirmação do usuário.
+- **D8.3 — Manter dispatcher genérico:** `wize-research` continua existindo como skill genérico, mas as três vertentes oferecem passos estruturados e templates próprios.
+- **D8.4 — Versionamento dos workflows antigos:** cópias dos `workflow.md` monolíticos de `wize-create-architecture` e `wize-code-review` são arquivadas em `.wize/knowledge/decisions/` para referência, não mantidas em produção.
+- **D8.5 — Registro em catálogos:** skills adicionados a `src/core-skills/module.yaml` e `src/method-skills/module.yaml`; fluxos refletidos no `README.md`.
+
 ## Perguntas em aberto
 
 _(serão preenchidas conforme a entrevista avança)_
+

package/README.md

@@ -83,6 +83,9 @@ Below is the canonical flow Wizer drives in a real session. Each step is a slash
 2.  /wize-product-brief         Pepper turns raw demand into brief.md.
     /wize-trigger-map           Pepper maps user psychology → business goals (WDS).
     /wize-research              Pepper synthesizes external evidence (optional).
+                                Or run a focused pass:
+                                /wize-market-research, /wize-domain-research,
+                                /wize-technical-research.
 
 3.  /wize-create-prd            Maria Hill writes prd.md (goals, scope, ACs).
     /wize-validate-prd          Maria Hill (+ Mantis/Fury) signs off.
@@ -93,7 +96,8 @@ Below is the canonical flow Wizer drives in a real session. Each step is a slash
 5.  /wize-tech-vision           Fury picks the stack family + non-negotiables.
     /wize-nfr-principles        Fury writes the NFR budget (perf, sec, a11y…).
 
-6.  /wize-create-architecture   Tony writes architecture.md + ADRs.
+6.  /wize-create-architecture   Tony writes architecture.md + ADRs via 8 steps
+                                (context → decisions → patterns → structure → validation).
     /wize-design-system         Mantis writes design-system/ (tokens + components).
     /wize-create-epics-and-stories
                                 Tony slices epics → stories (each has ACs).
@@ -113,6 +117,9 @@ Cross-cutting:
     /wize-help                  Wizer figures out where you are and proposes
                                 the next step (use anytime).
     /wize-quick-dev             Shuri takes a small fix without the full ride.
+    /wize-code-review           Shuri runs an adversarial peer review (Blind Hunter,
+                                Edge Case Hunter, Acceptance Auditor) before Hawkeye's TEA review.
+    /wize-spec                  Distill any intent into a canonical five-field spec.
     /wize-party-mode            Wizer convenes multi-persona for hard calls.
 ```
 
@@ -163,7 +170,7 @@ npx wize-dev-kit uninstall       # remove .wize/ (your code is left untouched)
 
 ## Status
 
-**v0.3.0+ — beta.** The core lifecycle is scaffolded and the `document-project` engine is wired: quick baseline, initial/full/deep scans, project-type classification, resume state, and IDE adapters for Claude Code, Cursor, Windsurf, and others. The CLI commands listed above are executable and tested. Production-readiness target remains v0.5.0.
+**v0.3.0+ — beta.** The core lifecycle is scaffolded, the `document-project` engine is wired, and selected BMAD step flows have been adapted into Wize skills: `wize-spec`, `wize-create-architecture` (8-step), `wize-code-review` (adversarial triage), and vertical research skills (`wize-market-research`, `wize-domain-research`, `wize-technical-research`). IDE adapters for Claude Code, Cursor, Windsurf, and others are regenerated automatically. Production-readiness target remains v0.5.0.
 
 ---
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "wize-dev-kit",
-  "version": "0.3.1",
+  "version": "0.4.1",
   "description": "Full-lifecycle AI-assisted development kit with Test Architect and Whiteport Design Studio embedded. Inspired by BMAD Method and WDS.",
   "keywords": [
     "ai",

package/src/core-skills/module.yaml

@@ -22,3 +22,7 @@ skills:
   - code: wize-review-adversarial
     name: "Adversarial Review"
     description: "Red-team review of artifacts — challenges assumptions, surfaces edge cases."
+  - code: wize-spec
+    name: "Spec"
+    description: "Distills any intent input into a canonical five-field spec kernel + companions."
+

package/src/core-skills/wize-spec/assets/headless-schemas.md

@@ -0,0 +1,39 @@
+# Headless response schemas for wize-spec
+
+Used when `wize-spec` is invoked non-interactively (headless).
+
+## Create / Update
+
+```json
+{
+  "error_code": null,
+  "spec_path": "{project-root}/.wize/specs/spec-{slug}/SPEC.md",
+  "slug": "{slug}",
+  "capabilities": ["CAP-1", "CAP-2"],
+  "companions": ["glossary.md"],
+  "assumptions": [],
+  "open_questions": [],
+  "verdict": "Coherence: pass. Preservation: pass."
+}
+```
+
+## Error codes
+
+- `missing_slug` — headless caller did not provide a slug and it could not be derived.
+- `insufficient_intent` — no input content provided.
+- `too_sparse` — input too thin to distill; suggest `wize-product-brief` or `wize-create-prd`.
+
+## Validate
+
+```json
+{
+  "error_code": null,
+  "violations": [
+    {
+      "rule": "4",
+      "message": "No explicit non-goals found."
+    }
+  ],
+  "verdict": "Coherence: 1 issue. Preservation: pass."
+}
+```

package/src/core-skills/wize-spec/assets/spec-template.md

@@ -0,0 +1,40 @@
+---
+slug: "{{slug}}"
+status: draft
+owner: "{{owner}}"
+companions: []
+sources: []
+assumptions: []
+open_questions: []
+---
+
+# SPEC — {{slug}}
+
+## Why
+
+{{One paragraph: what problem this thing exists to solve and for whom.}}
+
+## Capabilities
+
+| ID | Intent | Success |
+|---|---|---|
+| CAP-1 | {{what the system does for the user}} | {{observable outcome that proves it works}} |
+| CAP-2 | … | … |
+
+## Constraints
+
+- {{Constraint that bends a design decision.}}
+- …
+
+## Non-goals
+
+- {{Explicitly out of scope.}}
+- …
+
+## Success signal
+
+{{Concrete, testable or demonstrable signal that the spec is satisfied.}}
+
+## Decision log
+
+See `.decision-log.md`.

package/src/core-skills/wize-spec/customize.toml

@@ -0,0 +1,20 @@
+# Wize Dev Kit — overrides for the built-in skill "wize-spec".
+# DO NOT EDIT in the installed kit; copy to .wize/custom/skills/wize-spec/
+# 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 skill keeps in mind for the whole run.
+persistent_facts = [
+  "file:{project-root}/.wize/knowledge/document-project/conventions.md",
+]
+
+# Scalar executed when the spec is finalized and the decision-log verdict is written.
+# Override wins. Leave empty for no custom post-completion behavior.
+on_complete = ""

package/src/core-skills/wize-spec/skill.md

@@ -0,0 +1,110 @@
+---
+code: wize-spec
+name: Spec
+module: core
+status: ready
+---
+
+# Spec
+
+**Goal.** Distill any intent input into a canonical, preservation-validated machine contract for downstream Wize work.
+
+Takes any intent input — vague idea, brain dump, PRD, RFC, brief, Slack thread, customer email, meeting transcript, mockups, mixed multi-source — and produces `SPEC.md` carrying the five-field kernel (Why, Capabilities, Constraints, Non-goals, Success signal) plus companion files for load-bearing content that does not fit or would bloat the kernel.
+
+Peggy Carter edits prose; Tony, Maria Hill, and Shuri consume the spec downstream.
+
+## When to use
+
+- "Create a spec for this idea."
+- "Distill this PRD into a spec."
+- "Validate this spec."
+- "Update the spec."
+
+Multiple skills may call to update the same spec over time.
+
+## Workspace
+
+The spec is **always a folder** named `{output_folder}/specs/spec-{slug}/`.
+
+`{slug}` describes the thing being specced, not the input shape:
+
+- Source artifact already carries a slug (e.g., `prd-foo-bar-2026-05-23/`): inherit (`foo-bar`).
+- Sparse, in-chat, or multi-source input: ask interactively. Headless callers must provide it.
+- Same slug = same folder. A second invocation updates in place, preserving capability IDs.
+
+Inside the spec folder:
+
+```
+<spec-folder>/
+  SPEC.md                  ← uppercase, the kernel
+  <companion-1>.md         ← optional, content-typed
+  <companion-2>.md
+  .decision-log.md         ← canonical memory for this spec
+```
+
+## The Operation
+
+1. Read the input and its ancillary linked materials. If no input, ask or block.
+2. If a prior `SPEC.md` exists at the target folder, read it — the operation becomes an **update**. Preserve capability IDs; new capabilities get the next unused `CAP-N`; never reuse retired IDs.
+3. When input is structured and pre-sorted (PRD with addendum, brief from Pepper, UX spec from Mantis), trust the authored separation.
+4. When input is mixed (brain dump, transcript, email), sort claims using the three-lens load-bearing test and route to the kernel field or a companion.
+5. Distill into the five-field kernel using `assets/spec-template.md`. When input is rich, extract directly. When input is sparse, choose:
+   - **express** — best-effort distill, every gap becomes an `open_questions[]` entry
+   - **guided** — walk the five fields with the user one at a time
+6. Write lean: every sentence must earn its place.
+7. If input is genuinely too thin (e.g. "an app for hikers" with no context), stop and suggest `wize-product-brief` or `wize-create-prd`.
+
+## Load-bearing
+
+A claim is **load-bearing** if any downstream consumer (skill, implementing agent, verification pass) would change a decision without it.
+
+## Companions
+
+When load-bearing content does not fit the five-field kernel, it lives in a companion. The kernel cites it; the companion holds it. Companions are part of the contract; every consumer reads `companions:` in `SPEC.md` frontmatter to discover them.
+
+**Spawn a companion when the content needs more than one kernel-shape line:** multi-item catalogs (archetypes, modes, routes, entity matrices), tables, diagrams (always), editorial voice rules, long-form reference material the kernel cites by name.
+
+Companions are either:
+
+- **Spec-authored** — written by `wize-spec` and live as siblings of `SPEC.md` (e.g., `glossary.md`, `patron-archetypes.md`, `stack.md`, `conventions.md`, `brownfield.md`, `architecture-diagrams.md`, `state-machines.md`, `failure-modes.md`).
+- **Adopted** — load-bearing artifacts written by upstream skills that downstream still needs to read (e.g., a `DESIGN.md` from Mantis, an API spec from a partner). The originating skill owns them; `wize-spec` references them in `companions:` but does not edit them.
+
+Two rules govern companions:
+
+1. Name spec-authored companions for the content type they hold.
+2. Diagrams always land in a companion, regardless of size. Mermaid/ASCII/image references live there; `SPEC.md` holds prose only.
+
+Pre-existing project-wide docs (e.g., `.wize/knowledge/document-project/conventions.md`) that downstream needs are listed as **adopted companions**, never duplicated.
+
+## Spec Law
+
+1. Each capability has both `intent` and `success`.
+2. Intents describe WHAT, not HOW.
+3. Constraints actually bend design decisions.
+4. Non-goals are explicit — at least one.
+5. Success signal is concrete enough to test or demonstrate against.
+6. Capability IDs are stable and unique — never reused, never renumbered.
+7. Preservation — every load-bearing source claim lands in `SPEC.md` or a companion.
+8. Lean prose — every sentence carries load-bearing content.
+
+## Self-Validate
+
+After every create or update, sweep the artifact in two passes:
+
+- **Pass 1 — Coherence.** Judge against Spec Law rules 1–6 and 8. Calls made without direct confirmation become `assumptions[]`; gaps become `open_questions[]`.
+- **Pass 2 — Preservation.** Walk source claims; confirm each landed in `SPEC.md` or a companion. Wrapper-only drops are logged under "Wrapper-only content" so the drop is on the record.
+
+Append a one-paragraph verdict to `.decision-log.md`.
+
+## Output
+
+- **Interactive** — share the spec folder path, name capability count, companions produced, and verdict in one or two sentences. List `assumptions[]` and `open_questions[]` if non-empty.
+- **Headless** — return JSON per `assets/headless-schemas.md`.
+
+## After the spec is output
+
+Any update to assumptions, open questions, or other changes is appended to `.decision-log.md` and, when applicable, to the source artifact's decision log.
+
+## Hand-off
+
+> Spec `{slug}` distilled into `{output_folder}/specs/spec-{slug}/SPEC.md` with `{n}` capabilities and `{m}` companions. Verdict: `{verdict}`. Open questions: `{list}`.

package/src/method-skills/1-analysis/wize-domain-research/customize.toml

@@ -0,0 +1,14 @@
+# Wize Dev Kit — overrides for the built-in workflow "wize-domain-research".
+# DO NOT EDIT in the installed kit; copy to .wize/custom/workflows/wize-domain-research/
+# for project-level overrides.
+
+[workflow]
+
+activation_steps_prepend = []
+activation_steps_append = []
+
+persistent_facts = [
+  "file:{project-root}/.wize/planning/brief.md",
+]
+
+on_complete = ""

package/src/method-skills/1-analysis/wize-domain-research/domain-steps/step-01-init.md

@@ -0,0 +1,49 @@
+# Step 1: Domain Research Scope Confirmation
+
+## Rules
+
+- 🛑 Never generate content without user confirmation.
+- 📖 Always read the complete step file before acting.
+- 🔍 Scope confirmation only.
+- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
+
+## Task
+
+Confirm domain research scope.
+
+## Execution
+
+Present:
+
+```
+I understand you want domain/industry research for {{research_topic}}.
+
+This research will cover:
+✅ Domain overview and ecosystem
+✅ Competitive landscape
+✅ Regulatory and compliance considerations
+✅ Technical trends
+✅ Strategic implications
+
+[C] Continue — begin domain research with this scope
+```
+
+On [C], append the scope confirmation, update `stepsCompleted: [1]`, and load `./domain-steps/step-02-domain-analysis.md`.
+
+## Append
+
+```markdown
+## Domain Research Scope Confirmation
+
+**Research Topic:** {{research_topic}}
+**Research Goals:** {{research_goals}}
+
+**Scope:**
+- Domain overview and ecosystem
+- Competitive landscape
+- Regulatory and compliance considerations
+- Technical trends
+- Strategic implications
+
+**Scope Confirmed:** {{date}}
+```

package/src/method-skills/1-analysis/wize-domain-research/domain-steps/step-02-domain-analysis.md

@@ -0,0 +1,39 @@
+# Step 2: Domain Analysis
+
+## Rules
+
+- 🌐 Search the web to verify claims.
+- 📝 Write findings to the document immediately.
+- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
+
+## Task
+
+Analyze the domain ecosystem for {{research_topic}}.
+
+## Execution
+
+Search for:
+
+- "{{research_topic}} industry overview"
+- "{{research_topic}} market size"
+- "{{research_topic}} value chain"
+
+Synthesize and append:
+
+```markdown
+## Domain Analysis
+
+### Industry Overview
+...
+
+### Market Size and Growth
+...
+
+### Value Chain
+...
+
+### Source Citations
+...
+```
+
+Update `stepsCompleted: [1, 2]` and load `./domain-steps/step-03-competitive-landscape.md`.

package/src/method-skills/1-analysis/wize-domain-research/domain-steps/step-03-competitive-landscape.md

@@ -0,0 +1,39 @@
+# Step 3: Competitive Landscape
+
+## Rules
+
+- 🌐 Search the web to verify claims.
+- 📝 Write findings to the document immediately.
+- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
+
+## Task
+
+Map the competitive landscape for {{research_topic}}.
+
+## Execution
+
+Search for:
+
+- "{{research_topic}} key players"
+- "{{research_topic}} market share"
+- "{{research_topic}} industry leaders"
+
+Synthesize and append:
+
+```markdown
+## Competitive Landscape
+
+### Key Players
+...
+
+### Market Positioning
+...
+
+### Barriers to Entry
+...
+
+### Source Citations
+...
+```
+
+Update `stepsCompleted: [1, 2, 3]` and load `./domain-steps/step-04-regulatory-focus.md`.

package/src/method-skills/1-analysis/wize-domain-research/domain-steps/step-04-regulatory-focus.md

@@ -0,0 +1,39 @@
+# Step 4: Regulatory Focus
+
+## Rules
+
+- 🌐 Search the web to verify claims.
+- 📝 Write findings to the document immediately.
+- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
+
+## Task
+
+Identify regulatory and compliance considerations for {{research_topic}}.
+
+## Execution
+
+Search for:
+
+- "{{research_topic}} regulations"
+- "{{research_topic}} compliance requirements"
+- "{{research_topic}} GDPR / LGPD / SOC2"
+
+Synthesize and append:
+
+```markdown
+## Regulatory Focus
+
+### Applicable Regulations
+...
+
+### Compliance Requirements
+...
+
+### Risk Implications
+...
+
+### Source Citations
+...
+```
+
+Update `stepsCompleted: [1, 2, 3, 4]` and load `./domain-steps/step-05-technical-trends.md`.

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

@@ -0,0 +1,39 @@
+# Step 5: Technical Trends
+
+## Rules
+
+- 🌐 Search the web to verify claims.
+- 📝 Write findings to the document immediately.
+- ✅ Speak in `{communication_language}`; write artifacts in `{document_output_language}`.
+
+## Task
+
+Identify technical trends shaping {{research_topic}}.
+
+## Execution
+
+Search for:
+
+- "{{research_topic}} technology trends"
+- "{{research_topic}} digital transformation"
+- "{{research_topic}} emerging technologies"
+
+Synthesize and append:
+
+```markdown
+## Technical Trends
+
+### Current Technology Adoption
+...
+
+### Emerging Technologies
+...
+
+### Implications for Product Architecture
+...
+
+### Source Citations
+...
+```
+
+Update `stepsCompleted: [1, 2, 3, 4, 5]` and load `./domain-steps/step-06-research-synthesis.md`.

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

@@ -0,0 +1,43 @@
+# Step 6: Domain 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 domain research synthesis.
+
+## Execution
+
+Replace `[Research overview and methodology will be appended here.]` with a concise summary.
+
+Append:
+
+```markdown
+## Research Synthesis
+
+### Key Findings
+1. ...
+2. ...
+
+### Strategic Implications
+...
+
+### Constraints for the Product
+...
+
+### 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-domain-research/research.template.md

@@ -0,0 +1,31 @@
+---
+research_type: domain
+research_topic: "{{research_topic}}"
+research_goals: "{{research_goals}}"
+status: in-progress
+stepsCompleted: []
+owner: Pepper Potts
+created: "{{date}}"
+---
+
+# Domain Research — {{research_topic}}
+
+## Research Overview
+
+[Research overview and methodology will be appended here.]
+
+## Scope Confirmation
+
+## Domain Analysis
+
+## Competitive Landscape
+
+## Regulatory Focus
+
+## Technical Trends
+
+## Research Synthesis
+
+## Sources
+
+## Open Questions