prizmkit 1.0.148 → 1.0.149

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.0.148",
-  "bundledAt": "2026-03-31T16:37:46.664Z",
-  "bundledFrom": "b56218a"
+  "frameworkVersion": "1.0.149",
+  "bundledAt": "2026-03-31T17:50:05.806Z",
+  "bundledFrom": "9c1abf7"
 }

package/bundled/adapters/claude/command-adapter.js

@@ -103,8 +103,9 @@ export async function installCommand(corePath, targetRoot) {
   const hasAssets = existsSync(path.join(corePath, 'assets'));
   const hasScripts = existsSync(path.join(corePath, 'scripts'));
   const hasRules = existsSync(path.join(corePath, 'rules'));
+  const hasReferences = existsSync(path.join(corePath, 'references'));
 
-  if (hasAssets || hasScripts || hasRules) {
+  if (hasAssets || hasScripts || hasRules || hasReferences) {
     // Use directory structure for commands with resources
     const targetDir = path.join(targetRoot, COMMANDS_DIR, skillName);
     mkdirSync(targetDir, { recursive: true });
@@ -118,7 +119,7 @@ export async function installCommand(corePath, targetRoot) {
     }
 
     // Copy assets and scripts
-    for (const subdir of ['scripts', 'assets', 'rules']) {
+    for (const subdir of ['scripts', 'assets', 'rules', 'references']) {
       const srcSubdir = path.join(corePath, subdir);
       if (existsSync(srcSubdir)) {
         cpSync(srcSubdir, path.join(targetDir, subdir), { recursive: true });

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.0.148",
+  "version": "1.0.149",
   "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/references/architecture-decisions.md

@@ -0,0 +1,48 @@
+# Architecture Decision Capture
+
+During planning, key **framework-level** architectural decisions may emerge. When they do, capture them in the project instruction file so all future AI sessions have this context.
+
+## What Qualifies (ALL must apply)
+
+Only capture decisions that are **framework-shaping** — NOT individual feature details. Qualifying categories:
+
+| Category | Examples |
+|----------|----------|
+| Tech stack choices | PostgreSQL over MongoDB, React over Vue, Node.js runtime |
+| Communication patterns | REST vs GraphQL, WebSocket vs SSE vs polling |
+| Architectural patterns | Monorepo, microservices, monolith, event-driven |
+| Data model strategies | Relational vs document, event sourcing, CQRS |
+| Security architecture | JWT vs session, OAuth provider, RBAC model |
+
+**Do NOT capture**: individual feature implementation details, UI component choices, specific API endpoint designs, or anything scoped to a single feature.
+
+**This is conditional** — most planning sessions will NOT produce architecture decisions. Only capture when genuinely impactful decisions are made during the discussion.
+
+## When to Capture
+
+After Phase 5 (DAG verification), before Phase 6 (JSON generation). At this point decisions are settled.
+
+## How to Capture
+
+1. **Detect platform** — determine which project instruction file to update:
+   - `.claude/` directory exists → append to `CLAUDE.md`
+   - `.codebuddy/` directory exists → append to `CODEBUDDY.md`
+   - Both exist → append to both
+   - Neither exists → skip (no project instruction file)
+
+2. **Check for existing section** — read the target file and look for `### Architecture Decisions` heading:
+   - If heading exists → append new entries below it (avoid duplicates with existing entries)
+   - If heading does not exist → create it at the end of the file
+
+3. **Format** — one line per decision, no feature IDs:
+   ```markdown
+   ### Architecture Decisions
+   - WebSocket for real-time: sub-second latency required for collaboration features
+   - PostgreSQL: relational data model with complex queries, ACID compliance needed
+   - Monorepo structure: shared types between frontend and backend
+   ```
+
+4. **User confirmation** — before writing, show the collected decisions and ask:
+   > "These architecture decisions were identified during planning. Record them to [CLAUDE.md / CODEBUDDY.md]? (Y/n)"
+
+   If user declines, skip without further prompting.

package/bundled/skills/app-planner/references/brainstorm-guide.md

@@ -0,0 +1,101 @@
+# Brainstorm Guide — Structured Ideation Before Implementation
+
+> Separate WHAT from HOW. Explore the problem space before committing to a solution.
+
+This guide provides the structured brainstorming framework used in Phase 1 of the workflow.
+The AI facilitates this process as a **design collaborator**, not a builder.
+
+## Four Phases
+
+### Phase A: Assess Clarity
+
+Evaluate the user's initial goal statement:
+
+- **Clear** — Specific and actionable (e.g., "add JWT auth to the API")
+- **Vague** — Direction exists but needs narrowing (e.g., "improve security")
+- **Exploring** — No firm goal yet, just a direction (e.g., "something with auth")
+
+If **vague** or **exploring**, ask follow-up questions to sharpen the goal.
+Do NOT proceed until there is a concrete, testable problem statement (one sentence).
+
+### Phase B: Understand the Idea
+
+Answer these questions (use codebase exploration as needed):
+
+1. **What problem does this solve?** — State the pain point in concrete terms.
+2. **Who benefits?** — End users, developers, operators?
+3. **What exists today?** — Current state, prior art in the codebase, adjacent systems.
+4. **What constraints matter?** — Performance, compatibility, security, timeline.
+
+Non-functional requirements to explicitly clarify or propose defaults for:
+- Performance expectations
+- Scale (users, data, traffic)
+- Security or privacy constraints
+- Reliability / availability needs
+- Maintenance and ownership expectations
+
+If the user is unsure on any point, propose reasonable defaults and clearly mark them as **assumptions**.
+
+Summarize findings before moving on. If anything is unclear, ask.
+
+### Phase C: Explore Approaches
+
+Generate **2-3 distinct approaches**. For each:
+
+- **Name** — Short label (e.g., "JWT middleware", "OAuth proxy")
+- **How it works** — 2-3 sentences
+- **Pros** — What it gets right
+- **Cons** — What it gets wrong or defers
+- **Effort** — Rough scope (small / medium / large)
+
+#### Adversarial Critique (Red Team)
+
+Before asking the user to choose, stress-test each approach using the red team checklist
+(`references/red-team-checklist.md`):
+
+1. What breaks first?
+2. What's the hidden cost?
+3. What assumption is wrong?
+4. Who disagrees?
+
+Mark any approach that fails 2+ red team questions as **HIGH RISK**.
+If all approaches fail, generate a hybrid addressing the weaknesses.
+
+Present the comparison and let the user pick an approach or request a hybrid.
+
+### Phase D: Capture Design
+
+Produce a structured summary:
+
+```markdown
+## Problem Statement
+[One sentence, testable]
+
+## Approaches Considered
+[2-3 approaches with pros/cons/effort]
+
+## Selected Approach
+[User's choice + rationale]
+
+## Assumptions
+[All assumptions explicitly listed]
+
+## Open Questions
+[Unresolved items, if any]
+
+## Key Decisions
+[What was decided and why — alternatives and rationale]
+```
+
+This summary becomes the input for the next phase (specification or planning).
+
+---
+
+## Rules
+
+- Ask as many questions as needed — no rushing
+- One topic at a time for complex clarifications
+- Prefer multiple-choice questions when possible
+- Assumptions must be explicit, never silent
+- YAGNI ruthlessly — avoid premature complexity
+- Do NOT implement, code, or modify behavior during brainstorming

package/bundled/skills/app-planner/references/browser-interaction.md

@@ -0,0 +1,34 @@
+# Browser Interaction Planning
+
+For web apps with UI, features that involve user-facing pages or interactive flows can optionally include a `browser_interaction` field. This enables the dev-pipeline to verify UI behavior automatically using `playwright-cli` after implementation.
+
+## How to Capture
+
+During Phase 4 (refine descriptions and acceptance criteria), for qualifying features ask:
+
+> "This feature has UI behavior. Want to add browser verification so the pipeline can auto-check it after implementation? (Y/n)"
+
+If yes, generate the `browser_interaction` object:
+
+```json
+{
+  "browser_interaction": {
+    "url": "http://localhost:3000/login",
+    "setup_command": "npm run dev",
+    "verify_steps": [
+      "snapshot",
+      "click <ref> — click login button",
+      "fill <ref> 'test@example.com' — enter email",
+      "screenshot"
+    ],
+    "screenshot": true
+  }
+}
+```
+
+## Field Rules
+
+- `url` is required — the page URL to verify
+- `setup_command` is optional — command to start dev server (omit if already running)
+- `verify_steps` are descriptive placeholders — the actual `ref` IDs are resolved at runtime by `playwright-cli snapshot`. Use natural language descriptions (e.g., "click login button") that the pipeline agent will map to real refs.
+- `screenshot` defaults to `true` — capture final state for human review

package/bundled/skills/app-planner/references/error-recovery.md

@@ -0,0 +1,109 @@
+# Error Recovery & Resume Support
+
+Structured error handling for validation failures, interrupted sessions, and checkpoint-based resumption.
+
+## Validation Failures
+
+When `python3 scripts/validate-and-generate.py validate --input <file> --mode <mode>` returns errors:
+
+### Parse validation output
+Script returns JSON with `"valid": false`, `"errors": [...]`, `"warnings": [...]`
+
+### Decision Tree
+
+**if `error_count == 0` (warnings only):**
+- Proceed with user approval
+- Show warnings and ask: "Continue? (Y/n)"
+
+**elif `error_count > 0` (critical errors):**
+
+Group errors by type and apply targeted fixes:
+
+| Error Type | Symptom | Fix Offered | Auto-Fix? |
+|-----------|---------|------------|-----------|
+| **Schema mismatch** | `$schema` invalid, missing `app_name`, wrong `features` type | "Set `$schema` to `dev-pipeline-feature-list-v1`, `app_name` to string" | Yes |
+| **Feature ID issues** | Invalid format (not `F-NNN`), duplicate IDs, undefined refs | "Suggest corrected IDs, show duplicates" | Yes |
+| **Dependency errors** | Circular dependency, undefined target features | "Show cycle chain (e.g., `F-003 → F-005 → F-003`), suggest break point" | No |
+| **Missing fields** | Feature missing required keys (title, description, AC) | "List each feature + missing keys, guide patch" | Partial |
+| **Insufficient AC** | Feature has <2 acceptance criteria | "Show feature, suggest AC examples" | No |
+| **Invalid values** | complexity not in [low/medium/high], status not pending | "Show field, valid values" | Yes |
+
+### Execution
+
+```
+For auto-fixable errors:
+  1. Show summary: "Found N schema/ID/format issues"
+  2. Offer: auto-fix? (Y/n)
+  3. Apply fix → regenerate file
+  4. Re-run validation
+  5. If new errors → loop (max 2 more attempts)
+
+For manual fixes (dependencies, AC content):
+  1. Show concise prompt: "Edit line X-Y in feature-list.json"
+  2. Wait for user action
+  3. Retry validation (max 2 more attempts)
+
+if all_retries_exceeded:
+  → Escalate: "After 3 attempts, validation still fails.
+              (a) Review file manually, OR
+              (b) Restart planning from Phase 1"
+```
+
+## Resume Support
+
+App-planner sessions can be resumed from the last completed checkpoint without losing context.
+
+### Detection Logic
+
+Check for artifact files in working directory:
+
+| Artifacts Found | Last Completed Checkpoint | Next Phase | Resume Action |
+|-----------------|--------------------------|-----------|----------------|
+| None | (new session) | Phase 1: Vision | Start fresh planning |
+| `feature-list.json` exists | CP-AP-6 (file generated) | Phase 7: Final validation | Offer to validate or extend |
+| `feature-list.json` + validation passed | CP-AP-7 (validation pass) | Handoff: dev-pipeline | Offer: execute pipeline now |
+| Partial state (incomplete file) | CP-AP-2 or CP-AP-4 | Next phase after last checkpoint | Resume interactive planning |
+| User restarts mid-session | User says "restart" | Return to Phase 1 Vision, or load previous checkpoint if requested |
+| Max validation retries exceeded | 3 failed validation loops | Offer: (a) manual review, (b) restart from Phase 1 |
+
+### Resume Command (Project Structure)
+
+For projects using `.prizmkit/` structure:
+
+```bash
+# Explicit resume (if file is not in current directory):
+app-planner --resume-from <path-to-existing-feature-list.json>
+```
+
+AI detects existing file → suggests:
+```
+"Existing plan found with N features, M newly added.
+Resume incremental planning? (Y/n)"
+```
+
+### Incremental Mode Abort
+
+If in Incremental mode but existing `feature-list.json` not found:
+- Ask: "Start new plan or provide existing file?"
+- If new plan chosen → switch to Route A (New App Planning)
+- If existing file uploaded → continue Route B
+
+### Artifact Path Convention
+
+**CRITICAL PATH RULE**: `feature-list.json` MUST be written to the project root directory
+(same level as `package.json` / `.git`).
+
+Before writing, verify: `ls package.json .git 2>/dev/null` — if these exist in the current
+directory, you are at the project root. NEVER write to `dev-pipeline/` or any subdirectory.
+
+After writing, verify: `ls -la feature-list.json` from project root.
+
+```
+<project-root>/
+  ├── feature-list.json              # Primary output (always here, at project root)
+  └── .prizmkit/planning/            # Optional organization for backups
+      ├── feature-list.validated.json    # Checkpoint backup after CP-AP-7
+      └── <ISO-timestamp>.backup.json    # Optional incremental backups
+```
+
+The pipeline reads `feature-list.json` from the project root by default. If the user specifies a custom path, the launcher accepts it as an argument.

package/bundled/skills/app-planner/references/frontend-design-guide.md

@@ -0,0 +1,71 @@
+# Frontend Design Guide — High-Quality UI Implementation
+
+> Create distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics.
+
+**App-planner context**: In the planning phase, use this guide to establish **design direction decisions** (aesthetic tone, typography approach, color strategy, layout philosophy). Do NOT produce CSS, code, or implementation artifacts — capture the design direction as decisions in the project instruction file (`CLAUDE.md` / `CODEBUDDY.md`). Downstream implementation skills will consume these decisions when building features.
+
+Load this guide **only when the feature involves frontend/UI work**. Skip for backend-only or infrastructure features.
+
+## Context Gathering (Required Before Design)
+
+Before any UI design work, gather:
+- **Target audience**: Who uses this product and in what context?
+- **Use cases**: What jobs are they trying to get done?
+- **Brand personality/tone**: How should the interface feel?
+
+You cannot infer this from codebase alone — ask the user.
+
+## Design Direction
+
+Commit to a **bold** aesthetic direction:
+- **Purpose**: What problem does this interface solve? Who uses it?
+- **Tone**: Pick an intentional aesthetic — minimalist, editorial, brutalist, organic, luxury, playful, retro-futuristic, industrial, art deco, etc.
+- **Differentiation**: What makes this unforgettable?
+
+## Typography
+
+- Choose distinctive fonts. Pair a display font with a refined body font.
+- Use a modular type scale with fluid sizing (`clamp()`)
+- Vary font weights and sizes for clear visual hierarchy
+- Avoid overused fonts: Inter, Roboto, Arial, Open Sans, system defaults
+- Avoid monospace as lazy shorthand for "technical" vibes
+
+## Color & Theme
+
+- Use modern CSS color functions (oklch, color-mix, light-dark)
+- Tint neutrals toward brand hue for subconscious cohesion
+- Avoid: pure black (#000) or pure white (#fff) — always tint
+- Avoid: the AI palette (cyan-on-dark, purple-to-blue gradients, neon accents on dark)
+- Avoid: gradient text for "impact", default dark mode with glowing accents
+
+## Layout & Space
+
+- Create visual rhythm through varied spacing — not uniform padding
+- Use fluid spacing with `clamp()` that breathes on larger screens
+- Embrace asymmetry and unexpected compositions
+- Avoid: wrapping everything in cards, nesting cards, identical card grids
+- Avoid: centering everything, uniform spacing
+
+## Motion
+
+- Focus on high-impact moments: one well-orchestrated page load > scattered micro-interactions
+- Use exponential easing for natural deceleration
+- Use `transform` and `opacity` only — avoid animating layout properties
+- Avoid: bounce/elastic easing, excessive animations
+
+## Interaction
+
+- Use progressive disclosure — start simple, reveal complexity through interaction
+- Design empty states that teach the interface
+- Use optimistic UI — update immediately, sync later
+- Avoid: making every button primary, redundant headers
+
+## Responsive
+
+- Use container queries (`@container`) for component-level responsiveness
+- Adapt the interface for different contexts, don't just shrink it
+- Never hide critical functionality on mobile
+
+## The AI Slop Test
+
+If you showed this interface to someone and said "AI made this", would they believe you immediately? If yes, redesign. A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

package/bundled/skills/app-planner/references/incremental-feature-planning.md

@@ -0,0 +1,112 @@
+# Incremental Feature Planning Reference
+
+Use this reference when the user adds features to an existing app/plan.
+
+## Pre-Checks
+
+1. Read existing `feature-list.json`.
+2. Determine current max ID and continue from next `F-NNN`.
+3. **Detect existing writing style** (see §Style Detection below).
+4. Preserve compatibility with existing dependency structure.
+5. **Project conventions** — handled by the main SKILL.md flow (rule #6) before incremental planning begins. No additional action needed here; conventions are loaded automatically.
+
+If `feature-list.json` is missing, ask whether to initialize a new plan.
+
+## Style Detection (Automatic)
+
+Before drafting new features, analyze existing plan to preserve consistency:
+
+1. **Language Detection**
+   - Scan `title` and `description` fields
+   - If >70% English titles → default to English
+   - If >70% Chinese titles → suggest Chinese (or allow bilingual)
+
+2. **Description Density**
+   - Calculate avg word count per description
+   - If avg <30 words → draft concise descriptions
+   - If avg 30-80 words → draft standard detail
+   - If avg >80 words → draft detailed descriptions
+
+3. **Acceptance Criteria Patterns**
+   - Count avg AC per feature
+   - Identify dominant format (Given/When/Then Gherkin, BDD, or loose)
+   - Draft new AC in same format
+
+4. **Complexity Distribution**
+   - Count low/medium/high distribution in existing features
+   - Alert if new features deviate significantly (>20 percentile points)
+   - Suggest rebalancing if needed
+
+### Style Consistency Prompt
+
+If new features deviate significantly from detected style:
+
+```
+"Your new features use avg X words/description, but existing features use Y.
+Current ratio: low:M%, medium:N%, high:O%.
+Adjust new features to match? (Y/n)"
+```
+
+Accept user choice, then adjust draft accordingly before JSON generation.
+
+## Incremental Planning Flow
+
+### Step 1: Clarify Increment Scope
+Capture:
+- business objective of the new increment
+- affected existing modules/features
+- timeline or priority constraints
+
+### Step 2: Impact Mapping
+For each candidate feature, identify:
+- upstream dependencies
+- downstream impacts
+- risk hotspots (auth, data migration, API compatibility)
+
+### Step 3: Append Features
+Append new items only (do not rewrite old validated features unless user asks).
+
+For each new feature:
+- assign next ID
+- set `status: "pending"`
+- link dependencies to existing IDs where needed
+- keep title in English
+- **write rich descriptions** (see `planning-guide.md` §4):
+  - minimum 15 words (validation error below this)
+  - recommended: 30+ words (low), 50+ words (medium), 80+ words (high complexity)
+  - include: what to build, key behaviors, integration points, data model, error/edge cases
+
+### Step 4: Rebalance Priority
+Allow priority updates for both old and new features if user requests reprioritization.
+Keep dependency correctness as first constraint.
+
+### Step 5: Validate
+Run:
+```bash
+python3 ${SKILL_DIR}/scripts/validate-and-generate.py validate --input feature-list.json --mode incremental
+```
+
+Fix and re-run until pass.
+
+## Merge/Rewrite Rules
+
+- Default: append only
+- Rewrite existing features only when user explicitly asks
+- Never break valid IDs/references
+- Never set new features to `in_progress` or `completed`
+
+## Practical Prompts
+
+Use concise prompts during interaction:
+- "What is the goal of this increment? Which user problem is the priority?"
+- "Which existing Feature IDs do these new features depend on?"
+- "Do you want to reprioritize at the same time, or just append to the current sequence?"
+
+## Final Delivery Checklist
+
+- [ ] Existing file read before edits
+- [ ] New IDs continue sequence
+- [ ] Existing style preserved
+- [ ] Dependency graph still DAG
+- [ ] Validation passes
+- [ ] Next step recommendation follows priority: launcher → daemon → run.sh

package/bundled/skills/app-planner/references/new-app-planning.md

@@ -0,0 +1,85 @@
+# New App Planning Reference
+
+Use this reference when the user is planning a product from scratch.
+
+## Phase Guide
+
+### Phase 1: Vision
+Capture:
+- problem statement
+- target users
+- core value proposition
+- non-goals (what to exclude from MVP)
+
+### Phase 2: Stack Defaults
+If user has no preference, propose defaults aligned with project conventions:
+- Frontend: Next.js + TypeScript
+- Backend: Express/Nest (choose one and stay consistent)
+- DB: PostgreSQL
+- ORM: Prisma
+- Test: unit + e2e baseline
+
+If `.prizmkit/config.json` exists, prioritize its settings.
+
+### Phase 3: MVP Features
+Rules:
+- Include foundational setup feature first
+- Aim 5-12 features for MVP
+- Keep each feature implementable in one pipeline unit unless clearly too large
+
+For each feature define:
+- `id`
+- `title`
+- `description`
+- `priority` — string: `"high"`, `"medium"`, or `"low"` (never numeric)
+- `estimated_complexity`
+- `dependencies`
+- `acceptance_criteria`
+- `status: "pending"`
+- `browser_interaction` (optional — for UI features, see §Browser Interaction Planning in SKILL.md)
+
+### Phase 4: Dependency & Priority
+Check:
+- no cycles
+- all dependency targets exist
+- order is executable
+- priorities align with delivery value and risk
+
+### Phase 5: Granularity
+Split into `sub_features` when:
+- scope crosses too many modules
+- acceptance criteria are excessive
+- complexity is high and uncertainty is high
+
+### Phase 6: Generate + Validate
+1. Write `feature-list.json`.
+2. Run:
+   ```bash
+   python3 ${SKILL_DIR}/scripts/validate-and-generate.py validate --input feature-list.json --mode new
+   ```
+3. Fix all errors, then re-run.
+
+## Quality Rules
+
+- Keep titles concise and English
+- Make descriptions implementation-oriented (clear boundaries, interfaces, behavior)
+- **Description depth by complexity:**
+  - **Low complexity**: ≥30 words — what to build, key behavior, which files/modules are affected
+  - **Medium complexity**: ≥50 words — add integration points, data model overview, error handling approach
+  - **High complexity**: ≥80 words — add architecture decisions, performance considerations, security implications, migration strategy if applicable
+- **Description must cover** (adapt per feature):
+  1. **What**: concrete deliverable (API endpoints, UI components, data models)
+  2. **How it integrates**: which existing modules/services it connects to
+  3. **Key behaviors**: business rules, validation rules, state transitions
+  4. **Data model**: entities, relationships, key fields (when applicable)
+  5. **Error/edge cases**: what happens on failure, empty states, limits
+- Write testable acceptance criteria (at least 3; prefer 5+ for medium/high)
+- Keep dependency graph simple and explicit
+
+## Final Delivery Checklist
+
+- [ ] User confirmed MVP scope
+- [ ] IDs are sequential
+- [ ] `status` initialized to `pending`
+- [ ] Validation passes
+- [ ] Next step recommendation follows priority: launcher → daemon → run.sh

package/bundled/skills/app-planner/references/project-conventions.md

@@ -0,0 +1,93 @@
+# Project Conventions — First-Run Setup Questions
+
+> Capture project-wide norms once, reuse across all planning sessions.
+
+These questions establish foundational conventions that affect every feature. They should be asked **once** during the first `app-planner` session and persisted to `.prizmkit/project-conventions.json` so subsequent sessions skip them.
+
+## Persistence
+
+- **File**: `.prizmkit/project-conventions.json`
+- **Read on startup**: If the file exists and a convention has a non-null value, skip that question.
+- **Write after asking**: Save answers immediately after the user responds.
+- **Shared**: Other skills (`prizmkit-init`, `dev-pipeline`) may also read this file.
+
+## Convention Questions
+
+Ask only unanswered conventions. Group related questions together in a single prompt when possible.
+
+### 1. UI Display Language
+
+**Key**: `ui_language`
+
+> "What is the primary language for the application's user interface? (e.g., English, 中文, 日本語, etc.)"
+
+**Follow-up if applicable**: If the user specifies a non-English language, confirm whether all UI text (buttons, labels, error messages, tooltips) should be in that language.
+
+### 2. Multi-Language Support (i18n)
+
+**Key**: `i18n_enabled`, `i18n_languages`
+
+> "Does the application need multi-language support (i18n)?"
+
+- If **yes** → ask: "Which languages should be supported? List all target languages."
+- If **no** → set `i18n_enabled: false`, skip `i18n_languages`.
+
+**Impact on planning**: If i18n is enabled, add an infrastructure feature for i18n setup (framework, translation file structure, language switcher) early in the dependency graph.
+
+### 3. Date, Time & Currency Formats
+
+**Key**: `date_format`, `timezone_strategy`, `currency`
+
+> "What are your preferences for date/time and currency display?"
+
+Sub-questions (ask as a group):
+- **Date format**: "Preferred date display format?" (e.g., `YYYY-MM-DD`, `MM/DD/YYYY`, `DD/MM/YYYY`, locale-auto)
+- **Timezone strategy**: "How should the app handle timezones?" (e.g., UTC storage + local display, user-selected timezone, server timezone only)
+- **Currency**: "If the app handles money, which currency format?" (e.g., USD `$1,234.56`, CNY `¥1,234.56`, EUR `€1.234,56`, or N/A if no monetary values)
+
+If the user says "not applicable" for currency, set `currency: null`.
+
+### 4. Code & Git Language Conventions
+
+**Key**: `code_comment_language`, `git_commit_language`
+
+> "What language should be used for code comments and git commit messages?"
+
+Options to present:
+- **Code comments**: English / Chinese / Match UI language / Mixed
+- **Git commit messages**: English / Chinese / Match code comments
+
+**Default suggestion**: English for both (widely accessible, compatible with open-source contribution).
+
+## JSON Schema
+
+```json
+{
+  "ui_language": "English",
+  "i18n_enabled": false,
+  "i18n_languages": [],
+  "date_format": "YYYY-MM-DD",
+  "timezone_strategy": "utc_storage_local_display",
+  "currency": null,
+  "code_comment_language": "English",
+  "git_commit_language": "English"
+}
+```
+
+## How Conventions Are Used
+
+Conventions are **AI context** — they inform your behavior during planning but are NOT written into `feature-list.json` `global_context` fields. Specifically:
+
+- `ui_language` → Write feature descriptions and acceptance criteria in a way that acknowledges the target UI language (e.g., mention CJK text handling if Chinese, RTL layout if Arabic)
+- `i18n_enabled` → If true, consider proposing an i18n infrastructure feature early in the dependency graph; ensure feature descriptions mention translation-ready patterns
+- `date_format`, `timezone_strategy` → When features involve date/time display or storage, reference the chosen convention in feature descriptions
+- `currency` → When features involve monetary values, reference the currency convention in descriptions
+- `code_comment_language` → Inform the language used in code-related examples within feature descriptions
+- `git_commit_language` → Inform pipeline and workflow language expectations
+
+## Rules
+
+- **Ask at most once per convention** — if answered, never re-ask unless user invokes a reset.
+- **No blocking** — if the user skips a question ("I'll decide later"), set value to `null` and move on. The question will be re-asked next session.
+- **Respect existing config** — if `.prizmkit/config.json` already has equivalent fields (e.g., `tech_stack.language`), do not duplicate. Only ask questions not covered by existing config.
+- **Minimal interruption** — batch all unanswered questions into a single interaction round, not one-by-one.

package/bundled/skills/app-planner/references/red-team-checklist.md

@@ -0,0 +1,40 @@
+# Red Team Checklist for Ideation
+
+Use these questions to stress-test approaches during brainstorm Phase C.
+
+## Structural Questions
+
+1. **What breaks first?** — Identify the weakest link under stress (load, concurrency, edge cases, adversarial input). If you can't name a specific failure mode, the approach is under-specified.
+
+2. **What's the hidden cost?** — Every approach has costs beyond implementation time: maintenance burden, cognitive load for new contributors, infrastructure requirements, monitoring needs, migration complexity.
+
+3. **What assumption is wrong?** — List the unstated assumptions. Which one, if false, invalidates the approach? Common false assumptions: "the API won't change", "data fits in memory", "users will read the docs", "this library is maintained".
+
+4. **Who disagrees?** — Steel-man the opposing view. A performance engineer and a UX designer will critique the same approach differently. What does the most skeptical qualified person say?
+
+## Scoring
+
+| Red Team Failures | Classification |
+|-------------------|---------------|
+| 0 | Strong approach |
+| 1 | Viable with mitigation |
+| 2+ | HIGH RISK — needs rethinking or mitigation plan |
+
+## When All Approaches Are HIGH RISK
+
+If every approach fails 2+ questions, the problem statement may be wrong. Consider:
+- Is the goal too broad? Split it.
+- Is there a constraint you haven't stated? Surface it.
+- Generate a hybrid approach that addresses the specific red team failures.
+
+## Common False Assumptions
+
+| Assumption | Why It Fails |
+|-----------|-------------|
+| "The API won't change" | External APIs change without notice; pin versions and add contract tests |
+| "Data fits in memory" | Works in dev, breaks in prod when dataset grows 10x |
+| "Users will read the docs" | They won't; make the happy path obvious and errors informative |
+| "This library is maintained" | Check commit history; many popular libraries are effectively abandoned |
+| "We can refactor later" | Technical debt compounds; later never comes without explicit scheduling |
+| "Performance doesn't matter yet" | Architecture decisions that ignore performance are expensive to fix |
+| "The team will adopt it" | New tools need champions, training, and visible wins to gain traction |

package/package.json

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

package/src/scaffold.js

@@ -156,8 +156,8 @@ export async function installSkills(platform, skills, projectRoot, dryRun) {
       if (!frontmatter.name) frontmatter.name = skillName;
       await fs.writeFile(path.join(targetDir, 'SKILL.md'), buildMarkdown(frontmatter, body));
 
-      // 复制 assets/ 和 scripts/
-      for (const subdir of ['assets', 'scripts']) {
+      // 复制 assets/、scripts/ 和 references/
+      for (const subdir of ['assets', 'scripts', 'references']) {
         const srcSubdir = path.join(corePath, subdir);
         if (await fs.pathExists(srcSubdir)) {
           await fs.copy(srcSubdir, path.join(targetDir, subdir));
@@ -172,6 +172,7 @@ export async function installSkills(platform, skills, projectRoot, dryRun) {
 
       const hasAssets = await fs.pathExists(path.join(corePath, 'assets'));
       const hasScripts = await fs.pathExists(path.join(corePath, 'scripts'));
+      const hasReferences = await fs.pathExists(path.join(corePath, 'references'));
 
       // Always write the command file at the flat level (.claude/commands/skillName.md)
       // so Claude Code shows it as /skillName (not /skillName:skillName).
@@ -184,12 +185,12 @@ export async function installSkills(platform, skills, projectRoot, dryRun) {
       await fs.ensureDir(commandsDir);
       await fs.writeFile(path.join(commandsDir, `${skillName}.md`), converted);
 
-      if (hasAssets || hasScripts) {
+      if (hasAssets || hasScripts || hasReferences) {
         // Place assets/scripts outside .claude/commands/ to prevent Claude Code
         // from registering them as slash commands (e.g. /skillName:assets:file).
         const assetTargetDir = path.join(projectRoot, '.claude', 'command-assets', skillName);
         await fs.ensureDir(assetTargetDir);
-        for (const subdir of ['assets', 'scripts']) {
+        for (const subdir of ['assets', 'scripts', 'references']) {
           const srcSubdir = path.join(corePath, subdir);
           if (await fs.pathExists(srcSubdir)) {
             await fs.copy(srcSubdir, path.join(assetTargetDir, subdir));