prizmkit 1.0.119 → 1.0.121

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.0.119",
-  "bundledAt": "2026-03-27T15:01:36.094Z",
-  "bundledFrom": "3b42eb5"
+  "frameworkVersion": "1.0.121",
+  "bundledAt": "2026-03-27T15:30:11.092Z",
+  "bundledFrom": "c47b687"
 }

package/bundled/dev-pipeline/templates/bootstrap-tier2.md

@@ -129,6 +129,14 @@ ls .prizmkit/specs/{{FEATURE_SLUG}}/plan.md 2>/dev/null
 
 If either missing, write them yourself:
 - `plan.md`: architecture — components, interfaces, data flow, files to create/modify, testing approach, and a Tasks section with `[ ]` checkboxes ordered by dependency
+
+**Database Design Gate** (if feature involves data persistence — new tables, schema changes, new entities):
+Before proceeding past CP-1, verify:
+1. Plan.md Data Model section references existing schema/model files (scan for `*.prisma`, `*.sql`, `migrations/`, `models/`, `*.entity.*` files; read them if not already in context-snapshot)
+2. All new tables/fields follow existing naming conventions, ID strategy, timestamp patterns, and constraint style
+3. No `[NEEDS CLARIFICATION]` remains in Data Model section — resolve by reading existing code and making a conservative choice that matches existing patterns. Document the resolution in plan.md.
+4. If a DB design decision genuinely cannot be resolved from existing code alone, document the assumption made and flag it in the Implementation Log for user review.
+
 **CP-1**: plan.md exists with Tasks section.
 
 ### Phase 3: Implement — Dev Subagent

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.0.119",
+  "version": "1.0.121",
   "skills": {
     "prizm-kit": {
       "description": "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management.",

package/bundled/skills/app-planner/SKILL.md

@@ -11,6 +11,26 @@ Plan deliverable features for dev-pipeline in two modes:
 
 Always produce a validated `feature-list.json` that conforms to `dev-pipeline-feature-list`.
 
+## Scope Boundary (Hard Rule)
+
+**This skill is PLANNING ONLY.** You must NEVER:
+- Create, modify, or delete source code files (*.js, *.ts, *.py, *.go, *.html, *.css, etc.)
+- Create project scaffolding, directories, or boilerplate
+- Run build/install/test commands (npm init, pip install, etc.)
+- Execute any implementation action beyond writing `feature-list.json`
+
+**Your ONLY writable outputs are:**
+1. `feature-list.json` (project root)
+2. Architecture decisions appended to `CLAUDE.md` / `CODEBUDDY.md` (with user consent, see §Architecture Decision Capture)
+3. Draft backups in `.prizmkit/planning/`
+
+**After planning is complete**, you MUST:
+1. Present the summary and recommended next step
+2. **Ask the user explicitly** whether they want to proceed to execution
+3. If the user agrees → recommend invoking `dev-pipeline-launcher` or running `run.sh` (do NOT execute it yourself)
+4. If the user wants to adjust → continue refining `feature-list.json`
+5. **NEVER auto-execute** the pipeline, launcher, or any implementation step
+
 ## When to Use
 
 Trigger this skill for requests like:
@@ -22,6 +42,7 @@ Trigger this skill for requests like:
 Do NOT use this skill when:
 - user only wants to run pipeline now (invoke `dev-pipeline-launcher`)
 - user is debugging/refactoring unrelated to feature planning
+- user wants to write or modify source code directly
 
 ## Resource Loading Rules (Mandatory)
 

package/bundled/skills/prizmkit-analyze/SKILL.md

@@ -107,6 +107,14 @@ Focus on high-signal findings. Limit to **50 findings total**; aggregate remaind
 - Task ordering contradictions (e.g., integration tasks before foundational setup without dependency note)
 - Conflicting requirements (e.g., one requires REST while other specifies GraphQL)
 
+#### G. Database Design Consistency (when plan.md has Data Model section)
+- New entity/field naming inconsistent with existing schema conventions documented in "Existing Schema Audit"
+- Missing constraints (NOT NULL, UNIQUE, FK, INDEX) on fields where existing similar tables define them
+- Unresolved `[NEEDS CLARIFICATION]` in Data Model section → **CRITICAL** (must be resolved before implementation)
+- Style Conformance Checklist items unchecked → **HIGH** (design not verified against existing conventions)
+- New tables with no foreign key relationship to any existing table (orphan table warning — may indicate missing business logic)
+- Missing migration strategy for schema changes that affect existing data
+
 ### Step 5: Severity Assignment
 
 Use this heuristic to prioritize findings:

package/bundled/skills/prizmkit-clarify/SKILL.md

@@ -23,6 +23,7 @@ Interactive requirement clarification that resolves ambiguities in feature speci
 1. Read `spec.md` from `.prizmkit/specs/###-feature-name/`
 2. Scan for `[NEEDS CLARIFICATION]` markers and underspecified areas
 3. Categorize ambiguities by dimension and prioritize — address the ones that would most affect architecture and data model first, since those are hardest to change later:
+   - Data model (what entities, relationships, constraints?) — **highest priority when DB changes are involved**: field types, nullability, naming conventions, relationships, and constraint patterns must all be resolved before plan finalization. Unresolved DB design decisions during implementation lead to expensive rework.
    - Functional scope (what does it do?)
    - Data model (what entities, relationships?)
    - UX flow (what does the user see?)

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

@@ -46,6 +46,12 @@ Generate a comprehensive technical implementation plan from a feature specificat
    - Architecture approach (how feature fits into existing structure)
    - Component design (new/modified components)
    - Data model changes (new entities, modified schemas)
+   - **Database design gate** (when feature involves DB changes):
+     1. Read ALL existing schema/migration/model files to understand current conventions (naming, constraints, relationships, ID strategy, timestamps)
+     2. Ensure new schema follows existing patterns — do NOT introduce new conventions unless explicitly justified
+     3. Verify every new table/field has: purpose, type, constraints, and relationship to existing entities
+     4. If any data model decision is uncertain → mark as `[NEEDS CLARIFICATION]` and resolve via `/prizmkit-clarify` BEFORE generating the Tasks section
+     5. **RULE**: The Tasks section MUST NOT be generated until all `[NEEDS CLARIFICATION]` items in Data Model are resolved. Unresolved DB design leads to implementation rework that is expensive to fix after code is written.
    - Interface design (API endpoints, request/response formats, module interfaces)
    - Integration points (external services, internal modules)
    - Testing strategy (unit, integration, e2e)

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

@@ -12,7 +12,34 @@
 - [Component]: [What changes and why]
 
 ## Data Model
-[Entity definitions, schemas, and relationships — include all details here]
+<!-- Skip this section if the feature does not involve database changes -->
+<!-- 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 before proceeding to Tasks -->
+<!-- If any remain, run /prizmkit-clarify to resolve them first -->
 
 ## Interface Design
 [API endpoints, request/response formats, module interfaces — include all details here]
@@ -32,7 +59,8 @@
 
 ## Pre-Implementation Gates
 - [ ] Spec coverage: all user stories mapped to components
-- [ ] Data model reviewed
+- [ ] Data model reviewed — existing schema conventions documented and followed
+- [ ] All Data Model `[NEEDS CLARIFICATION]` items resolved (mandatory for DB features)
 - [ ] API contracts defined
 - [ ] Testing approach agreed
 

package/bundled/skills/prizmkit-specify/SKILL.md

@@ -39,11 +39,21 @@ Create structured feature specifications from natural language descriptions. Thi
    - Scope boundaries (In scope / Out of scope)
    - Dependencies and constraints
    - `[NEEDS CLARIFICATION]` markers for ambiguous items (max 3)
-7. Run internal quality validation loop (max 3 iterations):
+7. **Database design detection**: If the feature involves data persistence (new entities, new fields, schema changes), add a `## Data Model` section to spec.md (see template):
+   - Scan for existing database schema files to understand current conventions:
+     ```bash
+     find . -maxdepth 4 -type f \( -name "*.prisma" -o -name "*.sql" -o -path "*/migrations/*" -o -path "*/models/*" -o -name "schema.*" -o -name "*.entity.*" \) -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/dist/*' -not -path '*/__pycache__/*' | head -20
+     ```
+   - Read existing schema/model files to extract conventions: naming style (snake_case vs camelCase), ID strategy (UUID vs auto-increment), timestamp patterns, soft-delete approach, constraint patterns, relationship patterns
+   - Document in spec.md Data Model section: existing schema reference, new entities needed, relationships to existing tables
+   - Mark uncertain fields or relationships with `[NEEDS CLARIFICATION]` — these MUST be resolved before planning
+   - **RULE**: Never design new tables in isolation — always reference existing schema to maintain style consistency
+8. Run internal quality validation loop (max 3 iterations):
    - Check: All user stories have acceptance criteria?
    - Check: Scope boundaries clearly defined?
    - Check: No more than 3 `[NEEDS CLARIFICATION]` markers?
-8. Output: `spec.md` path and summary
+   - Check: If Data Model section exists, are existing schema conventions documented?
+9. Output: `spec.md` path and summary
 
 ## Writing Principles
 

package/bundled/skills/prizmkit-specify/assets/spec-template.md

@@ -24,6 +24,25 @@
 ## Dependencies
 - [Dependency 1]: [Why needed]
 
+## Data Model (if feature involves database changes)
+
+### Existing Schema Reference
+<!-- Read existing schema/model files BEFORE designing new tables. Document observed conventions here. -->
+- Tables reviewed: [list existing tables related to this feature]
+- 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]
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prizmkit",
-  "version": "1.0.119",
+  "version": "1.0.121",
   "description": "Create a new PrizmKit-powered project with clean initialization — no framework dev files, just what you need.",
   "type": "module",
   "bin": {

package/bundled/skills/prizmkit-retrospective/assets/retrospective-template.md

@@ -1,13 +0,0 @@
-# Retrospective: [FEATURE_NAME]
-Date: YYYY-MM-DD
-
-## Knowledge Captured
-- TRAPS added: N (list affected modules)
-- RULES added: N (list affected modules)
-- DECISIONS recorded: N (list affected modules)
-
-## Key Insights
-- [insight]: [why it matters for future work]
-
-## .prizm-docs/ Updates
-- [file]: [what was updated]