wize-dev-kit 0.4.1 → 0.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +49 -0
- package/package.json +1 -1
- package/src/core-skills/wize-customize/skill.md +114 -0
- package/src/core-skills/wize-editorial-review-prose/skill.md +92 -0
- package/src/core-skills/wize-editorial-review-structure/skill.md +97 -0
- package/src/core-skills/wize-index-docs/skill.md +117 -0
- package/src/core-skills/wize-review-edge-case-hunter/skill.md +112 -0
- package/src/method-skills/2-plan-workflows/wize-edit-prd/workflow.md +108 -0
- package/src/method-skills/3-solutioning/wize-project-context/workflow.md +118 -0
- package/src/method-skills/4-implementation/wize-checkpoint-preview/workflow.md +115 -0
- package/src/method-skills/4-implementation/wize-correct-course/workflow.md +89 -0
- package/src/method-skills/4-implementation/wize-investigate/workflow.md +121 -0
- package/src/method-skills/4-implementation/wize-sprint-planning/workflow.md +58 -71
- package/src/method-skills/4-implementation/wize-sprint-status/workflow.md +29 -82
- package/src/orchestrator-skills/wize-onboarding/workflow.md +76 -14
- package/src/security-overlay/_shared/allowlist.js +154 -0
- package/src/security-overlay/_shared/cli-runner.js +87 -0
- package/src/security-overlay/_shared/cvss.js +108 -0
- package/src/security-overlay/_shared/detect.js +125 -0
- package/src/security-overlay/_shared/install-script.js +205 -0
- package/src/security-overlay/_shared/invoke-phase.js +86 -0
- package/src/security-overlay/_shared/owasp.js +56 -0
- package/src/security-overlay/_shared/partial.js +225 -0
- package/src/security-overlay/_shared/preflight.js +175 -0
- package/src/security-overlay/_shared/scope-gate.js +172 -0
- package/src/security-overlay/_shared/scope-parser.js +120 -0
- package/src/security-overlay/agents/red-teamer/agent.yaml +51 -0
- package/src/security-overlay/agents/red-teamer/persona.md +43 -0
- package/src/security-overlay/data/common.txt +115 -0
- package/src/security-overlay/data/owasp-top10.json +15 -0
- package/src/security-overlay/data/tool-allowlist.json +31 -0
- package/src/security-overlay/skills/wize-sec-enumerate/scripts/run-enumerate.js +180 -0
- package/src/security-overlay/skills/wize-sec-enumerate/skill.md +32 -0
- package/src/security-overlay/skills/wize-sec-exploit/data/common.txt +117 -0
- package/src/security-overlay/skills/wize-sec-exploit/scripts/run-ffuf.js +147 -0
- package/src/security-overlay/skills/wize-sec-exploit/scripts/run-nikto.js +145 -0
- package/src/security-overlay/skills/wize-sec-exploit/scripts/run-nuclei.js +176 -0
- package/src/security-overlay/skills/wize-sec-exploit/scripts/run-sqlmap.js +139 -0
- package/src/security-overlay/skills/wize-sec-pentest/scripts/run-pipeline.js +157 -0
- package/src/security-overlay/skills/wize-sec-pentest/skill.md +52 -0
- package/src/security-overlay/skills/wize-sec-recon/scripts/run-gitleaks.js +139 -0
- package/src/security-overlay/skills/wize-sec-recon/scripts/run-osv.js +227 -0
- package/src/security-overlay/skills/wize-sec-recon/scripts/run-recon.js +162 -0
- package/src/security-overlay/skills/wize-sec-recon/skill.md +35 -0
- package/src/security-overlay/skills/wize-sec-report/scripts/render-report.js +999 -0
- package/src/tea-skills/wize-qa-generate-e2e-tests/workflow.md +119 -0
- package/tools/installer/onboarding.js +1 -0
- package/tools/installer/render-shared.js +50 -3
- package/tools/installer/wize-cli.js +72 -5
package/CHANGELOG.md
CHANGED
|
@@ -5,6 +5,55 @@ Format inspired by [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
|
|
|
5
5
|
|
|
6
6
|
## [Unreleased]
|
|
7
7
|
|
|
8
|
+
## [0.6.0] — 2026-06-20
|
|
9
|
+
|
|
10
|
+
### Added
|
|
11
|
+
|
|
12
|
+
- **`security-overlay` — AI Pentester (novo profile opcional).** Pipeline file-first de pentest que roda no harness do usuário (zero runtime próprio, zero dependência npm nova). Selecionável no instalador como `security-overlay`.
|
|
13
|
+
- **Persona `red-teamer`** + orquestradora `wize-sec-pentest` que encadeia recon → enumerate → SAST → DAST → report.
|
|
14
|
+
- **Gate de escopo** (`.wize/security/scope.md`, allowlist assinada com SHA-256): toda ação ofensiva é verificada por fase; alvo fora do escopo é recusado e auditado em `.refusals.log`. Default passivo; exploit ativo só com `--active`.
|
|
15
|
+
- **Allowlist de flags por ferramenta** (`data/tool-allowlist.json`): `--dump`/`--os-shell` e afins nunca chegam ao `execFile`, independente do input.
|
|
16
|
+
- **SAST**: secrets via gitleaks (com redação `***REDACTED***`) + dependências vulneráveis via osv-scanner/grype (CVE + CVSS).
|
|
17
|
+
- **DAST**: nuclei, nikto (safe checks), sqlmap e ffuf (content discovery), gated por `--active` quando ofensivos.
|
|
18
|
+
- **CVSS v3.1** zero-dep + tagger **OWASP Top 10 (2021)**.
|
|
19
|
+
- **Relatório** `report.md` + `report.html` self-contained (CSS inline, offline, WCAG 2.2 AA): risk score 0–100, briefing executivo, plano de ação P0/P1/P2, cobertura honesta do teste (audit confidence), recomendação por finding.
|
|
20
|
+
- **AI insights**: o renderer consome `ai-insights.json` escrito pelo LLM do harness (briefing + recomendações), sem chamada externa — dados ficam locais.
|
|
21
|
+
- **Preflight** (Epic 08): detecta SO/arch/package-manager e gera `install-pentest-tools.sh` com a fonte correta por ferramenta (apt para nmap/nikto/sqlmap; GitHub release para gitleaks/nuclei/ffuf/osv-scanner; script oficial para grype).
|
|
22
|
+
- Documentação completa do overlay em `.wize/planning` e `.wize/solutioning` (brief, PRD, tech-vision, NFR, architecture, 4 ADRs, 8 epics, 26+ stories).
|
|
23
|
+
|
|
24
|
+
## [0.5.0] — 2026-06-17
|
|
25
|
+
|
|
26
|
+
### Added
|
|
27
|
+
|
|
28
|
+
- **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.
|
|
29
|
+
- **`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`.
|
|
30
|
+
- **`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.
|
|
31
|
+
- **`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.
|
|
32
|
+
- **`wize-checkpoint-preview`** (4-implementation) — pause mid-story to validate direction. Records snapshot + decision in `checkpoints/{story_id}.md`.
|
|
33
|
+
- **`wize-investigate`** (4-implementation) — structured RCA: frame, reproduce, hypothesize (top 3), verify, conclude. Report in `investigations/{date}-{slug}.md`.
|
|
34
|
+
- **`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`.
|
|
35
|
+
- **`wize-review-edge-case-hunter`** (core) — focused edge-case pass. 4 areas (input, state, time/race, integration) with top-5 P0 ranking.
|
|
36
|
+
- **`wize-index-docs`** (core) — rebuilds `.wize/knowledge/index.md` from the actual tree, 5 sections.
|
|
37
|
+
- **`wize-editorial-review-prose` + `wize-editorial-review-structure`** (core) — Peggy Carter's review skills. Voice/jargon/hedging/pronouns; missing/misordered/heading-level/empty.
|
|
38
|
+
- **`wize-customize`** (core) — guided override of built-in agents/skills/workflows via `.wize/custom/{type}/{code}/customize.toml`.
|
|
39
|
+
- Sprint tracking: `.wize/implementation/sprint-status.yaml` (YAML state machine) plus human-readable `.wize/implementation/sprint-status.md`. 4 sprints closed (S1–S4).
|
|
40
|
+
- Backlog: `.wize/implementation/backlog.md` with prioritized list of missing agile workflows.
|
|
41
|
+
- TEA risk profile: 17 risks catalogued, all HIGH-impact mitigated.
|
|
42
|
+
|
|
43
|
+
### Changed
|
|
44
|
+
|
|
45
|
+
- **`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.
|
|
46
|
+
- 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.
|
|
47
|
+
|
|
48
|
+
### Fixed
|
|
49
|
+
|
|
50
|
+
- 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.
|
|
51
|
+
- 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.
|
|
52
|
+
|
|
53
|
+
### Tests
|
|
54
|
+
|
|
55
|
+
- 233 passing (was 222). New: 4 Anthropic-family companion-file tests + 1 sprint-planning hand-off regression test.
|
|
56
|
+
|
|
8
57
|
## [0.4.1] — 2026-06-13
|
|
9
58
|
|
|
10
59
|
### Fixed
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"$schema": "https://json.schemastore.org/package.json",
|
|
3
3
|
"name": "wize-dev-kit",
|
|
4
|
-
"version": "0.
|
|
4
|
+
"version": "0.6.0",
|
|
5
5
|
"description": "Full-lifecycle AI-assisted development kit with Test Architect and Whiteport Design Studio embedded. Inspired by BMAD Method and WDS.",
|
|
6
6
|
"keywords": [
|
|
7
7
|
"ai",
|
|
@@ -0,0 +1,114 @@
|
|
|
1
|
+
---
|
|
2
|
+
code: wize-customize
|
|
3
|
+
name: Customize
|
|
4
|
+
module: core
|
|
5
|
+
status: ready
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Customize
|
|
9
|
+
|
|
10
|
+
**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.
|
|
11
|
+
|
|
12
|
+
Wizer drives. Tony on call for agent structure.
|
|
13
|
+
|
|
14
|
+
## When to use
|
|
15
|
+
|
|
16
|
+
- "Override the persona of `wize-agent-pm`."
|
|
17
|
+
- "Customize the wording in `wize-product-brief`."
|
|
18
|
+
- "Add a tool to `wize-orchestrator`."
|
|
19
|
+
|
|
20
|
+
## When NOT to use
|
|
21
|
+
|
|
22
|
+
- Creating a brand-new agent/skill/workflow → use `wize-create-agent` (or `wize-create-skill` / `wize-create-workflow`).
|
|
23
|
+
- Updating built-ins directly (the kit does not support forking built-ins; the next update would clobber your changes).
|
|
24
|
+
|
|
25
|
+
## Inputs
|
|
26
|
+
|
|
27
|
+
- A target: agent code, skill code, or workflow code.
|
|
28
|
+
- A scope: what to override (name, title, persona, tools, body).
|
|
29
|
+
|
|
30
|
+
## Output
|
|
31
|
+
|
|
32
|
+
- A new file at `.wize/custom/{type}/{code}/customize.toml` (or update of an existing one).
|
|
33
|
+
- A re-run of `wize-dev-kit sync` to apply the override.
|
|
34
|
+
|
|
35
|
+
## Steps
|
|
36
|
+
|
|
37
|
+
### 1. Identify the target
|
|
38
|
+
|
|
39
|
+
The user names the code (e.g., `wize-agent-pm`). The skill validates:
|
|
40
|
+
|
|
41
|
+
- Code shape: `wize-{kind}-{slug}`.
|
|
42
|
+
- Exists in the kit's built-in roster.
|
|
43
|
+
|
|
44
|
+
If the target does not exist, suggest `wize-create-agent` instead.
|
|
45
|
+
|
|
46
|
+
### 2. Inspect the existing override
|
|
47
|
+
|
|
48
|
+
If `.wize/custom/{type}/{code}/customize.toml` exists, read it. The user is updating; otherwise creating.
|
|
49
|
+
|
|
50
|
+
### 3. Ask what to change
|
|
51
|
+
|
|
52
|
+
The skill asks the user to pick from the overrideable fields:
|
|
53
|
+
|
|
54
|
+
- `name` (display name)
|
|
55
|
+
- `title` (job title)
|
|
56
|
+
- `persona` (markdown body)
|
|
57
|
+
- `tools` (list of tool names the agent can call)
|
|
58
|
+
- `icon` (emoji)
|
|
59
|
+
|
|
60
|
+
One field per run. Re-run for additional fields.
|
|
61
|
+
|
|
62
|
+
### 4. Generate the customize.toml
|
|
63
|
+
|
|
64
|
+
Write the new (or merged) customize.toml. Keep the structure as comments so the user can see the template.
|
|
65
|
+
|
|
66
|
+
```toml
|
|
67
|
+
# Override for {code} — generated by /wize-customize
|
|
68
|
+
# Re-running the skill merges; lines you delete are restored on next install.
|
|
69
|
+
|
|
70
|
+
[persona]
|
|
71
|
+
# name = "Your name here"
|
|
72
|
+
# title = "Your title here"
|
|
73
|
+
|
|
74
|
+
[tools]
|
|
75
|
+
# Add tool names the agent can call. Empty = default set.
|
|
76
|
+
# tools = []
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
### 5. Re-sync
|
|
80
|
+
|
|
81
|
+
Run `wize-dev-kit sync` (or instruct the user to). The override is loaded by the adapter and emitted to the IDE targets.
|
|
82
|
+
|
|
83
|
+
### 6. Hand off
|
|
84
|
+
|
|
85
|
+
Notify the user of:
|
|
86
|
+
|
|
87
|
+
- File written: `.wize/custom/{type}/{code}/customize.toml`.
|
|
88
|
+
- Sync completed (or instructions to run it).
|
|
89
|
+
- Where to verify the override (e.g., `.claude/skills/{code}/SKILL.md`).
|
|
90
|
+
|
|
91
|
+
## Output template
|
|
92
|
+
|
|
93
|
+
The skill does not write a markdown output; it writes the customize.toml and re-syncs.
|
|
94
|
+
|
|
95
|
+
```toml
|
|
96
|
+
# Override for wize-agent-pm — generated by /wize-customize
|
|
97
|
+
|
|
98
|
+
[persona]
|
|
99
|
+
name = "Hill" # shortened from "Maria Hill"
|
|
100
|
+
|
|
101
|
+
[tools]
|
|
102
|
+
# tools = [] # default set
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
## Anti-patterns Wizer rejects
|
|
106
|
+
|
|
107
|
+
- Suggesting direct edits to built-in files in `node_modules/wize-dev-kit/`. (Next update clobbers.)
|
|
108
|
+
- Creating a customize.toml with no overrideable fields filled. (Empty = no-op.)
|
|
109
|
+
- Auto-running `wize-dev-kit sync` silently. (Confirm with the user first.)
|
|
110
|
+
- Customizing the same field twice in one run. (One field per run.)
|
|
111
|
+
|
|
112
|
+
## Hand-off
|
|
113
|
+
|
|
114
|
+
> "Override written at `.wize/custom/{type}/{code}/customize.toml`. Sync applied. Verify in `.claude/skills/{code}/SKILL.md` (or your IDE target)."
|
|
@@ -0,0 +1,92 @@
|
|
|
1
|
+
---
|
|
2
|
+
code: wize-editorial-review-prose
|
|
3
|
+
name: Editorial Review — Prose
|
|
4
|
+
module: core
|
|
5
|
+
status: ready
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Editorial Review — Prose
|
|
9
|
+
|
|
10
|
+
**Goal.** Catch prose drift in Wize artifacts (brief, PRD, ADR, gate, story, retrospective). Peggy Carter runs the review; the user applies the fixes.
|
|
11
|
+
|
|
12
|
+
Peggy drives. Wizer is on call for the call to action ("rewrite the whole section" or "leave it").
|
|
13
|
+
|
|
14
|
+
## When to use
|
|
15
|
+
|
|
16
|
+
- "Review the prose in this PRD."
|
|
17
|
+
- "Find jargon and hedging in the brief."
|
|
18
|
+
- "Is this gate file clear?"
|
|
19
|
+
|
|
20
|
+
## When NOT to use
|
|
21
|
+
|
|
22
|
+
- Spelling/grammar (use a linter; out of scope here).
|
|
23
|
+
- Structure (missing sections, wrong ordering) → use `wize-editorial-review-structure`.
|
|
24
|
+
- Tone change (tone is intentional; leave it).
|
|
25
|
+
|
|
26
|
+
## Inputs
|
|
27
|
+
|
|
28
|
+
- A markdown file under `.wize/`.
|
|
29
|
+
- A line range (optional; default = whole file).
|
|
30
|
+
|
|
31
|
+
## Output
|
|
32
|
+
|
|
33
|
+
- A markdown review with line-level findings, each tagged with severity (nit / suggest / recommend).
|
|
34
|
+
|
|
35
|
+
## Steps
|
|
36
|
+
|
|
37
|
+
### 1. Read
|
|
38
|
+
|
|
39
|
+
Read the file (or line range). Skip code blocks. Skip frontmatter.
|
|
40
|
+
|
|
41
|
+
### 2. Hunt (4 areas)
|
|
42
|
+
|
|
43
|
+
- **Voice.** Active voice preferred. Flag passive constructions ("was decided by", "is being implemented").
|
|
44
|
+
- **Jargon.** Acronyms not defined on first use. Discipline-specific terms (e.g., "JTBD", "NFR") that are not in the project glossary.
|
|
45
|
+
- **Hedging.** Softeners that hide commitment: "might", "could possibly", "we should consider", "it would be nice". Suggest a stronger verb.
|
|
46
|
+
- **Pronouns.** Ambiguous "this", "it", "they" without a clear referent. Suggest a specific noun.
|
|
47
|
+
|
|
48
|
+
### 3. Rank
|
|
49
|
+
|
|
50
|
+
Per finding:
|
|
51
|
+
|
|
52
|
+
- **Nit** — minor; user can ignore.
|
|
53
|
+
- **Suggest** — worth a 5-second fix.
|
|
54
|
+
- **Recommend** — blocks the artifact's clarity; should be fixed.
|
|
55
|
+
|
|
56
|
+
### 4. Hand off
|
|
57
|
+
|
|
58
|
+
Output is a markdown list. The user applies or rejects each finding. Peggy does not auto-edit.
|
|
59
|
+
|
|
60
|
+
## Output template
|
|
61
|
+
|
|
62
|
+
```markdown
|
|
63
|
+
---
|
|
64
|
+
date: 2026-06-17
|
|
65
|
+
file: planning/prd.md
|
|
66
|
+
author: Peggy
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
# Prose review — prd.md
|
|
70
|
+
|
|
71
|
+
## Recommendations
|
|
72
|
+
- L42: "we should consider using a token bucket" → "we use a token bucket". Hedging hides the decision. **[recommend]**
|
|
73
|
+
- L78: "this might affect the user" → "this affects new signups". Pronoun + hedging. **[recommend]**
|
|
74
|
+
|
|
75
|
+
## Suggests
|
|
76
|
+
- L15: "rate-limit" appears 4 times. First use: spell out "rate-limit (per-IP cap on request rate)". **[suggest]**
|
|
77
|
+
- L23: passive "is implemented by" → active "we implement". **[suggest]**
|
|
78
|
+
|
|
79
|
+
## Nits
|
|
80
|
+
- L88: comma splice. **[nit]**
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
## Anti-patterns Peggy rejects
|
|
84
|
+
|
|
85
|
+
- Auto-editing the source file. (Suggest; never write.)
|
|
86
|
+
- Commenting on tone or style preference. (Tone is intentional; structure is a separate review.)
|
|
87
|
+
- Marking everything as recommend. (Cap at 5 recommends per review.)
|
|
88
|
+
- Reviewing code blocks. (Out of scope.)
|
|
89
|
+
|
|
90
|
+
## Hand-off
|
|
91
|
+
|
|
92
|
+
> "Prose review complete for `{file}`. {N} findings. {M} recommends, {K} suggests, {L} nits. Apply or reject per finding."
|
|
@@ -0,0 +1,97 @@
|
|
|
1
|
+
---
|
|
2
|
+
code: wize-editorial-review-structure
|
|
3
|
+
name: Editorial Review — Structure
|
|
4
|
+
module: core
|
|
5
|
+
status: ready
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Editorial Review — Structure
|
|
9
|
+
|
|
10
|
+
**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.
|
|
11
|
+
|
|
12
|
+
Peggy drives. Tony on call for architecture artifacts; Maria Hill for PRD; Hawkeye for gates.
|
|
13
|
+
|
|
14
|
+
## When to use
|
|
15
|
+
|
|
16
|
+
- "Review the structure of this PRD."
|
|
17
|
+
- "Is this ADR complete?"
|
|
18
|
+
- "Does this gate file have all required sections?"
|
|
19
|
+
|
|
20
|
+
## When NOT to use
|
|
21
|
+
|
|
22
|
+
- Prose quality → use `wize-editorial-review-prose`.
|
|
23
|
+
- Content correctness (does the AC actually hold?) → use `wize-tea-review` or `wize-validate-prd`.
|
|
24
|
+
|
|
25
|
+
## Inputs
|
|
26
|
+
|
|
27
|
+
- A markdown file under `.wize/`.
|
|
28
|
+
- (Optional) the artifact type (PRD, ADR, gate, story, brief) — auto-detected from path.
|
|
29
|
+
|
|
30
|
+
## Output
|
|
31
|
+
|
|
32
|
+
- A markdown review with section-level findings (missing, misordered, mistyped).
|
|
33
|
+
|
|
34
|
+
## Steps
|
|
35
|
+
|
|
36
|
+
### 1. Detect
|
|
37
|
+
|
|
38
|
+
Infer the artifact type from the path:
|
|
39
|
+
|
|
40
|
+
| Path | Type |
|
|
41
|
+
|---|---|
|
|
42
|
+
| `planning/brief.md` | brief |
|
|
43
|
+
| `planning/prd.md` | prd |
|
|
44
|
+
| `solutioning/adrs/ADR-*.md` | adr |
|
|
45
|
+
| `solutioning/architecture.md` | architecture |
|
|
46
|
+
| `implementation/tea/{epic}/{story}/gate.md` | gate |
|
|
47
|
+
| `solutioning/stories/*/*.md` | story |
|
|
48
|
+
| `solutioning/epics/*/*.md` | epic |
|
|
49
|
+
|
|
50
|
+
### 2. Check against the template
|
|
51
|
+
|
|
52
|
+
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.
|
|
53
|
+
|
|
54
|
+
### 3. Hunt (4 areas)
|
|
55
|
+
|
|
56
|
+
- **Missing sections.** Required H2 not present.
|
|
57
|
+
- **Misordered sections.** H2 present but in wrong order relative to the template.
|
|
58
|
+
- **Inconsistent heading levels.** H3 used where H2 is expected (or vice versa).
|
|
59
|
+
- **Empty sections.** H2 with no content (a heading and nothing else).
|
|
60
|
+
|
|
61
|
+
### 4. Hand off
|
|
62
|
+
|
|
63
|
+
Output is a markdown list with section-level findings. Severity: **must-fix** (missing) / **should-fix** (misordered) / **nit** (heading level).
|
|
64
|
+
|
|
65
|
+
## Output template
|
|
66
|
+
|
|
67
|
+
```markdown
|
|
68
|
+
---
|
|
69
|
+
date: 2026-06-17
|
|
70
|
+
file: planning/prd.md
|
|
71
|
+
type: prd
|
|
72
|
+
author: Peggy
|
|
73
|
+
---
|
|
74
|
+
|
|
75
|
+
# Structure review — prd.md (PRD)
|
|
76
|
+
|
|
77
|
+
## Must-fix
|
|
78
|
+
- Missing H2: "Out of scope".
|
|
79
|
+
- Missing H2: "Open questions".
|
|
80
|
+
|
|
81
|
+
## Should-fix
|
|
82
|
+
- H2 "Success criteria" appears after "Non-goals"; should be before (per template).
|
|
83
|
+
|
|
84
|
+
## Nits
|
|
85
|
+
- H3 used in "Constraints" where H4 would match the rest of the doc.
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
## Anti-patterns Peggy rejects
|
|
89
|
+
|
|
90
|
+
- Suggesting a different section order than the template. (The template is the source of truth.)
|
|
91
|
+
- Reviewing prose. (Use the prose skill.)
|
|
92
|
+
- Marking optional sections (e.g., "Glossary" in PRD) as missing.
|
|
93
|
+
- Auto-rewriting the file. (Suggest; never write.)
|
|
94
|
+
|
|
95
|
+
## Hand-off
|
|
96
|
+
|
|
97
|
+
> "Structure review complete for `{file}` ({type}). {M} must-fix, {K} should-fix, {L} nits. Apply or reject per finding."
|
|
@@ -0,0 +1,117 @@
|
|
|
1
|
+
---
|
|
2
|
+
code: wize-index-docs
|
|
3
|
+
name: Index Docs
|
|
4
|
+
module: core
|
|
5
|
+
status: ready
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Index Docs
|
|
9
|
+
|
|
10
|
+
**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.
|
|
11
|
+
|
|
12
|
+
Wizer drives. Peggy polishes the one-line descriptions on the second pass.
|
|
13
|
+
|
|
14
|
+
## When to run
|
|
15
|
+
|
|
16
|
+
- After any major artifact is created or moved.
|
|
17
|
+
- Before sprint planning (to confirm what exists).
|
|
18
|
+
- When onboarding a new team member.
|
|
19
|
+
|
|
20
|
+
## When NOT to run
|
|
21
|
+
|
|
22
|
+
- Inside an IDE target folder (`.claude/`, `.cursor/`, etc.) — out of scope.
|
|
23
|
+
- As a CI step on every commit (too noisy; manual).
|
|
24
|
+
|
|
25
|
+
## Inputs
|
|
26
|
+
|
|
27
|
+
- The `.wize/` tree (read-only scan).
|
|
28
|
+
- A user message: "Rebuild the index" or similar.
|
|
29
|
+
|
|
30
|
+
## Output
|
|
31
|
+
|
|
32
|
+
- `.wize/knowledge/index.md` with sections: Planning, Solutioning, Implementation, Knowledge, Custom.
|
|
33
|
+
|
|
34
|
+
## Steps
|
|
35
|
+
|
|
36
|
+
### 1. Scan
|
|
37
|
+
|
|
38
|
+
Walk `.wize/` recursively. Skip hidden directories (`.DS_Store` etc.). For each file:
|
|
39
|
+
|
|
40
|
+
- Read its YAML frontmatter.
|
|
41
|
+
- If `description` is present, use it.
|
|
42
|
+
- Else use the first `# Heading` line.
|
|
43
|
+
- Else use the file name (kebab-case to title case).
|
|
44
|
+
|
|
45
|
+
### 2. Group
|
|
46
|
+
|
|
47
|
+
Sort into 5 sections by file path:
|
|
48
|
+
|
|
49
|
+
| Section | Path prefix |
|
|
50
|
+
|---|---|
|
|
51
|
+
| Planning | `.wize/planning/` |
|
|
52
|
+
| Solutioning | `.wize/solutioning/` |
|
|
53
|
+
| Implementation | `.wize/implementation/` |
|
|
54
|
+
| Knowledge | `.wize/knowledge/` (excluding the index file itself) |
|
|
55
|
+
| Custom | `.wize/custom/` |
|
|
56
|
+
|
|
57
|
+
### 3. Write
|
|
58
|
+
|
|
59
|
+
Generate `.wize/knowledge/index.md` with:
|
|
60
|
+
|
|
61
|
+
- YAML frontmatter (`generated`, `last_updated`, `total_files`).
|
|
62
|
+
- One H2 per section.
|
|
63
|
+
- One bullet per file: `- [{title}]({relative_path}) — {one-line description}`.
|
|
64
|
+
- A footer with the total file count and the timestamp.
|
|
65
|
+
|
|
66
|
+
If a section is empty, omit the heading.
|
|
67
|
+
|
|
68
|
+
### 4. Hand off
|
|
69
|
+
|
|
70
|
+
Output is the index file. The user can review and adjust manually if the one-liners are stale. Re-run to overwrite.
|
|
71
|
+
|
|
72
|
+
## Output template
|
|
73
|
+
|
|
74
|
+
```markdown
|
|
75
|
+
---
|
|
76
|
+
generated: 2026-06-17
|
|
77
|
+
last_updated: 2026-06-17
|
|
78
|
+
total_files: 24
|
|
79
|
+
---
|
|
80
|
+
|
|
81
|
+
# Wize artifacts index
|
|
82
|
+
|
|
83
|
+
## Planning (5)
|
|
84
|
+
- [Brief — site-qwize](planning/brief.md) — Pepper's one-pager for the site.
|
|
85
|
+
- [PRD — site-qwize](planning/prd.md) — Maria Hill's PRD for v1.
|
|
86
|
+
- [Trigger map](planning/trigger-map.md) — WDS user-psychology map.
|
|
87
|
+
- [UX scenarios](planning/ux/ux-scenarios.md) — Mantis's 8-question dialog.
|
|
88
|
+
- [Tech vision](planning/tech-vision.md) — Fury's stack pick.
|
|
89
|
+
|
|
90
|
+
## Solutioning (4)
|
|
91
|
+
- [Architecture](solutioning/architecture.md) — Tony's 8-step architecture.
|
|
92
|
+
- [ADR-001](solutioning/adrs/ADR-001-...) — ...
|
|
93
|
+
...
|
|
94
|
+
|
|
95
|
+
## Implementation (8)
|
|
96
|
+
- [Sprint 1 status](implementation/sprint-status.md) — closed.
|
|
97
|
+
- [Risk profile](implementation/tea/risk-profile.md) — 13 risks mitigated.
|
|
98
|
+
...
|
|
99
|
+
|
|
100
|
+
## Knowledge (6)
|
|
101
|
+
- [Document project overview](knowledge/document-project/overview.md) — ...
|
|
102
|
+
...
|
|
103
|
+
|
|
104
|
+
## Custom (1)
|
|
105
|
+
- [Agent: runbooks](custom/agents/wize-agent-runbooks/agent.yaml) — ...
|
|
106
|
+
```
|
|
107
|
+
|
|
108
|
+
## Anti-patterns Wizer rejects
|
|
109
|
+
|
|
110
|
+
- Including IDE target folders (`.claude/`, `.cursor/`, `.kimi/`, etc.) in the index.
|
|
111
|
+
- Dumping file contents (just the description + link).
|
|
112
|
+
- Auto-running on every commit (manual or scheduled only).
|
|
113
|
+
- Mixing in files outside `.wize/`.
|
|
114
|
+
|
|
115
|
+
## Hand-off
|
|
116
|
+
|
|
117
|
+
> "Index rebuilt at `.wize/knowledge/index.md`. {N} files indexed across 5 sections. Next: `/wize-help` reads this file when answering."
|
|
@@ -0,0 +1,112 @@
|
|
|
1
|
+
---
|
|
2
|
+
code: wize-review-edge-case-hunter
|
|
3
|
+
name: Edge Case Hunter
|
|
4
|
+
module: core
|
|
5
|
+
status: ready
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Edge Case Hunter
|
|
9
|
+
|
|
10
|
+
**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.
|
|
11
|
+
|
|
12
|
+
Shuri runs the hunt. Hawkeye on call for test design. Wizer on call for cross-cutting risk.
|
|
13
|
+
|
|
14
|
+
## When to use
|
|
15
|
+
|
|
16
|
+
- "Hunt edge cases in this PR."
|
|
17
|
+
- "What can break in this code?"
|
|
18
|
+
- "Give me the edge case list before I refactor."
|
|
19
|
+
|
|
20
|
+
## When NOT to use
|
|
21
|
+
|
|
22
|
+
- Full adversarial code review → use `wize-code-review`.
|
|
23
|
+
- Generate E2E test cases → use `wize-qa-generate-e2e-tests`.
|
|
24
|
+
- Quick-dev fix → use `wize-quick-dev`.
|
|
25
|
+
|
|
26
|
+
## Inputs
|
|
27
|
+
|
|
28
|
+
- A code change (diff, file, or story reference).
|
|
29
|
+
- A short scope statement (one sentence: what is this code trying to do?).
|
|
30
|
+
- Optional: the relevant story file (`.wize/solutioning/stories/{epic}/{story}.md`).
|
|
31
|
+
|
|
32
|
+
## Output
|
|
33
|
+
|
|
34
|
+
- A markdown list of edge cases, grouped by category, with line-level `file:line` references when possible.
|
|
35
|
+
- Suggested action per case: write a test, add a guard, accept, or defer.
|
|
36
|
+
|
|
37
|
+
## Steps
|
|
38
|
+
|
|
39
|
+
### 1. Scope
|
|
40
|
+
|
|
41
|
+
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.
|
|
42
|
+
|
|
43
|
+
### 2. Hunt (per area)
|
|
44
|
+
|
|
45
|
+
Walk 4 areas in order:
|
|
46
|
+
|
|
47
|
+
- **Input edges.** Empty, null, unicode, max length, malformed, wrong type, wrong encoding. Boundary values (0, 1, max, max+1).
|
|
48
|
+
- **State edges.** Concurrent writes, stale reads, missing state, mixed state (some fields set, others not), partial failure.
|
|
49
|
+
- **Time / race.** Timeouts, retries, clock skew, ordering, idempotency.
|
|
50
|
+
- **Integration edges.** Vendor down, slow vendor, malformed vendor response, network partition, version skew.
|
|
51
|
+
|
|
52
|
+
For each area, list specific cases in 1 line each. Cite `file:line` when relevant.
|
|
53
|
+
|
|
54
|
+
### 3. Rank
|
|
55
|
+
|
|
56
|
+
For each case, score:
|
|
57
|
+
|
|
58
|
+
- **Likelihood** (low / medium / high): probability of triggering.
|
|
59
|
+
- **Impact** (low / medium / high): what happens when it triggers.
|
|
60
|
+
|
|
61
|
+
Order cases by `(likelihood + impact)`. The top 5 are P0; the rest P1/P2.
|
|
62
|
+
|
|
63
|
+
### 4. Hand off
|
|
64
|
+
|
|
65
|
+
For each P0 case, propose an action:
|
|
66
|
+
|
|
67
|
+
- **Test** → the user adds a test.
|
|
68
|
+
- **Guard** → the user adds input validation or a defensive check.
|
|
69
|
+
- **Accept** → the user documents the risk and moves on.
|
|
70
|
+
- **Defer** → the user opens a follow-up story.
|
|
71
|
+
|
|
72
|
+
Output is a markdown table. The user picks what to apply.
|
|
73
|
+
|
|
74
|
+
## Output template
|
|
75
|
+
|
|
76
|
+
```markdown
|
|
77
|
+
---
|
|
78
|
+
date: 2026-06-17
|
|
79
|
+
scope: "Refactor of validateInviteEmail — split into 3 helpers"
|
|
80
|
+
author: Shuri
|
|
81
|
+
---
|
|
82
|
+
|
|
83
|
+
# Edge cases — {scope}
|
|
84
|
+
|
|
85
|
+
## Top 5 (P0)
|
|
86
|
+
|
|
87
|
+
| # | Case | Likelihood | Impact | Action | Location |
|
|
88
|
+
|---|---|---|---|---|---|
|
|
89
|
+
| 1 | Empty email string | high | medium | test | src/validate.ts:42 |
|
|
90
|
+
| 2 | Email with leading/trailing whitespace | high | low | guard | src/validate.ts:55 |
|
|
91
|
+
| 3 | Email with internationalized TLD (e.g. .中国) | medium | medium | test | src/validate.ts:48 |
|
|
92
|
+
| 4 | Email longer than 254 chars | low | medium | guard | src/validate.ts:48 |
|
|
93
|
+
| 5 | Null vs undefined | high | low | test | src/validate.ts:33 |
|
|
94
|
+
|
|
95
|
+
## Other (P1/P2)
|
|
96
|
+
|
|
97
|
+
- Unicode normalization mismatch — P1 — test
|
|
98
|
+
- Two plus signs in local part — P2 — accept
|
|
99
|
+
- Trailing dot in domain — P2 — defer (open E06-S05)
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
## Anti-patterns Shuri rejects
|
|
103
|
+
|
|
104
|
+
- Listing 50 cases per area. (Top 5 P0; cap at 15 total.)
|
|
105
|
+
- Auto-fixing (hunt, don't fix).
|
|
106
|
+
- Skipping the rank step. (Without rank, the user cannot prioritize.)
|
|
107
|
+
- Skipping the action per case. (An edge case without an action is just noise.)
|
|
108
|
+
- Hunting only one area (e.g., only input). (All 4 areas.)
|
|
109
|
+
|
|
110
|
+
## Hand-off
|
|
111
|
+
|
|
112
|
+
> "Edge case hunt complete. {N} cases ranked. P0: {M}. Next: implement P0 (Shuri) or open follow-up stories (Hill)."
|