prizmkit 1.1.54 → 1.1.56

package/bundled/skills/app-planner/references/rules/mobile/template.md

@@ -0,0 +1,175 @@
+# Mobile Rules — {{ project_name }}
+
+> This document was generated by the `mobile-rules` skill on {{ generated_at }}
+> Audience: All mobile developers + all AI coding assistants on this project
+>
+> **Usage**:
+> 1. All AI coding assistants must read this file before generating or modifying any mobile code
+> 2. This document takes precedence over "general best practices" in AI training data
+> 3. Code conflicting with this document must not be committed
+
+---
+
+## 0. TL;DR — Key Decisions at a Glance
+
+| Dimension | Decision |
+|-----------|----------|
+| Platform | {{ platform }} |
+| Min OS Version | {{ min_os_version }} |
+| Architecture Pattern | {{ architecture }} |
+| UI Framework | {{ ui_framework }} |
+| Navigation | {{ navigation }} |
+| State Management | {{ state_management }} |
+| Networking | {{ networking }} |
+| Local Persistence | {{ persistence }} |
+| Push Notifications | {{ push_notifications }} |
+| Background Tasks | {{ background_tasks }} |
+| Permissions Strategy | {{ permissions_strategy }} |
+| Test Coverage | {{ test_coverage }} |
+| Unit Test Framework | {{ unit_test_framework }} |
+| E2E Test Framework | {{ e2e_framework }} |
+| Distribution | {{ distribution }} |
+| Performance Target | {{ performance_target }} |
+| Accessibility Target | {{ a11y_target }} |
+
+---
+
+## 1. Project Structure
+
+{{ FIXED_RULES_STRUCTURE }}
+
+{{ tech_stack_rules }}
+
+---
+
+## 2. UI Development
+
+{{ FIXED_RULES_UI }}
+
+{{ ui_rules }}
+
+---
+
+## 3. Navigation & Deep Linking
+
+{{ FIXED_RULES_NAVIGATION }}
+
+{{ navigation_rules }}
+
+---
+
+## 4. State Management
+
+{{ FIXED_RULES_STATE }}
+
+{{ state_rules }}
+
+---
+
+## 5. Networking
+
+{{ FIXED_RULES_NETWORKING }}
+
+{{ networking_rules }}
+
+---
+
+## 6. Data Persistence
+
+{{ FIXED_RULES_PERSISTENCE }}
+
+{{ persistence_rules }}
+
+---
+
+## 7. Platform Features
+
+{{ FIXED_RULES_PLATFORM_FEATURES }}
+
+{{ platform_features_rules }}
+
+---
+
+## 8. Performance
+
+{{ FIXED_RULES_PERFORMANCE }}
+
+{{ performance_rules }}
+
+---
+
+## 9. Accessibility
+
+{{ FIXED_RULES_A11Y }}
+
+{{ a11y_rules }}
+
+---
+
+## 10. Security
+
+{{ FIXED_RULES_SECURITY }}
+
+---
+
+## 11. Testing
+
+{{ FIXED_RULES_TEST }}
+
+{{ test_rules }}
+
+---
+
+## 12. App Distribution
+
+{{ FIXED_RULES_DISTRIBUTION }}
+
+{{ distribution_rules }}
+
+---
+
+## 13. AI Vibecoding Behavior Constraints
+
+### 13.1 Baseline Constraints (project-agnostic, always active)
+
+{{ FIXED_RULES_AI_BASE }}
+
+### 13.2 Project-Specific Hard Constraints
+
+- **Adding dependencies**: {{ ai_dependency_rule }}
+- **Modifying shared code**: {{ ai_breaking_change_rule }}
+- **Platform-specific code**: {{ ai_platform_rule }}
+
+### 13.3 Mandatory Pre-Actions (before every code generation)
+
+AI must complete the following in order before generating or modifying any mobile code:
+
+1. Read this file (`mobile-rules.md`)
+2. Read existing files in the target feature's directory to confirm whether similar functionality already exists
+3. If modifying shared widgets/components/services, search all callers and assess platform impact
+4. If modifying navigation routes or deep link schemes, assess all entry points
+
+---
+
+## 14. Architecture
+
+{{ arch_rules }}
+
+---
+
+## Appendix A: Deny List (Quick Reference)
+
+> This appendix is auto-generated by AI in Phase 4 by extracting all forbidden entries from each section.
+
+{{ deny_list_summary }}
+
+## Appendix B: Recommended Libraries & Tools
+
+> This appendix is auto-generated by AI in Phase 4 to recommend the supporting ecosystem based on platform and framework choices.
+
+{{ recommended_libs }}
+
+---
+
+**Version**: v1.0 — Generated on {{ generated_at }}
+**Next review recommended**: before tech stack changes or platform migration

package/bundled/skills/prizm-kit/SKILL.md

@@ -18,7 +18,7 @@ Each task begins by reading context at two levels:
 
 **Application level** (read every session):
 - `.prizmkit/prizm-docs/root.prizm` — L0 project architecture index (modules, tech stack, conventions)
-- `.prizmkit/plans/project-brief.md` — user's product vision checklist (generated by app-planner)
+- `.prizmkit/plans/project-brief.md` — user's product vision checklist (generated during project initialization)
 - `.prizmkit/config.json` — tech stack config, deploy strategy
 
 **Task level** (read for the specific task):

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/bundled/skills/prizmkit-init/SKILL.md

@@ -90,9 +90,22 @@ BROWNFIELD WORKFLOW (existing project):
 
    **IMPORTANT**: Not all projects have all fields. A pure backend API will have no `frontend_framework` or `frontend_styling`. A library may have no database. Only record what is actually detected — never generate empty or placeholder values.
 
-**Phase 4.5: Infrastructure Quick Scan**
+**Phase 4.5: Layer Detection**
 
-Detect database and deployment signals, then ask 1-2 brief questions. This phase is **optional** — users can skip and configure later via `app-planner` or `/prizmkit-deploy`.
+After tech stack detection, determine which development layers exist in the project — these are code domains that may benefit from custom dev rules (frontend, backend, database, mobile). This is a quick detection step, not an interactive Q&A — rules can be configured later based on detected layers.
+
+1. Read `${SKILL_DIR}/references/rules/layer-detection.md` for the detection signal table and AI judgment guidelines.
+2. Scan the project against each signal, and supplement with your own judgment — the signal table is a guide, not exhaustive. If you see clear evidence of a layer not covered by the table, include it. If a signal matches but context is misleading, downgrade or ignore it:
+   - **frontend**: React/Vue/Angular/etc. in dependencies, or `src/components/` with UI files
+   - **backend**: Express/FastAPI/Gin/etc. in dependencies, or `routes/`/`controllers/` with server code
+   - **database**: Prisma/TypeORM/SQLAlchemy/etc. in dependencies, or `migrations/`/`prisma/` directory
+   - **mobile**: `pubspec.yaml` (Flutter), `react-native` in package.json, or simultaneous `ios/`+`android/` directories
+3. For mobile signals — if ambiguous (e.g., monorepo with web + ios/android dirs), use `AskUserQuestion` to confirm: "Mobile platform signals detected. Is this project a mobile app?" Options: "Yes, this is a mobile app" / "No, these are for another purpose".
+4. Assemble `detected_layers` array (e.g., `["frontend", "backend", "database"]`). If no layers detected (library/CLI project), array is empty.
+
+**Phase 4.6: Infrastructure Quick Scan**
+
+Detect database and deployment signals, then ask 1-2 brief questions. This phase is **optional** — users can skip and configure later.
 
 - **BROWNFIELD**: Auto-detect infrastructure signals from existing files, then ask 1-2 brief questions (pre-filled with detection results)
 - **GREENFIELD**: No auto-detection possible — ask the 2 brief questions directly (database need and deployment target)
@@ -136,7 +149,7 @@ Detect database and deployment signals, then ask 1-2 brief questions. This phase
      #### Deployment
      - **Target**: [platform name or "undecided"]
      ```
-     → This is intentionally minimal (Quick Scan). Full conventions and deployment details will be added by app-planner or prizmkit-deploy later.
+     → This is intentionally minimal (Quick Scan). Full conventions and deployment details can be added later.
    - If user selects "Skip — decide later" for BOTH topics: write deferred marker instead:
      ```markdown
      ### Infrastructure
@@ -148,6 +161,20 @@ Detect database and deployment signals, then ask 1-2 brief questions. This phase
      <!-- database: deferred -->
      ```
 
+**Phase 4.7: Rules Quick Entry**
+
+After Infrastructure Quick Scan completes, check if `detected_layers` is non-empty (from Phase 4.5). If layers were detected, offer a lightweight entry point for rules configuration.
+
+1. If `detected_layers` is empty (library/CLI project) → skip this phase entirely, proceed to Phase 5.
+2. If layers detected, use `AskUserQuestion`:
+
+   **Question**: "Detected **{list detected layers}** code. Would you like to set up custom development rules for AI to follow? This helps AI generate code that matches your conventions."
+   - **Configure later (Recommended)** — Record layers and configure rules later
+   - **Skip entirely** — no custom rules, AI uses general best practices
+
+3. If user picked "Skip entirely" → clear `detected_layers` to empty array, proceed to Phase 5.
+4. If user picked "Configure later" → keep `detected_layers`, proceed to Phase 5. The layers will be written to config.json in Phase 6.
+
 **Phase 5: Prizm Documentation Generation**
 Invoke prizmkit-prizm-docs (Init operation), passing the two-tier module structure from Phase 4:
   - Create `.prizmkit/prizm-docs/` directory structure mirroring the source tree (sub-module dirs become subdirectories under `.prizmkit/prizm-docs/<top-level>/`)
@@ -166,6 +193,12 @@ Invoke prizmkit-prizm-docs (Init operation), passing the two-tier module structu
 6b. Write detected tech stack to `.prizmkit/config.json`:
    → Read `${SKILL_DIR}/references/config-schema.md` for merge strategy, field definitions, and examples.
 
+6c. Write `detected_layers` to `.prizmkit/config.json` (alongside `tech_stack`):
+   - Field: `"detected_layers": ["frontend", "backend"]` — the layers from Phase 4.5
+   - If user chose "Skip entirely" in Phase 4.7, write empty array `[]`
+   - For greenfield projects (Phase 4.5 skipped): write `[]` — no code layers to configure rules for yet; user can configure rules later when code exists
+   - This field indicates which development layers exist in the project and can be used to determine available rule configuration options.
+
 **Phase 7: Project Brief Generation**
 
 If action for project brief == skip, output "Project brief: skipped (exists)" and proceed to Phase 8 (Report).
@@ -225,11 +258,12 @@ Saved to: `.prizmkit/config.json` → `tech_stack` field
 Next step: "Use `/prizmkit-plan` to start your first feature"
 
 GREENFIELD WORKFLOW (new project):
-- Skip Phase 4 (no code to scan) — but ask the user about their intended tech stack:
+- Skip Phase 4 code scanning (no code to scan — Phase 4.5 Layer Detection and Phase 4.7 Rules Quick Entry are skipped; no layers to detect yet):
+  - Ask the user about their intended tech stack:
   - "What language/framework will you use?" (e.g. React + Node.js, Python + FastAPI, etc.)
   - Record answers in `config.json` `tech_stack` with `"_auto_detected": false` (user-provided, not auto-detected)
   - If user is unsure, skip tech_stack — it can be populated later on re-init after code exists
-- Phase 4.5: Run Infrastructure Quick Scan — in greenfield mode, no auto-detection is possible, so only ask the 2 brief questions (database need and deployment target). If user is unsure, skip — these can be configured later via `app-planner` or `/prizmkit-deploy`.
+- Phase 4.6: Run Infrastructure Quick Scan — in greenfield mode, no auto-detection is possible, so only ask the 2 brief questions (database need and deployment target). If user is unsure, skip — these can be configured later.
 - Phase 5: Create minimal `.prizmkit/prizm-docs/` with just `root.prizm` skeleton (populate TECH_STACK from user answers if provided)
 - Phase 7: Generate project brief (greenfield flow — ask user about project goals, see Phase 7 above)
 - Phases 6, 8: Same as brownfield (Phase 8 Report recommends `/prizmkit-plan` for first feature)
@@ -259,11 +293,18 @@ Tech stack detected:
   Bundler:      Vite
   Project type: fullstack
 
+Layer Detection:
+  Detected layers: frontend, backend, database (from dependency + directory signals)
+  → Stored for config.json
+
 Infrastructure Quick Scan:
   Database: PostgreSQL (Prisma) — detected from dependencies
   Deployment: Vercel — detected from vercel.json
   → Written to CLAUDE.md ### Infrastructure
 
+Rules Quick Entry:
+  Matched layers: frontend (React), backend (Express.js), database (Prisma) → keeping default rules
+
 Modules discovered:
   src/routes/     → .prizmkit/prizm-docs/routes.prizm (12 files)
   src/models/     → .prizmkit/prizm-docs/models.prizm (8 files)
@@ -274,7 +315,7 @@ Project brief: inferred from codebase → confirmed by user
   → .prizmkit/plans/project-brief.md
 
 Generated: root.prizm + 4 L1 docs + changelog.prizm
-Saved: .prizmkit/config.json (tech_stack recorded)
+Saved: .prizmkit/config.json (tech_stack + detected_layers recorded)
 
 Next: Use /prizmkit-plan to start your first feature
 ```

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

@@ -7,10 +7,11 @@ 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)
+  → **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`
+  → **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
@@ -21,6 +22,7 @@ Handles re-init without losing user edits:
 | `platform` | string | `"codebuddy"` \| `"claude"` \| `"both"` |
 | `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). |
 
 ## Examples
 
@@ -29,6 +31,7 @@ Fullstack project:
 {
   "adoption_mode": "passive",
   "platform": "claude",
+  "detected_layers": ["frontend", "backend", "database"],
   "tech_stack": {
     "language": "TypeScript",
     "runtime": "Node.js 20",
@@ -59,6 +62,7 @@ Pure Python backend:
     "testing": "pytest",
     "project_type": "backend",
     "_auto_detected": true
-  }
+  },
+  "detected_layers": ["backend", "database"]
 }
 ```

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

@@ -0,0 +1,41 @@
+# 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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prizmkit",
-  "version": "1.1.54",
+  "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": {