wize-dev-kit 0.14.0 → 0.16.0

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

@@ -1,133 +1,60 @@
 ---
-
 code: wize-product-brief
-description: "Use quando uma demanda bruta chegar e precisar ser convertida em um product brief de uma página."
 name: Product Brief
 phase: 1-analysis
 owner: wize-agent-analyst   # Pepper Potts
 absorbs: "WDS Saga — Phase 1"
-status: ready
+status: stub
 ---
 
 # Product Brief
 
-**Goal.** Convert raw demand into a one-page brief the team can ship from. The brief is the single source of truth at this point — every other artifact (PRD, UX, architecture) references back to it.
-
-Pepper drives. Peggy edits prose. Output lands in `.wize/planning/brief.md`.
+**Goal.** Turn raw demand into a concise, decision-ready brief that the rest of the team can ship from.
 
 ## Inputs
 
-- Raw demand (chat message, doc, ticket, screenshot, recording).
-- Optional existing materials (deck, doc, prior brief).
-- `.wize/config/project.toml`.
+- Raw demand (chat or file)
+- Optional existing materials (deck, doc, ticket, recording)
+- `.wize/config/project.toml`
 
 ## Outputs
 
 - `.wize/planning/brief.md`
-- Optionally `.wize/knowledge/research/` if Pepper pulled external sources.
 
 ## Steps
 
-### 1. Frame in one paragraph
-
-What is being asked, by whom, and by when. If you can't write it in three sentences, you don't understand it yet. One open decision → ask one clarifying question, then write. More than one → offer a `wize-grill` pass (one question at a time, recommendation attached) and interview until shared understanding; answers land straight in the brief fields below, unresolved ones in *Open questions*.
-
-### 2. Audience
-
-- **Primary user** (one, name them by role + JTBD).
-- **Secondary users** (≤ 2).
-- **Stakeholders** (≤ 3 — the people whose lives change if this ships).
-
-If the user list overflows, the brief is too broad. Force the cut.
-
-### 3. Vision
-
-One sentence describing the desired future state. Future tense. Concrete. No buzzwords. Test: can a new dev one month from now repeat it after a 30-second read?
-
-### 4. Success criteria
-
-3–5 measurable outcomes. Numbers, not adjectives.
-
-Examples:
-- ✓ "Median TTI on the checkout page ≤ 1.5s on a mid-range Android by Q3."
-- ✗ "Faster checkout."
-
-### 5. Non-goals
-
-What this is *not*. Cut ambiguity early. If a feature isn't ruled in or out here, it will be in the PRD review.
-
-### 6. Constraints
-
-Hard limits. Pick from:
-- Deadline (and what slipping it means).
-- Budget envelope (one-time and run-rate).
-- Compliance (GDPR, LGPD, SOC2, PCI, HIPAA, etc.).
-- Integrations the product must speak to.
-- Team / hiring envelope.
+1. **Frame.** One paragraph: what is being asked, by whom, by when.
+2. **Audience.** Primary user (1), secondary users (≤2), stakeholders (≤3).
+3. **Vision.** One sentence describing the desired future state.
+4. **Success criteria.** 3–5 measurable outcomes (numbers, not adjectives).
+5. **Non-goals.** What this is *not*. Cut ambiguity early.
+6. **Constraints.** Deadlines, budgets, compliance, integrations.
+7. **Open questions.** Ranked, each with the person who can answer.
+8. **Hand off.** Mark `status: ready-for-prd`; ping Wizer to call Maria Hill.
 
-### 7. Open questions
-
-Each with the human who can answer it. Each marked priority `blocker` / `important` / `nice-to-know`. Blockers must be resolved before the PRD starts.
-
-### 8. Hand-off
-
-- Mark `status: ready-for-prd` in the brief.
-- Notify Wizer: "Brief ready, hand to Hill."
-- Move to `wize-trigger-map` next (Pepper continues).
-
-## Brief template
+## Brief template (target file)
 
 ```markdown
----
-status: ready-for-prd | draft
-owner: Pepper Potts
-created: YYYY-MM-DD
----
-
 # Brief — {{project_name}}
 
 ## Vision
 …
 
 ## Audience
-- **Primary:** … (one role + their JTBD)
-- **Secondary:** …
-- **Stakeholders:** …
+- Primary: …
+- Secondary: …
+- Stakeholders: …
 
 ## Success criteria
 1. …
 2. …
-3. …
 
 ## Non-goals
 - …
 
 ## Constraints
-- **Deadline:** …
-- **Budget:** …
-- **Compliance:** …
-- **Integrations:** …
+- …
 
 ## Open questions
-- [ ] **(blocker)** … — *owner: NAME*
-- [ ] **(important)** … — *owner: NAME*
-- [ ] **(nice-to-know)** … — *owner: NAME*
+- [ ] … (owner: …)
 ```
-
-## Anti-patterns Pepper rejects
-
-- "Make the product better." → no audience, no outcome, not a brief.
-- Pasting a stakeholder's slack message verbatim. Rewrite in the brief voice.
-- Success criteria like "increase engagement". Reword: which event, how much, by when.
-- Hidden assumptions ("everyone has fast internet"). Surface them in *Constraints* or *Open questions*.
-- Open questions with no owner. If nobody owns it, the answer never comes.
-
-## When to skip
-
-This workflow is **not optional** for new products / new features. For tiny fixes (typo, copy, dependency bump), use `wize-quick-dev` instead — Pepper isn't called.
-
-## Hand-off
-
-When the brief is approved, Pepper notifies Wizer:
-
-> Brief is ready in `.wize/planning/brief.md`. No blockers open. Hill, your call on PRD.

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

@@ -3,49 +3,22 @@ code: wize-research
 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."
+status: stub
 ---
 
-# Research (Dispatcher)
+# Research
 
-**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.
+**Goal.** Synthesize external evidence (market, competitors, analytics, interviews) that informs the brief.
 
-## Classification guide
+## Inputs
+- Research questions from the brief
+- External access (browser, MCPs) and/or attached docs
 
-Analyze the user's question for these signals. Score each category by keyword hits; delegate to the highest-scoring category.
-
-| 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` |
+## Outputs
+- `.wize/planning/research.md`
 
 ## Steps
-
-### 1. Read the question
-
-Extract the user's research topic or question. If the user provided a long message, identify the core research intent.
-
-### 2. Classify
-
-Match keywords against the classification guide above. Score each category by keyword hits. Pick the highest-scoring category.
-
-### 3. Delegate or ask
-
-- **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:
-
-> Isso é pesquisa de mercado, domínio ou técnica?
-
-Wait for the user's answer, then delegate to the chosen variant.
-
-## Anti-patterns
-
-- Executing research directly instead of delegating.
-- Asking more than one clarifying question.
-- Guessing when the signal is ambiguous — ask, don't assume.
-
-## Hand-off
-
-> Pesquisa classificada como {{category}}. Delegando para {{variant}}.
+1. List the questions to answer.
+2. For each question: gather sources, summarize, cite.
+3. Mark gaps explicitly as `open` so Wizer can re-route.
+4. Hand off back to brief workflow.

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

@@ -1,26 +1,20 @@
 ---
-
 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
 absorbs: "WDS Saga — Phase 2 (Trigger Mapping)"
-status: ready
+status: stub
 ---
 
 # Trigger Map
 
-**Goal.** Map user psychology to business goals. For each user action the product wants to drive, name the **trigger** (the need/anxiety/desire that precedes it), the **friction** that blocks it today, the **business outcome** unlocked, and the **signal** that confirms it happened.
-
-This is the bridge between Pepper's brief and Maria Hill's PRD: it forces the team to argue *why* users would do the thing before *what* the team will build.
-
-Pepper drives. Output lands in `.wize/planning/ux/trigger-map.md`.
+**Goal.** Map user psychology to business goals. For each user action we want to drive, identify the **trigger** (need/anxiety/desire) and the **business outcome** it unlocks.
 
 ## Inputs
 
-- `.wize/planning/brief.md` (vision + audience + success criteria).
-- `.wize/planning/research.md` (when present — strengthens triggers with evidence).
+- `.wize/planning/brief.md`
+- `.wize/planning/research.md` (if exists)
 
 ## Outputs
 
@@ -28,79 +22,19 @@ Pepper drives. Output lands in `.wize/planning/ux/trigger-map.md`.
 
 ## Steps
 
-### 1. List target user actions
-
-From the brief, list **3–8 actions** users must take for the product to succeed. Verb-led. Concrete.
-
-- ✓ "Sign up using a work email."
-- ✓ "Add a teammate."
-- ✓ "Confirm the first invoice."
-- ✗ "Get value." (too abstract)
-
-If you have more than 8, you're conflating products. Trim.
-
-### 2. Per row: trigger / friction / business outcome / signal
-
-For each action, fill four cells. Each cell ≤ 1 sentence.
-
-| Field | What goes here |
-|---|---|
-| **Trigger** | The mental state preceding the action. *Need / anxiety / desire.* What makes the user think "I need to do this now"? |
-| **Friction** | The cost of doing it today (in the current workaround or competitor). What stops them? |
-| **Business outcome** | What changes for the business when this action happens. Revenue, retention, cost, NPS, risk reduction. |
-| **Signal** | The telemetry event/state-change proving it happened. Name it like an event (`signup_succeeded`), not a phrase ("user signs up"). |
-
-### 3. Mark each row evidence-backed or hypothesis
-
-Every cell must be tagged:
-
-- `evidence:<source>` — when based on an interview, survey, analytics or a citable doc.
-- `hypothesis` — when we believe it but haven't proven it.
-
-Hypotheses are fine. Hidden hypotheses are not. Force the label.
-
-### 4. Wire to success criteria
+1. **List target user actions.** From the brief, list the 3–8 actions we want users to take.
+2. **For each action**, fill the row:
+   - **Trigger** — what state of mind/need precedes this action?
+   - **Friction** — what stops users from doing it today?
+   - **Business outcome** — what changes for the business when this action happens?
+   - **Signal** — what telemetry/event proves it happened?
+3. **Validate.** Cite research or mark `hypothesis`.
+4. **Hand off to Mantis** for UX Scenarios.
 
-For each of Pepper's success criteria in the brief, identify **which row of the map is the load-bearing one**. If a criterion has no row mapped to it, either it's not a real success criterion or the map is missing an action.
-
-### 5. Hand off
-
-Mark `status: ready-for-prd`. Tell Wizer the next step is Maria Hill.
-
-## Output template
+## Trigger Map template
 
 ```markdown
----
-status: ready-for-prd | draft
-owner: Pepper Potts
-created: YYYY-MM-DD
----
-
-# Trigger Map — {{project_name}}
-
-## Actions
-
-| # | Action | Trigger | Friction | Business outcome | Signal | Evidence |
-|---|---|---|---|---|---|---|
-| 1 | Sign up with work email | "We need a tool we can hand to the team next week." | Existing tool requires manual SSO; we want self-serve. | New paid-team conversion. | `signup_completed` | research:user-interview-2026-04 |
-| 2 | Invite first teammate | Won't move forward solo. | Email + reminder loops cost manager 10min. | Activation. | `teammate_invited` | hypothesis |
-| … | … | … | … | … | … | … |
-
-## Coverage of brief success criteria
-
-- **Criterion 1** ("TTI ≤ 1.5s on Android by Q3") → covered by row 4 (`page_loaded`).
-- **Criterion 2** ("…") → covered by row 1.
-- …
+| Action | Trigger | Friction | Business outcome | Signal | Evidence |
+|---|---|---|---|---|---|
+| … | … | … | … | … | research:/hypothesis |
 ```
-
-## Anti-patterns Pepper rejects
-
-- **Triggers written as features.** "Wants the dashboard." Wrong layer. Reword to the emotion/need: "Wants to know if the team is okay."
-- **Friction in vague language.** "It's confusing." Wrong. Name the step that breaks: "After invite, no email arrives for 4 hours."
-- **Business outcomes with no metric.** "Drives engagement." Wrong. "Reduces churn by ≥ 1pp in cohort C." If you can't measure it, it's not an outcome — it's a hope.
-- **Signals that fire on intent, not completion.** `signup_button_clicked` is intent. `signup_completed` is the signal.
-- **Same row repeated for two actions.** Each row must justify a distinct action. If you can collapse them, do it.
-
-## Hand-off
-
-> Trigger map is in `.wize/planning/ux/trigger-map.md`. Hill, the PRD goals should anchor on rows 1, 3, and 5 — they map to the success criteria in the brief.

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

@@ -1,169 +1,57 @@
 ---
-
 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
-status: ready
+status: stub
 ---
 
 # Create PRD
 
-**Goal.** Turn brief + research + trigger map into a Product Requirements Document the team can build from. The PRD names *what* and *why* with measurable boundaries. Mantis, Fury, Tony will read it. Shuri ships against the acceptance criteria.
-
-Maria Hill drives. Peggy edits prose. Output lands in `.wize/planning/prd.md`.
-
-Before drafting: if goals, scope, or ACs would need guessing beyond what the brief + trigger map answer, offer a `wize-grill` pass with the user first — decisions land in the PRD fields, leftovers in *Open questions*. Don't guess scope; ask.
+**Goal.** Turn brief + research + trigger-map into a Product Requirements Document the team can build from.
 
 ## Inputs
-
-- `.wize/planning/brief.md` (vision, audience, success criteria).
-- `.wize/planning/research.md` (when present).
-- `.wize/planning/ux/trigger-map.md` (every PRD goal references rows of this map).
-- `.wize/planning/prfaq.md` (when present — PRD scope mirrors FAQ Q5 "what's in/out").
+- `.wize/planning/brief.md`
+- `.wize/planning/research.md`
+- `.wize/planning/ux/trigger-map.md`
 
 ## Outputs
-
 - `.wize/planning/prd.md`
-- `.wize/solutioning/epics/` — coarse epic outlines Tony refines later.
 
 ## Steps
+1. **Goals.** Pull the success criteria from the brief; restate as PRD goals.
+2. **Scope (in / out).** Explicit list of in-scope and out-of-scope items.
+3. **User stories backbone.** "As a … I want … so that …" — coarse, will be sliced by Tony.
+4. **Acceptance criteria per scope item.** Each scope item gets ACs Hawkeye can test.
+5. **Constraints + assumptions.** From brief and Fury (if Fury has run already).
+6. **Open questions.** Owners assigned.
+7. **Hand-off.** Trigger Mantis to start UX scenarios.
 
-### 1. Goals (3–5)
-
-Pull the success criteria from the brief; restate as PRD goals. Each goal is:
-- One sentence.
-- Measurable (named metric + target + deadline).
-- Tied to a trigger-map row.
-
-Example: *"Reduce signup time from 3.5min to 1min by Q3 (signal: `signup_completed` median; row 1)."*
-
-### 2. Scope — in / out (explicit)
-
-| In | Out (for now) |
-|---|---|
-| First-team signup flow | Multi-team admin roles |
-| Self-serve invite | SSO via SAML |
-| English (US) | Other locales |
-
-If a stakeholder asked for it and it isn't here, they will ask again at gate review. Put their item in **Out** with a one-line reason, not silence.
-
-### 3. User stories backbone
-
-Coarse stories that map to scope items. "As a {role}, I want to {action}, so that {outcome}." Each story will be sliced finer by Tony in `wize-create-epics-and-stories`.
-
-Use the trigger-map rows as backbone:
-- Row 1 (Sign up) → "As a team admin, I want to sign up with my work email, so that I can invite my team within 5 minutes."
-
-### 4. Acceptance criteria per scope item
-
-For every In-scope item, write 3–7 ACs Hawkeye can test.
-
-Format: `Given … When … Then …` or a numbered behavioral list.
-
-ACs are **observable**. ✓ "If the user enters an invalid email, the input shows error text within 200ms." ✗ "The form validates emails correctly."
-
-Each AC gets an ID: `AC-{epic}-{n}`. Hawkeye references these in `tea-trace.md`.
-
-### 5. Constraints + assumptions
-
-Pull constraints from the brief. Add:
-- **Assumptions** that, if wrong, change scope.
-- **Dependencies** on other teams/services with name + deadline.
-
-Each assumption is one line + verification plan. *"Assumption: Stripe Connect onboarding average 7 days. Verification: confirm with Stripe by 2026-07-01."*
-
-### 6. NFR pointer
-
-Don't redefine NFRs in the PRD. Reference `.wize/planning/nfr-principles.md` (Fury's) once. Note any project-specific tightening.
-
-### 7. Open questions
-
-What still needs deciding before solutioning starts. Each with an owner + deadline. Blockers can't carry into Phase 3.
-
-### 8. Hand off
-
-- Mark `status: ready-for-validation`.
-- Run `wize-validate-prd` (Maria Hill + Mantis + Fury sign-off).
-- Then Mantis starts `wize-ux-scenarios`.
-
-## Output template
+## PRD template
 
 ```markdown
----
-status: draft | ready-for-validation | validated
-owner: Maria Hill
-created: YYYY-MM-DD
----
-
 # PRD — {{project_name}}
 
 ## Goals
-1. {{goal}} (metric: …, target: …, deadline: …, trigger-map row: …)
-2. …
+1. …
 
 ## Scope
-
 ### In scope
-- {{item}} — {{2–3 lines of detail}}
-
+- …
 ### Out of scope
-- {{item}} — {{one-line reason: not now / not us / not yet}}
+- …
 
-## Backbone (coarse stories)
-- E01: As a {{role}}, I want to {{action}}, so that {{outcome}}.
-- E02: …
+## Backbone (user stories)
+- …
 
 ## Acceptance criteria
+| Item | ACs |
+|---|---|
+| … | AC1 …; AC2 … |
 
-### E01 — Sign-up
-- **AC-01-1:** Given a new visitor on `/signup`, When they submit a valid work email + password, Then an account is created and they land on `/onboarding` within 1.5s.
-- **AC-01-2:** Given an invalid email, When the user blurs the field, Then error text appears within 200ms identifying which rule failed.
-- **AC-01-3:** Given a duplicate email, When the user submits, Then they see a "Sign in instead?" CTA and the request returns HTTP 409.
+## Constraints / assumptions
 - …
 
-## Constraints
-- Deadline: …
-- Budget: …
-- Compliance: GDPR, LGPD, SOC2.
-
-## Assumptions
-- Stripe Connect onboarding ≤ 7 days avg. — verify by …
-- Auth0 free tier sufficient for first 6 months. — verify by …
-
-## Dependencies
-- Design system tokens from Mantis by {{date}}.
-- Database from infra team by {{date}}.
-
-## NFR pointer
-See `.wize/planning/nfr-principles.md`. Project tightening: p95 LCP ≤ 2.0s (vs. global 2.5s) on signup pages.
-
 ## Open questions
-- [ ] (blocker) Pricing tier exposed pre-payment? — *owner: NAME, by: DATE*
-- [ ] (important) Brazil-only beta or global launch? — *owner: NAME, by: DATE*
+- [ ] … (owner: …)
 ```
-
-## INVEST checklist (per AC group)
-
-Maria Hill validates every story's ACs against INVEST:
-
-- **I**ndependent: no implicit dependency on another story being built first.
-- **N**egotiable: details can move; intent can't.
-- **V**aluable: a real outcome to a real user.
-- **S**mall: ≤ 1 PR worth (sliced finer in Phase 3 if not) — the only sizing test. INVEST's "Estimable" is dropped on purpose: we don't produce time or point estimates.
-- **T**estable: every AC is observable.
-
-If any letter fails, fix the story before it leaves Plan.
-
-## Anti-patterns Maria Hill rejects
-
-- **PRD as wishlist.** Pages of "the system shall…" with no Out-of-Scope. Force the cut.
-- **ACs as descriptions.** "The form is responsive." → no. *"At 360px, the form fits in the viewport with no horizontal scroll."*
-- **Open questions with no owner / no deadline.** They never get answered.
-- **Constraint hidden in prose.** Pull to its own bullet.
-- **PRD without a version + status.** Reviewers can't tell what they're reviewing.
-
-## Hand-off
-
-> PRD draft is at `.wize/planning/prd.md`. Two open blockers; CEO and Sales Lead have until Friday. Mantis — once we're `validated`, you start with the trigger map + PRD. Fury — your call on stack family.