prizmkit 1.1.111 → 1.1.113

package/bundled/skills/feature-planner/references/new-project-planning.md

@@ -1,31 +1,29 @@
-# New App Planning Reference
+# Initial Feature Set Planning Reference
 
-Use this reference when the user is planning a product from scratch.
+Use this reference when an existing or already app-planned project needs its first `.prizmkit/plans/feature-list.json`.
+
+Do not use this reference to define app vision, tech stack, or architecture from scratch. That belongs to `app-planner`.
 
 ## Phase Guide
 
-### Phase 1: Vision
-Capture:
-- problem statement
-- target users
-- core value proposition
-- non-goals (what to exclude from MVP)
+### Phase 1: Existing Context
+
+Capture or infer:
+- project brief and current product goals
+- already implemented capabilities
+- target users and primary workflows from existing docs or code
+- explicit non-goals already documented for the project
 
-### 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
+### Phase 2: Existing Stack and Architecture
 
-If `.prizmkit/config.json` exists, prioritize its settings.
+Read `.prizmkit/config.json`, `.prizmkit/plans/project-brief.md`, `.prizmkit/prizm-docs/root.prizm`, and platform instruction files when present. If app-level context is missing and the user is asking for product/stack decisions, recommend `app-planner`.
 
 ### 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
+- Include foundational setup feature first only when the existing project still needs setup work.
+- Aim 5-12 features for an initial executable plan unless the user explicitly scopes smaller.
+- Keep each feature implementable in one pipeline unit unless clearly too large.
 
 For each feature define:
 - `id`
@@ -36,9 +34,10 @@ For each feature define:
 - `dependencies`
 - `acceptance_criteria`
 - `status: "pending"`
-- `browser_interaction` (optional — for UI features, see §Browser Interaction Planning in SKILL.md)
+- `browser_interaction` when UI verification is useful (see §Browser Interaction Planning in SKILL.md)
 
 ### Phase 4: Dependency & Priority
+
 Check:
 - no cycles
 - all dependency targets exist
@@ -46,39 +45,36 @@ Check:
 - 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:
+
+1. Write `.prizmkit/plans/feature-list.draft.json`.
+2. Generate the final file:
    ```bash
-   python3 ${SKILL_DIR}/scripts/validate-and-generate.py validate --input feature-list.json
+   python3 ${SKILL_DIR}/scripts/validate-and-generate.py generate --input .prizmkit/plans/feature-list.draft.json --output .prizmkit/plans/feature-list.json
    ```
-3. Fix all errors, then re-run.
+3. Fix draft errors, then re-run generate.
 
 ## 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
+- 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 what, integration points, key behaviors, data model when applicable, and error/edge cases.
+- Write at least 1 testable acceptance criterion to satisfy schema validation. Fewer than 3 criteria is a planner quality warning; medium/high features should usually target 5+.
+- Keep dependency graph simple and explicit.
 
 ## Final Delivery Checklist
 
-- [ ] User confirmed MVP scope
+- [ ] User confirmed initial feature scope
 - [ ] IDs are sequential
 - [ ] `status` initialized to `pending`
 - [ ] Validation passes

package/bundled/skills/feature-planner/scripts/validate-and-generate.py

@@ -268,7 +268,7 @@ def validate_feature_list(data, is_new_plan=True):
         if isinstance(priority, str) and priority in VALID_PRIORITIES:
             priorities.append(priority)
         else:
-            errors.append("{}: priority must be one of 'high', 'medium', 'low', got {}".format(
+            errors.append("{}: priority must be one of 'critical', 'high', 'medium', 'low', got {}".format(
                 label, repr(priority)
             ))