wize-dev-kit 0.4.1 → 0.5.0

package/CHANGELOG.md

@@ -5,6 +5,39 @@ Format inspired by [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [0.5.0] — 2026-06-17
+
+### Added
+
+- **Onboarding real.** `wize-onboarding` is no longer a stub; reads `.wize/config/{project,user}.toml` and detects state S0–S4, then routes to the right next workflow with explicit hand-off copy.
+- **`wize-correct-course`** (4-implementation) — react when a sprint drifts. 5 sections: detect, classify (cut / re-route / escalate), propose, confirm with human, update `sprint-status.yaml`. Logs to `course-corrections.md`.
+- **`wize-edit-prd`** (2-plan) — update `.wize/planning/prd.md` without rewriting. 4 edit types (AC, scope, non-goal, decision) with mandatory `prd-changelog.md` row per change.
+- **`wize-project-context`** (3-solutioning) — consolidates brief + PRD + UX + architecture + ADRs + risk profile into `.wize/knowledge/project-context.md`. 5 sections, one canonical source for other agents.
+- **`wize-checkpoint-preview`** (4-implementation) — pause mid-story to validate direction. Records snapshot + decision in `checkpoints/{story_id}.md`.
+- **`wize-investigate`** (4-implementation) — structured RCA: frame, reproduce, hypothesize (top 3), verify, conclude. Report in `investigations/{date}-{slug}.md`.
+- **`wize-qa-generate-e2e-tests`** (tea) — translates UX screens + ACs into concrete E2E cases with P0/P1/P2 priority. Output in `tea/e2e-cases/{screen}.md`.
+- **`wize-review-edge-case-hunter`** (core) — focused edge-case pass. 4 areas (input, state, time/race, integration) with top-5 P0 ranking.
+- **`wize-index-docs`** (core) — rebuilds `.wize/knowledge/index.md` from the actual tree, 5 sections.
+- **`wize-editorial-review-prose` + `wize-editorial-review-structure`** (core) — Peggy Carter's review skills. Voice/jargon/hedging/pronouns; missing/misordered/heading-level/empty.
+- **`wize-customize`** (core) — guided override of built-in agents/skills/workflows via `.wize/custom/{type}/{code}/customize.toml`.
+- Sprint tracking: `.wize/implementation/sprint-status.yaml` (YAML state machine) plus human-readable `.wize/implementation/sprint-status.md`. 4 sprints closed (S1–S4).
+- Backlog: `.wize/implementation/backlog.md` with prioritized list of missing agile workflows.
+- TEA risk profile: 17 risks catalogued, all HIGH-impact mitigated.
+
+### Changed
+
+- **`wize-sprint-planning` hand-off** now suggests `/loop /wize-dev-story` so the dev loop runs across the sprint's `ready-for-dev` queue without re-invoking the workflow per story.
+- IDE adapters now copy companion files (`steps/`, `templates/`, `data/`, `*.csv`, `*-template.md`, `customize.toml`, `research.template.md`) alongside the SKILL.md. Anthropic-family adapter emit count: 63 → 119 per run.
+
+### Fixed
+
+- Installer: the "How should the agents call you?" prompt is always surfaced (was being skipped when the user name was inferred from the OS). Uses `prompts` library consistently for text + confirm inputs; no more residual stdin.
+- IDE adapters: micro-file workflows like `wize-create-architecture` previously rendered only their SKILL.md, dropping the entire `steps/` folder. Now all 4 Anthropic-family adapters copy siblings.
+
+### Tests
+
+- 233 passing (was 222). New: 4 Anthropic-family companion-file tests + 1 sprint-planning hand-off regression test.
+
 ## [0.4.1] — 2026-06-13
 
 ### Fixed

package/package.json

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

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

@@ -0,0 +1,114 @@
+---
+code: wize-customize
+name: Customize
+module: core
+status: ready
+---
+
+# Customize
+
+**Goal.** Guide the user through creating an override (customize.toml) for a built-in agent, skill, or workflow. The override lives at `.wize/custom/{type}/{code}/customize.toml` and is loaded by the adapter at sync time.
+
+Wizer drives. Tony on call for agent structure.
+
+## When to use
+
+- "Override the persona of `wize-agent-pm`."
+- "Customize the wording in `wize-product-brief`."
+- "Add a tool to `wize-orchestrator`."
+
+## When NOT to use
+
+- Creating a brand-new agent/skill/workflow → use `wize-create-agent` (or `wize-create-skill` / `wize-create-workflow`).
+- Updating built-ins directly (the kit does not support forking built-ins; the next update would clobber your changes).
+
+## Inputs
+
+- A target: agent code, skill code, or workflow code.
+- A scope: what to override (name, title, persona, tools, body).
+
+## Output
+
+- A new file at `.wize/custom/{type}/{code}/customize.toml` (or update of an existing one).
+- A re-run of `wize-dev-kit sync` to apply the override.
+
+## Steps
+
+### 1. Identify the target
+
+The user names the code (e.g., `wize-agent-pm`). The skill validates:
+
+- Code shape: `wize-{kind}-{slug}`.
+- Exists in the kit's built-in roster.
+
+If the target does not exist, suggest `wize-create-agent` instead.
+
+### 2. Inspect the existing override
+
+If `.wize/custom/{type}/{code}/customize.toml` exists, read it. The user is updating; otherwise creating.
+
+### 3. Ask what to change
+
+The skill asks the user to pick from the overrideable fields:
+
+- `name` (display name)
+- `title` (job title)
+- `persona` (markdown body)
+- `tools` (list of tool names the agent can call)
+- `icon` (emoji)
+
+One field per run. Re-run for additional fields.
+
+### 4. Generate the customize.toml
+
+Write the new (or merged) customize.toml. Keep the structure as comments so the user can see the template.
+
+```toml
+# Override for {code} — generated by /wize-customize
+# Re-running the skill merges; lines you delete are restored on next install.
+
+[persona]
+# name = "Your name here"
+# title = "Your title here"
+
+[tools]
+# Add tool names the agent can call. Empty = default set.
+# tools = []
+```
+
+### 5. Re-sync
+
+Run `wize-dev-kit sync` (or instruct the user to). The override is loaded by the adapter and emitted to the IDE targets.
+
+### 6. Hand off
+
+Notify the user of:
+
+- File written: `.wize/custom/{type}/{code}/customize.toml`.
+- Sync completed (or instructions to run it).
+- Where to verify the override (e.g., `.claude/skills/{code}/SKILL.md`).
+
+## Output template
+
+The skill does not write a markdown output; it writes the customize.toml and re-syncs.
+
+```toml
+# Override for wize-agent-pm — generated by /wize-customize
+
+[persona]
+name = "Hill"  # shortened from "Maria Hill"
+
+[tools]
+# tools = []   # default set
+```
+
+## Anti-patterns Wizer rejects
+
+- Suggesting direct edits to built-in files in `node_modules/wize-dev-kit/`. (Next update clobbers.)
+- Creating a customize.toml with no overrideable fields filled. (Empty = no-op.)
+- Auto-running `wize-dev-kit sync` silently. (Confirm with the user first.)
+- Customizing the same field twice in one run. (One field per run.)
+
+## Hand-off
+
+> "Override written at `.wize/custom/{type}/{code}/customize.toml`. Sync applied. Verify in `.claude/skills/{code}/SKILL.md` (or your IDE target)."

package/src/core-skills/wize-editorial-review-prose/skill.md

@@ -0,0 +1,92 @@
+---
+code: wize-editorial-review-prose
+name: Editorial Review — Prose
+module: core
+status: ready
+---
+
+# Editorial Review — Prose
+
+**Goal.** Catch prose drift in Wize artifacts (brief, PRD, ADR, gate, story, retrospective). Peggy Carter runs the review; the user applies the fixes.
+
+Peggy drives. Wizer is on call for the call to action ("rewrite the whole section" or "leave it").
+
+## When to use
+
+- "Review the prose in this PRD."
+- "Find jargon and hedging in the brief."
+- "Is this gate file clear?"
+
+## When NOT to use
+
+- Spelling/grammar (use a linter; out of scope here).
+- Structure (missing sections, wrong ordering) → use `wize-editorial-review-structure`.
+- Tone change (tone is intentional; leave it).
+
+## Inputs
+
+- A markdown file under `.wize/`.
+- A line range (optional; default = whole file).
+
+## Output
+
+- A markdown review with line-level findings, each tagged with severity (nit / suggest / recommend).
+
+## Steps
+
+### 1. Read
+
+Read the file (or line range). Skip code blocks. Skip frontmatter.
+
+### 2. Hunt (4 areas)
+
+- **Voice.** Active voice preferred. Flag passive constructions ("was decided by", "is being implemented").
+- **Jargon.** Acronyms not defined on first use. Discipline-specific terms (e.g., "JTBD", "NFR") that are not in the project glossary.
+- **Hedging.** Softeners that hide commitment: "might", "could possibly", "we should consider", "it would be nice". Suggest a stronger verb.
+- **Pronouns.** Ambiguous "this", "it", "they" without a clear referent. Suggest a specific noun.
+
+### 3. Rank
+
+Per finding:
+
+- **Nit** — minor; user can ignore.
+- **Suggest** — worth a 5-second fix.
+- **Recommend** — blocks the artifact's clarity; should be fixed.
+
+### 4. Hand off
+
+Output is a markdown list. The user applies or rejects each finding. Peggy does not auto-edit.
+
+## Output template
+
+```markdown
+---
+date: 2026-06-17
+file: planning/prd.md
+author: Peggy
+---
+
+# Prose review — prd.md
+
+## Recommendations
+- L42: "we should consider using a token bucket" → "we use a token bucket". Hedging hides the decision. **[recommend]**
+- L78: "this might affect the user" → "this affects new signups". Pronoun + hedging. **[recommend]**
+
+## Suggests
+- L15: "rate-limit" appears 4 times. First use: spell out "rate-limit (per-IP cap on request rate)". **[suggest]**
+- L23: passive "is implemented by" → active "we implement". **[suggest]**
+
+## Nits
+- L88: comma splice. **[nit]**
+```
+
+## Anti-patterns Peggy rejects
+
+- Auto-editing the source file. (Suggest; never write.)
+- Commenting on tone or style preference. (Tone is intentional; structure is a separate review.)
+- Marking everything as recommend. (Cap at 5 recommends per review.)
+- Reviewing code blocks. (Out of scope.)
+
+## Hand-off
+
+> "Prose review complete for `{file}`. {N} findings. {M} recommends, {K} suggests, {L} nits. Apply or reject per finding."

package/src/core-skills/wize-editorial-review-structure/skill.md

@@ -0,0 +1,97 @@
+---
+code: wize-editorial-review-structure
+name: Editorial Review — Structure
+module: core
+status: ready
+---
+
+# Editorial Review — Structure
+
+**Goal.** Catch structural drift in Wize artifacts: missing required sections, wrong ordering, inconsistent heading levels. Peggy Carter runs the review; the user applies the fixes.
+
+Peggy drives. Tony on call for architecture artifacts; Maria Hill for PRD; Hawkeye for gates.
+
+## When to use
+
+- "Review the structure of this PRD."
+- "Is this ADR complete?"
+- "Does this gate file have all required sections?"
+
+## When NOT to use
+
+- Prose quality → use `wize-editorial-review-prose`.
+- Content correctness (does the AC actually hold?) → use `wize-tea-review` or `wize-validate-prd`.
+
+## Inputs
+
+- A markdown file under `.wize/`.
+- (Optional) the artifact type (PRD, ADR, gate, story, brief) — auto-detected from path.
+
+## Output
+
+- A markdown review with section-level findings (missing, misordered, mistyped).
+
+## Steps
+
+### 1. Detect
+
+Infer the artifact type from the path:
+
+| Path | Type |
+|---|---|
+| `planning/brief.md` | brief |
+| `planning/prd.md` | prd |
+| `solutioning/adrs/ADR-*.md` | adr |
+| `solutioning/architecture.md` | architecture |
+| `implementation/tea/{epic}/{story}/gate.md` | gate |
+| `solutioning/stories/*/*.md` | story |
+| `solutioning/epics/*/*.md` | epic |
+
+### 2. Check against the template
+
+Each type has a required set of H2 sections. Use the template in the relevant workflow file (e.g., for PRD, see `wize-create-prd/workflow.md`). Compare against the file.
+
+### 3. Hunt (4 areas)
+
+- **Missing sections.** Required H2 not present.
+- **Misordered sections.** H2 present but in wrong order relative to the template.
+- **Inconsistent heading levels.** H3 used where H2 is expected (or vice versa).
+- **Empty sections.** H2 with no content (a heading and nothing else).
+
+### 4. Hand off
+
+Output is a markdown list with section-level findings. Severity: **must-fix** (missing) / **should-fix** (misordered) / **nit** (heading level).
+
+## Output template
+
+```markdown
+---
+date: 2026-06-17
+file: planning/prd.md
+type: prd
+author: Peggy
+---
+
+# Structure review — prd.md (PRD)
+
+## Must-fix
+- Missing H2: "Out of scope".
+- Missing H2: "Open questions".
+
+## Should-fix
+- H2 "Success criteria" appears after "Non-goals"; should be before (per template).
+
+## Nits
+- H3 used in "Constraints" where H4 would match the rest of the doc.
+```
+
+## Anti-patterns Peggy rejects
+
+- Suggesting a different section order than the template. (The template is the source of truth.)
+- Reviewing prose. (Use the prose skill.)
+- Marking optional sections (e.g., "Glossary" in PRD) as missing.
+- Auto-rewriting the file. (Suggest; never write.)
+
+## Hand-off
+
+> "Structure review complete for `{file}` ({type}). {M} must-fix, {K} should-fix, {L} nits. Apply or reject per finding."

package/src/core-skills/wize-index-docs/skill.md

@@ -0,0 +1,117 @@
+---
+code: wize-index-docs
+name: Index Docs
+module: core
+status: ready
+---
+
+# Index Docs
+
+**Goal.** Rebuild `.wize/knowledge/index.md` from the actual tree. One file that lists every artifact with a one-line description and a relative link. New devs read this file first.
+
+Wizer drives. Peggy polishes the one-line descriptions on the second pass.
+
+## When to run
+
+- After any major artifact is created or moved.
+- Before sprint planning (to confirm what exists).
+- When onboarding a new team member.
+
+## When NOT to run
+
+- Inside an IDE target folder (`.claude/`, `.cursor/`, etc.) — out of scope.
+- As a CI step on every commit (too noisy; manual).
+
+## Inputs
+
+- The `.wize/` tree (read-only scan).
+- A user message: "Rebuild the index" or similar.
+
+## Output
+
+- `.wize/knowledge/index.md` with sections: Planning, Solutioning, Implementation, Knowledge, Custom.
+
+## Steps
+
+### 1. Scan
+
+Walk `.wize/` recursively. Skip hidden directories (`.DS_Store` etc.). For each file:
+
+- Read its YAML frontmatter.
+- If `description` is present, use it.
+- Else use the first `# Heading` line.
+- Else use the file name (kebab-case to title case).
+
+### 2. Group
+
+Sort into 5 sections by file path:
+
+| Section | Path prefix |
+|---|---|
+| Planning | `.wize/planning/` |
+| Solutioning | `.wize/solutioning/` |
+| Implementation | `.wize/implementation/` |
+| Knowledge | `.wize/knowledge/` (excluding the index file itself) |
+| Custom | `.wize/custom/` |
+
+### 3. Write
+
+Generate `.wize/knowledge/index.md` with:
+
+- YAML frontmatter (`generated`, `last_updated`, `total_files`).
+- One H2 per section.
+- One bullet per file: `- [{title}]({relative_path}) — {one-line description}`.
+- A footer with the total file count and the timestamp.
+
+If a section is empty, omit the heading.
+
+### 4. Hand off
+
+Output is the index file. The user can review and adjust manually if the one-liners are stale. Re-run to overwrite.
+
+## Output template
+
+```markdown
+---
+generated: 2026-06-17
+last_updated: 2026-06-17
+total_files: 24
+---
+
+# Wize artifacts index
+
+## Planning (5)
+- [Brief — site-qwize](planning/brief.md) — Pepper's one-pager for the site.
+- [PRD — site-qwize](planning/prd.md) — Maria Hill's PRD for v1.
+- [Trigger map](planning/trigger-map.md) — WDS user-psychology map.
+- [UX scenarios](planning/ux/ux-scenarios.md) — Mantis's 8-question dialog.
+- [Tech vision](planning/tech-vision.md) — Fury's stack pick.
+
+## Solutioning (4)
+- [Architecture](solutioning/architecture.md) — Tony's 8-step architecture.
+- [ADR-001](solutioning/adrs/ADR-001-...) — ...
+...
+
+## Implementation (8)
+- [Sprint 1 status](implementation/sprint-status.md) — closed.
+- [Risk profile](implementation/tea/risk-profile.md) — 13 risks mitigated.
+...
+
+## Knowledge (6)
+- [Document project overview](knowledge/document-project/overview.md) — ...
+...
+
+## Custom (1)
+- [Agent: runbooks](custom/agents/wize-agent-runbooks/agent.yaml) — ...
+```
+
+## Anti-patterns Wizer rejects
+
+- Including IDE target folders (`.claude/`, `.cursor/`, `.kimi/`, etc.) in the index.
+- Dumping file contents (just the description + link).
+- Auto-running on every commit (manual or scheduled only).
+- Mixing in files outside `.wize/`.
+
+## Hand-off
+
+> "Index rebuilt at `.wize/knowledge/index.md`. {N} files indexed across 5 sections. Next: `/wize-help` reads this file when answering."

package/src/core-skills/wize-review-edge-case-hunter/skill.md

@@ -0,0 +1,112 @@
+---
+code: wize-review-edge-case-hunter
+name: Edge Case Hunter
+module: core
+status: ready
+---
+
+# Edge Case Hunter
+
+**Goal.** Focused edge-case pass on a code change. Returns a structured list of edge cases, ranked by likelihood × impact, with a hand-off to test or guard each one.
+
+Shuri runs the hunt. Hawkeye on call for test design. Wizer on call for cross-cutting risk.
+
+## When to use
+
+- "Hunt edge cases in this PR."
+- "What can break in this code?"
+- "Give me the edge case list before I refactor."
+
+## When NOT to use
+
+- Full adversarial code review → use `wize-code-review`.
+- Generate E2E test cases → use `wize-qa-generate-e2e-tests`.
+- Quick-dev fix → use `wize-quick-dev`.
+
+## Inputs
+
+- A code change (diff, file, or story reference).
+- A short scope statement (one sentence: what is this code trying to do?).
+- Optional: the relevant story file (`.wize/solutioning/stories/{epic}/{story}.md`).
+
+## Output
+
+- A markdown list of edge cases, grouped by category, with line-level `file:line` references when possible.
+- Suggested action per case: write a test, add a guard, accept, or defer.
+
+## Steps
+
+### 1. Scope
+
+Read the change + the one-line scope statement. Confirm the boundary: what is in scope (changed code) and what is not (existing dependencies, framework). Reject if the scope is too broad (> 500 LOC); suggest slicing first.
+
+### 2. Hunt (per area)
+
+Walk 4 areas in order:
+
+- **Input edges.** Empty, null, unicode, max length, malformed, wrong type, wrong encoding. Boundary values (0, 1, max, max+1).
+- **State edges.** Concurrent writes, stale reads, missing state, mixed state (some fields set, others not), partial failure.
+- **Time / race.** Timeouts, retries, clock skew, ordering, idempotency.
+- **Integration edges.** Vendor down, slow vendor, malformed vendor response, network partition, version skew.
+
+For each area, list specific cases in 1 line each. Cite `file:line` when relevant.
+
+### 3. Rank
+
+For each case, score:
+
+- **Likelihood** (low / medium / high): probability of triggering.
+- **Impact** (low / medium / high): what happens when it triggers.
+
+Order cases by `(likelihood + impact)`. The top 5 are P0; the rest P1/P2.
+
+### 4. Hand off
+
+For each P0 case, propose an action:
+
+- **Test** → the user adds a test.
+- **Guard** → the user adds input validation or a defensive check.
+- **Accept** → the user documents the risk and moves on.
+- **Defer** → the user opens a follow-up story.
+
+Output is a markdown table. The user picks what to apply.
+
+## Output template
+
+```markdown
+---
+date: 2026-06-17
+scope: "Refactor of validateInviteEmail — split into 3 helpers"
+author: Shuri
+---
+
+# Edge cases — {scope}
+
+## Top 5 (P0)
+
+| # | Case | Likelihood | Impact | Action | Location |
+|---|---|---|---|---|---|
+| 1 | Empty email string | high | medium | test | src/validate.ts:42 |
+| 2 | Email with leading/trailing whitespace | high | low | guard | src/validate.ts:55 |
+| 3 | Email with internationalized TLD (e.g. .中国) | medium | medium | test | src/validate.ts:48 |
+| 4 | Email longer than 254 chars | low | medium | guard | src/validate.ts:48 |
+| 5 | Null vs undefined | high | low | test | src/validate.ts:33 |
+
+## Other (P1/P2)
+
+- Unicode normalization mismatch — P1 — test
+- Two plus signs in local part — P2 — accept
+- Trailing dot in domain — P2 — defer (open E06-S05)
+```
+
+## Anti-patterns Shuri rejects
+
+- Listing 50 cases per area. (Top 5 P0; cap at 15 total.)
+- Auto-fixing (hunt, don't fix).
+- Skipping the rank step. (Without rank, the user cannot prioritize.)
+- Skipping the action per case. (An edge case without an action is just noise.)
+- Hunting only one area (e.g., only input). (All 4 areas.)
+
+## Hand-off
+
+> "Edge case hunt complete. {N} cases ranked. P0: {M}. Next: implement P0 (Shuri) or open follow-up stories (Hill)."

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

@@ -0,0 +1,108 @@
+---
+code: wize-edit-prd
+name: Edit PRD
+phase: 2-plan-workflows
+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)."