wize-dev-kit 0.3.1 → 0.4.0

package/src/method-skills/4-implementation/wize-code-review/steps/step-01-gather-context.md

@@ -0,0 +1,64 @@
+---
+diff_output: ''
+spec_file: ''
+review_mode: ''
+story_key: ''
+---
+
+# Step 1: Gather Context
+
+## Rules
+
+- Speak in `{communication_language}`.
+- The prompt that triggered this workflow IS the intent.
+- Do not modify any files in this step. Read-only.
+
+## Instructions
+
+1. **Find the review target.** Check in this order and stop as soon as the target is identified:
+
+   **Tier 1 — Explicit argument.**
+   Did the user pass a PR, commit SHA, branch, spec file, or diff source?
+   - PR reference → resolve to branch/commit via `gh pr view`.
+   - Commit or branch → use directly.
+   - Spec file → set `{spec_file}` to the path. Check its frontmatter for `baseline_commit`.
+   - Diff-mode keywords: `staged`, `uncommitted`, `branch diff`, `commit range`, `this diff`.
+
+   **Tier 2 — Recent conversation.**
+   Look for refs in the last few messages.
+
+   **Tier 3 — Sprint tracking.**
+   Look for `*sprint-status*` files and find stories with status `review`.
+
+   **Tier 4 — Current git state.**
+   If not on the default branch, confirm whether to review the current branch.
+
+   **Tier 5 — Ask.**
+   Present options: uncommitted changes, staged changes, branch diff, commit range, provided diff.
+
+2. **Construct `{diff_output}`.**
+   - Staged only: `git diff --cached`
+   - Uncommitted: `git diff HEAD`
+   - Branch diff: `git diff <base>..<branch>`
+   - Commit range: `git diff <from>..<to>`
+   - Provided diff: validate and use verbatim
+   - File list: `git diff HEAD -- <files...>`, with untracked files included via `git diff --no-index /dev/null <path>`
+
+   If `{diff_output}` is empty, halt and say so.
+
+3. **Set the spec context.**
+   - If `{spec_file}` is set and readable, set `{review_mode}` = `"full"`.
+   - Otherwise ask: "Is there a spec or story file that provides context for these changes?"
+     - Yes → set `{spec_file}`, verify it, set `{review_mode}` = `"full"`.
+     - No → set `{review_mode}` = `"no-spec"`.
+
+4. **Sanity check.**
+   If the diff exceeds ~3000 lines, warn and offer to chunk.
+
+### Checkpoint
+
+Present a summary: diff stats, `{review_mode}`, loaded spec/context docs. Halt and wait for confirmation to proceed.
+
+## Next
+
+Read fully and follow `./step-02-review.md`.

package/src/method-skills/4-implementation/wize-code-review/steps/step-02-review.md

@@ -0,0 +1,38 @@
+---
+failed_layers: ''
+---
+
+# Step 2: Review
+
+## Rules
+
+- Speak in `{communication_language}`.
+- The Blind Hunter subagent receives **only** the diff — no project context.
+- The Edge Case Hunter subagent receives the diff and project read access.
+- The Acceptance Auditor subagent receives the diff, spec, and context docs.
+- All review subagents run at the same model capability as the current session.
+
+## Instructions
+
+1. If `{review_mode}` = `"no-spec"`, note: "Acceptance Auditor skipped — no spec file provided."
+
+2. Launch parallel subagents without conversation context:
+
+   - **Blind Hunter** — receives `{diff_output}` only. Invoke via `wize-review-adversarial`.
+     Prompt: "Review this diff cynically. Assume problems exist. Find at least ten issues. Output as a Markdown list with one-line titles."
+
+   - **Edge Case Hunter** — receives `{diff_output}` and read access to the project. Invoke via `wize-review-edge-case-hunter`.
+     Prompt: "Walk every branching path and boundary condition in this diff. Report only unhandled edge cases as a JSON array."
+
+   - **Acceptance Auditor** (only if `{review_mode}` = `"full"`) — receives `{diff_output}`, `{spec_file}` content, and context docs.
+     Prompt: "Review this diff against the spec. Check for violations of acceptance criteria, deviations from spec intent, and missing behavior. Output findings as a Markdown list with AC/constraint reference and evidence."
+
+3. If subagents are unavailable, generate prompt files in `{implementation_artifacts}` and halt, asking the user to run each in a separate session.
+
+4. If any subagent fails, times out, or returns empty, append the layer name to `{failed_layers}` and proceed with findings from the remaining layers.
+
+5. Collect all findings from completed layers.
+
+## Next
+
+Read fully and follow `./step-03-triage.md`.

package/src/method-skills/4-implementation/wize-code-review/steps/step-03-triage.md

@@ -0,0 +1,43 @@
+# Step 3: Triage
+
+## Rules
+
+- Speak in `{communication_language}`.
+- Be precise. When uncertain between categories, prefer the more conservative classification.
+
+## Instructions
+
+1. **Normalize** findings into a common format. Expected input formats:
+   - Blind Hunter: Markdown list of descriptions.
+   - Edge Case Hunter: JSON array with `location`, `trigger_condition`, `guard_snippet`, `potential_consequence`.
+   - Acceptance Auditor: Markdown list with title, AC/constraint reference, and evidence.
+
+   Convert all to a unified list with:
+   - `id` — sequential integer
+   - `source` — `blind`, `edge`, `auditor`, or merged (`blind+edge`, etc.)
+   - `title` — one-line summary
+   - `detail` — full description
+   - `location` — file and line reference if available
+
+2. **Deduplicate.** Merge findings that describe the same issue:
+   - Use the most specific finding as the base (prefer Edge Case Hunter JSON with location).
+   - Append unique detail, reasoning, or locations from other findings.
+   - Set `source` to merged sources.
+
+3. **Classify** each finding into exactly one bucket:
+   - **decision_needed** — ambiguous choice requiring human input. Only possible if `{review_mode}` = `"full"`.
+   - **patch** — code issue fixable without human input.
+   - **defer** — pre-existing issue not caused by this change.
+   - **dismiss** — noise, false positive, or handled elsewhere.
+
+   If `{review_mode}` = `"no-spec"` and a finding would be `decision_needed`, reclassify as `patch` or `defer`.
+
+4. **Drop** all `dismiss` findings. Record the dismiss count.
+
+5. If `{failed_layers}` is non-empty, report which layers failed. If zero findings remain and layers failed, warn the user that the review may be incomplete.
+
+6. If zero findings remain after triage, state: "✅ Clean review — all layers passed."
+
+## Next
+
+Read fully and follow `./step-04-present.md`.

package/src/method-skills/4-implementation/wize-code-review/steps/step-04-present.md

@@ -0,0 +1,100 @@
+---
+deferred_work_file: '{implementation_artifacts}/deferred-work.md'
+---
+
+# Step 4: Present and Act
+
+## Rules
+
+- Speak in `{communication_language}`.
+- When `{spec_file}` is set, always write findings to the story file before offering action choices.
+- `decision_needed` findings must be resolved before handling `patch` findings.
+
+## Instructions
+
+### 1. Clean review shortcut
+
+If zero findings remain after triage, state that and proceed to section 6 (Sprint Status Update).
+
+### 2. Write findings to the story file
+
+If `{spec_file}` exists and contains a Tasks/Subtasks section, append a `### Review Findings` subsection in this order:
+
+1. `decision_needed` (unchecked):
+   ```
+   - [ ] [Review][Decision] <Title> — <Detail>
+   ```
+2. `patch` (unchecked):
+   ```
+   - [ ] [Review][Patch] <Title> [<file>:<line>]
+   ```
+3. `defer` (checked):
+   ```
+   - [x] [Review][Defer] <Title> [<file>:<line>] — deferred, pre-existing
+   ```
+
+Also append each `defer` finding to `{deferred_work_file}` under `## Deferred from: code review ({date})`.
+
+### 3. Present summary
+
+```
+Code review complete.
+- decision_needed: {D}
+- patch: {P}
+- defer: {W}
+- dismissed: {R}
+```
+
+If `{spec_file}` is set, add: "Findings written to `{spec_file}`."
+
+### 4. Resolve decision_needed findings
+
+Present each `decision_needed` finding and ask the user to decide. Once resolved, each becomes a `patch`, `defer`, or is dismissed.
+
+If deferred, ask for a one-line reason and append it to both the story file bullet and the deferred-work file.
+
+### 5. Handle patch findings
+
+If `patch` findings exist, ask:
+
+```
+How would you like to handle the {P} patch findings?
+1. Apply every patch — fix all now, no per-finding confirmation.
+2. Leave as action items — they are already in the story file (only if spec_file set).
+3. Walk through each patch — show details before deciding.
+```
+
+Wait for the numbered choice. Do not proceed until selected.
+
+- **Apply every patch**: apply all patch findings. Afterward, present a summary of changes and check off patch items in the story file if applicable.
+- **Leave as action items**: done.
+- **Walk through each patch**: present each finding with detail and suggested fix, then re-offer the menu.
+
+### 6. Update story status and sync sprint tracking
+
+Skip if `{spec_file}` is not set.
+
+Determine `{new_status}`:
+- If all `decision_needed` and `patch` findings are resolved and no unresolved issues remain → `done`
+- If patch findings were left as action items or unresolved issues remain → `in-progress`
+
+Update the story file status and save it.
+
+If `{story_key}` is set and a sprint-status file exists, update the matching `development_status` entry.
+
+### 7. Next steps
+
+Present options:
+
+```
+What would you like to do next?
+1. Start the next story — run wize-dev-story to pick up the next ready-for-dev story.
+2. Re-run code review — address findings and review again.
+3. Done — end the workflow.
+```
+
+Wait for the numbered choice.
+
+## On complete
+
+Run `{workflow.on_complete}` if non-empty.

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

@@ -2,118 +2,63 @@
 code: wize-code-review
 name: Code Review
 phase: 4-implementation
-owner: wize-agent-dev   # Shuri (peer Shuri — done at PR open time)
+owner: wize-agent-dev   # Shuri (peer review)
 status: ready
 ---
 
 # Code Review
 
-**Goal.** Audit **code health** on the PR. Separate from Hawkeye's `tea-review` (which audits AC fulfillment). Both run on every story PR; they're complementary.
+**Goal.** Review code changes adversarially using parallel review layers and structured triage into actionable categories.
 
-Shuri reviews peer PRs. Tony reviews when architecture is at stake.
+This is **Shuri's peer code review** — separate from Hawkeye's `wize-tea-review` (which audits AC fulfillment). Both run on every story PR; they are complementary.
 
 ## When to run
 
-Every PR that ships code. Quick-dev PRs get a lighter review (skip code-architecture checks unless they touched architecture).
+Every PR that ships code. Quick-dev PRs get a lighter review (skip architecture checks unless they touched architecture).
 
 ## Inputs
 
-- The PR (diff + tests).
-- Story file (for context — what the PR is supposed to accomplish).
-- Linked design system (when components change).
+- The diff, PR, branch, or commit range to review.
+- The spec/story file for context (optional but recommended).
+- Existing code style and project context from `.wize/knowledge/document-project/`.
 
-## Output
+## Outputs
 
-- Inline comments on the PR.
-- Final review verdict: `approve` / `request-changes` / `comment`.
+- Inline-style findings presented in the conversation.
+- Optional patch application if the user chooses to fix findings now.
+- Updated story file with a `### Review Findings` section when a spec file is provided.
+- Updated sprint status when a story key is discovered.
 
-## What this checks
+## Workflow architecture
 
-### Naming + structure
-- Are types, functions, variables named for **what they are**, not **how they're used**?
-- Are files in the right folder per the architecture?
-- Are exports minimal? Module boundaries respected?
-- Are there new abstractions justified by the story or premature?
+This skill uses **step-file architecture**:
 
-### Tests
-- Do tests cover the changed behavior (not just coverage %)?
-- Are they fast and isolated?
-- Are mocks at the boundary, not inside the unit?
-- Any `test.skip` / `.only` left in?
+- Each step is self-contained and followed exactly.
+- Sequential enforcement: complete steps in order, no skipping.
+- State tracked in frontmatter variables set at runtime.
+- Append-only building of findings.
 
-### Security (obvious-misses)
-- Input validation at boundaries.
-- Tokens / secrets / PII never logged.
-- SQL parameterized, not concatenated.
-- New deps audited; no known CVEs introduced.
-- Auth context checked on every server entry point.
+## Critical rules
 
-### Performance (obvious-misses)
-- No N+1 queries.
-- No `await` in tight loops without batching.
-- No new sync I/O on hot paths.
-- Bundle delta acceptable (size of new front-end imports).
+- **Read completely** each step file before acting.
+- **Never** load multiple step files simultaneously.
+- **Always** halt at checkpoints and wait for human input.
+- Use CWD-relative `path:line` for every code reference.
 
-### Architectural drift
-- Story didn't quietly introduce a new layer / new pattern.
-- If it did, an ADR was opened or a comment justifies it.
-- Components reused from design system; new components added to system if reusable.
+## On activation
 
-### Style + convention
-- Follows lint / format / type rules.
-- Comments explain *why*, not *what*.
-- Dead code removed.
-- TODOs have an owner + a ticket.
+1. Load `.wize/config/project.toml` and `.wize/config/user.toml`.
+2. Resolve `user_name`, `communication_language`, `document_output_language`, `implementation_artifacts`, `planning_artifacts`.
+3. Greet the user in `communication_language`.
+4. Read fully and follow `./steps/step-01-gather-context.md`.
 
-## What this does NOT check
+## Steps
 
-- Whether ACs are met — that's Hawkeye's `tea-review`.
-- Whether the design is right — that's reviewed in pull-request walk-through, ADR review, or party-mode.
-
-Don't conflate. Two reviewers, two scopes.
-
-## Comment style
-
-Use these prefixes:
-
-| Prefix | Meaning |
-|---|---|
-| `nit:` | Cosmetic; non-blocking |
-| `q:` | Question; might be a misunderstanding |
-| `praise:` | Real call-outs; teams need them |
-| `suggestion:` | Idea, the author decides |
-| `blocking:` | Must change before merge |
-| `out-of-scope:` | Real issue, separate story |
-
-Never `LGTM` without scanning. Never `LGTM` with `blocking:` open.
-
-## Verdict
-
-- **approve** — all blockings resolved.
-- **request-changes** — at least one `blocking:`.
-- **comment** — reviewed, no opinion (rare; used for early-draft PRs).
-
-## PR-open checklist (Shuri's self-review)
-
-Before opening, Shuri runs through:
-
-- [ ] CI green locally.
-- [ ] Lint + format clean.
-- [ ] Type-check clean.
-- [ ] No `console.log` / `dbg!` / debug printf.
-- [ ] No `test.skip` / `.only`.
-- [ ] Reading the diff right now, can I explain every line?
-- [ ] Self-walk: open the changed screen / call the changed endpoint.
-- [ ] Story status flipped to `ready-for-review`.
-
-## Anti-patterns Shuri rejects in herself
-
-- Approving without reading.
-- Approving on the basis of green CI alone.
-- "Big PR; will trust" — refuse and ask for slicing.
-- Inline suggestions for full rewrites — open a follow-up instead.
-- Demanding stylistic preferences not in the lint config.
+1. `step-01-gather-context.md` — identify the diff source, construct `{diff_output}`, set `{review_mode}` and `{spec_file}`.
+2. `step-02-review.md` — launch parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor).
+3. `step-03-triage.md` — normalize, deduplicate, and classify findings into `decision_needed`, `patch`, `defer`, `dismiss`.
+4. `step-04-present.md` — present findings, resolve decisions, apply patches, update story status.
 
 ## Hand-off
 
-> Reviewed PR #418 (E02-S02). 2 nits, 1 blocking on auth-context check missing in one new route. Shuri to fix; re-review needed; then Hawkeye runs `tea-review`.
+> Code review complete for `{story_key or change}`. `{decision_needed}` decision(s), `{patch}` patch(es), `{defer}` deferred, `{dismissed}` dismissed as noise. Next: re-run review or continue to `wize-tea-review` (Hawkeye).

package/src/method-skills/module.yaml

@@ -97,9 +97,28 @@ 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-market-research
+    name: "Market Research"
+    description: "Competition and customer research for the product brief and PRD."
+  - code: wize-domain-research
+    name: "Domain Research"
+    description: "Industry, regulatory, and technical-trend research."
+  - code: wize-technical-research
+    name: "Technical Research"
+    description: "Technology, architecture, and implementation-pattern research."
+  - 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."
+
 # Phase directories (declarative discovery for the installer):
 phases:
   - "1-analysis"
   - "2-plan-workflows"
   - "3-solutioning"
   - "4-implementation"
+