prizmkit 1.1.55 → 1.1.56

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.55",
-  "bundledAt": "2026-05-25T01:36:43.012Z",
-  "bundledFrom": "0664e65"
+  "frameworkVersion": "1.1.56",
+  "bundledAt": "2026-05-25T14:52:42.567Z",
+  "bundledFrom": "2846267"
 }

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.55",
+  "version": "1.1.56",
   "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

@@ -240,16 +240,54 @@ After Infrastructure configuration is complete (CP-AP-1.5), check whether the pr
 
 Rules are optional. If the user skips, AI uses general best practices freely — no reminders, no blocking.
 
-### Step 1: Detect missing rules
+### Step 1: Detect which layers need rules
 
 1. Read `.prizmkit/config.json` to get `detected_layers` (written by `prizmkit-init` Phase 4.5).
-   - If `detected_layers` field is absent or empty → skip this entire section, proceed to Prerequisites.
-2. For each layer in `detected_layers`, check if `.prizmkit/rules/<layer>-rules.md` exists:
+   - If `detected_layers` is present and non-empty → use it directly, jump to step 3.
+   - If `detected_layers` is absent or empty → run self-detection (step 2). Do NOT skip rules configuration just because this field is missing — the project may still have layers that need rules.
+
+2. **Self-detection** (only when `detected_layers` is absent/empty from config.json):
+
+   Scan the project to determine which development layers exist. Combine signal matching with your own judgment — the signals below are a guide, not exhaustive.
+
+   | Layer | Where to Look | Signals |
+   |-------|---------------|---------|
+   | **frontend** | `package.json` deps | `react`, `vue`, `angular`, `next`, `nuxt`, `svelte`, `solid-js`, `preact`, `remix`, `astro`, `qwik` |
+   | **frontend** | `package.json` devDeps | `vite`, `webpack`, `parcel`, `turbo` |
+   | **frontend** | Directory | `src/components/`, `pages/`, `app/` with `.tsx`/`.jsx`/`.vue` files |
+   | **backend** | `package.json` deps | `express`, `fastify`, `koa`, `hono`, `nest` |
+   | **backend** | `pyproject.toml`/`requirements.txt` | `fastapi`, `django`, `flask`, `sanic`, `litestar` |
+   | **backend** | `go.mod` | `gin-gonic`, `echo`, `fiber`, `chi` |
+   | **backend** | `pom.xml`/`build.gradle` | `spring-boot`, `quarkus`, `micronaut`, `ktor` |
+   | **backend** | Directory | `routes/`, `controllers/`, `handlers/`, `api/` with server code |
+   | **database** | `package.json` deps | `prisma`, `typeorm`, `sequelize`, `mongoose`, `knex`, `drizzle-orm`, `kysely` |
+   | **database** | `pyproject.toml`/`requirements.txt` | `sqlalchemy`, `pony`, `peewee`, `tortoise-orm` |
+   | **database** | `go.mod` | `gorm`, `sqlx`, `sqlc`, `ent`, `bun` |
+   | **database** | Directory/Env | `migrations/`, `prisma/`, `alembic/`; `.env*` with `DATABASE_URL`, `DB_HOST`, `MONGO_URI` |
+   | **mobile** | File | `pubspec.yaml` (Flutter) |
+   | **mobile** | `package.json` deps | `react-native`, `expo` |
+   | **mobile** | Directory | Both `ios/*.xcodeproj` + `android/build.gradle` simultaneously |
+
+   **Apply your own judgment**: if you see clear evidence of a layer not covered above, include it. If a signal matches but context suggests it's misleading (e.g., a dependency present but not used as the primary tech), downgrade or ignore it.
+
+   After scanning, present findings via `AskUserQuestion`:
+
+   **Question**: "I detected these development layers: [list with brief evidence]. Is this correct?"
+   - **Yes, looks correct (Recommended)** — use detected layers
+   - **Mostly correct, adjust** — I'll note changes
+   - **No layers apply** — skip rules configuration (library/CLI project)
+
+   If user picks "No layers apply" → skip this entire section, proceed to Prerequisites.
+   If user picks "Mostly correct, adjust" → ask what to add, remove, or change, then reassemble `detected_layers`. Continue to step 3.
+   If user confirms → assemble `detected_layers` array and continue to step 3.
+
+3. For each layer in `detected_layers`, check if `.prizmkit/rules/<layer>-rules.md` exists:
    - `frontend` → `.prizmkit/rules/frontend-rules.md`
    - `backend` → `.prizmkit/rules/backend-rules.md`
    - `database` → `.prizmkit/rules/database-rules.md`
    - `mobile` → `.prizmkit/rules/mobile-rules.md`
-3. Display status:
+
+4. Display status:
 
    ```
    Rules Status Check:
@@ -258,8 +296,8 @@ Rules are optional. If the user skips, AI uses general best practices freely —
      [missing] database-rules.md — database interaction detected, no rules configured
    ```
 
-4. If all detected layers already have rules → skip to Prerequisites.
-5. If missing rules found, proceed to Step 2.
+5. If all detected layers already have rules → skip to Prerequisites.
+6. If missing rules found, proceed to Step 2.
 
 ### Step 2: Ask configuration mode
 
@@ -323,7 +361,7 @@ After all selected layers are configured:
 2. **If root.prizm exists**:
    - Read the file.
    - Check if `RULES:` line exists:
-     - If present: append new rules file paths to the existing line.
+     - If present: append new rules file paths to the existing line (check for duplicates first — skip paths already on the line).
      - If absent: add `RULES: .prizmkit/rules/<layer>-rules.md, ...` at the end (after PROJECT_BRIEF line).
 3. **If root.prizm does not exist** (e.g., project without prizm-docs init):
    - Create a minimal `root.prizm` with:
@@ -529,7 +567,7 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
 | **CP-AP-0** | Intent Confirmed | User confirmed session goal (produce / explore) | 1 |
 | **CP-AP-1** | Conventions Checked | Project conventions loaded or asked; `### Project Conventions` section in `CLAUDE.md` / `CODEBUDDY.md` up to date | 1 |
 | **CP-AP-1.5** | Infrastructure Checked | Infrastructure config loaded or asked; `### Infrastructure` section in `CLAUDE.md` / `CODEBUDDY.md` addressed — database, deployment **and cloud services** each configured or explicitly deferred | 1-2 |
-| **CP-AP-1.6** | Rules Configured | For each layer in `detected_layers`, rules file exists in `.prizmkit/rules/` or user explicitly skipped. `root.prizm` `RULES:` pointer up-to-date. | 2 |
+| **CP-AP-1.6** | Rules Configured | For each detected layer (from config.json or self-detection), rules file exists in `.prizmkit/rules/` or user explicitly skipped. `root.prizm` `RULES:` pointer up-to-date. | 2 |
 | **CP-AP-2** | Vision Summary | Goal/users/differentiators confirmed by user. For brownfield: existing purpose confirmed or refined. | 1-2 |
 | **CP-AP-3** | Frontend Design Evaluated | For frontend projects: checked for existing UI/UX design system; user was asked if missing. **Auto-pass** for backend-only or non-UI projects. | 2 |
 | **CP-AP-4** | Project Brief Accumulated | `.prizmkit/plans/project-brief.md` exists at `.prizmkit/plans/` with at least 3 ideas listed. For brownfield: already-implemented items marked `[x]` count toward this total. | 3 |

package/bundled/skills/prizmkit-code-review/SKILL.md

@@ -32,7 +32,8 @@ The loop repeats until the Reviewer finds no issues or the max round limit is re
 
 1. **Read spec.md** from the artifact directory — extract goals and acceptance criteria.
 2. **Read plan.md** from the artifact directory — extract architecture decisions and completed tasks.
-3. **Capture workspace diff**: run `git diff` (unstaged) + `git diff --cached` (staged) + `git status` to understand the full scope of changes. For new files in git status, note their paths for the Reviewer to read.
+3. **Read dev rules** (if configured): Read `.prizmkit/prizm-docs/root.prizm` and check for a `RULES:` line. If present, read all referenced `.prizmkit/rules/<layer>-rules.md` files. If a referenced file does not exist, skip it silently and continue. These define per-layer conventions that the code should follow.
+4. **Capture workspace diff**: run `git diff` (unstaged) + `git diff --cached` (staged) + `git status` to understand the full scope of changes. For new files in git status, note their paths for the Reviewer to read.
    - If no changes are detected, output PASS and stop.
 
 ## Phase 1: Review-Fix Loop
@@ -41,7 +42,7 @@ The loop repeats until the Reviewer finds no issues or the max round limit is re
 ┌─── Loop (max 3 rounds) ──────────────────────────────┐
 │                                                        │
 │  Step 1: Spawn Reviewer Agent (read-only)              │
-│    → Input: git diff + spec goals + plan decisions     │
+│    → Input: git diff + spec goals + plan decisions + dev rules│
 │    → Output: structured findings or PASS               │
 │                                                        │
 │  Step 2: Check result                                  │
@@ -66,10 +67,10 @@ The loop repeats until the Reviewer finds no issues or the max round limit is re
 
 ### Step 1: Spawn Reviewer Agent
 
-Spawn a **read-only** agent (subagent_type: `Explore`) with the following prompt:
+Include the dev rules read in Phase 0 step 3 in the `## Dev Rules` section of the prompt below. Spawn a **read-only** agent (subagent_type: `Explore`) with the following prompt:
 
 ```
-You are a code reviewer. Review workspace changes against the spec goals and plan decisions.
+You are a code reviewer. Review workspace changes against the spec goals, plan decisions, and per-layer dev rules.
 
 ## Spec Goals
 {goals and acceptance criteria from spec.md}
@@ -77,6 +78,9 @@ You are a code reviewer. Review workspace changes against the spec goals and pla
 ## Plan Decisions
 {architecture decisions and task list from plan.md}
 
+## Dev Rules (per-layer conventions)
+{rules from .prizmkit/rules/<layer>-rules.md, or "No custom dev rules configured — use general best practices."}
+
 ## Review Round
 Round {N}. {round_context}
 
@@ -97,6 +101,7 @@ Evaluate the changes across these dimensions (focus on what's relevant):
 3. **Completeness**: Files that should have been changed but weren't? Missing tests, types, imports, exports?
 4. **Consistency**: Do changes follow the project's existing patterns, naming conventions, and code style?
 5. **Security**: Hardcoded secrets, injection vulnerabilities, unsafe operations.
+6. **Rules compliance**: (Skip this dimension if no dev rules were provided.) Do changes follow the per-layer dev rules? Flag violations of framework conventions, naming patterns, state management, or other rules defined for that layer.
 
 ## Output Format
 Respond with EXACTLY this format:
@@ -108,7 +113,7 @@ Respond with EXACTLY this format:
 
 #### Finding N
 - **Severity**: high | medium | low
-- **Dimension**: goal-alignment | defect | completeness | consistency | security
+- **Dimension**: goal-alignment | defect | completeness | consistency | security | rules-compliance
 - **Location**: filepath:line (or "project-level")
 - **Problem**: What is wrong and why it matters
 - **Suggestion**: Recommended fix approach

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

@@ -31,6 +31,7 @@ Before implementation, load context once:
 
 1. **Task context**: Read `plan.md` (including Tasks section) and `spec.md` from the artifact directory. If other companion documents exist in the directory (e.g., `refactor-analysis.md`), read them for additional context.
 2. **Architecture context**: Read `.prizmkit/prizm-docs/root.prizm` (L0 — project overview, module index, tech stack, conventions) and relevant L1/L2 docs for affected modules. Pay special attention to TRAPS (known pitfalls) and DECISIONS (architectural choices).
+3. **Dev rules** (if configured): Check `.prizmkit/prizm-docs/root.prizm` for a `RULES:` line — if present, read all referenced `.prizmkit/rules/<layer>-rules.md` files. If a referenced file does not exist, skip it silently and continue. These define per-layer conventions (frameworks, naming, patterns, state management, etc.) that AI must follow when generating code for that layer. Apply these rules during implementation — if a rule conflicts with what plan.md describes, call it out and ask the user.
 
 > `.prizmkit/prizm-docs/` uses a 3-level hierarchy: L0 (`root.prizm`) is the project-wide index. L1 (e.g., `auth.prizm`) covers a module — its key files, interfaces, dependencies, traps, and decisions. L2 is for sub-modules with their own complexity. Implement reads these docs to avoid repeating known mistakes; `/prizmkit-retrospective` is responsible for updating them after implementation.
 

package/package.json

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