prizmkit 1.1.100 → 1.1.102

package/bundled/skills-windows/prizmkit-prizm-docs/references/op-status.md

@@ -1,14 +0,0 @@
-# Operation: Status — Detailed Steps
-
-Check freshness of all .prizm docs.
-
-PRECONDITION: .prizmkit/prizm-docs/ exists with root.prizm.
-
-STEPS:
-1. Get last git modification time of root.prizm via `git log -1 --format="%ai" -- .prizmkit/prizm-docs/root.prizm`.
-2. Count commits since that time via `git log --since="<timestamp>" --oneline | wc -l`.
-3. For each L1/L2 doc, compare git modification time of the .prizm file (`git log -1 --format="%ai" -- <prizm-file>`) against latest git modification of source files in that module (`git log -1 --format="%ai" -- <module-path>/`).
-4. Classify each doc as: FRESH (prizm file updated after latest source change), STALE (source changed more recently than prizm file), MISSING (module exists but no .prizm doc).
-5. Flag any docs exceeding size limits.
-
-OUTPUT: Freshness report table with columns: DOC_PATH | LEVEL | STATUS | PRIZM_LAST_MOD | SOURCE_LAST_MOD.

package/bundled/skills-windows/prizmkit-prizm-docs/references/op-update.md

@@ -1,19 +0,0 @@
-# Operation: Update — Detailed Steps
-
-Update .prizmkit/prizm-docs/ to reflect recent code changes.
-
-PRECONDITION: .prizmkit/prizm-docs/ exists with root.prizm.
-
-STEPS:
-1. Get changed files via `git diff --cached --name-status`. If nothing staged, use `git diff --name-status`. If no git changes at all, do full rescan comparing code against existing docs — this includes checking for modules that have source files but no L2 doc.
-2. Map changed files to modules by matching against MODULE_INDEX or MODULE_GROUPS in root.prizm. Group changes by module.
-3. Classify each change: A (added) -> new KEY_FILES entries. D (deleted) -> remove entries, update counts. M (modified) -> check dependency changes. R (renamed) -> update all path references.
-4. Update affected docs: L2 first (KEY_FILES, INTERFACES, DATA_FLOW, DEPENDENCIES, TRAPS, DECISIONS), then L1 (FILES count, KEY_FILES, DEPENDENCIES — L1 does NOT contain INTERFACES/DATA_FLOW/TRAPS/DECISIONS), then L0 (MODULE_INDEX or MODULE_GROUPS counts, CROSS_CUTTING) only if structural change. Do not write CHANGELOG sections/files, UPDATED/date metadata, feature/bug/refactor/task/session/run/pipeline/workflow IDs, branch names, absolute worktree paths, or `.prizmkit/specs` / `.prizmkit/dev-pipeline` artifact paths — git tracks history. **Preserve** any `PROJECT_BRIEF:` line in root.prizm — it is managed by prizmkit-init, not by this skill.
-5. Skip updates if: only internal implementation changed (no interface/dependency change), only comments/whitespace/formatting, only .prizm files changed. DO NOT skip test file changes or bug fixes — they may reveal TRAPS worth capturing in L2.
-6. If new directory qualifies as a module (per MODULE_DISCOVERY_CRITERIA) and matches no existing module: create L1 immediately, add to MODULE_INDEX. If the current diff includes Added or Modified source files in this module → also create L2 immediately with sections: MODULE, FILES, RESPONSIBILITY, INTERFACES, DATA_FLOW, KEY_FILES, DEPENDENCIES, RULES, TRAPS, DECISIONS. Otherwise defer L2.
-6a. **L2 gap check** (runs during full rescan mode only — when no git changes detected): For each existing module in MODULE_INDEX, check if L2 doc exists. If L2 is missing and the module has source files with meaningful logic (not trivial config/wrapper) → create L2 with sections: MODULE, FILES, RESPONSIBILITY, INTERFACES, DATA_FLOW, KEY_FILES, DEPENDENCIES, RULES, TRAPS, DECISIONS. This ensures Update fills documentation gaps left by previous sessions.
-7. Enforce size limits: L0 > 4KB -> consolidate. L1 > 4KB -> trim KEY_FILES descriptions, ensure RULES <= 3 entries. L2 > 5KB -> trim non-essential derived detail or split oversized cross-cutting detail.
-7a. Validate memory hygiene: no CHANGELOG/UPDATED fields, no workflow metadata, no L1 behavioral sections.
-8. Stage updated .prizm files via `git add .prizmkit/prizm-docs/`
-
-OUTPUT: List of updated/created/skipped docs with reasons.

package/bundled/skills-windows/prizmkit-prizm-docs/references/op-validate.md

@@ -1,17 +0,0 @@
-# Operation: Validate — Detailed Steps
-
-Check format compliance and consistency of all .prizm docs.
-
-PRECONDITION: .prizmkit/prizm-docs/ exists.
-
-STEPS:
-1. FORMAT CHECK: Verify all .prizm files use KEY: value format. Flag any prose paragraphs, code blocks (```), markdown headers (##), emoji, ASCII art, or horizontal rules. Flag TRAPS entries missing severity prefix ([CRITICAL], [HIGH], or [LOW]). Flag CHANGELOG sections/files, UPDATED/date metadata, feature/bug/refactor/task/session/run/pipeline/workflow IDs, branch names, absolute worktree paths, and `.prizmkit/specs` / `.prizmkit/dev-pipeline` artifact paths as auxiliary noise. Note: [REVIEW] preceding severity (e.g., `[REVIEW][HIGH]`) is a valid temporary staleness marker, not a format violation.
-2. SIZE CHECK: Verify size limits: L0 <= 4KB, L1 <= 4KB, L2 <= 5KB. Report files exceeding limits with current size.
-3. POINTER CHECK: Verify all arrow (->) references resolve to existing .prizm files. Report broken pointers.
-4. STALENESS CHECK: Compare git modification time of each .prizm file against source directory. Flag docs where source was modified more recently.
-5. COMPLETENESS CHECK: Verify root.prizm has all required fields (PRIZM_VERSION, PROJECT, LANG, MODULE_INDEX or MODULE_GROUPS). Verify L1 docs have MODULE, FILES, RESPONSIBILITY, DEPENDENCIES (no INTERFACES/TRAPS/DECISIONS). Verify L2 docs have MODULE, FILES, KEY_FILES, DEPENDENCIES, INTERFACES, TRAPS.
-6. ANTI-PATTERN CHECK: Flag duplicate information across levels, implementation details in L0/L1, TODO items, session-specific context, changelog/history sections, and workflow metadata.
-7. RULES HIERARCHY CHECK: Verify L1/L2 RULES do not contradict root.prizm RULES. L1/L2 may only supplement with module-specific exceptions.
-8. TRAPS STALENESS CHECK: For each L2 doc where TRAPS section has more than 8 entries, verify that TRAPS include staleness metadata (`STALE_IF:` or `REF:` fields). Flag TRAPS without any staleness metadata as `NEEDS_METADATA` — these are not auto-removed, but flagged for the next `/prizmkit-retrospective` to enrich with `STALE_IF:` globs or `REF:` hashes.
-
-OUTPUT: Validation report with PASS/FAIL per check, list of issues with file paths and suggested fixes.

package/bundled/skills-windows/prizmkit-retrospective/SKILL.md

@@ -1,87 +0,0 @@
----
-name: "prizmkit-retrospective"
-description: "Incremental .prizmkit/prizm-docs/ maintainer. Performs two jobs: (1) structural sync — update .prizmkit/prizm-docs/ KEY_FILES/INTERFACES/DEPENDENCIES, (2) architecture knowledge — inject TRAPS/RULES/DECISIONS into .prizmkit/prizm-docs/. All project knowledge lives in .prizmkit/prizm-docs/ . Run after code review passes and before committing. Trigger on: 'retrospective', 'retro', 'update docs', 'sync docs', 'wrap up', 'done with feature', 'feature complete'. (project)"
----
-
-# PrizmKit Retrospective
-
-| Store | Location | Content | Purpose |
-|-------|----------|---------|---------|
-| **Architecture Index** | `.prizmkit/prizm-docs/` | MODULE, FILES, INTERFACES, DEPENDENCIES, TRAPS, RULES, DECISIONS | AI quickly locates code structure, interfaces, known pitfalls, and key design decisions |
-
-**This skill handles both structural sync and knowledge injection in one pass:**
-
-1. **Structural Sync** — reflect what changed in code → `.prizmkit/prizm-docs/` (KEY_FILES, INTERFACES, DEPENDENCIES, file counts)
-2. **Architecture Knowledge** — inject TRAPS, RULES, and DECISIONS → `.prizmkit/prizm-docs/`
-
-For initial doc setup, validation, or migration, use `/prizmkit-prizm-docs` instead.
-
-## When to Use
-
-- **Before every commit** (mandatory in pipeline) — ensures docs and code are in sync
-- After completing a feature, refactoring, or bug fix
-- After code review passes
-- User says "retrospective", "retro", "update docs", "sync docs", "wrap up"
-
-## Input
-
-| Parameter | Required | Description |
-|-----------|----------|-------------|
-| `artifact_dir` | No | Directory containing spec.md, plan.md, review-report.md. If omitted, scan `.prizmkit/` subdirectories for the most recently modified directory with a `plan.md`. When invoked as a handoff step, reuse the caller's `artifact_dir` rather than re-detecting. If no artifact directory found, run in standalone mode (structural sync only from `git diff`). |
-
-## When NOT to Use
-
-- Only comments, whitespace, or formatting changed — no structural/knowledge change
-- Only test files changed — no module-level impact
-- Only .prizm files changed — avoid circular updates
-
----
-
-### Job 1: Structural Sync (always runs)
-Synchronize `.prizmkit/prizm-docs/` structure with actual codebase changes from this session.
-→ Read `${SKILL_DIR}/references/structural-sync-steps.md` for the detailed procedure.
-
-**Key outputs**: Synced L1 file counts, L2 INTERFACES/DATA_FLOW, DEPENDENCIES, and stale TRAPS cleanup.
-
-**Memory hygiene**: `.prizmkit/prizm-docs/` must not contain CHANGELOG sections/files, UPDATED/date metadata, feature/bug/refactor/task/session/run/pipeline/workflow IDs, branch names, absolute worktree paths, or `.prizmkit/specs` / `.prizmkit/dev-pipeline` artifact paths. Convert artifact-scoped wording into durable product/domain language before writing.
-
----
-
-### Job 2: Knowledge Injection (conditional)
-Inject newly discovered project knowledge (TRAPS, RULES, DECISIONS) into architecture docs.
-→ Read `${SKILL_DIR}/references/knowledge-injection-steps.md` for the detailed procedure.
-
-**Review gate**: Before running Job 2, check `review-report.md` in the artifact directory for the `## Verdict:` line:
-- Verdict is `PASS` → proceed
-- Verdict is `NEEDS_FIXES` → **skip Job 2** — do not inject knowledge for code that hasn't passed review. Output warning: "Review report has unresolved findings. Skipping knowledge injection."
-- No `review-report.md` found → proceed with warning
-- No artifact directory (standalone mode) → skip Job 2, only Job 1 runs
-
-**Skip for**: pure refactors (no behavioral change).
-
-**Bug Fix Documentation Policy**:
-- DEFAULT for bug fixes: Run Job 1 (structural sync) only. Skip Job 2 (knowledge injection).
-- RUN Job 2 when the bug fix causes any of:
-  • Interface signature changes
-  • Dependency additions/removals
-  • Observable behavior changes to existing features
-  • Newly discovered TRAPs (gotchas/pitfalls)
-- When any of the above apply, run full retrospective (Job 1 + Job 2).
-
-**Key outputs**: New TRAPS entries, RULES updates, DECISIONS records in relevant L1/L2 docs and root.prizm.
-
----
-
-## Final: Stage
-
-**3a.** Stage all doc changes:
-```powershell
-git add .prizmkit/prizm-docs/
-```
-
-**HANDOFF:** `/prizmkit-committer`
-
-## Output
-
-- `.prizmkit/prizm-docs/*.prizm` — Structurally synced + TRAPS/RULES/DECISIONS enriched
-- All `.prizmkit/prizm-docs/` changes staged via `git add`

package/bundled/skills-windows/prizmkit-retrospective/references/knowledge-injection-steps.md

@@ -1,50 +0,0 @@
-# Knowledge Injection — Detailed Steps (2a–2c)
-
-**2a.** Gather context — read the **actual code that was changed** plus any available artifacts:
-
-- `git diff HEAD` — the real source of truth for what happened
-- `review-report.md` in the artifact directory — read the findings and fix instructions. If this file exists, use it as a source for pre-categorized decisions and findings.
-- `plan.md` in the artifact directory — read planned vs actual
-- Any companion documents in the artifact directory (e.g., `refactor-analysis.md`, `fix-report.md`) — read what was discovered
-- The relevant `.prizmkit/prizm-docs/` L1/L2 docs for affected modules
-
-**2b.** Extract knowledge from what was **observed in code**, not invented:
-
-**TRAPS** (highest priority) — things that look safe but break:
-- Minimal format: `- [SEVERITY] <description> | FIX: <approach>`
-- Full format: `- [SEVERITY] <description> | FIX: <approach> | REF: <hash> | STALE_IF: <glob>`
-- Source: actual bugs hit, surprising behavior discovered in code, non-obvious coupling
-
-**TRAPS severity classification**:
-- `[CRITICAL]`: data loss, security, financial error, system crash
-- `[HIGH]`: functional failure, silent error, interface incompatibility
-- `[LOW]`: misleading naming, non-intuitive API, minor performance issue
-
-When writing TRAPS:
-- Severity prefix is MANDATORY (e.g., `[CRITICAL]`, `[HIGH]`, `[LOW]`)
-- OPTIONAL: append `| REF: <7-char-hash>` when you know the relevant commit (for traceability)
-- OPTIONAL: append `| STALE_IF: <glob>` when the TRAP is tightly coupled to specific files (for auto-expiry detection)
-
-**Consuming [REVIEW] markers** (from staleness check 1g):
-- If you encounter a TRAP prefixed with `[REVIEW]` (e.g., `[REVIEW][HIGH] ...`), verify whether the trap is still valid by checking the current code. If still valid: remove the `[REVIEW]` prefix, keeping the severity. If no longer relevant: delete the TRAP entry.
-
-**RULES** — conventions established or constraints discovered:
-- Format: `- MUST/NEVER/PREFER: <rule>`
-- Source: patterns that proved necessary during implementation
-
-**DECISIONS** — key design choices that affect future development:
-- Format: `- <what was decided> — <rationale>`
-- Source: non-obvious design choices, interface conventions, cross-module contracts
-- Only record decisions that a future AI session would benefit from knowing
-- Do NOT record obvious implementation details that can be derived by reading the code
-
-**QUALITY GATE**: Every item must answer: "If a new AI session reads only `.prizmkit/prizm-docs/` and this entry, does it gain actionable understanding?" If not, discard. Do not record trivially observable code patterns — the AI can read the code directly.
-
-**MEMORY HYGIENE GATE**: Before writing any `.prizmkit/prizm-docs/` entry, remove or translate workflow metadata. Never write CHANGELOG sections/files, UPDATED/date metadata, feature/bug/refactor/task/session/run/pipeline/workflow IDs, branch names, absolute worktree paths, or `.prizmkit/specs` / `.prizmkit/dev-pipeline` artifact paths. If source artifacts say "fixed in B-001" or "implemented in F-003", write only the durable product/domain fact.
-
-**2c.** Inject into the correct `.prizmkit/prizm-docs/` file:
-- Module-level TRAPS/RULES/DECISIONS → the affected **L2** `.prizm` file. If the target L2 does not exist, create it first using the L2 GENERATION TEMPLATE before injecting knowledge. (TRAPS/DECISIONS/RULES belong in L2, not L1.)
-- Project-level RULES/PATTERNS → `root.prizm` (respect the current format — MODULE_INDEX or MODULE_GROUPS — do not convert between them during injection)
-- Cross-module concerns spanning 2+ modules → `root.prizm` CROSS_CUTTING section
-
-**RULE**: Only add genuinely new information. Never duplicate existing entries. Never rewrite entire files.

package/bundled/skills-windows/prizmkit-retrospective/references/structural-sync-steps.md

@@ -1,43 +0,0 @@
-# Structural Sync — Detailed Steps
-
-**1a.** Get changed files (staged + unstaged vs HEAD):
-```powershell
-git diff HEAD --name-status
-```
-
-**1b.** Read `.prizmkit/prizm-docs/root.prizm` to get MODULE_INDEX (or MODULE_GROUPS). Map each changed file to its module.
-
-**1c.** Classify changes:
-- `A` (added) → add to KEY_FILES, check for new INTERFACES
-- `D` (deleted) → remove from KEY_FILES, update FILE count
-- `M` (modified) → check if public interfaces or dependencies changed
-- `R` (renamed) → update all path references
-
-**1d.** Update affected docs (bottom-up: L2 → L1 → L0):
-
-- **L2**: If L2 exists → update **only the sections affected by the diff files in this module**. For example, if only `api.js` changed: update its KEY_FILES entry, its INTERFACES (if exports changed), its DEPENDENCIES (if imports changed). Do NOT re-scan unchanged files in the module. If L2 does NOT exist AND the module has Added or Modified source files in the current diff with meaningful logic (not trivial config) → create L2 with these sections: MODULE, FILES, RESPONSIBILITY, INTERFACES, DATA_FLOW, KEY_FILES, DEPENDENCIES, RULES, TRAPS, DECISIONS. Populate **only from the diff files** (the Added/Modified files in this module from step 1a), not from the entire module directory.
-- **L1**: Update FILES count, KEY_FILES (if major files added/removed), DEPENDENCIES (if module-level deps changed). **L1 does NOT contain INTERFACES, DATA_FLOW, TRAPS, or DECISIONS** — those belong in L2 only.
-- **L0 root.prizm**: Update MODULE_INDEX file counts only if counts changed. Update CROSS_CUTTING if cross-module concerns changed. Update only if structural change (module added/removed). **Preserve** any `PROJECT_BRIEF:` line — it is managed by prizmkit-init.
-
-**Memory hygiene**: During L0/L1/L2 updates, do not write CHANGELOG sections/files, UPDATED/date metadata, feature/bug/refactor/task/session/run/pipeline/workflow IDs, branch names, absolute worktree paths, or `.prizmkit/specs` / `.prizmkit/dev-pipeline` artifact paths. Update durable sections in place; git history is the change log.
-
-**1e.** If new directory qualifies as a module and matches no existing module:
-- A directory qualifies as a module if any of: contains source files forming a logical unit, contains entry/config/interface files, contains qualifying sub-modules, or is referenced by multiple modules as dependency.
-- Create L1 doc immediately, add to MODULE_INDEX.
-- If the current diff includes Added or Modified source files with meaningful logic → create L2 immediately. Otherwise defer L2.
-
-**1f.** Enforce size limits:
-- L0 > 4KB → if using MODULE_INDEX with > 15 entries, convert to MODULE_GROUPS format (group by functional domain). Otherwise, consolidate MODULE_INDEX descriptions.
-- L1 > 4KB → trim KEY_FILES descriptions, ensure RULES <= 3 entries
-- L2 > 5KB → trim non-essential detail, split oversized cross-cutting detail, or move derived context back to source references
-
-**SKIP structural sync if**: only internal implementation changed (no interface/dependency impact), only comments/whitespace, only .prizm files. **DO NOT skip** test file changes or bug fixes — they may reveal TRAPS worth capturing in L2.
-
-**1g. TRAPS staleness check** (only when an L2 doc's TRAPS section has > 10 entries):
-
-Perform a quick staleness scan on existing TRAPS to prevent unbounded accumulation:
-1. If a TRAP has `STALE_IF:` and the glob-matched files no longer exist (verified via `ls`) → delete the TRAP entry
-2. If a TRAP has `REF:` → check if the referenced file still exists and the REF commit is less than 180 days old (via `git log --since="180 days ago" <hash> 2>$null`). If the file is deleted OR the REF commit is older than 180 days → prepend `[REVIEW]` to the severity, signaling it needs verification during the next retrospective Job 2
-3. Process at most 5 of the oldest TRAPS per L2 doc per session (to bound context cost)
-
-This step is lightweight — it only triggers when TRAPS exceed 10 entries, and processes at most 5 per run.

package/bundled/skills-windows/prizmkit-test/SKILL.md

@@ -1,227 +0,0 @@
----
-name: "prizmkit-test"
-description: "Full-stack test generation and orchestration. Detects architecture, discovers/runs existing tests, analyzes coverage gaps, generates missing unit/integration/E2E tests including business-specific boundary cases, validates every interface with a required boundary coverage matrix, and outputs a unified report. Use after completing development to verify quality before deploy. Trigger on: 'test', 'run tests', 'check quality', 'verify code', 'generate tests', 'test coverage', 'fill test gaps', 'boundary tests', 'edge cases', 'quality check', 'add tests'. (project)"
----
-
-# PrizmKit Test
-
-A comprehensive test generation and orchestration skill. Discovers existing tests, runs them, compares coverage against spec acceptance criteria and module interfaces, generates missing tests at three levels (unit → integration → E2E), verifies business-specific boundary coverage for every in-scope interface, and produces a unified report.
-
-### When to Use
-- After completing one or more features/refactors/bugfixes
-- As a quality gate before deploy
-- Project has a test framework installed but zero tests written (first-time test generation)
-- User says "test", "run tests", "verify", "check quality", "add tests"
-
-### When NOT to Use
-- Project has no test framework AND no code to test
-- Trivial single-line config changes
-
-## Precondition
-
-| Required State | Check | If Missing |
-|---|---|---|
-| `.prizmkit/prizm-docs/root.prizm` exists | File exists | Run `/prizmkit-init` first |
-| Test framework installed | Dependency in package.json or equivalent | Offer to skip or let user install one manually |
-
-If `.prizmkit/prizm-docs/` exists but may be stale (no retrospective run after recent changes), warn user: "Prizm docs may be out of date. Gap analysis accuracy depends on current docs. Continue anyway?"
-
-## Context Loading
-
-Before execution, load context once:
-
-1. **Architecture context**: Read `.prizmkit/prizm-docs/root.prizm` (L0 — project overview, module index, tech stack, conventions) and relevant L1 docs for modules in scope. If scope includes specific modules, also load relevant L2 docs for INTERFACES, DATA_FLOW, TRAPS, and DECISIONS.
-2. **Project config**: Read `.prizmkit/config.json` (tech stack, AI CLI config).
-3. **Dependencies**: Read `package.json` or equivalent to detect test framework and project type.
-
-For `scope=this-change`, load only:
-- `.prizmkit/prizm-docs/root.prizm`
-- relevant L1/L2 docs inferred from in-scope changed files
-- `artifact_dir/spec.md`
-- `artifact_dir/plan.md`
-- `artifact_dir/context-snapshot.md` if present
-- `artifact_dir/review-report.md` if present
-- changed source files and directly related existing tests
-
-Do not load all modules or all specs merely because they exist.
-
-## Input
-
-| Parameter | Required | Description |
-|-----------|----------|-------------|
-| `scope` | No | `full-project`, `module:<name>`, `feature:<slug>`, or `this-change`. In headless mode, defaults to `this-change` only when `artifact_dir` points to `.prizmkit/specs/<FEATURE_SLUG>/`; otherwise defaults to full project. |
-| `artifact_dir` | No | Feature artifact directory. For `scope=this-change`, must be `.prizmkit/specs/<FEATURE_SLUG>/`. Do not infer this-change scope from `.prizmkit/bugfix/` or `.prizmkit/refactor/`. |
-| `diff_base` | No | Git ref used to compute changed files for this feature. |
-| `changed_files` | No | Explicit caller-provided changed file list. Takes precedence over `diff_base`. |
-| `generation_policy` | No | Defaults to `in-scope-only` for `scope=this-change`. Out-of-scope gaps are reported but not generated. |
-
-## Execution
-
-### Phase 0: Architecture Detection
-
-1. From context already loaded, classify project type:
-
-| Signal | Classification |
-|--------|---------------|
-| react/vue/angular/next in deps, no backend framework | Frontend |
-| express/fastify/django/flask in deps, no frontend framework | Backend |
-| Both present | Fullstack |
-| Neither clear | Ask user (headless: mark as "unknown", skip E2E) |
-
-2. Detect test framework by scanning dependencies:
-   - Jest → `npx jest` or `npm test`
-   - Vitest → `npx vitest run`
-   - pytest → `python -m pytest`
-   - Go testing → `go test ./...`
-   - Multiple frameworks found → use the one with the most test files; list all in report
-   - Custom `npm test` script → use `npm test`
-
-3. **Interactive mode**: Show "Detected: {type}, test framework: {name}. Correct?"
-   **Headless mode**: Auto-proceed with detected values, note assumptions in report.
-
-### Phase 1: Scope Selection
-
-**Interactive mode** — present three options:
-
-1. **Full project** — all modules, all specs in `.prizmkit/specs/`
-2. **Single module** — pick from L1 doc module names (e.g., "auth", "payment")
-3. **Single feature** — pick from `.prizmkit/specs/###-*/` directories
-
-**Headless mode**:
-1. If `scope=this-change`, require `artifact_dir=.prizmkit/specs/<FEATURE_SLUG>/` and run in feature-scoped mode.
-2. If `artifact_dir=.prizmkit/specs/<FEATURE_SLUG>/` is provided without `scope`, treat it as `scope=this-change`.
-3. If `scope=full-project` is explicitly provided, run full-project mode even if an artifact directory exists.
-4. If `artifact_dir` points to `.prizmkit/bugfix/` or `.prizmkit/refactor/`, do not infer `scope=this-change`.
-5. If neither `scope` nor feature `artifact_dir` is provided, default to full project.
-
-`scope=this-change` is feature-only. It is valid only when `artifact_dir` is under `.prizmkit/specs/<FEATURE_SLUG>/`. Do not automatically apply `scope=this-change` to `.prizmkit/bugfix/<BUG_ID>/` or `.prizmkit/refactor/<REFACTOR_ID>/`. If the caller passes `scope=this-change` with a bugfix/refactor artifact directory, stop and report that this mode is unsupported for that artifact type. Bugfix and refactor workflows keep their existing reproduction-test and behavior-preservation test gates.
-
-### Phase 2: Run Existing Tests
-
-1. Find test directories matching common patterns: `tests/`, `__tests__/`, `*.test.*`, `*.spec.*`. If no test files exist at all, note this and skip to Phase 3 (all coverage is "missing").
-
-2. Run the detected test command in scope. Capture:
-   - Pass/fail counts and failed test details
-   - Which test files exist (for gap analysis)
-   - Raw output (saved to report directory)
-
-3. Classify existing test failures before continuing:
-   - For `scope=this-change`, failures in changed tests, tests mapped to in-scope source files, or tests directly covering feature acceptance criteria are `In-Scope Failures` unless a captured pre-feature baseline proves they already failed before this feature.
-   - For `scope=this-change`, unrelated failures are `Baseline Failures`; record them without failing the scoped verdict.
-   - For other scopes, record failures as existing test failures and do not assume they are caused by this test-generation pass.
-
-4. If `scope=this-change` has any unexplained `In-Scope Failures`, the final report verdict must be `NEEDS_FIXES` or `BLOCKED`, not `PASS`. Do not hide them as baseline failures.
-
-### Phase 3: Coverage Gap Analysis
-
-Staleness of `.prizmkit/prizm-docs/` was already checked during Context Loading (see Precondition). Gap analysis proceeds with the available data.
-
-For `scope=this-change`:
-
-1. Build the in-scope source set using this priority:
-   - `changed_files` parameter
-   - `git diff --name-only <diff_base>`
-   - files/tasks listed in `artifact_dir/plan.md`
-   - File Manifest in `artifact_dir/context-snapshot.md`
-   - direct file/module mapping from `artifact_dir/spec.md` acceptance criteria
-2. Build the in-scope test set:
-   - tests already changed in this feature
-   - tests matching in-scope source files by project naming convention
-   - directly affected integration/E2E tests for feature acceptance criteria
-3. Analyze only:
-   - changed/new public interfaces
-   - feature acceptance criteria from `artifact_dir/spec.md`
-   - integration boundaries directly affected by in-scope files
-   - UI/E2E flows directly affected by this feature
-4. For unrelated historical gaps, record them under `Out of Scope Gaps`; do not generate tests and do not fail the feature verdict because of them.
-
-For other scopes, compare what exists against what should exist, across three levels:
-
-**Unit test gaps** — for each module in scope:
-- Read the corresponding L2 `.prizm` doc INTERFACES section to get exported functions/classes. If no L2 doc exists for a module, analyze source files directly to identify exported functions/classes.
-- Check if each has a corresponding test file (match project's test naming: `foo.test.ts`, `foo.spec.ts`, `test_foo.py`)
-- Flag uncovered interfaces
-
-**Integration test gaps** (skip if project has no API/DB layer — pure library/CLI tool):
-- Read L1 doc DEPENDENCIES section for cross-module interactions
-- Check if tests exist covering module boundaries, API endpoints, DB operations
-- Flag missing integration coverage
-
-**E2E test gaps** (skip if project has no UI):
-- Collect acceptance criteria from all spec.md files in scope
-- Check existing E2E test files against these criteria
-- Flag uncovered criteria
-
-### Phase 4: Boundary Coverage Matrix
-
-Phase 3 answers "which interfaces are missing tests?" Phase 4 answers "which business boundaries are missing for each interface?" Build this matrix before generating tests so the run does not mistake broad happy-path coverage for real safety coverage.
-
-A path, method, function, or class is not considered covered merely because a happy-path test exists; happy path proves the interface works once, while boundary tests prove it behaves safely under realistic invalid, unauthorized, edge, and failure states.
-
-Read `${SKILL_DIR}/references/boundary-coverage-protocol.md` for the required matrix format, category definitions, and completion gate. For every in-scope interface and API endpoint, classify applicable categories such as request validation, auth/permission/ownership, domain invariants, collection/pagination, date/time boundaries, state transitions, dependency failures, and response contract checks. In `scope=this-change`, build this matrix only for the in-scope feature interfaces/endpoints; unrelated interfaces belong in `Out of Scope Gaps`.
-
-For each category, mark one of:
-- `covered` — an existing test already asserts the boundary behavior
-- `generated` — this run generated and passed the test
-- `needs-review` — a valid generated test found behavior mismatch
-- `skipped` — not applicable, with a concrete reason
-
-If an interface has only happy-path coverage, mark it `boundary-missing` and generate applicable boundary tests in Phase 5. Do not mark happy-path-only coverage as `covered`.
-
-### Phase 5: Generate Missing and Boundary Tests
-
-Read `${SKILL_DIR}/references/test-generation-steps.md` for the detailed generation procedure — boundary-matrix-driven workflow, priority order (unit → integration → E2E), failure handling rules, and generation patterns for each test level.
-
-When generating unit tests for service-like functions or API/integration tests for endpoints with business-specific behavior, use `${SKILL_DIR}/references/service-boundary-test-catalog.md` via the generation procedure so boundary cases reflect the interface's business responsibility, not only generic null/empty inputs.
-
-For `scope=this-change`:
-- Generate or update tests only for the in-scope source/test set.
-- Check for equivalent existing tests before writing new tests.
-- Do not create tests for unrelated modules just because coverage is missing.
-- Do not refactor unrelated tests.
-- Do not modify unrelated production code.
-- Do not expand to full-project coverage unless the user explicitly requested `scope=full-project`.
-- Generated tests must assert real behavior, boundaries, or integration contracts; do not add empty assertions or mock-success-only tests.
-
-### Phase 6: Unified Report and Boundary Validation
-
-Create `.prizmkit/test/{YYYY_MM_DD_HH_MM_SS}_testresult/` directory. Read `${SKILL_DIR}/references/test-report-template.md` for the full report format and artifact list.
-
-For `scope=this-change`, the report must include:
-- `## Scope` with mode, artifact dir, diff base, changed-files source, generation policy, in-scope source files, and in-scope test files
-- `## Existing Tests Run`
-- `## Generated / Updated Tests`
-- `## In-Scope Failures`
-- `## Baseline Failures`
-- `## Out of Scope Gaps`
-- `## Verdict` with `PASS`, `NEEDS_FIXES`, or `BLOCKED`
-
-`Out of Scope Gaps` are informational only for `scope=this-change`: they must not trigger generated tests and must not fail the verdict.
-
-After writing the report, run the deterministic boundary-report validator when the project has an OpenAPI file or the report contains a Boundary Matrix:
-
-```bash
-python3 ${SKILL_DIR}/scripts/validate_boundary_report.py \
-  --report .prizmkit/test/{timestamp}_testresult/test-report.md \
-  --openapi openapi.yaml
-```
-
-If the project has no OpenAPI file, omit `--openapi`. If validation fails, keep the report but do not claim the run is complete; report that tests may pass while boundary coverage remains incomplete.
-
-## Output
-
-- Test report: `.prizmkit/test/{timestamp}_testresult/test-report.md`
-- Generated test files written to project test directories
-- Existing test output, generated test copies, E2E artifacts, and boundary validation output in the report directory
-
-## Recovery
-
-If the session is interrupted:
-- Check `.prizmkit/test/` for the most recent report directory — it contains what was completed before interruption
-- Re-run `/prizmkit-test` — it starts fresh, but Phase 2 will skip tests that already pass, and Phase 3/4 will re-evaluate gaps and boundary coverage
-
-## Examples
-
-Read `${SKILL_DIR}/references/examples.md` for worked examples of full-project, single-feature, and happy-path-only remediation runs.
-
-**HANDOFF:** Independent skill — no handoff. User may proceed to `/prizmkit-committer` only if tests pass and the boundary completion gate passes. If tests are marked `needs-review` or boundary validation fails, fix issues manually or run another targeted `/prizmkit-test` pass.