prizmkit 1.1.100 → 1.1.102

package/bundled/skills-windows/prizmkit-init/assets/project-brief-template.md

@@ -1,82 +0,0 @@
-# Project Brief Template
-
-> Capture the user's key product ideas as a simple checklist. Each line is one idea. This file is referenced by `root.prizm` (`PROJECT_BRIEF:`) so every new AI session automatically knows the project's goals.
-
-## File Location
-
-`.prizmkit/plans/project-brief.md`
-
-## Format
-
-```markdown
-# Project Brief
-
-[ ] Core product idea or constraint
-[ ] Another product idea
-[ ] Third idea — one sentence, no sub-bullets
-[x] Already implemented feature -> src/feature/, src/utils/helper.ts
-```
-
-## Rules
-
-1. **First line**: `# Project Brief`
-2. **Remaining lines**: One idea per line, prefixed with `[ ]` (pending) or `[x]` (done)
-3. Each line is **one sentence** — no paragraphs, no sub-bullets, no grouping headers
-4. Language: match the user's language (Chinese or English)
-5. **Size limit**: 500 words max (this file is injected into every session's context window)
-6. **Completion marking** (mandatory): When a brief item is implemented:
-   - Change `[ ]` to `[x]`
-   - Append `->` followed by the **key file or directory paths** that implement it
-   - List the most important 1-3 paths only (entry point, core module, or directory) — not every touched file
-   - Example: `[x] User authentication with OAuth -> src/auth/, src/middleware/auth.ts`
-   - This lets future AI sessions instantly locate the implementation without re-scanning
-
-## Brownfield Init
-
-When initializing an existing project, AI infers the brief from:
-- Generated `root.prizm` (tech stack, module structure)
-- `README.md` (if exists)
-- Package metadata (`package.json` description, `pyproject.toml`, etc.)
-
-Then presents the draft to the user for confirmation and editing.
-
-## Greenfield Init
-
-When initializing a new/empty project, use **progressive questioning** to fully understand the user's intent before generating the brief. Do NOT dump all questions at once — ask in rounds, adapting based on answers.
-
-### Round 1: Problem & Vision (required)
-- What problem does this project solve? (or: what's the core idea?)
-- Who is the target user / audience?
-
-### Round 2: Scope & Features (required)
-- What are the 3-5 core features or capabilities? (ask user to list them)
-- What is the MVP scope? (what's the minimum version that delivers value?)
-- Are there any explicit non-goals? (things this project deliberately does NOT do)
-
-### Round 3: Technical Constraints (if user has preferences)
-- Any preferred tech stack / language / framework?
-- Any integration requirements? (third-party APIs, databases, auth providers)
-- Deployment target? (web app, mobile, CLI, library, self-hosted, cloud)
-
-### Round 4: Clarification (adaptive — only if gaps remain)
-If previous answers are vague or incomplete, probe deeper:
-- "You mentioned X — can you give a concrete example of how a user would use it?"
-- "Are there existing tools that do something similar? How is yours different?"
-- "What does success look like for V1?"
-
-### Completion Criteria
-Stop asking when ALL of these are clear:
-1. **Problem** — what pain point or opportunity this addresses
-2. **Users** — who will use it and in what context
-3. **Core features** — at least 3 concrete capabilities (not vague aspirations)
-4. **Boundaries** — what's in scope vs. out of scope for V1
-5. **Technical direction** — enough to populate `config.json` tech_stack (or explicitly deferred)
-
-If the user gives short/vague answers, don't accept them — rephrase and ask again. A weak brief leads to weak specs downstream.
-
-### Generate & Confirm
-Once all criteria are met:
-1. Generate brief in checklist format (see Format section above)
-2. Present to user with: "Here's what I captured — anything to add, remove, or change?"
-3. Apply edits and write to `.prizmkit/plans/project-brief.md`
-

package/bundled/skills-windows/prizmkit-init/references/config-schema.md

@@ -1,70 +0,0 @@
-# config.json Schema — Tech Stack Fields
-
-## Merge Strategy
-
-Handles re-init without losing user edits:
-
-- Read existing `config.json` if present
-- If `tech_stack` field exists AND `_auto_detected` is `false` or absent:
-  → **SKIP** — user has manually configured tech stack, preserve their settings
-- Always update `detected_layers` with new layer detection results on every init run — layer detection is based on code that exists, not user preference. This ensures greenfield projects that later gain code get their `detected_layers` populated correctly. Note: the final value written is still determined by Phase 6c (e.g., if user chose "Skip entirely" in Phase 4.7, Phase 6c writes `[]` regardless of detection results).
-- If `tech_stack` field exists AND `_auto_detected` is `true`:
-  → **MERGE** — overwrite auto-detected values with new detection results, but preserve any keys the user added manually (keys not in the new detection result). Overwrite `detected_layers` with new layer detection results.
-- If `tech_stack` field does NOT exist:
-  → **WRITE** full detected tech stack with `"_auto_detected": true`, and write `detected_layers` from layer detection
-- Only include fields that were actually detected (no empty/null values)
-
-## Field Definitions
-
-| Field | Type | Description |
-|-------|------|-------------|
-| `adoption_mode` | string | `"passive"` \| `"advisory"` \| `"active"` |
-| `platform` | string | `"codebuddy"` \| `"claude"` \| `"codex"` \| `"all"` |
-| `tech_stack` | object | Detected or user-provided tech stack |
-| `tech_stack._auto_detected` | boolean | `true` if auto-detected, `false` if user-provided |
-| `detected_layers` | string[] | Development layers detected in the project. Written by prizmkit-init Phase 4.5. Used to determine available rule configuration options. Values: `frontend` / `backend` / `database` / `mobile`. Empty array when no layers detected or user skipped rules. Always updated on every init run based on fresh code detection — not gated by `_auto_detected` (see Merge Strategy above). |
-
-Legacy manifests may still contain `both` for read-only migration compatibility. New config writes must use `codebuddy`, `claude`, `codex`, or `all`.
-
-## Examples
-
-Fullstack project:
-```json
-{
-  "adoption_mode": "passive",
-  "platform": "claude",
-  "detected_layers": ["frontend", "backend", "database"],
-  "tech_stack": {
-    "language": "TypeScript",
-    "runtime": "Node.js 20",
-    "frontend_framework": "React",
-    "frontend_styling": "Tailwind CSS",
-    "backend_framework": "Express.js",
-    "database": "PostgreSQL",
-    "orm": "Prisma",
-    "testing": "Vitest",
-    "bundler": "Vite",
-    "project_type": "fullstack",
-    "_auto_detected": true
-  }
-}
-```
-
-Pure Python backend:
-```json
-{
-  "adoption_mode": "passive",
-  "platform": "claude",
-  "tech_stack": {
-    "language": "Python",
-    "runtime": "Python >=3.11",
-    "backend_framework": "FastAPI",
-    "database": "PostgreSQL",
-    "orm": "SQLAlchemy",
-    "testing": "pytest",
-    "project_type": "backend",
-    "_auto_detected": true
-  },
-  "detected_layers": ["backend", "database"]
-}
-```

package/bundled/skills-windows/prizmkit-init/references/rules/layer-detection.md

@@ -1,41 +0,0 @@
-# Layer Detection — Signal Reference Table
-
-> Load this file in Phase 4.5 to determine which development layers exist in the project.
-> A "layer" means a distinct code domain that may benefit from custom dev rules.
-
-## Detection Signals
-
-> **This table is a reference guide, not an exhaustive checklist.** The signals below cover common frameworks and patterns, but the list cannot be complete — new frameworks emerge, projects use unconventional setups, and context matters more than any single string match. In addition to matching against these signals, **apply your own judgment**: if you see files, directories, or dependencies that clearly indicate a development layer (even if not listed below), include it. If a signal matches but context suggests it's misleading (e.g., a dependency present but not actually used as the primary tech), downgrade or ignore it. The goal is to accurately reflect what the project contains, not to mechanically match strings.
-
-| Layer | Signal Source | Detection Rule |
-|-------|--------------|----------------|
-| **frontend** | `package.json` dependencies | Contains `react`, `vue`, `angular`, `next`, `nuxt`, `svelte`, `solid-js`, `preact`, `remix`, `astro`, `qwik` |
-| **frontend** | `package.json` devDependencies | Contains `vite`, `webpack`, `parcel`, `turbo` |
-| **frontend** | Directory | `src/components/`, `pages/`, `app/` with `.tsx`/`.jsx`/`.vue` files |
-| **backend** | `package.json` dependencies | Contains `express`, `fastify`, `koa`, `hono`, `nest`, `next` (API routes) |
-| **backend** | `requirements.txt` / `pyproject.toml` | Contains `fastapi`, `django`, `flask`, `sanic`, `litestar` |
-| **backend** | `go.mod` | Contains `gin-gonic`, `echo`, `fiber`, `chi` |
-| **backend** | `pom.xml` / `build.gradle` | Contains `spring-boot`, `quarkus`, `micronaut`, `ktor` |
-| **backend** | Directory | `routes/`, `controllers/`, `handlers/`, `api/`, `internal/` with server code |
-| **database** | `package.json` dependencies | Contains `prisma`, `typeorm`, `sequelize`, `mongoose`, `knex`, `drizzle-orm`, `kysely` |
-| **database** | `requirements.txt` / `pyproject.toml` | Contains `sqlalchemy`, `django` (ORM), `pony`, `peewee`, `tortoise-orm` |
-| **database** | `go.mod` | Contains `gorm`, `sqlx`, `sqlc`, `ent`, `bun` |
-| **database** | Directory | `migrations/`, `prisma/`, `alembic/`, `db/`, `schema/` |
-| **database** | Environment | `.env*` contains `DATABASE_URL`, `DB_HOST`, `DB_NAME`, `MONGO_URI` |
-| **mobile** | File | `pubspec.yaml` exists (Flutter) |
-| **mobile** | `package.json` dependencies | Contains `react-native`, `expo` |
-| **mobile** | Directory | Both `ios/*.xcodeproj` + `android/build.gradle` exist simultaneously |
-
-## Mobile Confirmation
-
-When mobile signals are detected but ambiguous (e.g., a monorepo with web + mobile), use `AskUserQuestion`:
-
-> "Mobile platform signals detected (ios/ + android/ directories). Is this project
-> a mobile app, or are these directories for another purpose?"
-> Options: "Yes, this is a mobile app" / "No, these are for another purpose"
-
-## Output
-
-After detection (signals + your own judgment), assemble `detected_layers` array (e.g., `["frontend", "backend", "database"]`).
-Store in memory for Phase 6 config.json writing.
-If no layers detected (library/CLI project), array is empty.

package/bundled/skills-windows/prizmkit-init/references/tech-stack-catalog.md

@@ -1,13 +0,0 @@
-# Tech Stack Detection — Field Catalog
-
-Adaptive field list — only include fields that apply to the project being scanned.
-
-- **Language & Runtime**: e.g. TypeScript + Node.js 20, Python 3.11, Go 1.22
-- **Frontend framework** (if applicable): React, Vue.js, Angular, Next.js, Svelte, etc.
-- **Frontend styling** (if applicable): Tailwind CSS, SCSS, Styled Components, Material UI, etc.
-- **Backend framework** (if applicable): Express.js, FastAPI, Django, NestJS, Gin, etc.
-- **Database** (if applicable): PostgreSQL, MySQL, MongoDB, Redis, SQLite — detected from deps or `docker-compose.yml`
-- **ORM** (if applicable): Prisma, Drizzle, TypeORM, SQLAlchemy, Mongoose, etc.
-- **Bundler** (if applicable): Vite, Webpack, esbuild, Rollup, Turborepo
-- **Testing**: Vitest, Jest, pytest, Go test, etc.
-- **Project type** (inferred): `frontend` | `backend` | `fullstack` | `library` | `cli` | `monorepo`

package/bundled/skills-windows/prizmkit-init/references/update-supplement.md

@@ -1,9 +0,0 @@
-# Update Supplement — Post-Merge Gap-Fill Procedure
-
-Runs after tech stack merge in Update mode:
-
-1. **Module scan**: Re-scan project directories using the same TWO-TIER model from Step 1. Compare discovered modules against existing MODULE_INDEX in root.prizm.
-2. **Missing L1 check**: For any discovered module with no corresponding L1 `.prizm` doc → create L1 immediately and add to MODULE_INDEX.
-3. **Missing L2 check**: For any module/sub-module that has source files with meaningful logic but no L2 `.prizm` doc → create L2 using the L2 GENERATION TEMPLATE. Judgment call: skip trivial wrapper directories or single-config modules.
-4. **Stale L1 check**: For existing L1 docs, verify FILES count and KEY_FILES are still accurate. Update if source directory contents have changed significantly.
-5. **Report**: Include in the Update report: modules added, L1 docs created, L2 docs created, stale docs refreshed.

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

@@ -1,102 +0,0 @@
----
-name: "prizmkit-plan"
-description: "Specify and plan tasks: natural language → spec.md & plan.md with architecture and executable tasks. Use before /prizmkit-implement. Trigger on: 'specify', 'plan', 'new task', 'I want to add/build...', 'architect', 'design', 'break it down', 'create tasks'. (project)"
----
-
-# PrizmKit Plan
-
-A universal spec + plan generator. Takes a natural-language description of ANY development task (new feature, refactoring, bug fix, migration, etc.) and produces `spec.md` (WHAT/WHY) and `plan.md` (HOW) with executable tasks.
-
-### When to Use
-- Any non-trivial development task that benefits from written specification and planning
-- Before `/prizmkit-implement` — to create the spec + task breakdown
-- User says "specify", "plan", "new task", "I want to add...", "architect", "design", "break it down"
-
-### When NOT to Use
-- Config tweaks, typo fixes, trivial one-line changes → edit directly
-- Simple changes where the developer already knows exactly what to do and the scope is ≤10 lines in a single file
-
-## Input
-
-| Parameter | Required | Description |
-|-----------|----------|-------------|
-| `description` | Yes | Natural-language description of the task |
-| `artifact_dir` | No | Directory to write spec.md + plan.md into. If omitted, auto-generates under `.prizmkit/specs/` (see Phase 0 Step 2). |
-
-## Execution
-
-### Phase 0: Specify (→ spec.md)
-
-**Skip condition**: If `spec.md` already exists in the artifact directory, skip to Phase 1.
-
-**Steps:**
-
-1. Gather input: read the task description. If no description is provided and interactive session is available, ask the user; otherwise abort with an error.
-2. Determine artifact directory:
-   - If `artifact_dir` is provided → use it directly
-   - If not provided → scan `.prizmkit/specs/` for existing `###-*` directories, find highest numeric prefix, next = highest + 1 (zero-padded to 3 digits; start at `001` if empty). Create `.prizmkit/specs/###-task-slug/`
-   - Auto-generate 2-10 word task slug from description
-3. Load project context: read `.prizmkit/prizm-docs/root.prizm` and relevant L1/L2 docs
-4. Generate `spec.md` from template (`${SKILL_DIR}/assets/spec-template.md`):
-   - Fill sections based on the task description — all sections are optional, include only what is relevant
-   - `[NEEDS CLARIFICATION]` markers for all ambiguous items
-5. **Database design detection**: If changes involve data persistence (new entities, fields, schema changes), add `## Data Model` section — scan existing schema files to extract naming conventions, ID strategy, constraint patterns. Mark uncertain decisions with `[NEEDS CLARIFICATION]`.
-6. Run quality validation : all goals have criteria? scope defined? DB conventions documented (if applicable)?
-7. **Auto-clarification**: If any `[NEEDS CLARIFICATION]` markers remain and interactive session is available, enter interactive clarification.
-   → Read `${SKILL_DIR}/references/clarify-guide.md` for question strategy and update rules.
-   If non-interactive, resolve ambiguities by choosing the most conservative option and annotating the decision.
-   Resolve all markers before proceeding to Phase 1.
-
-**Writing principles**: Focus on WHAT and WHY, never HOW. Every goal needs acceptance criteria. Scope boundaries must be explicit. Mark all genuine ambiguities — the clarification phase resolves them.
-
-**Internal ID hygiene**: PrizmKit IDs (`F-001`, `B-001`, `R-001`), task IDs (`T-100`), session IDs, run IDs, branch names, absolute worktree paths, and `.prizmkit/specs` / `.prizmkit/dev-pipeline` artifact paths are internal tracking metadata. They may appear in specs, plans, commit messages, and non-memory pipeline artifacts, but must never be written to `.prizmkit/prizm-docs/`, user-visible product copy, UI text, API responses, or expected UI strings in tests. If a behavior is scoped to the current feature, describe the product behavior without the ID.
-
-### Phase 1: Design (spec.md → plan.md)
-
-**Precondition**: `spec.md` exists in the artifact directory.
-
-**Steps:**
-
-1. Read `spec.md` from the artifact directory
-2. Load project context if not already loaded in Phase 0: read `.prizmkit/prizm-docs/root.prizm` and relevant L1/L2 docs
-3. Resolve any remaining `[NEEDS CLARIFICATION]` by proposing solutions
-4. Generate `plan.md` from template (`${SKILL_DIR}/assets/plan-template.md`):
-   - Change approach (how the changes integrate with existing system)
-   - Component / file changes
-   - Data model changes (with **database design gate** — read ALL existing schema files, ensure new schema follows existing patterns, resolve all DB ambiguities inline before proceeding)
-   - Interface design (API endpoints, request/response formats)
-   - Testing strategy
-   - Risk assessment
-   - Behavior preservation strategy (if the task modifies existing behavior — include what must remain unchanged and how to verify)
-5. Cross-check: every goal in spec.md maps to plan components — unmapped goals = coverage gaps
-6. Check alignment with `.prizmkit/prizm-docs/root.prizm` RULES section
-
-### Phase 2: Task Generation (plan.md → Tasks section)
-
-1. If interactive session is available, ask user for strategy; otherwise infer automatically: MVP-first / Incremental / Parallel
-2. Append `## Tasks` section to `plan.md` using template in `${SKILL_DIR}/assets/plan-template.md`:
-   - Phases: Setup (T-001~T-009) → Foundation (T-010~T-099) → Core (T-100+) → Polish (T-900+)
-   - Each task: `- [ ] [T-NNN] [P?] [G-N?] Description — file: path/to/file`
-   - Checkpoint tasks between phases for validation
-   - Organize Core tasks by goals (G-1, G-2, ...) or by logical grouping appropriate to the task
-3. Verify consistency and coverage → read `${SKILL_DIR}/references/verification-checklist.md` and run all checks. Fix any issues inline before output.
-4. Output: `plan.md` path, summary of design decisions, task count.
-
-**HANDOFF:** `/prizmkit-implement`
-
-## Examples
-
-Read `${SKILL_DIR}/references/examples.md` for worked examples of feature, refactoring, and bug fix planning.
-
-## References
-
-- Spec template: `${SKILL_DIR}/assets/spec-template.md`
-- Plan template: `${SKILL_DIR}/assets/plan-template.md`
-- Clarification guide: `${SKILL_DIR}/references/clarify-guide.md`
-- Verification checklist: `${SKILL_DIR}/references/verification-checklist.md`
-
-## Output
-
-| Directory | Files |
-|---|---|
-| `artifact_dir` (provided or auto-generated `.prizmkit/specs/###-slug/`) | `spec.md` + `plan.md` |

package/bundled/skills-windows/prizmkit-plan/assets/plan-template.md

@@ -1,115 +0,0 @@
-# Plan: [TITLE]
-
-## Change Approach
-[Description of the technical approach — how these changes integrate with the existing system]
-
-## Component Design
-
-### New Components
-- [Component]: [Purpose]
-
-### Modified Components
-- [Component]: [What changes and why]
-
-## Behavior Preservation Strategy
-<!-- Include when the task modifies existing behavior. Delete if not applicable (e.g., greenfield feature). -->
-<!-- Strategy: one of test-gate / snapshot / manual -->
-<!-- test-gate: all tests must pass after each task -->
-<!-- snapshot: before-after comparison of outputs -->
-<!-- manual: reviewer verification at checkpoints -->
-- Strategy: [test-gate / snapshot / manual]
-- Baseline: [describe green test suite or snapshot state]
-
-## Data Model
-<!-- Include when changes involve database / data persistence. Delete if not applicable. -->
-<!-- IMPORTANT: Read existing schema/model files BEFORE designing new tables -->
-
-### Existing Schema Audit
-<!-- List existing tables/models reviewed. Note observed conventions. -->
-- Tables reviewed: [list tables examined]
-- Naming convention: [snake_case/camelCase — document what existing schema uses]
-- ID strategy: [UUID/auto-increment/CUID — match existing]
-- Timestamp fields: [created_at/updated_at pattern — match existing]
-- Soft delete: [yes/no, field name if applicable]
-- Constraint patterns: [NOT NULL defaults, UNIQUE patterns, index conventions]
-
-### Schema Changes
-| Entity | Type | Fields | Constraints | Relationships | Migration Notes |
-|--------|------|--------|-------------|---------------|-----------------|
-| [name] | new/modify | [field: type, ...] | [NOT NULL, UNIQUE, INDEX, ...] | [FK → existing_table(id)] | [migration strategy] |
-
-### Style Conformance Checklist
-- [ ] Table/column naming matches existing conventions
-- [ ] ID strategy consistent with existing tables
-- [ ] Timestamp fields follow existing patterns
-- [ ] Foreign key constraints and indexes defined
-- [ ] Soft delete strategy matches existing pattern (if applicable)
-- [ ] All fields have explicit nullability (NOT NULL or nullable)
-
-### Unresolved Questions
-<!-- NONE — all DB design questions must be resolved inline before proceeding to Tasks -->
-
-## Interface Design
-[API endpoints, request/response formats, module interfaces — include all details here]
-
-## Integration Points
-- [Service/Module]: [How integrated]
-
-## Testing Strategy
-- Unit: [Approach]
-- Integration: [Approach]
-- E2E: [Approach]
-
-## Risk Assessment
-| Risk | Impact | Mitigation |
-|------|--------|------------|
-| [Risk] | [H/M/L] | [Plan] |
-
-## Deployment Considerations
-<!-- Include when there is deployment impact (new services, infra, environment changes). Delete if not applicable. -->
-
-### New Infrastructure Requirements
-- [Component]: [Deployment target from config deploy_strategy] — [any special config needed]
-
-### New Environment Variables
-| Variable | Required | Description | Example |
-|----------|----------|-------------|---------|
-| [VAR_NAME] | yes/no | [Purpose] | [example value] |
-
-### Deployment Impact
-- [ ] No infrastructure changes needed (skip this section)
-- [ ] New service/container required
-- [ ] New environment variables added
-- [ ] Database migration required in production
-- [ ] CI/CD pipeline update needed
-
-## Pre-Implementation Gates
-- [ ] Spec coverage: all goals mapped to components
-- [ ] Data model reviewed — existing schema conventions documented and followed (if applicable)
-- [ ] All `[NEEDS CLARIFICATION]` items resolved
-- [ ] Testing approach agreed
-- [ ] Behavior preservation strategy defined (if modifying existing behavior)
-- [ ] Root cause confirmed with reproduction test design (if fixing a defect)
-
-## Tasks
-
-### Strategy: [MVP-first | Incremental | Parallel]
-
-### Phase: Setup
-- [ ] [T-001] [Description] — file: [path]
-
-### Phase: Foundation
-- [ ] [T-010] [Description] — file: [path]
-
-### Phase: Core
-<!-- Organize by goals (G-1, G-2, ...) or by logical grouping appropriate to the task -->
-- [ ] [T-100] [P] [G-1] [Task description] — file: [path]
-
-### Phase: Polish
-- [ ] [T-900] Final verification
-- [ ] [T-901] Documentation update
-
-### Checkpoints
-- [ ] [CP-1] After Setup: project builds and tests pass
-- [ ] [CP-2] After Foundation: base changes verified
-- [ ] [CP-3] After each Core group: acceptance criteria pass

package/bundled/skills-windows/prizmkit-plan/assets/spec-template.md

@@ -1,73 +0,0 @@
-# [TITLE]
-
-## Overview
-[One paragraph describing the purpose and motivation]
-
-## Goals
-
-### G-1: [Goal Title]
-[Goal description — use whatever format best suits the task:
-  - User Story format: "As a [role], I want [capability], so that [benefit]."
-  - Objective format: "Objective: [change to make]. Target state: [desired outcome]."
-  - Fix format: "Fix: [symptom]. Root cause: [brief cause]."
-  - Or any other clear format.]
-
-**Acceptance Criteria:**
-- [ ] [Criterion 1 — Given/When/Then, or a concrete verifiable statement]
-
-## Scope
-
-### In Scope
-- [Item 1]
-
-### Out of Scope
-- [Item 1]
-
-## Behavior Preservation
-<!-- Include this section when the task modifies existing behavior (refactoring, bug fixes, migrations, etc.). Delete if not applicable. -->
-- [What behavior / contracts / interfaces must remain unchanged]
-- [Existing test suites that must continue to pass]
-
-## Root Cause
-<!-- Include this section when the task is fixing a defect. Delete if not applicable. -->
-- Error classification: [Runtime / Network / Auth / Data / Logic / Config / External]
-- Root cause: [specific code location and mechanism]
-- Affected files: [file list with line numbers]
-- Impact: [blast radius — which modules / features are affected]
-
-## Dependencies
-- [Dependency 1]: [Why needed]
-
-## Data Model
-<!-- Include this section when changes involve database / data persistence. Delete if not applicable. -->
-
-### Existing Schema Reference
-<!-- Read existing schema/model files BEFORE designing new tables. Document observed conventions here. -->
-- Tables reviewed: [list existing tables related to this change]
-- Naming convention: [snake_case/camelCase — match existing]
-- ID strategy: [UUID/auto-increment — match existing]
-- Timestamp pattern: [created_at/updated_at — match existing]
-- Soft delete: [yes/no, field name — match existing]
-
-### New/Modified Entities
-| Entity | Type (new/modify) | Key Fields | Relationships | Constraints |
-|--------|-------------------|------------|---------------|-------------|
-| [entity_name] | new | [field: type] | [FK to existing_table] | [NOT NULL, UNIQUE, etc.] |
-
-### Open Data Model Questions
-<!-- All questions here MUST be resolved before /prizmkit-plan generates Tasks -->
-- [NEEDS CLARIFICATION] [Any uncertain data model decisions — field types, nullability, relationships]
-
-## Constraints
-- [Constraint 1]
-
-## Clarifications
-[NEEDS CLARIFICATION]: [Ambiguous item]
-
-## Review Checklist
-- [ ] All goals have acceptance criteria
-- [ ] Scope boundaries are clearly defined
-- [ ] Dependencies are identified
-- [ ] No implementation details (WHAT not HOW)
-- [ ] Behavior preservation defined (if modifying existing behavior)
-- [ ] Root cause identified with evidence (if fixing a defect)

package/bundled/skills-windows/prizmkit-plan/references/clarify-guide.md

@@ -1,67 +0,0 @@
-# Clarification Phase — Execution Guide
-
-Invoked automatically during `/prizmkit-plan` Phase 0 (specify) when `[NEEDS CLARIFICATION]` markers exist, or during Phase 1 (design) when data model ambiguities arise.
-
----
-
-## Question Strategy
-
-**Ask one question at a time.** Batching questions produces lower-quality answers.
-
-For each question:
-1. Cite the exact location in spec.md (e.g., "§Goals G-1 says..." or "§Scope says...")
-2. State what is ambiguous and why it matters for implementation
-3. Provide a **recommended answer** with rationale — gives the user a concrete starting point to accept, modify, or reject
-
-**Prioritize by implementation impact** (highest first):
-1. Data model (entities, relationships, field types, constraints, naming) — **hardest to change after code is written**
-2. Functional scope boundaries
-3. UX flow and error handling
-4. Non-functional requirements (performance, security)
-5. Edge cases and integration points
-
-## Update Discipline
-
-After **each** user answer:
-- Immediately update `spec.md` (do not batch at the end)
-- Remove the resolved `[NEEDS CLARIFICATION]` marker
-- Re-evaluate for new ambiguities exposed by the answer
-
-## No Limits Policy
-
-**There is no cap on rounds or questions.** Keep asking until:
-- All `[NEEDS CLARIFICATION]` markers are removed, AND
-- No vague or underspecified areas remain, AND
-- You are fully confident about the requirements
-
-If the user's answer raises new questions — ask those too. If a previously-resolved item needs revisiting due to new context — go back.
-
-## Early Termination
-
-If the user says "done", "stop", or "enough" — end immediately and output a summary of:
-- What was resolved
-- What remains unclear (list any open `[NEEDS CLARIFICATION]` items)
-
-## Example Exchange
-
-**Question:**
-> §Goals G-1 says "User can upload files" but doesn't specify file types or size limits.
->
-> **Recommended:** Accept JPEG, PNG, PDF up to 10MB — covers common use cases without straining storage.
->
-> Do you agree, or different constraints?
-
-**User:** "Also allow SVG, make it 25MB"
-
-**Action:** Update spec.md §Goals G-1 → `File upload: JPEG, PNG, PDF, SVG. Max 25MB per file.` Remove marker.
-
-**Follow-up question triggered by answer:**
-> SVGs can contain embedded scripts (XSS risk). Should uploaded SVGs be sanitized (strip `<script>` + event handlers), or restricted to trusted users only?
->
-> **Recommended:** Sanitize all SVG uploads — allows all users to upload safely.
-
-## Guidelines
-
-- Stay at WHAT/WHY level — no implementation details (HOW) in spec
-- If an answer contradicts an existing requirement, surface the conflict and ask which takes precedence
-- If the user seems fatigued: "I have N more questions — continue now or later?" — but never silently stop with unresolved ambiguities

package/bundled/skills-windows/prizmkit-plan/references/examples.md

@@ -1,85 +0,0 @@
-# Plan Examples
-
-## Example 1: New Feature
-
-**Input:** "I want users to upload avatars"
-
-**Phase 0 output:** `.prizmkit/specs/003-user-avatar/spec.md`
-```markdown
-# User Avatar Upload
-## Overview
-Allow registered users to upload and manage profile pictures.
-## Goals
-### G-1: Upload Avatar
-As a registered user, I want to upload a profile picture,
-so that other users can visually identify me.
-**Acceptance Criteria:**
-- Given I am on my profile page
-- When I select an image file and click upload
-- Then my avatar is updated and visible across the platform
-## Scope
-- **In scope:** Upload, display, remove avatar; image format validation
-- **Out of scope:** Image cropping/editing, avatar history
-```
-
-**Phase 1-2 output:** `plan.md` excerpt:
-```markdown
-## Tasks
-### Phase: Foundation (T-010~T-019)
-- [ ] [T-010] [G-1] Add avatar_url field to User model — file: src/models/user.ts
-- [ ] [T-011] [G-1] Create S3 upload utility — file: src/lib/s3.ts
-### Phase: Core [P] (T-100~T-109)
-- [ ] [T-100] [P] [G-1] POST /api/avatar upload endpoint — file: src/routes/avatar.ts
-```
-
-## Example 2: Refactoring
-
-**Input:** "Extract shared auth middleware from the API routes"
-
-**Phase 0 output:** `.prizmkit/specs/004-extract-auth-middleware/spec.md`
-```markdown
-# Extract Auth Middleware
-## Overview
-Consolidate duplicated authentication logic scattered across route files into a single shared middleware.
-## Goals
-### G-1: Extract Shared Authentication Logic
-Consolidate duplicated auth checks from 5 route files into a single middleware module.
-**Acceptance Criteria:**
-- All existing auth-related tests pass without modification
-- Auth logic exists in exactly one file (src/middleware/auth.ts)
-- No route file contains inline token verification
-## Scope
-- **In scope:** src/routes/users.ts, orders.ts, admin.ts, payments.ts, profile.ts
-- **Out of scope:** Authorization (role-based access), rate limiting
-## Behavior Preservation
-- All 23 existing API tests must pass unchanged
-- Response formats and HTTP status codes must not change
-- Error message strings must remain identical
-```
-
-## Example 3: Bug Fix
-
-**Input:** "Login page crashes when API returns 401"
-
-**Phase 0 output:** `.prizmkit/specs/005-login-401-crash/spec.md`
-```markdown
-# Fix: Login Crash on 401 Response
-## Overview
-Login page throws unhandled exception when auth API returns 401, causing a white screen.
-## Goals
-### G-1: Handle 401 Response Gracefully
-When the auth API returns 401, display an error message instead of crashing.
-**Acceptance Criteria:**
-- Given user submits invalid credentials, When API returns 401, Then error message "Invalid credentials" is displayed
-- Given user submits invalid credentials, When API returns 401, Then no unhandled exception is thrown
-## Root Cause
-- Error classification: Runtime
-- Root cause: `AuthService.handleLogin()` at src/services/auth.ts:42 does not handle null token
-- Affected files: src/services/auth.ts (L42), src/pages/login.tsx (L28)
-## Scope
-- **In scope:** Null handling in auth service, error display in login page
-- **Out of scope:** Other HTTP error codes (403, 500), auth flow redesign
-## Behavior Preservation
-- All existing login success tests must pass unchanged
-- Auth token flow for valid credentials must not change
-```