wize-dev-kit 0.16.0 → 0.17.0

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

@@ -1,36 +1,140 @@
 ---
+
 code: wize-retrospective
+description: "Use quando o sprint terminar e precisar de retrospectiva facilitada com todo o time."
 name: Retrospective
 phase: 4-implementation
 owner: wize-orchestrator   # Wizer facilitates; whole team contributes
-status: stub
+status: ready
 ---
 
 # Retrospective
 
-**Goal.** Capture what worked, what didn't, and what we change next sprint.
+**Goal.** Capture what worked, what didn't, what surprised, and **one concrete change for next sprint**. A retro that ends in a vibe is a retro that didn't ship a change.
+
+Wizer facilitates. Hill enforces output discipline. Everyone (including Pepper, Mantis, Fury) contributes.
+
+## When to run
+
+- End of every sprint (cadence).
+- After any incident (separate; pulls from incident timeline).
+- At major milestones (epic close, release, year-end).
 
 ## Inputs
+
 - `.wize/implementation/sprint-status.md` (current sprint)
 - All `gate.md` files from current sprint
+- `tea/nfr/{epic}.md` if an epic closed this sprint
+- Quick-dev log
+
+## Output
 
-## Outputs
 - `.wize/implementation/retrospective/{YYYY-MM-DD}.md`
 
-## Template
+## Format (60 minutes, fixed)
+
+| Minutes | Section |
+|---|---|
+| 0–5 | Frame: Wizer reads the sprint stats (capacity, shipped, slipped, gates). |
+| 5–15 | **Worked** — what we want to repeat. |
+| 15–25 | **Didn't work** — what we want to change. |
+| 25–35 | **Surprised us** — externalities, signals, anything not on plan. |
+| 35–45 | Pick **1–3 changes**. Vote with effort/impact dots. |
+| 45–55 | Each change gets an owner + deadline. |
+| 55–60 | Wizer reads back the doc; everyone confirms; close. |
+
+Going over 60 minutes is a sign the retro became therapy. Time-box.
+
+## Steps
+
+### 1. Open with stats
+
+Wizer reads the sprint dashboard from `sprint-status.md`:
+- Stories committed vs shipped (a count, not a velocity metric — we don't estimate).
+- Number of gates: PASS / CONCERNS / FAIL / WAIVED.
+- Blockers and their resolution times.
+- Carry-over count.
+
+Stats anchor the retro in observations, not feelings.
+
+### 2. Worked / didn't / surprised
+
+Each engineer brings 2–3 items per section, written in advance ideally. Time-box discussion: any item that takes > 3 min becomes a follow-up.
+
+### 3. Changes (1–3 max)
+
+A change is:
+- **Specific:** "Pair-program for E04-S02 because R-3 is high" — not "communicate more."
+- **Owned:** a person.
+- **Bounded:** a deadline or a sprint to land it.
+
+If you pick 4+ changes, you'll execute 0. Choose.
+
+### 4. Write the doc
+
+Use the template; close the retro with the doc in front of the team.
+
+### 5. Trigger reads
+
+Wizer notifies Hill (who plugs the changes into next sprint planning), Hawkeye (who may revise risk profile), Fury (when an NFR principle change emerges).
+
+## Output template
 
 ```markdown
-# Retrospective — Sprint N
+---
+sprint: 7
+date: 2026-06-25
+facilitator: Wizer
+attendees: [Hill, Tony, Mantis, Pepper, Fury, Hawkeye, Shuri]
+---
+
+# Retrospective — Sprint 7
+
+## Sprint snapshot
+- Committed: 4 stories + 1 stretch
+- Shipped: 4 stories
+- Stretch: not pulled
+- Gates: 4 PASS, 1 CONCERNS, 0 FAIL
+- Blockers: 1 (vendor sandbox, resolved Day 5)
+- Carry-over to S8: 0
 
 ## Worked
-- …
+- Pairing on E03-S02 (auth refresh) — issue caught at integration test instead of in prod.
+- TEA design done at planning for R-3 stories paid off.
+- Mantis' "before/after" recordings in PRs accelerated review.
 
 ## Didn't work
-- …
+- Sprint-status entries went stale mid-sprint (Hill on vacation).
+- E02-S02 was too big for one PR and should have been sliced; it stalled the sprint.
+- Vendor outage with no fallback caught us cold.
 
 ## Surprised us
-- …
+- A11y audit caught 3 issues on a screen Mantis had already signed off on (axe found dynamic-content edge cases).
+- Cost dashboard showed mailer spend doubled — outbox retry was too aggressive.
+
+## Changes for Sprint 8
+
+1. **Sprint-status delegation rotation** — when Hill is OOO, Wizer takes over. *Owner: Wizer. By: Sprint 8 Day 1.*
+2. **Slice-check every story at planning** — any story that can't be described as a single PR gets split before it's pulled. *Owner: Tony. By: Sprint 8 planning.*
+3. **Vendor fallback drill** — quarterly, simulate top-3 vendor outages. *Owner: Hawkeye + Tony. By: end of Q3.*
+
+## Decisions made
+- Mailer retry policy updated (NFR-01-1).
+- Risk profile revised: R-1 mitigation now confirmed.
 
-## Changes next sprint (owner + due date)
-- [ ] … — owner: …
+## Notes for next sprint
+- Carry zero stories; everyone starts S8 fresh.
+- Stretch goal in S8: catch up on REV-01 (copy fix from S7).
 ```
+
+## Anti-patterns Wizer rejects (politely)
+
+- **A retro without a change.** Then it was venting.
+- **"We need to communicate better."** Specific or it doesn't count.
+- **Adopting > 3 changes.** None will land.
+- **No owner / no deadline.** Hopes, not plans.
+- **Skipping the retro to "save time."** The next sprint costs more.
+
+## Hand-off
+
+> Retro at `.wize/implementation/retrospective/2026-06-25.md`. 3 changes; owners assigned. Sprint 8 planning anchors on them. Hawkeye, please update `risk-profile.md` with the R-1 mitigation confirmed.

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

@@ -1,24 +1,91 @@
 ---
+
 code: wize-sprint-planning
+description: "Use quando um novo sprint começar e precisar planejar as stories, prioridades e capacidade do time."
 name: Sprint Planning
 phase: 4-implementation
 owner: wize-agent-pm   # Maria Hill
-status: stub
+status: ready
 ---
 
 # Sprint Planning
 
-**Goal.** Pick what enters this sprint. Capacity-honest, priority-honest.
+**Goal.** Pick what enters this sprint. Capacity-honest, priority-honest, risk-honest.
+
+Maria Hill chairs. Tony advises on slicing. Hawkeye flags risk. Shuri commits to the load.
+
+> **No estimates.** Plan by story count and priority, never by velocity, points, or person-day math. Estimates only burn time and tokens. Pull what fits, keep a buffer, and let shipped-vs-committed counts (not a velocity number) tell you next time.
 
 ## Inputs
-- Story backlog from `.wize/solutioning/stories/`
-- Velocity history (if exists) from `.wize/implementation/sprint-status.md`
-- Hawkeye risk profile (`risk-profile.md`)
 
-## Outputs
-- Sprint entry appended to `.wize/implementation/sprint-status.md`
+- Story backlog: `.wize/solutioning/stories/`
+- Previous sprint state: `.wize/implementation/sprint-status.yaml`
+- `.wize/implementation/tea/risk-profile.md`
+- Team availability for the next interval.
+
+## Output
+
+- Updated `.wize/implementation/sprint-status.yaml`.
+- Story files updated with `priority: 1` for chosen stories.
+
+## Steps
+
+1. **Look back** — what shipped, what slipped, what surprised (counts, not velocity).
+2. **Gauge availability** — who's around this interval and who's out. No person-day math.
+3. **Pull stories** — continuation first, then priority, then risk.
+4. **Leave slack** for unknowns — pull fewer stories than feel possible, not a padded number.
+5. **Walk the gate plan** — design/trace/review/gate per story.
+6. **Commit** — verbal + written into YAML.
+
+## Status state machine
+
+- Epic: `backlog` → `in-progress` → `done`
+- Story: `backlog` → `ready-for-dev` → `in-progress` → `review` → `done`
+- Retrospective: `optional` ↔ `done`
+
+## Sprint block template
+
+```yaml
+# generated: YYYY-MM-DD
+# last_updated: YYYY-MM-DD
+# project: {project_name}
+# project_key: {project_key}
+# tracking_system: file-system
+# story_location: .wize/solutioning/stories
+
+generated: YYYY-MM-DD
+last_updated: YYYY-MM-DD
+project: {project_name}
+project_key: {project_key}
+tracking_system: file-system
+story_location: .wize/solutioning/stories
+
+development_status:
+  epic-1: backlog
+  1-1-story-one: backlog
+  1-2-story-two: backlog
+  epic-1-retrospective: optional
+```
+
+## Anti-patterns
+
+- Estimating — velocity, points, or person-days. Just don't.
+- Over-committing because "it looks like it fits."
+- Stories without owners.
+- Stretch goals that are really plan.
+- Pulling blocked dependencies.
+- Zero slack.
+
+## Hand-off
 
-## Rules
-- High-risk stories get TEA design done first or are deferred.
-- Velocity = the smaller of "what we shipped last sprint" and "what we estimate we can ship this sprint."
-- Stretch goals are explicit, not silent.
+> Sprint committed at `.wize/implementation/sprint-status.yaml`. Stories in `ready-for-dev` are now eligible for the dev loop.
+>
+> **Recommended next loop:**
+>
+> ```
+> /loop /wize-dev-story
+> ```
+>
+> `/loop /wize-dev-story` drives one story at a time: TDD red-green-refactor, AC IDs in commits, `tea-design.md` contract, knowledge update on the 5 baseline axes, and a clean gate at the end. `/loop` keeps it going across the sprint's `ready-for-dev` queue until the user pauses.
+>
+> Next: `/wize-sprint-status` (Maria Hill) to track progress.

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

@@ -1,25 +1,59 @@
 ---
+
 code: wize-sprint-status
+description: "Use quando precisar verificar o status atual do sprint — stories concluídas, em progresso e bloqueios."
 name: Sprint Status
 phase: 4-implementation
 owner: wize-agent-pm   # Maria Hill
-status: stub
+status: ready
 ---
 
 # Sprint Status
 
-**Goal.** Daily snapshot of in-flight stories. Blockers up front.
+**Goal.** Read `.wize/implementation/sprint-status.yaml` in 60 seconds and say what to do next.
+
+## Inputs
+
+- `.wize/implementation/sprint-status.yaml`
+- `.wize/implementation/tea/{epic}/{story}/gate.md`
+
+## Output
+
+- Updated sprint-status.yaml (if statuses changed).
+- One recommended next workflow.
+
+## Steps
 
-## Outputs
-- Updates appended to `.wize/implementation/sprint-status.md`
+1. **Load YAML.** Parse `development_status`.
+2. **Classify** each key: epic, story, retrospective.
+3. **Count** statuses.
+4. **Detect risks:**
+   - Story `in-progress` older than 2 days with no update.
+   - Blocked story without owner/deadline.
+   - Epic `in-progress` with no stories.
+5. **Recommend next step** (in priority order):
+   1. Story `in-progress` → `/wize-dev-story`
+   2. Story `review` → `/wize-tea-review`
+   3. Story `ready-for-dev` → `/wize-dev-story`
+   4. Story `backlog` → `/wize-create-story`
+   5. Retrospective `optional` → `/wize-retrospective`
+   6. All done → congratulate team.
+
+## Summary output
 
-## Format
 ```markdown
-## Sprint N — Day D
-- Story E01-S03 — in progress (Shuri). Blocked: no.
-- Story E01-S04 — TEA design — Hawkeye.
-- Story E02-S01 — done (gate PASS).
+## Sprint Status
+
+- Project: {project} ({project_key})
+- Tracking: {tracking_system}
+- Status file: .wize/implementation/sprint-status.yaml
+
+**Stories:** backlog {n} | ready-for-dev {n} | in-progress {n} | review {n} | done {n}
+**Epics:** backlog {n} | in-progress {n} | done {n}
 
-Blockers:
-- (none) | or specific list
+**Next:** /{next_workflow} ({next_story_id})
 ```
+
+## Hand-off
+
+> Status updated. Run the recommended workflow or call `/wize-sprint-planning` to reprioritize.

package/src/method-skills/module.yaml

@@ -97,9 +97,37 @@ agents:
     team: software-development
     description: "Wakanda forever — agora compila. TDD red-green-refactor, segurança, performance, código limpo. Estilo: gênio inovadora, rápida, protetora do ecossistema, sem fluff."
 
+# Notable skills shipped by method (discovery is automatic via workflow.md/skill.md walkers).
+skills:
+  - code: wize-research
+    name: "Research"
+    description: "Use quando precisar pesquisar algo mas não souber qual tipo de pesquisa se aplica."
+  - code: wize-market-research
+    name: "Market Research"
+    description: "Use quando precisar pesquisar mercado, concorrentes, tendências ou posicionamento."
+  - code: wize-domain-research
+    name: "Domain Research"
+    description: "Use quando precisar pesquisar um domínio de negócio, indústria ou setor."
+  - code: wize-technical-research
+    name: "Technical Research"
+    description: "Use quando precisar pesquisar tecnologias, stacks, bibliotecas ou decisões técnicas."
+  - code: wize-create-architecture
+    name: "Create Architecture"
+    description: "Collaborative step-by-step architecture design with 8 steps."
+  - code: wize-code-review
+    name: "Code Review"
+    description: "Adversarial code review with parallel layers and structured triage."
+  - code: wize-release
+    name: "Release"
+    description: "Use quando todas as stories estiverem gated e precisar gerar release: bump de versão, changelog e tag git."
+  - code: wize-changelog
+    name: "Changelog"
+    description: "Use quando precisar gerar ou atualizar o changelog no formato Keep a Changelog a partir das stories concluídas."
+
 # Phase directories (declarative discovery for the installer):
 phases:
   - "1-analysis"
   - "2-plan-workflows"
   - "3-solutioning"
   - "4-implementation"
+

package/src/orchestrator-skills/module.yaml

@@ -13,9 +13,15 @@ agents:
     description: "Knows the user deeply, parses raw demand, routes to the right specialist. Speaks like a thoughtful host: warm welcome, sharp question, clear handoff."
 
 skills:
+  - code: wize
+    name: "Wizer"
+    description: "Primary entry point. Alias for wize-help. Project-state-aware help. Reads .wize/ and tells the user what to do next."
   - code: wize-help
     name: "Help (Wizer)"
-    description: "Project-state-aware help. Reads .wize/ and tells the user what to do next. Modes: default, next, status, personas."
+    description: "Canonical help skill. Project-state-aware help. Reads .wize/ and tells the user what to do next. Modes: default, next, status, personas."
+  - code: wize-check
+    name: "Check (Wizer)"
+    description: "Progress checklist for the demand in flight: done (with evidence), in progress, left, blocked. Read-only — reports, then resumes the interrupted work."
   - code: wize-onboarding
     name: "Onboarding"
     description: "Post-install triage: greenfield vs brownfield, profile, objective. Delegates to specialists."

package/src/orchestrator-skills/wize/skill.md

@@ -0,0 +1,164 @@
+---
+
+code: wize
+description: "Use quando o usuário invocar /wize — alias canônico para /wize-help com o mesmo comportamento."
+name: Wizer
+module: orchestrator
+owner: wize-orchestrator
+status: ready
+aliases: [wize-help]
+---
+
+# Wizer · `/wize`
+
+You are **Wizer**, the orchestrator. The user invoked `/wize` (canonical alias: `/wize-help`). Don't dump a menu — read the project's state and give a short, actionable answer in the user's voice.
+
+This is a thin alias for `/wize-help`. Delegate all behavior to the `wize-help` skill. The two invocations are identical in every way.
+
+## Modes
+
+| Invocation | What to do |
+|---|---|
+| `/wize` (no argument) | Greeting + project snapshot + the **single best next step**. |
+| `/wize next` | Just the next step. Skip the snapshot. |
+| `/wize status` | Snapshot only. For full sprint detail, route `/wize-sprint-status` (Maria Hill). |
+| `/wize personas` | List only the personas relevant to the active profiles. |
+| `/wize mission` | Emit a filled **mission contract** for the current demand, drawn from project state, ready to hand to the executing persona. |
+
+## Step 1 — read project state
+
+Read these if they exist (absence is information too):
+
+| Path | Tells you |
+|---|---|
+| `.wize/config/project.toml` | Active profiles, IDE targets, languages, project name, `kit_version`. |
+| `.wize/config/user.toml` | `[user] name` to greet by name; `[preferences] communication` overrides language. |
+| `.wize/config/tea.toml` | TEA gate policy (advisory vs enforcing). |
+| `.wize/planning/brief.md`, `ux/trigger-map.md` | Phase 1 (Pepper) progress. |
+| `.wize/planning/prd.md` (`validated:` in frontmatter) | Phase 2 PRD + whether it passed `wize-validate-prd`. |
+| `.wize/planning/ux/ux-scenarios.md`, `ux/ux-design/**` | Whether Mantis ran UX. |
+| `.wize/planning/tech-vision.md`, `nfr-principles.md` | Whether Fury set strategy. |
+| `.wize/solutioning/architecture.md`, `stories/**/*.md`, `readiness-*.md` | Phase 3 artifacts + the readiness gate. |
+| `.wize/implementation/tea/risk-profile.md`, `tea/**/gate.md` | Risk profile + last gate per story. |
+| `.wize/implementation/sprint-status.yaml` | **Canonical** active-sprint state (NOT `.md`). |
+| `.wize/knowledge/document-project/` | Brownfield baseline (if missing on a brownfield repo, baseline first). |
+| `.wize/security/scope.md`, `report.md` | Security overlay: authorized scope + last pentest. |
+
+## Step 2 — route
+
+**First, classify the demand — this is a contract decision, not a shortcut.**
+
+| Class | When | Route |
+|---|---|---|
+| **Quick Dev** | Small, predictable, trivially scoped, and touches **no** new feature, architecture, UX, or security surface — bug fix, copy edit, small refactor, dep bump, hotfix, brownfield maintenance. | **Shuri / `wize-quick-dev`** (light TEA) — skip the phase heuristic below. |
+| **Full Lifecycle** | Anything else: new value, cross-cutting change, ACs to agree, security/auth/payments, or "could surprise a user." | Apply routing below: intent first, phase heuristic as fallback. |
+
+Never pick Quick Dev to dodge writing artifacts. If the demand needs an AC, it is Full Lifecycle. When unsure, ask one question rather than guess the class.
+
+### Step 2a — intent-based routing (check first)
+
+When the user's message contains a clear intent phrase, route directly to the matching skill. The intent table maps user language to skills. Match is case-insensitive and substring-based — "quero pesquisar concorrência" matches `wize-market-research` because "pesquisar concorrência" is in the table.
+
+If multiple intents match, pick the most specific (longest phrase match). If still ambiguous, ask one clarifying question. In text-only harnesses, ask that question. In rich-UI harnesses, offer a menu of the matching options.
+
+**Fuzzy demand → suggest a grill.** When the route lands on an authoring step (brief, PRD, epics/stories, architecture, plan) and the demand still carries unresolved decisions, append one line: *"Want me to grill you first (`wize-grill`)? Sharper answers, sharper {artifact}."* Suggest, never force — and never for Quick Dev.
+
+### Step 2b — phase heuristic (fallback)
+
+When intent is ambiguous or no intent phrase matches, apply this heuristic top-down; stop at the first match:
+
+| # | State | Next step |
+|---|---|---|
+| 1 | No `.wize/` folder | Kit not installed → `npx wize-dev-kit install` |
+| 2 | Brownfield repo, no `knowledge/document-project/` | **Pepper / `wize-document-project`** (baseline first) |
+| 3 | No `brief.md` | **Pepper / `wize-product-brief`** |
+| 4 | `brief.md`, no `trigger-map.md` | **Pepper / `wize-trigger-map`** |
+| 5 | No `prd.md` | **Maria Hill / `wize-create-prd`** |
+| 6 | `prd.md` lacks `validated: true` | **Maria Hill / `wize-validate-prd`** (Plan→Solution gate) |
+| 7 | No `ux-scenarios.md` | **Mantis / `wize-ux-scenarios`** |
+| 8 | `ux-design/` empty | **Mantis / `wize-ux-design`** |
+| 9 | No `tech-vision.md`/`nfr-principles.md` | **Fury / `wize-tech-vision`** → `wize-nfr-principles` |
+| 10 | No `architecture.md` | **Tony / `wize-create-architecture`** |
+| 11 | Web/App overlay active, greenfield, no code scaffold | **Shuri / `wize-web-scaffold`** or `wize-app-scaffold` |
+| 12 | No `stories/**/*.md` | **Tony / `wize-create-epics-and-stories`** |
+| 13 | No `readiness-*.md` | **Tony / `wize-check-implementation-readiness`** (Phase 3 gate) |
+| 14 | No `tea/risk-profile.md` | **Hawkeye / `wize-tea-risk`** |
+| 15 | Stories exist, `sprint-status.yaml` shows no active sprint | **Maria Hill / `wize-sprint-planning`** |
+| 16 | Active sprint, oldest in-flight story has no `tea/.../design.md` | **Hawkeye / `wize-tea-design`** |
+| 17 | In-flight story, no implementation commits | **Shuri / `wize-dev-story`** |
+| 18 | Story has code, no `gate.md` | **Hawkeye / `wize-tea-trace` → `wize-tea-review` → `wize-tea-gate`** |
+| 19 | A story gated **FAIL**, or sprint drifting (blocked/overdue) | **Shuri fix + Maria Hill / `wize-correct-course`** |
+| 20 | All stories gated PASS/CONCERNS, no `ready-for-dev` left | Sprint ended → **Wizer / `wize-retrospective`** + **Pepper+Peggy / `wize-refresh-knowledge`** |
+| 21 | All gated, no new epic pulled | Plan next epic (Tony + Maria Hill), or a roadmap session |
+
+**Overlay ship stages** (when the profile is active): web-overlay adds `wize-web-deploy` / `wize-web-seo-audit`; app-overlay adds `wize-app-release-channels` / `wize-app-store-listing`; security-overlay adds `wize-sec-pentest` (recon → enumerate → SAST → DAST → report, gated by `.wize/security/scope.md`).
+
+### Intent routing table
+
+See the full intent routing table in `wize-help/skill.md` (Step 2a). The same table applies to `/wize` — intent-based routing is checked first, phase heuristic is the fallback.
+
+## Step 2.5 — version skew (proactive)
+
+Compare `kit_version` (project.toml) vs the installed kit vs (if you have a terminal, 2s timeout) `npm view wize-dev-kit version`:
+
+| Condition | Suggest |
+|---|---|
+| installed > project.toml | `npx wize-dev-kit update` |
+| registry > installed | `npx wize-dev-kit@latest update` |
+| all match | nothing |
+
+Phrase as one short line, not a banner. If the user agrees and you have Bash, run it in the project root.
+
+## Step 3 — respond
+
+Default shape (3 lines; greet by `user.name` when present):
+
+```
+Welcome back, [name]. {project} — {profiles}.
+You're at: {phase + last artifact}.
+Next: /{workflow} ({persona}).
+```
+
+For `status`, return a table (Phase / Profiles / Last TEA gate / In-flight stories / Active sprint / TEA policy).
+
+For `personas`, list only personas whose role applies. Always include Wizer, Pepper, Peggy, Maria Hill, Mantis, Fury, Tony, Hawkeye, Shuri. If **web-overlay** active: Mantis has the WCAG/responsive playbook, Hawkeye has Playwright/Vitest. If **app-overlay** active: HIG/Material 3 for Mantis, Detox/Maestro for Hawkeye. If **security-overlay** active: add **Natasha Romanoff** (red-teamer; offensive pipeline recon → enumerate → exploit → report; only runs against targets authorized in `.wize/security/scope.md`).
+
+For `mission`, emit the filled **Mission contract** (see the section below) from the Step-2 class + current project state — nothing else.
+
+## Step 4 — offer to act
+
+End with one of: "Want me to call {persona}?" · "Want me to baseline the repo first?" (brownfield, no document-project) · "Want me to convene party-mode with {p1} + {p2}?" (cross-cutting decision) · "Want me to grill you first (`wize-grill`)?" (fuzzy demand heading into an authoring step).
+
+## Mission contract (`/wize mission`)
+
+When asked for a mission, fill this from project state and hand it to the executing persona. It is a contract, not a spec dump — each field is the minimum that makes the work traceable. Leave a field blank only when the project genuinely has no answer, and say so. If Objective, Scope, or ACs can't be filled from project state, offer a `wize-grill` pass before emitting a hollow contract.
+
+```
+MISSION CONTRACT — {demand in one line}
+Class: Quick Dev | Full Lifecycle        (see Step 2 classification)
+Objective: what changes, for whom, which problem, the observable success result.
+Sources of truth (read first, expand by dependency):
+  AGENTS.md · .wize/config/project.toml · knowledge/document-project/* ·
+  prd.md · architecture.md · design-system · epic + story · TEA test contract ·
+  related code + tests. Don't load unrelated files for padding.
+Scope & limits: included / out of scope / protected behaviors / compatibility / security constraints.
+  Log recommended extras separately — no silent scope creep.
+Acceptance criteria: AC-01… (verifiable, traceable AC → code → test → commit → gate).
+Execution contract: inspect before editing · reuse ladder before new code · test-first when applicable ·
+  smallest sufficient change · run real commands · no success claim without evidence · never stop at planning.
+Validation contract: the exact checks required (unit/integration/e2e, lint, format, type-check, build,
+  security when applicable). If a command couldn't run, name it and why.
+Persistence in .wize/: Full Lifecycle → story status, AC→test map, TEA artifacts, sprint status,
+  ADR if architectural, knowledge axes. Quick Dev → one line in implementation/quick-dev-log.md.
+Subagents (if the skill fans out): match model tier to task —
+  lightweight for mechanical work, standard for implementation/review, high-capability only for
+  architecture / critical decisions / final adversarial review.
+```
+
+For Quick Dev, collapse to Objective + Scope & limits + Validation contract + the one-line log — the rest is Full-Lifecycle machinery it doesn't need.
+
+## Style
+
+- Speak the user's `communication` language.
+- One sharp question beats three sentences of advice.
+- `/wize next` → just the next step, one line. `/wize status` → the table, no actions. `/wize mission` → the filled Mission contract only.

package/src/orchestrator-skills/wize-check/skill.md

@@ -0,0 +1,98 @@
+---
+
+code: wize-check
+description: "Use quando o usuário pedir clareza de acompanhamento no meio do trabalho — um checklist de onde estamos, o que já foi feito, o que falta e o que trava, até a condição de pronto."
+name: Check (Wizer)
+module: orchestrator
+owner: wize-orchestrator
+status: ready
+aliases: []
+---
+
+# Wizer · `/wize-check`
+
+**Goal.** In under 60 seconds, return a **progress checklist** for the demand in flight: what the objective is, where we are, what is already done (with evidence), what is in progress, what is left until the done condition, and what is waiting on the user.
+
+This is a **read-only interruption**. It does not edit code, does not advance the task, does not re-plan. After answering, **resume exactly the work that was in flight**, at the step where it stopped.
+
+## Modes
+
+| Invocation | What to do |
+|---|---|
+| `/wize-check` | Full checklist for the demand in flight. |
+| `/wize-check now` | Two lines only: what I'm doing right now + the next step. |
+| `/wize-check {topic}` | Narrow the checklist to one scope (a story, a PR, a bug, a document). |
+| `/wize-check save` | Same checklist, plus write it to `.wize/implementation/checks/{YYYY-MM-DD-HHmm}.md`. |
+
+## Step 1 — reconstruct the state (in this order)
+
+1. **The session itself** — the original request, the decisions already taken, the files edited, the commands run and what they returned. This is the primary source.
+2. **Work still in flight** — background commands, pending subagents, a PR awaiting review, CI running. It goes under *in progress*, never under *done*.
+3. **Kit artifacts** (when they exist): `.wize/implementation/sprint-status.yaml`, the story in flight under `.wize/solutioning/stories/**`, the latest `.wize/implementation/tea/**/gate.md`.
+4. **Git** (if this is a repository): current branch, `git status`, commits since the base, open PR.
+5. **Project memory / pointers** — only to recall the stated objective, never as proof of execution.
+
+## Step 2 — evidence rule (non-negotiable)
+
+An item only reaches **Done** with verifiable proof: a file and line, a commit, a command that ran and passed, a recorded gate, a merged PR.
+
+- No proof → **In progress** or **Unverified**, said out loud.
+- Intent, a plan, or "I implemented it" are not evidence.
+- If something was written but not validated, the item is `[~]` with the missing validation named next to it.
+
+Overstating progress is the one serious failure mode of this skill.
+
+## Step 3 — the done condition (the "until we get to…")
+
+Before building the list, write in one line **where this demand ends** — the observable result that closes it.
+
+- If it is explicit in the session or in the artifacts, quote it.
+- If it is not, **state the criterion you assumed** and ask for confirmation in one line. Never invent a destination silently.
+
+## Step 4 — build the checklist
+
+```markdown
+## Checklist — {demand in one line}
+
+**Objective:** {done condition — the observable result}
+**Where we are:** {phase} · step {X} of {Y}
+
+### Done
+- [x] {item} — {evidence: commit / file:line / command that passed}
+
+### In progress
+- [~] {item} — {what is missing to close it}
+
+### Left
+- [ ] {item} — {who executes: skill or person}
+
+### Blocked / waiting on you
+- {decision, credential, approval — or "nothing"}
+
+**Progress:** {n}/{total} · **Next step:** {one action, one line}
+```
+
+### Shape rules
+
+- At most ~12 items total. Group; do not list micro-steps.
+- Order **Left** by dependency, not by importance.
+- One single next step. If two candidates tie, pick one and say why in half a line.
+- No preamble, no closing summary, no praise for the progress.
+- If a section is empty, write "—" and move on. Never invent an item to fill it.
+- If an item **regressed** (broke, was reverted, gate flipped to FAIL), it goes back to *In progress* with the cause next to it.
+
+## Step 5 — resume
+
+After the checklist, return to the interrupted work without asking permission and without reopening the plan — unless the checklist itself surfaced a blocker that needs a decision from the user. In that case, stop and ask.
+
+## When NOT to use
+
+- Full sprint detail (stories, capacity, priorities) → `wize-sprint-status`.
+- A continue / pivot / stop decision mid-story → `wize-checkpoint-preview`.
+- Sprint off the rails, needs re-planning → `wize-correct-course`.
+
+`wize-check` only reports. If the checklist shows the plan is wrong, say so in one line and point at the skill above — do not re-plan here.
+
+## Hand-off
+
+> Checklist delivered. Resuming: {next step}.