wize-dev-kit 0.15.0 → 0.16.0

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

@@ -1,123 +0,0 @@
----
-
-code: wize-investigate
-description: "Use quando um bug ou comportamento inesperado surgir e precisar de investigação estruturada com root cause analysis."
-name: Investigate
-phase: 4-implementation
-owner: wize-agent-dev   # Shuri (+ wize-agent-test-architect Hawkeye on call)
-status: ready
----
-
-# Investigate
-
-**Goal.** Structured root-cause analysis for a failed test, regression, or unexpected behavior. Produces a written report so the team (and future-you) can retrace the steps.
-
-Shuri drives. Hawkeye on call for test-specific analysis. Wizer is on call for cross-cutting impact.
-
-## When to run
-
-- A test fails and the cause is not obvious from the diff.
-- A regression appears in production or CI.
-- A user reports a bug with unclear repro steps.
-- An incident triggers post-mortem.
-
-## When NOT to run
-
-- The cause is obvious from the diff → use `wize-quick-dev` to fix directly.
-- A new feature is needed (use `wize-create-story`).
-- A security finding is suspected (escalate immediately; do not investigate solo).
-
-## Inputs
-
-- The failing test, error log, or user report.
-- The commit range since the last known-good state.
-- The relevant story file (if any).
-- A free-form description of the symptoms.
-
-## Output
-
-- `.wize/implementation/investigations/{YYYY-MM-DD}-{short-slug}.md` — a written report.
-
-## Steps
-
-### 1. Frame
-
-One paragraph: what broke, when it was first noticed, who reported it, and how serious. If you cannot write this in 3 sentences, the report is too broad.
-
-### 2. Reproduce
-
-Step-by-step: how to reproduce locally. Include environment (OS, Node version, branch), commands, expected vs. actual output. If unreproducible, mark "not reproducible after N attempts" and stop.
-
-### 3. Hypothesize
-
-List 3 root causes, ranked by likelihood. For each:
-- What would explain the symptoms.
-- A 1-line test to confirm or refute.
-- Confidence: low / medium / high.
-
-### 4. Verify
-
-For each hypothesis, run the 1-line test. Record: confirmed / refuted / inconclusive. If all refuted, return to step 3 and re-rank.
-
-### 5. Conclude
-
-Pick the surviving root cause. State:
-- **Root cause:** {description}.
-- **Fix path:** {one paragraph: what to change and why}.
-- **Effort:** S / M / L.
-- **Risk of fix:** low / medium / high.
-- **Recommended next step:** open a quick-dev, open a story, or escalate.
-
-### 6. Hand off
-
-Notify the next workflow:
-- S / low risk → `/wize-quick-dev` (Shuri fixes directly).
-- M+ or higher risk → `/wize-create-story` (new story for the fix).
-- Escalation → `/wize-correct-course` (involve PM + Wizer).
-
-## Output template
-
-```markdown
----
-date: 2026-06-16
-author: Shuri
-severity: high
-related_story: E04-S02
-related_test: test/document-project-classify.test.js
-status: concluded
----
-
-# Investigation — {short-slug}
-
-## Frame
-{one paragraph}
-
-## Reproduce
-1. ...
-2. ...
-**Expected:** {x}
-**Actual:** {y}
-
-## Hypotheses
-1. **{hypothesis}** — Confidence: high. Test: {1-liner}. Result: confirmed.
-2. ...
-
-## Conclude
-- **Root cause:** {description}
-- **Fix path:** {one paragraph}
-- **Effort:** M
-- **Risk of fix:** low
-- **Next:** /wize-create-story (E04-S05)
-```
-
-## Anti-patterns Shuri rejects
-
-- Skipping the hypothesis ranking. (Ranking forces you to consider alternatives.)
-- Stopping at "I think it's X" without the verification test. (Confirmation bias.)
-- Mixing the investigation with the fix. (Investigate, then propose; do not edit code yet.)
-- One-paragraph reports. (If it's a real investigation, it's at least 5 sections.)
-- Sharing the report only in chat. (Always write to disk for archival.)
-
-## Hand-off
-
-> "Investigation concluded. Root cause: {summary}. Next: `/wize-create-story` (M+ fix) or `/wize-quick-dev` (S fix)."

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

@@ -1,162 +0,0 @@
----
-code: wize-release
-description: "Use quando todas as stories do sprint estiverem gated e você precisar gerar release: bump de versão, changelog e tag git."
-name: Release
-phase: 4-implementation
-owner: wize-agent-dev   # Shuri + Maria Hill
-status: ready
----
-
-# Release
-
-**Goal.** Bump de versão, changelog a partir das stories gated e tag git. O release é o passo entre "todas as stories passaram no gate" e a retrospectiva.
-
-Shuri executa. Maria Hill confirma o escopo (quais epics entram).
-
-## Pré-requisitos
-
-Antes de iniciar, verificar:
-
-1. **Sprint ativo** — `sprint-status.yaml` deve ter `development_status` com stories.
-2. **Todas as stories gated** — cada story no sprint ativo deve estar `done` no `sprint-status.yaml`. Stories com gate `FAIL` bloqueiam o release. Stories com `CONCERNS` precisam de waiver documentado.
-3. **Git limpo** — `git status --porcelain` deve estar vazio (ou conter apenas arquivos não rastreados que não fazem parte do release).
-4. **Branch main** — releases saem da `main`. Se estiver em feature branch, abortar e orientar merge via PR.
-
-Se qualquer pré-requisito falhar, reportar o bloqueio e parar. Não fazer release parcial.
-
-## Inputs
-
-- `.wize/implementation/sprint-status.yaml` — stories concluídas
-- `.wize/solutioning/stories/{epic}/*.md` — detalhes das stories
-- `package.json` — versão atual
-- `CHANGELOG.md` — changelog existente (se houver)
-- `git tag --list 'v*'` — tags existentes
-
-## Outputs
-
-- `package.json` com versão atualizada
-- `CHANGELOG.md` atualizado com a nova versão
-- Tag git `v{semver}`
-- `sprint-status.yaml` atualizado (sprint marcado como concluído)
-- Resumo do release no terminal
-
-## Steps
-
-### 1. Verificar pré-requisitos
-
-```bash
-git status --porcelain  # deve estar vazio
-git branch --show-current  # deve ser main
-```
-
-Ler `sprint-status.yaml` e validar que todas as stories do sprint ativo estão `done`. Se houver stories `backlog`, `ready-for-dev`, `in-progress` ou `review`, listar cada uma e abortar.
-
-### 2. Coletar stories concluídas
-
-Varrer `development_status` no `sprint-status.yaml`. Para cada story com status `done`:
-
-1. Localizar o arquivo da story em `.wize/solutioning/stories/{epic}/{story}.md`
-2. Extrair do frontmatter: `story_id`, `epic`, `status`
-3. Extrair do corpo: título (linha `# Story:`), acceptance criteria
-
-Agrupar por epic. Se o epic tiver `epic_id` no `sprint-status.yaml`, usar o nome do arquivo do epic em `.wize/solutioning/epics/` para obter o título legível.
-
-### 3. Determinar o bump de versão
-
-Ler a versão atual de `package.json`:
-
-```
-Versão atual: 0.11.0
-Qual o bump?
-  1. patch (0.11.1) — correções, hotfix, docs
-  2. minor (0.12.0) — novas features compatíveis
-  3. major (1.0.0) — breaking changes
-```
-
-Em modo interativo, perguntar ao usuário. Em modo não-interativo, usar o primeiro argumento (`patch`, `minor` ou `major`). Se nenhum argumento for passado, default `patch`.
-
-Calcular a nova versão com `semver.inc(current, bump)` — usar Node built-in (regex parse + increment, sem dependência externa).
-
-### 4. Gerar changelog
-
-Delegar a geração do changelog ao `wize-changelog`:
-
-1. Invocar o fluxo do `wize-changelog` com a nova versão e a lista de stories coletadas no passo 2.
-2. O changelog é gerado no formato Keep a Changelog e pré-pendido ao `CHANGELOG.md`.
-
-Se `CHANGELOG.md` não existir, criar com o cabeçalho padrão.
-
-### 5. Bump de versão
-
-Atualizar o campo `version` em `package.json` com a nova versão. Preservar a formatação existente (indentação, aspas duplas).
-
-### 6. Commit e tag
-
-```bash
-git add package.json CHANGELOG.md
-git commit -m "chore: release v{version}"
-git tag v{version} -m "Release v{version}"
-```
-
-A mensagem de commit deve listar os epics incluídos no release.
-
-### 7. Atualizar sprint-status.yaml
-
-Adicionar ao `sprint-status.yaml`:
-
-```yaml
-release:
-  version: "{version}"
-  date: "{YYYY-MM-DD}"
-  sprint: "{active_cycle}"
-  stories_released: {count}
-```
-
-Marcar o sprint como concluído e adicionar entrada de retrospectiva pendente.
-
-### 8. Resumo
-
-Emitir no terminal:
-
-```
-✓ Release v{version} criado
-
-Epics incluídos:
-  - {epic_name} ({story_count} stories)
-
-Changelog: CHANGELOG.md
-Tag: v{version}
-Commit: {commit_hash}
-
-Próximos passos:
-  - git push origin main --tags
-  - /wize-retrospective
-```
-
-**Não executar `git push` automaticamente.** O push é sempre manual — o desenvolvedor revisa antes de publicar.
-
-## Bump semver (built-in, zero-dep)
-
-```js
-function bumpVersion(current, type) {
-  const [major, minor, patch] = current.split('.').map(Number);
-  switch (type) {
-    case 'major': return `${major + 1}.0.0`;
-    case 'minor': return `${major}.${minor + 1}.0`;
-    case 'patch': return `${major}.${minor}.${patch + 1}`;
-    default: throw new Error(`Tipo de bump inválido: ${type}. Use patch, minor ou major.`);
-  }
-}
-```
-
-## Anti-patterns
-
-- Fazer release com stories não gated — o gate existe para proteger a main.
-- Fazer release de feature branch — releases saem da main.
-- Push automático — o desenvolvedor revisa antes de publicar.
-- Pular o changelog — "depois eu escrevo" = nunca escreve.
-- Bump manual de versão — usar o bump semver para evitar off-by-one.
-
-## Hand-off
-
-> Release v{version} criado. Changelog atualizado, tag aplicada. Execute `git push origin main --tags` quando revisar. Depois: `/wize-retrospective`.

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

@@ -1,164 +0,0 @@
----
-
-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

@@ -1,98 +0,0 @@
----
-
-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}.