wize-dev-kit 0.14.0 → 0.16.0

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

@@ -1,66 +0,0 @@
----
-code: wize-market-research
-name: Market Research
-phase: 1-analysis
-owner: wize-agent-analyst   # Pepper Potts
-status: ready
-description: "Use quando precisar pesquisar mercado, concorrentes, tendências ou posicionamento."
----
-
-> **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`
-
-# Market Research
-
-**Goal.** Conduct market research on competition and customers to inform the product brief and PRD.
-
-Pepper Potts drives. Peggy Carter edits prose. Output lands in `.wize/planning/research/market-{slug}-research-{date}.md`.
-
-## When to use
-
-- "I need market research on..."
-- "Who are the competitors?"
-- "What do customers actually want?"
-
-## Inputs
-
-- Open questions from `.wize/planning/brief.md`
-- User-provided topic or problem area
-- Web search access
-
-## Outputs
-
-- `.wize/planning/research/market-{slug}-research-{date}.md`
-
-## Workflow architecture
-
-This skill uses **step-file architecture**:
-
-- Six steps, each self-contained.
-- Sequential progression with user control.
-- Document state tracked in frontmatter (`stepsCompleted`).
-
-## On activation
-
-1. Load `.wize/config/project.toml` and `.wize/config/user.toml`.
-2. Resolve language settings and output paths.
-3. Greet the user in `communication_language`.
-4. Ask for the market research topic if not provided.
-5. Derive `{research_topic_slug}` and create the output file from `research.template.md`.
-6. Read fully and follow `./steps/step-01-init.md`.
-
-## Steps
-
-1. `step-01-init.md` — confirm scope.
-2. `step-02-customer-behavior.md` — analyze customer behavior.
-3. `step-03-customer-pain-points.md` — identify pain points.
-4. `step-04-customer-decisions.md` — map purchase/journey decisions.
-5. `step-05-competitive-analysis.md` — analyze competitors.
-6. `step-06-research-completion.md` — synthesize and complete.
-
-## Hand-off
-
-> Market research document is in `.wize/planning/research/`. Hill can quote the findings in the PRD; open questions route back to Wizer.

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

@@ -1,129 +0,0 @@
----
-
-code: wize-refresh-knowledge
-description: "Use quando o document-project acumulou bullets datados durante o sprint e precisar ser consolidado em uma baseline atualizada."
-name: Refresh Project Knowledge
-phase: 1-analysis
-owner: wize-agent-analyst    # Pepper (drives), with Peggy on prose
-status: ready
----
-
-# Refresh Project Knowledge
-
-**Goal.** Consolidate the dated bullets added to `document-project/*.md` over the sprint (via `wize-dev-story` step 8 and `wize-quick-dev` step 5) into a coherent, narrated, current-state baseline. Keep what's still true; demote what's outdated; archive what's no longer relevant.
-
-This is the workflow that **keeps `document-project` honest over months**, instead of letting it stale within a sprint.
-
-Pepper drives the consolidation. Peggy edits prose. Tony reviews architecture-snapshot changes. Hawkeye reviews risk-spots changes.
-
-## When to run
-
-- **End of sprint** (default cadence). `/wize next` (or `/wize-help next`) suggests it when it detects the sprint ended.
-- **After a major epic ships.** Architecture often shifts visibly; this is the moment to consolidate.
-- **Before onboarding a new engineer.** The baseline is the first thing they read; keep it fresh.
-- **Before an audit / external review.** Same.
-
-Don't run after every story — that's why each story already does its own inline update. This is the *periodic narration pass*.
-
-## Inputs
-
-- `.wize/knowledge/document-project/{overview,architecture-snapshot,conventions,dependencies,risk-spots,open-questions}.md`
-- `.wize/implementation/tea/**/gate.md` from this sprint (look for `KN-NN` findings — they flag where the baseline got out of sync).
-- Git log of the sprint window (`git log --since="<sprint-start>" --until="<sprint-end>"`).
-- `.wize/implementation/sprint-status.md` (latest sprint block).
-
-## Outputs
-
-- Updated `.wize/knowledge/document-project/*.md` (in place).
-- `.wize/knowledge/document-project/_history/{YYYY-Qn}/{sprint-N}.md` — sprint-scoped snapshot (frozen).
-- Optional new entries appended to `open-questions.md`.
-
-## Steps
-
-### 1. Collect the inline notes
-
-For each of the 5 axes, list every dated bullet added since the previous refresh (or since the baseline was created). They look like:
-
-```
-## 2026-06-12 — E01-S03
-- Conventions: `data-testid="invite-*"` published as public contract.
-- Risk: R-1 (mailer) mitigation confirmed.
-```
-
-Pepper extracts them by axis.
-
-### 2. Narrate, don't list
-
-For each axis, write a short paragraph that **integrates** the new bullets into the surrounding context. The bullets disappear; the prose grows. Each axis remains a single coherent file — not a chronological log.
-
-Example for `conventions.md` before refresh:
-
-```markdown
-## Tests
-Co-located with the file under test. `.spec.ts` for unit; `.e2e.ts` for end-to-end.
-```
-
-After refresh integrating an inline note "data-testid='invite-*' is a public contract":
-
-```markdown
-## Tests
-Co-located with the file under test. `.spec.ts` for unit; `.e2e.ts` for end-to-end. Test IDs follow the `data-testid="{feature}-{element}"` convention and are treated as a **public contract** — renaming one is a breaking change for end-to-end tests; ping Hawkeye before changing.
-```
-
-### 3. Demote what's outdated
-
-If a previous claim no longer holds (a service was retired, a convention was replaced), don't delete silently. Move it to a "Deprecated" section at the bottom of the file with the date it was replaced and the new pattern. Future readers need the breadcrumb.
-
-### 4. Archive a sprint snapshot
-
-Freeze the *current* state into `_history/{YYYY-Qn}/sprint-{N}.md`. This file is read-only after creation. Six months from now, when someone asks "when did we change the test-id convention?", the answer is in `_history/`.
-
-### 5. Open questions sweep
-
-Pull any `KN-NN` findings that weren't resolved (the gap was acknowledged but the doc still wasn't updated) and copy them as `open-questions.md` entries with owners.
-
-### 6. Diff narrative
-
-Append a one-paragraph summary to the bottom of each updated file:
-
-```markdown
-## Last refresh: 2026-06-25 (Sprint 7)
-- Architecture: 2 new components documented (`<InviteForm>`, `<TeamList>`); ADR-008 anchored in the auth section.
-- Conventions: test-id public contract documented; eslint plugin added (commit 7a3d2f).
-- Risk-spots: R-1 (mailer) closed; R-7 (rate limiter) added.
-- Dependencies: bumped zod, drizzle, expo (notes in dependencies.md).
-- Overview: unchanged; no new top-level feature in this sprint.
-```
-
-### 7. Hand off
-
-- All updated docs flip frontmatter `last_refreshed: YYYY-MM-DD`.
-- Wizer announces in `sprint-status.md`: *"Knowledge refresh done; baseline current."*
-- Maria Hill carries this into the retrospective: was the refresh smooth, or did the team accumulate too many KN findings?
-
-## Frontmatter convention for `document-project/*.md`
-
-Each baseline file ships with:
-
-```yaml
----
-status: baseline
-owner: Pepper + Peggy
-created: 2026-04-02
-last_refreshed: 2026-06-25
-sampled: "wkly + sprint refresh"
----
-```
-
-`last_refreshed` tells the next reader how much to trust the file vs read the more recent inline notes from `_history/`.
-
-## Anti-patterns Pepper rejects
-
-- **Refreshing into a chronological log.** That defeats narration; if a new dev opens `conventions.md` and sees 47 dated bullets, they can't form a mental model. Narrate.
-- **Refresh without reading the gate findings.** `KN-NN` findings are exactly the gaps you should be patching here; ignoring them recreates the original problem.
-- **Refresh every sprint regardless of activity.** If the sprint touched zero axes (rare but possible — a sprint of pure UI polish), say so in the diff narrative and skip the bulk of the work.
-- **Demotion without breadcrumb.** Future readers need the trail.
-
-## Hand-off
-
-> Knowledge refresh for Sprint 7 done. Baseline current; 1 historical snapshot frozen at `_history/2026-Q2/sprint-7.md`. KN-01 closed, KN-03 still open (deferred to S8 — assigned to Aaliyah).

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

@@ -1,14 +0,0 @@
-# Wize Dev Kit — overrides for the built-in workflow "wize-technical-research".
-# DO NOT EDIT in the installed kit; copy to .wize/custom/workflows/wize-technical-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-technical-research/research.template.md

@@ -1,31 +0,0 @@
----
-research_type: technical
-research_topic: "{{research_topic}}"
-research_goals: "{{research_goals}}"
-status: in-progress
-stepsCompleted: []
-owner: Pepper Potts
-created: "{{date}}"
----
-
-# Technical Research — {{research_topic}}
-
-## Research Overview
-
-[Research overview and methodology will be appended here.]
-
-## Scope Confirmation
-
-## Technology Stack Analysis
-
-## Integration Patterns
-
-## Architectural Patterns
-
-## Implementation Research
-
-## Research Synthesis
-
-## Sources
-
-## Open Questions

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

@@ -1,49 +0,0 @@
-# Step 1: Technical 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 technical research scope.
-
-## Execution
-
-Present:
-
-```
-I understand you want technical research for {{research_topic}}.
-
-This research will cover:
-✅ Technology stack and tooling
-✅ Integration patterns
-✅ Architectural patterns
-✅ Implementation approaches
-✅ Performance and scalability considerations
-
-[C] Continue — begin technical research with this scope
-```
-
-On [C], append the scope confirmation, update `stepsCompleted: [1]`, and load `./technical-steps/step-02-technical-overview.md`.
-
-## Append
-
-```markdown
-## Technical Research Scope Confirmation
-
-**Research Topic:** {{research_topic}}
-**Research Goals:** {{research_goals}}
-
-**Scope:**
-- Technology stack and tooling
-- Integration patterns
-- Architectural patterns
-- Implementation approaches
-- Performance and scalability considerations
-
-**Scope Confirmed:** {{date}}
-```

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

@@ -1,45 +0,0 @@
-# Step 2: Technology Stack 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 technology stack landscape for {{research_topic}}.
-
-## Execution
-
-Search for:
-
-- "{{research_topic}} programming languages frameworks"
-- "{{research_topic}} development tools platforms"
-- "{{research_topic}} database storage technologies"
-
-Synthesize and append:
-
-```markdown
-## Technology Stack Analysis
-
-### Programming Languages
-...
-
-### Frameworks and Libraries
-...
-
-### Database and Storage
-...
-
-### Development Tools and Platforms
-...
-
-### Cloud Infrastructure and Deployment
-...
-
-### Source Citations
-...
-```
-
-Update `stepsCompleted: [1, 2]` and load `./technical-steps/step-03-integration-patterns.md`.

package/src/method-skills/1-analysis/wize-technical-research/technical-steps/step-03-integration-patterns.md

@@ -1,39 +0,0 @@
-# Step 3: Integration Patterns
-
-## 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 integration patterns for {{research_topic}}.
-
-## Execution
-
-Search for:
-
-- "{{research_topic}} API design patterns"
-- "{{research_topic}} service integration"
-- "{{research_topic}} data integration"
-
-Synthesize and append:
-
-```markdown
-## Integration Patterns
-
-### API Design Patterns
-...
-
-### Service Integration
-...
-
-### Data Integration
-...
-
-### Source Citations
-...
-```
-
-Update `stepsCompleted: [1, 2, 3]` and load `./technical-steps/step-04-architectural-patterns.md`.

package/src/method-skills/1-analysis/wize-technical-research/technical-steps/step-04-architectural-patterns.md

@@ -1,39 +0,0 @@
-# Step 4: Architectural Patterns
-
-## 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 architectural patterns for {{research_topic}}.
-
-## Execution
-
-Search for:
-
-- "{{research_topic}} system architecture"
-- "{{research_topic}} architectural patterns"
-- "{{research_topic}} scalability patterns"
-
-Synthesize and append:
-
-```markdown
-## Architectural Patterns
-
-### Common Architectural Styles
-...
-
-### Scalability Patterns
-...
-
-### Security Patterns
-...
-
-### Source Citations
-...
-```
-
-Update `stepsCompleted: [1, 2, 3, 4]` and load `./technical-steps/step-05-implementation-research.md`.

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)."