prizmkit 1.1.53 → 1.1.55

package/bin/create-prizmkit.js

@@ -41,6 +41,8 @@ program
   .option('--no-playwright-cli', 'Disable playwright-cli installation')
   .option('--open-cli', 'Install opencli browser tool (default: true)')
   .option('--no-open-cli', 'Disable opencli installation')
+  .option('--open-cli-auto-download', 'Auto-download opencli extension if missing (default: true)')
+  .option('--no-open-cli-auto-download', 'Skip auto-download, show manual steps only')
   .option('--rules <preset>', 'Rules preset: recommended, minimal, or none', 'recommended')
   .option('--ai-cli <command>', 'AI CLI executable command (e.g. cbc, claude, claude-internal)')
   .option('--external-skills <names>', 'Comma-separated external skill names to install (e.g. find-skills,impeccable)')

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.53",
-  "bundledAt": "2026-05-24T05:20:15.152Z",
-  "bundledFrom": "156de40"
+  "frameworkVersion": "1.1.55",
+  "bundledAt": "2026-05-25T01:36:43.012Z",
+  "bundledFrom": "0664e65"
 }

package/bundled/rules/_rules-metadata.json

@@ -16,6 +16,10 @@
     "general/prefer-linux-commands": {
       "description": "Prefer Linux/Unix shell commands",
       "tags": ["general", "shell"]
+    },
+    "general/cohesive-modeling": {
+      "description": "Group co-occurring variables/fields/concepts into a cohesive unit (struct/class/interface)",
+      "tags": ["general", "design"]
     }
   },
   "presets": {
@@ -25,7 +29,8 @@
         "prizm/prizm-documentation",
         "prizm/prizm-commit-workflow",
         "prizm/prizm-progressive-loading",
-        "general/prefer-linux-commands"
+        "general/prefer-linux-commands",
+        "general/cohesive-modeling"
       ]
     },
     "minimal": {

package/bundled/rules/general/cohesive-modeling.md

@@ -0,0 +1,27 @@
+---
+description: "将总是同时出现的变量/字段/概念建模为高内聚的整体，而非散落碎片"
+---
+
+在设计或理解任何系统时，如果一组变量、字段、概念总是同时出现、表达同一个语义单元，就应该把它们规划成一个整体，而不是散落为独立的碎片：
+
+- **Go** — 定义 struct
+- **Java/Python** — 定义 class
+- **TypeScript** — 定义 interface/type
+- **配置** — 归入嵌套配置块
+- **模块划分** — 拆为独立模块
+
+本质是同一个原则：**高内聚的东西，在建模那一刻就应该是一个东西。**
+
+## 触发场景
+
+1. 同一个函数/方法的参数列表中，某几个参数始终一起传递 → 抽取为参数对象
+2. 多个变量总是被一起赋值、一起传递、一起返回 → 合并为结构体/类
+3. 配置文件中一组键总是成对/成群出现 → 合并为嵌套配置块
+4. 发现自己在不同文件里重复声明相同的一组字段 → 提取为公共类型/接口
+5. 修改一个值就必须同步修改另一个值 → 它们属于同一个不变量，应封装在一起
+
+## 反面模式（应避免）
+
+- 基本类型偏执（Primitive Obsession）：用散落的 string/number 代替有意义的类型
+- 数据泥团（Data Clumps）：相同的一组数据在参数列表、返回值、变量声明中反复出现
+- 霰弹式修改（Shotgun Surgery）：加一个字段需要改 N 个文件的函数签名

package/bundled/skills/_metadata.json

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

@@ -1,6 +1,6 @@
 ---
 name: "app-planner"
-description: "Plan an application through interactive conversation — capture vision, tech stack, constraints, and project brief. Works for both new (greenfield) and existing (brownfield) projects that need app-level planning. Use this skill when users say 'plan an app', 'design a new project', 'start from scratch', 'build a new application', or discuss app-level architecture and design. Also use for existing projects that need a project brief or app-level context. For adding features to existing projects that already have a project brief, use feature-planner instead."
+description: "Plan an application through interactive conversation — capture vision, tech stack, constraints, dev rules, and project brief. Works for both new (greenfield) and existing (brownfield) projects that need app-level planning. Also use for configuring per-layer development rules (frontend/backend/database/mobile) that AI coding assistants should follow. Use this skill when users say 'plan an app', 'design a new project', 'start from scratch', 'build a new application', 'set up dev rules', 'configure frontend rules', 'configure backend rules', or discuss app-level architecture and design. Also use for existing projects that need a project brief or app-level context. For adding features to existing projects that already have a project brief, use feature-planner instead."
 ---
 
 # app planner
@@ -29,7 +29,7 @@ If you believe the task is better suited for a different workflow, you MUST:
 
 **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
+- Create project scaffolding, directories, or boilerplate (exception: `.prizmkit/rules/` and `.prizmkit/prizm-docs/` directories may be created for dev rules and root.prizm output)
 - Run build/install/test commands (npm init, pip install, etc.)
 - Execute any implementation action beyond writing planning artifacts
 
@@ -37,6 +37,8 @@ If you believe the task is better suited for a different workflow, you MUST:
 1. `.prizmkit/plans/project-brief.md` (`.prizmkit/plans/` — accumulated project context brief)
 2. Project conventions and architecture decisions appended to `CLAUDE.md` / `CODEBUDDY.md` (with user consent)
 3. Infrastructure configuration (database conventions, deployment config, **cloud services**) appended to `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` section
+4. `.prizmkit/rules/<layer>-rules.md` — per-layer development rules generated by Rules Configuration
+5. `.prizmkit/prizm-docs/root.prizm` — `RULES:` pointer line only (not other root.prizm content; created minimally if absent)
 
 **After planning is complete**, you MUST:
 1. Present the summary of captured project-level context (vision, conventions, architecture decisions, project brief)
@@ -128,7 +130,7 @@ Do NOT use this skill when:
 
    After project conventions are captured, check `CLAUDE.md` / `CODEBUDDY.md` for `### Infrastructure` section:
 
-   - If `### Infrastructure` section does not exist → this project was not initialized with prizmkit-init's Phase 4.5. Treat as if both database and deployment are undecided — run full inquiry below.
+   - If `### Infrastructure` section does not exist → this project was not initialized with prizmkit-init's Phase 4.6. Treat as if both database and deployment are undecided — run full inquiry below.
    - If `<!-- infrastructure: deferred -->` → user explicitly skipped at init time. Ask: "During project init you deferred infrastructure decisions. Would you like to configure them now?" (options: "Yes — configure now (Recommended)", "Skip — decide later")
    - If `<!-- database: deferred -->` → only database was deferred, run database inquiry only
    - If `<!-- deployment: deferred -->` or deployment section is missing → run deployment inquiry only
@@ -232,6 +234,112 @@ Do NOT use this skill when:
    → Read `${SKILL_DIR}/references/project-brief-guide.md` for template and rules
    → Update after each meaningful user response containing business intent, constraints, or design decisions
 
+## Rules Configuration (after Infrastructure)
+
+After Infrastructure configuration is complete (CP-AP-1.5), check whether the project's development layers have custom rules configured. Rules are per-layer documents (frontend-rules.md, backend-rules.md, database-rules.md, mobile-rules.md) that tell AI coding assistants how to generate code for that layer — UI framework, state management, naming conventions, etc.
+
+Rules are optional. If the user skips, AI uses general best practices freely — no reminders, no blocking.
+
+### Step 1: Detect missing 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:
+   - `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:
+
+   ```
+   Rules Status Check:
+     [missing] frontend-rules.md — frontend code detected, no rules configured
+     [exists]  backend-rules.md  — already configured
+     [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.
+
+### Step 2: Ask configuration mode
+
+Use `AskUserQuestion`:
+
+**Question**: "{N} layer(s) without custom dev rules. How would you like to configure?"
+- **Quick setup (only core decisions, rest use recommended defaults)** — covers essential architecture, core technology decisions, and testing questions specific to each layer. Detailed configuration topics (design-system, i18n, performance tuning, deployment details, AI constraints) adopt recommended defaults. See Step 4 for exact per-layer coverage.
+- **Full setup (customize every detail)** — 15-25 questions per layer
+- **Skip — no custom rules needed**
+
+If user picks "Skip" → proceed to Prerequisites.
+
+### Step 3: Select layers to configure
+
+Use `AskUserQuestion` (multiSelect):
+
+**Question**: "Which layers do you want to configure?"
+- Options: the missing layers from Step 1, each with a brief description
+- All pre-selected by default
+
+### Step 4: Configure each selected layer
+
+For each selected layer, run the rules Q&A workflow. This follows the 4-phase rule generation pattern:
+
+**Phase A — Load layer resources:**
+- Read `${SKILL_DIR}/references/rules/<layer>/fixed-rules.md` — industry-consensus rules injected without asking
+- Read `${SKILL_DIR}/references/rules/<layer>/question-bank.md` — interactive questions organized in groups (G1→G10)
+
+**Phase B — Interactive Q&A:**
+- Ask questions one group at a time (max 3 questions per message), as defined in question-bank.md
+- Each question shows a "Recommended" option to reduce decision cost
+- **Quick mode**: ask only the following groups per layer. All other groups adopt recommended defaults silently.
+  - **Frontend**: G1 (Tech Stack), G2 (Styling), G3 (State & Data Fetching), G7 (Testing & Quality). Skip: G4 (Design System), G5 (Responsive), G6 (i18n), G8 (AI Vibecoding), G9 (Performance).
+  - **Backend**: G1 (Language & Runtime), G2 (Framework & Architecture), G3 (API Style), G4 (Data Layer), G7 (Testing & Quality). Skip: G5 (Auth), G6 (Infrastructure), G8 (Observability), G9 (AI Constraints).
+  - **Database**: G1 (Database Selection), G2 (Data Modeling), G3 (Migration), G7 (AI Constraints). Skip: G4 (Index & Performance), G5 (Security & Compliance), G6 (High Availability & Ops).
+  - **Mobile**: G1 (Platform & Language), G2 (Architecture), G3 (UI Framework), G4 (Navigation & State), G7 (Testing). Skip: G5 (Networking & Data), G6 (Platform Features), G8 (App Distribution), G9 (Performance & Accessibility), G10 (AI Constraints).
+- **Full mode**: ask all groups in order (G1→G9 for frontend/backend, G1→G7 for database, G1→G10 for mobile)
+- Shortcut commands work at any point:
+  - `recommended` / `default` → adopt all recommended for current group
+  - `all recommended` → adopt all recommended for all remaining groups
+  - `skip` → mark current group as "Not required at this stage"
+- Record answers in memory after each group.
+
+**Phase C — Auto-derivation:**
+- Read `${SKILL_DIR}/references/rules/<layer>/derivation-rules.md`
+- Match user answers against the trigger map using keyword matching
+- Derive platform-specific rules without asking the user (e.g., choosing Flutter → auto-inject Flutter widget/persistence/navigation rules)
+
+**Phase D — Render and write:**
+- Read `${SKILL_DIR}/references/rules/<layer>/template.md`
+- Fill all template placeholders with accumulated content from Phases A+B+C
+- **Post-render self-check**: scan for residual `{{ ` or ` }}` — count must be 0 before writing
+- Generate Appendix A (Deny List) and Appendix B (Recommended Tools) per template instructions
+- Create `.prizmkit/rules/` directory if it doesn't exist
+- Write `.prizmkit/rules/<layer>-rules.md`
+
+### Step 5: Update root.prizm
+
+After all selected layers are configured:
+1. Check if `.prizmkit/prizm-docs/root.prizm` exists.
+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 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:
+     ```
+     PRIZM_VERSION: 2
+     PROJECT: <name>  — from package.json name, directory name, or git repo name
+     MODULE_INDEX:
+     RULES: .prizmkit/rules/<layer>-rules.md, ...
+     ```
+   - The file will be expanded when the project later runs `prizmkit-prizm-docs init`.
+4. The RULES pointer tells every AI session where to find custom dev rules — AI reads rules via this pointer on session start
+
+### After rules configuration
+
+Proceed to Prerequisites and continue the app-planner workflow.
+
 ## Prerequisites
 
 Before questions, check optional context files (never block if absent):
@@ -421,6 +529,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-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 |
@@ -433,7 +542,7 @@ After Phase 2, if framework-shaping architecture decisions emerged during planni
 **How it works**:
 1. If decisions are captured → append to `CLAUDE.md` / `CODEBUDDY.md` under `### Architecture Decisions` section
 2. Downstream skills (feature-planner, prizmkit-plan, etc.) read `CLAUDE.md` / `CODEBUDDY.md` as standard context, so they automatically receive these decisions
-3. Do NOT write directly to `.prizmkit/prizm-docs/root.prizm` — that file is maintained by `prizmkit-prizm-docs` and `prizmkit-retrospective`. If the project needs `.prizmkit/prizm-docs/`, recommend the user run `prizmkit-prizm-docs` init after planning.
+3. Do NOT write architecture decision content directly to `.prizmkit/prizm-docs/root.prizm` — that file is maintained by `prizmkit-prizm-docs` and `prizmkit-retrospective`. (The `RULES:` pointer line is managed by Rules Configuration, not by this section.) If the project needs `.prizmkit/prizm-docs/`, recommend the user run `prizmkit-prizm-docs` init after planning.
 
 ## Project Brief Accumulation
 
@@ -469,6 +578,7 @@ After all checkpoints pass, present a summary and end the session:
    - Infrastructure config → `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` (database conventions + deployment config)
    - Tech stack → `.prizmkit/config.json`
    - Architecture decisions (if any) → `CLAUDE.md` / `CODEBUDDY.md` `### Architecture Decisions`
+   - Dev rules (if configured) → `.prizmkit/rules/<layer>-rules.md` (with `root.prizm` `RULES:` pointer)
    - Project brief → `.prizmkit/plans/project-brief.md`
 
 2. **Suggest possible next steps** (as text, NOT auto-invoked):