wize-dev-kit 0.14.0 → 0.16.0

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

@@ -1,99 +0,0 @@
----
-
-code: wize-editorial-review-structure
-description: "Use quando um artefato Wize precisar de revisão estrutural — seções obrigatórias, ordenação e níveis de heading."
-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-grill/skill.md

@@ -1,77 +0,0 @@
----
-
-code: wize-grill
-description: "Use quando uma demanda chegar vaga e precisar de entrevista exaustiva para alcançar entendimento compartilhado antes de produzir qualquer artefato."
-name: Grill
-module: core
-status: ready
----
-
-# Grill
-
-**Goal.** Interview the user exhaustively about a demand until both sides reach **shared understanding** — before any artifact is drafted. Sharper answers make a sharper brief, PRD, epic, story, or plan. Grill is an input-quality tool, not an artifact of its own.
-
-Any persona about to author an artifact can invoke it: Pepper before a brief, Maria Hill before a PRD, Tony before epics/stories/architecture, Wizer when a demand arrives fuzzy. Wizer also **suggests** it from `/wize` (or `/wize-help`) — always suggest, never force.
-
-## The five rules
-
-1. **One question at a time.** Ask, then wait for the answer. A batch of questions is bewildering and produces shallow answers.
-2. **Every question ships with a recommendation.** State your recommended answer and a one-line reason. The user confirms or corrects — far cheaper than answering from scratch.
-3. **Facts are looked up; decisions are asked.** If the answer lives in the repo, `.wize/`, or the environment (stack, existing behavior, conventions, prior artifacts), fetch it — never ask. Only genuine decisions — trade-offs, priorities, scope calls — go to the user.
-4. **Walk the decision tree in dependency order.** Resolve upstream decisions before the downstream ones that depend on them. Don't ask about scope before the problem is agreed.
-5. **No drafting until confirmed.** Close with a compact summary of every decision made and ask for confirmation of shared understanding. Only then hand back to the authoring workflow.
-
-## Question ladder (dependency order)
-
-Climb top-down; **skip any rung an existing artifact already answers** (brief, trigger map, PRD, architecture — check first, rule 3).
-
-| Rung | Resolves | Feeds |
-|---|---|---|
-| 1. Problem | What hurts, for whom, what's the evidence it hurts | Brief vision / story context |
-| 2. Outcome | The observable result that means "solved" — metric, target, deadline | Success criteria / PRD goals |
-| 3. Audience | Primary user (role + JTBD), who else is affected | Brief audience / trigger map |
-| 4. Scope | What's in, what's explicitly out, non-goals | PRD scope table / story restrictions |
-| 5. Constraints | Deadline, budget, compliance, integrations, protected behaviors | Brief constraints / restrictions |
-| 6. Risks & assumptions | What, if wrong, changes the plan | PRD assumptions / risk profile |
-| 7. Validation | How we'll verify — which checks, which ACs, what "done" means | ACs / validation contract |
-
-When an answer comes back vague, apply a technique from `wize-advanced-elicitation` (5 Whys, laddering, premortem) to that one rung before moving on.
-
-## Calibration — how hard to grill
-
-| Demand class | Depth |
-|---|---|
-| **Quick Dev** (bug fix, copy edit, dep bump) | Don't grill. One clarifying question max — grilling a typo fix is theater. |
-| **Full Lifecycle, incremental** (new story in a known epic) | Short pass: rungs 4, 5, 7 only — the upstream rungs live in the PRD. |
-| **Full Lifecycle, new value** (new feature, new product, new plan) | Full ladder. |
-
-Momentum shortcut: after **three consecutive "as you recommend"** answers, switch to batch mode — state the remaining recommendations as one list and ask for a single confirmation. Respect the user's time; the point is clarity, not ceremony.
-
-## Where answers land
-
-Grill produces no separate file. Route each decision to its home:
-
-- **Decisions** → the target artifact's fields (brief sections, PRD scope/ACs, story restrictions/validation contract) — in the artifact's own words, not chat quotes.
-- **Unresolved questions** → the artifact's *Open questions*, each with owner + priority (`blocker` / `important` / `nice-to-know`).
-- **Load-bearing trade-offs** → the artifact's decision log (or `DECISIONS.md` / an ADR when architectural).
-
-## Stop conditions
-
-Stop grilling when **any** of these hits:
-
-- Every relevant rung is resolved or explicitly parked as an open question with an owner.
-- The user says "enough" / "just go" — park the rest as open questions and proceed with your recommendations, flagged as assumptions.
-- The summary is confirmed — shared understanding reached.
-
-## Anti-patterns
-
-- Multiple questions in one message.
-- Asking a fact `grep` or `.wize/` would answer.
-- A question without a recommendation ("So… what do you want?").
-- Grilling a Quick Dev demand.
-- Re-opening a confirmed decision without new information.
-- Continuing to interrogate after confirmation — grill is a phase, not a personality.
-
-## Hand-off
-
-> Shared understanding confirmed: {n} decisions captured, {m} open questions parked with owners. Handing back to {persona} / `{workflow}` to draft the {artifact}.

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

@@ -1,119 +0,0 @@
----
-
-code: wize-index-docs
-description: "Use quando precisar reconstruir o índice da base de conhecimento (.wize/knowledge/index.md) a partir da árvore real de artefatos."
-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` (or `/wize-help`) reads this file when answering."

package/src/core-skills/wize-pre-pr-check/skill.md

@@ -1,134 +0,0 @@
----
-code: wize-pre-pr-check
-name: wize-pre-pr-check
-module: core
-description: "Quando for abrir um Pull Request ou PR leia"
----
-
-# Pre-PR Check
-
-**Goal.** Rodar os checks obrigatórios localmente antes de abrir um PR, falhando cedo e rápido. Evita ciclagem cara de CI no Actions — principalmente lint, format, build e testes rápidos. O objetivo é ser um portão (gate) antes de submeter código.
-
-**Agnóstica de tecnologia.** Não prescreve ferramentas específicas; lê os comandos disponíveis no repositório e executa o que for aplicável.
-
-## When to run
-
-- Imediatamente antes de `git push` para uma branch de PR.
-- Antes de abrir o PR no GitHub/GitLab.
-- Após `git commit` na branch de feature, como sanity check.
-- A qualquer momento durante o desenvolvimento — fail fast.
-
-## When NOT to run
-
-- Quando o CI já está verde e o PR está em revisão (o gate já passou).
-- Quando o repositório não tem scripts/ferramentas de lint/test configurados.
-
-## Operating contract
-
-- **Leia o projeto antes de rodar.** Procura por `package.json`, `composer.json`, `Makefile`, `justfile`, `pyproject.toml`, `Cargo.toml`, etc. para descobrir os comandos de check existentes.
-- **Só execute o que existir.** Se não houver `eslint`, pule o passo de lint. Se não houver `phpstan`, pule o passo de análise estática. Nunca exija uma ferramenta que não esteja configurada no repo.
-- **Pare no primeiro erro.** A menos que o usuário peça `--continue`, um check que falha interrompe a cadeia — corrija antes de continuar.
-- **Não seja um substituto completo do CI.** O CI continua sendo a fonte da verdade para testes de integração, e2e, banco de dados, Docker, etc. Este gate é para checks rápidos e baratos.
-- **Custo zero no Actions.** Tudo roda localmente.
-
-## Inputs
-
-- Estado atual do working tree (staged + unstaged).
-- Arquivos de config do projeto para descobrir comandos.
-
-## Outputs
-
-- Relatório compacto de quais checks passaram/falharam.
-- Se falhou: mensagem de erro + arquivo(s) sugerido(s) para corrigir.
-- Se passou: confirmação pronta para PR.
-
-## Steps
-
-### 1. Detectar stack
-
-Procurar nos arquivos de config do projeto quais ferramentas estão disponíveis:
-
-| Fonte | O que extrair |
-|-------|---------------|
-| `package.json` → `scripts` | `lint`, `format`, `format:check`, `type-check`, `build`, `test`, `test:unit` |
-| `composer.json` → `scripts` | `test`, `phpstan`, `pint`, `phpcs` |
-| `Makefile` / `justfile` | targets `lint`, `format`, `check`, `test` |
-| `pyproject.toml` / `setup.cfg` | `flake8`, `black`, `mypy`, `pytest` |
-| `Cargo.toml` | `cargo check`, `cargo test`, `cargo clippy`, `cargo fmt` |
-| `.github/workflows/*.yml` | steps de `lint`, `format`, `build`, `test` (como referência, não para rodar) |
-
-Heurística de prioridade: scripts do gerenciador de pacote local (`npm run`, `composer run`) > binários diretos (`vendor/bin/pint`) > comandos genéricos (`cargo clippy`).
-
-### 2. Selecionar checks por velocidade
-
-Separar em **rápido** (executa em segundos) e **lento** (minutos):
-
-**Rápido (executar sempre):**
-- Lint (ESLint, PHPStan, Clippy, Ruff, etc.)
-- Format check (Prettier, Pint, Black, rustfmt)
-- Type check (tsc, mypy)
-- Análise estática (PHPStan, Psalm)
-
-**Lento (executar quando houver mudanças relevantes):**
-- Build (Vite, Webpack, Cargo build)
-- Testes unitários (Vitest, Jest, Pest, pytest, `cargo test`)
-- Guard-rails custom (scripts próprios do projeto, ex: `check:orphans`)
-
-**Muito lento (opcional / em dia de merge):**
-- Testes de integração
-- E2E (Playwright, Cypress)
-- Build de Docker
-
-### 3. Rodar o gate
-
-Na ordem: format → lint → type-check → build → testes unitários → guard-rails.
-
-Comandos típicos por stack (detectados em tempo real, não hardcoded):
-
-| Stack | Comandos comuns |
-|-------|-----------------|
-| Node/JS/TS | `npm run format:check`, `npm run lint`, `npm run check:type` (ou `tsc --noEmit`), `npm run build`, `npm run test` |
-| PHP/Laravel | `vendor/bin/pint --test`, `vendor/bin/phpstan analyse`, `php artisan test` |
-| Python | `black --check`, `ruff check`, `mypy`, `pytest` |
-| Rust | `cargo fmt -- --check`, `cargo clippy`, `cargo check`, `cargo test` |
-| Go | `gofmt -l`, `golangci-lint run`, `go test ./...` |
-
-Se um check falhar, pare e reporte. Não prossiga para o próximo.
-
-### 4. Reportar
-
-Formato compacto, uma linha por check:
-
-```
-✓ format:check   (npm run format:check)     — 0.8s
-✓ lint           (vendor/bin/pint --test)   — 2.1s
-✗ phpstan        (vendor/bin/phpstan)       — 4.5s → FAIL
-  app/Http/Controllers/LegalController.php:11 — FQCN não importado
-→ Corrija antes de abrir o PR.
-```
-
-Se tudo passar:
-
-```
-✓ format:check   — PASS  (0.8s)
-✓ lint           — PASS  (2.1s)
-✓ phpstan        — PASS  (4.5s)
-✓ build          — PASS  (32s)
-✓ test:unit      — PASS  (30s)
-─────────────────────────────
-Gate limpo. Pode abrir o PR.
-```
-
-## Anti-patterns
-
-- **Rodar checks que não existem no repo.** Se não há `composer.json`, não tente `vendor/bin/pint`.
-- **Ignorar falhas de lint.** Lint fail = PR fail. Corrija antes.
-- **Executar E2E localmente toda vez.** E2E é caro; deixe para o CI ou rode antes de merge.
-- **Substituir o CI.** Este gate é complementar, não substituto.
-
-## Hand-off
-
-> Gate `wize-pre-pr-check` concluído. `{passados}/{total}` checks passaram. `{tempo_total}s`. Pronto para PR.
-
-Se houve falha:
-> Gate `wize-pre-pr-check` interrompido em `{check_falho}`. Corrija e re-execute antes de abrir o PR.

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

@@ -1,115 +0,0 @@
----
-
-code: wize-review-edge-case-hunter
-description: "Use quando um código ou PR precisar de caça sistemática de edge cases ranqueados por probabilidade × impacto."
-name: Edge Case Hunter
-module: core
-status: ready
-subtask: true
----
-
-# 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/core-skills/wize-spec/assets/headless-schemas.md

@@ -1,39 +0,0 @@
-# Headless response schemas for wize-spec
-
-Used when `wize-spec` is invoked non-interactively (headless).
-
-## Create / Update
-
-```json
-{
-  "error_code": null,
-  "spec_path": "{project-root}/.wize/specs/spec-{slug}/SPEC.md",
-  "slug": "{slug}",
-  "capabilities": ["CAP-1", "CAP-2"],
-  "companions": ["glossary.md"],
-  "assumptions": [],
-  "open_questions": [],
-  "verdict": "Coherence: pass. Preservation: pass."
-}
-```
-
-## Error codes
-
-- `missing_slug` — headless caller did not provide a slug and it could not be derived.
-- `insufficient_intent` — no input content provided.
-- `too_sparse` — input too thin to distill; suggest `wize-product-brief` or `wize-create-prd`.
-
-## Validate
-
-```json
-{
-  "error_code": null,
-  "violations": [
-    {
-      "rule": "4",
-      "message": "No explicit non-goals found."
-    }
-  ],
-  "verdict": "Coherence: 1 issue. Preservation: pass."
-}
-```

package/src/core-skills/wize-spec/assets/spec-template.md

@@ -1,40 +0,0 @@
----
-slug: "{{slug}}"
-status: draft
-owner: "{{owner}}"
-companions: []
-sources: []
-assumptions: []
-open_questions: []
----
-
-# SPEC — {{slug}}
-
-## Why
-
-{{One paragraph: what problem this thing exists to solve and for whom.}}
-
-## Capabilities
-
-| ID | Intent | Success |
-|---|---|---|
-| CAP-1 | {{what the system does for the user}} | {{observable outcome that proves it works}} |
-| CAP-2 | … | … |
-
-## Constraints
-
-- {{Constraint that bends a design decision.}}
-- …
-
-## Non-goals
-
-- {{Explicitly out of scope.}}
-- …
-
-## Success signal
-
-{{Concrete, testable or demonstrable signal that the spec is satisfied.}}
-
-## Decision log
-
-See `.decision-log.md`.

package/src/core-skills/wize-spec/customize.toml

@@ -1,20 +0,0 @@
-# Wize Dev Kit — overrides for the built-in skill "wize-spec".
-# DO NOT EDIT in the installed kit; copy to .wize/custom/skills/wize-spec/
-# for project-level overrides.
-
-[workflow]
-
-# Steps to run before standard activation (config load, greet).
-activation_steps_prepend = []
-
-# Steps to run after greet but before the workflow begins.
-activation_steps_append = []
-
-# Persistent facts the skill keeps in mind for the whole run.
-persistent_facts = [
-  "file:{project-root}/.wize/knowledge/document-project/conventions.md",
-]
-
-# Scalar executed when the spec is finalized and the decision-log verdict is written.
-# Override wins. Leave empty for no custom post-completion behavior.
-on_complete = ""