prizmkit 1.1.106 → 1.1.108

package/bundled/skills/bug-planner/SKILL.md

@@ -46,9 +46,22 @@ When the user provides detailed specifications, rules, or implementation require
 1. **Verbatim preservation**: The user's exact wording MUST be preserved in `description` and `acceptance_criteria` fields. Do NOT paraphrase, summarize, abstract, or simplify.
 2. **No autonomous simplification**: A 200-word user specification must NOT become a 30-word description. Match the detail level of the user's input.
 3. **Clarify, don't assume**: If any user-provided rule is ambiguous or potentially conflicts with another, ASK the user to clarify. No limit on clarification rounds. Do NOT proceed with unresolved ambiguities.
-4. **Populate `user_context`**: ALL user-provided materials (supplementary content, rules, file path references) MUST be written into the `user_context` array of each bug in the generated `.prizmkit/plans/bug-fix-list.json`. Format:
-   - Supplementary content or rules → store as-is (verbatim text)
-   - File references → store as path string, e.g. `src/auth/login.ts:42-78` or `src/utils/validate.ts — focus on validateEmail function`
+4. **Task-scoped `user_context`**: In single-bug planning, write the relevant user-provided materials into that bug's `user_context`. In multi-bug planning, multi-bug `user_context` must contain only the user text, file references, logs, and reproduction details relevant to that specific bug.
+   - Preserve the matching user wording verbatim, but scope it to the item it belongs to.
+   - Do NOT copy the full multi-bug request into every bug.
+   - Ensure there are no unrelated sibling bug descriptions, stack traces, logs, reproduction steps, expected/actual behavior notes, or supplementary materials in a bug's `user_context`.
+   - Shared global context may be copied to every item only when it is explicitly applicable to all generated items.
+   - If a log, stack trace, screenshot, reproduction path, or file reference applies to only one bug, attach it only to that matching bug.
+   - If applicability is unclear, ask the user to map the material to the correct bug before generating the final list.
+5. **`user_context` format**:
+   - Bug-specific supplementary content or rules → store as-is (verbatim text) on the matching bug only
+   - Bug-specific file references → store as path string, e.g. `src/auth/login.ts:42-78` or `src/utils/validate.ts — focus on validateEmail function`
+   - Truly shared global constraints or environment context → repeat only when they apply to every generated bug
+
+**Multi-bug isolation example:**
+- User request includes: `Bug A: login crashes when password is empty`, `Bug B: CSV export loses Chinese characters`, and `Shared: production uses Node 20`.
+- The login bug `user_context` includes `Bug A: login crashes when password is empty` and the shared Node 20 environment; it MUST NOT include `Bug B: CSV export loses Chinese characters`.
+- The CSV bug `user_context` includes `Bug B: CSV export loses Chinese characters` and the shared Node 20 environment; it MUST NOT include `Bug A: login crashes when password is empty`.
 
 ## When to Use
 
@@ -59,6 +72,43 @@ The `description` frontmatter declares the trigger phrases for this skill. Beyon
 - User wants to fix a single bug interactively → use `bug-fix-workflow`
 - User wants to plan features → use `feature-planner`
 
+## Priority and Severity Calibration (Mandatory)
+
+Bug planning must preserve the severity-to-priority mapping, but severity must be justified from concrete bug impact rather than from user frustration or the fact that something needs fixing.
+
+### Severity → Priority Mapping (Preserved)
+
+- `critical` severity → `high` priority (treated with highest urgency)
+- `high` severity → `high` priority
+- `medium` severity → `medium` priority
+- `low` severity → `low` priority
+
+### High Classification Guardrails
+
+Do not classify a user report as `high` severity or `high` priority unless the bug independently shows at least one high-impact indicator:
+- core feature outage or the user cannot complete a primary workflow
+- data loss, data corruption, or data integrity risk
+- security, privacy, authentication, or authorization failure
+- timeout, crash, unrecoverable error, or production 500 affecting a meaningful path
+- no reasonable workaround for affected users
+
+Do not assign every generated bug `Priority: high` and `Complexity: high` unless every bug independently satisfies the high/critical severity criteria and the rationale names the matching indicator. For bugs, `Complexity` is represented by the `Severity` classification in the planning summary. "The user cares about this", "this needs fixing", or "the bug is in framework code" is not enough.
+
+### Required Planning Review Summary
+
+Before writing `.prizmkit/plans/bug-fix-list.json`, display severity and priority rationales for every bug:
+
+```
+ID    | Title                       | Severity | Severity Rationale                  | Priority | Priority Rationale
+B-001 | Login returns 500           | high     | Core auth fails; no workaround      | high     | High severity maps to high priority
+B-002 | CSV export mojibake         | medium   | Incorrect output; workaround exists | medium   | Medium severity maps to medium priority
+B-003 | Warning text typo           | low      | Cosmetic copy issue only            | low      | Low severity maps to low priority
+```
+
+Medium and low bug assignments are expected for partial failures, workaround cases, cosmetic issues, and non-critical edge cases.
+
+---
+
 ## Intent Routing
 
 This skill handles multiple operations. Determine the user's intent and dispatch to the matching operation section below — each operation's authoritative trigger phrases live in its own **Operation:** section.
@@ -108,7 +158,6 @@ Gather project metadata from the project's own configuration and documentation
 1. **Identify project**: Read project name and description from these sources (first match wins):
    - `.prizmkit/config.json` (`project_name`, `description` fields)
    - `.prizmkit/prizm-docs/root.prizm` (project overview section)
-   - `CLAUDE.md` or `CODEBUDDY.md` (project instructions)
    - `package.json` / `pyproject.toml` / `Cargo.toml` (name + description fields)
    - If none found, ask the user
 2. **Identify tech stack**: Read from these sources (first match wins):
@@ -169,7 +218,7 @@ Only finalize the bug entry after user confirms all three points.
 
 ### Phase 3: Prioritization & Review
 
-1. **Auto-assign priorities**: Based on severity, adjustable by user
+1. **Auto-assign priorities**: Based on severity, adjustable by user; require a short severity rationale and priority rationale for each bug
 
    **Severity → Priority Mapping**:
    - `critical` severity → `high` priority (treated with highest urgency)
@@ -177,13 +226,18 @@ Only finalize the bug entry after user confirms all three points.
    - `medium` severity → `medium` priority
    - `low` severity → `low` priority
 
-   Note: Severity has 4 levels (critical, high, medium, low) but Priority has 3 levels (high, medium, low). Both critical and high severity bugs map to high priority.
-2. **Display summary table**:
+   Note: Severity has 4 levels (critical, high, medium, low) but Priority has 3 levels (high, medium, low). Both critical and high severity bugs map to high priority. Preserve this mapping exactly.
+
+   **Calibration check before accepting high**:
+   - High/critical severity requires a concrete indicator: core feature outage, data loss/integrity, security/privacy/auth failure, timeout/crash/production 500, or no workaround.
+   - If the report is "annoying", partially broken, has a workaround, or affects a non-critical edge case, prefer `medium` or `low` as documented in the severity rules.
+   - Do not treat "needs fixing", "user reported it", or "framework bug" as automatic high priority.
+2. **Display summary table with rationales**:
    ```
-   ID    | Title                        | Severity | Priority | Verification
-   B-001 | Login null reference crash    | critical | high     | automated
-   B-002 | CSV export Chinese encoding   | medium   | medium   | hybrid
-   B-003 | Slow dashboard loading        | low      | low      | manual
+   ID    | Title                        | Severity | Severity Rationale                  | Priority | Priority Rationale             | Verification
+   B-001 | Login null reference crash    | high     | Core auth fails; no workaround      | high     | High severity maps to high      | automated
+   B-002 | CSV export Chinese encoding   | medium   | Incorrect output; workaround exists | medium   | Medium severity maps to medium  | hybrid
+   B-003 | Slow dashboard loading        | low      | Non-critical page; minor delay      | low      | Low severity maps to low        | manual
    ```
 3. **Ask for adjustments**: "Want to reorder priorities, change severity, or remove any bugs?"
 4. **Detect potential duplicates**: If two bugs have similar error messages or affected modules, warn user
@@ -229,14 +283,42 @@ Only proceed to Phase 5 after user confirms.
    ```
    The script fills in defaults (`$schema`, `created_at`, `created_by`), validates all fields, and writes the final file only if validation passes.
 3. **If validation fails**: Fix the draft and retry (max 3 attempts). If the script is unavailable, use the checklist in `${SKILL_DIR}/references/schema-validation.md`.
-4. **Output**: File path, summary, and next steps
+4. **Run the mandatory Post-Generation Plan Review Gate** (see §Post-Generation Plan Review Gate below): invoke `/prizmkit-code-review` on only newly added/changed bug entries after validation passes and before success output.
+5. **Output**: File path, summary, review result, validation outcome, and next steps
 
 **Gate → CP-BP-5**: `bug-fix-list.json` passes validation script with zero errors.
 
+**Gate → CP-BP-6**: `/prizmkit-code-review` reviewed only newly added/changed bug entries; accepted fixes were regenerated and revalidated.
+
+## Post-Generation Plan Review Gate
+
+User requirement preserved verbatim: `每次完成任务规划的时候，应该调用/prizmkit-code-review 对新增的计划内容进行review，确保生成新增的计划的正确行和完整性。`
+
+Run this gate **after** `.prizmkit/plans/bug-fix-list.json` passes the validation/generate script and **before** any success output or next-step summary recommends `bugfix-pipeline-launcher`. This gate applies to Interactive Planning, From Log, From Tests, and any append-to-existing bug list flow.
+
+1. **Identify review scope**: compare the final validated bug list against the pre-session list when one existed. Review only newly added or changed bug entries. Do not re-review unchanged historical entries except when needed to verify duplicate/root-cause overlap or dependency references.
+2. **Invoke `/prizmkit-code-review` as a planning-quality gate** with an explicit prompt that this is a bug-plan-entry review, not an implementation review. The review must check:
+   - schema correctness and compatibility with `dev-pipeline-bug-fix-list-v1`
+   - dependency/DAG consistency, duplicate handling, and root-cause overlap
+   - description completeness, including expected vs actual behavior, reproduction path, code-location hints, and headless execution readiness
+   - acceptance criteria specificity and measurable verification method
+   - preservation of user-provided wording in `description`, `acceptance_criteria`, and `user_context`
+   - task-scoped `user_context` isolation: no unrelated sibling bug descriptions, logs, stack traces, reproduction steps, or supplementary materials, and shared context appears on multiple items only when explicitly global
+   - severity/priority calibration: every reviewed bug has a short severity rationale and priority rationale, the preserved severity-to-priority mapping is followed, and high priority is not used without core outage, data loss/integrity, security/auth, timeout/crash, or no-workaround indicators
+3. **Keep the review planning-only**: do NOT start `bugfix-pipeline-launcher`, do NOT run the bugfix pipeline, do NOT run tests/builds/installs, and do NOT implement source-code fixes.
+4. **Apply accepted review fixes through the draft/source plan**: when a finding is accepted, update `.prizmkit/plans/bug-fix-list.draft.json` or the in-memory draft representation first, then regenerate the final file with:
+   ```bash
+   python3 ${SKILL_DIR}/scripts/validate-bug-list.py generate --input .prizmkit/plans/bug-fix-list.draft.json --output .prizmkit/plans/bug-fix-list.json
+   ```
+   Do not hand-patch the final JSON as the source of truth; map final-output findings back to draft entries before regeneration.
+5. **Revalidate after every accepted fix batch**: the generate script must pass again before the planner can proceed. If validation fails, fix the draft and rerun until pass.
+6. **Report the gate outcome** in the final summary: include `/prizmkit-code-review` verdict, reviewed bug IDs, accepted fixes (or "none"), and final validation result.
+
 #### Success Output
 
 ```
 .prizmkit/plans/bug-fix-list.json generated with 3 bugs (1 critical, 1 medium, 1 low)
+Review gate: /prizmkit-code-review PASS, reviewed B-001..B-003, accepted fixes: none, final validation: PASS
 
 Next steps:
 - Review: cat .prizmkit/plans/bug-fix-list.json
@@ -254,6 +336,7 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
 | **CP-BP-3** | Priorities Set | Severity/priority assigned, duplicates resolved | 3 |
 | **CP-BP-4** | Completeness Passed | All bugs pass headless execution readiness check | 4 |
 | **CP-BP-5** | File Generated | `bug-fix-list.json` passes validation script | 5 |
+| **CP-BP-6** | Plan Review Passed | `/prizmkit-code-review` reviewed only newly added/changed bug entries; accepted fixes were regenerated and revalidated | 5 |
 
 **Resume Detection**: If existing `.prizmkit/plans/bug-fix-list.json` or draft found, read `${SKILL_DIR}/references/error-recovery.md` §Resume Support for checkpoint-based resumption.
 
@@ -280,6 +363,7 @@ Batch-parse error logs to generate bug entries without interactive prompts:
    ```bash
    python3 ${SKILL_DIR}/scripts/validate-bug-list.py generate --input .prizmkit/plans/bug-fix-list.draft.json --output .prizmkit/plans/bug-fix-list.json
    ```
+7. If validation passes, run the mandatory Post-Generation Plan Review Gate before summarizing or recommending `bugfix-pipeline-launcher`.
 
 ## Operation: From Tests
 
@@ -296,6 +380,7 @@ Batch-parse failed test output:
    ```bash
    python3 ${SKILL_DIR}/scripts/validate-bug-list.py generate --input .prizmkit/plans/bug-fix-list.draft.json --output .prizmkit/plans/bug-fix-list.json
    ```
+7. If validation passes, run the mandatory Post-Generation Plan Review Gate before summarizing or recommending `bugfix-pipeline-launcher`.
 
 ## Operation: Validate
 
@@ -348,10 +433,11 @@ Key points:
 
 Recommend invoking `bugfix-pipeline-launcher` to configure and launch the pipeline. Do NOT recommend running shell scripts directly — that is the launcher's responsibility.
 
-After `.prizmkit/plans/bug-fix-list.json` is generated, present:
+After `.prizmkit/plans/bug-fix-list.json` is generated, validated, and reviewed, present:
 1. Summary of generated bugs (count, severity breakdown)
-2. Recommend: "Say 'start fixing' to launch the bugfix pipeline via `bugfix-pipeline-launcher`"
-3. Alternative: fix a single bug interactively via `bug-fix-workflow`
+2. Review result: `/prizmkit-code-review` verdict, reviewed bug IDs, accepted fixes (or "none"), and final validation result
+3. Recommend: "Say 'start fixing' to launch the bugfix pipeline via `bugfix-pipeline-launcher`"
+4. Alternative: fix a single bug interactively via `bug-fix-workflow`
 
 ## Error Handling
 

package/bundled/skills/bug-planner/references/severity-rules.md

@@ -1,16 +1,28 @@
 # Severity Auto-Classification Rules
 
-When extracting bugs, apply these rules to auto-suggest severity:
+When extracting bugs, apply these rules to auto-suggest severity. Require a short rationale for every severity assignment and then map severity to priority using the planner's preserved mapping.
 
 | Severity | Indicators | Examples |
 |----------|------------|----------|
-| **critical** | System crash, data loss, security breach, OOM, unrecoverable error | `Segmentation fault`, `OutOfMemoryError`, `SQL injection vulnerability`, `Database corrupted` |
-| **high** | Core feature broken, authentication failure, data integrity issue, timeout | `Auth token invalid`, `Payment failed`, `Connection timeout`, `500 Internal Server Error` |
-| **medium** | Feature partially broken, workaround exists, incorrect output | `CSV encoding issue`, `Pagination not working`, `Wrong date format`, `Missing validation` |
-| **low** | Cosmetic issue, minor inconvenience, edge case | `UI misalignment`, `Typo in error message`, `Slow loading (non-critical page)`, `Non-breaking warning` |
+| **critical** | System-wide crash, active data loss/corruption, exploitable security breach, OOM, unrecoverable production outage, no workaround | `Segmentation fault` on startup, `OutOfMemoryError` halting workers, `SQL injection vulnerability`, `Database corrupted` |
+| **high** | Core feature outage, authentication/authorization failure, data integrity issue, repeated timeout/crash/500 on primary workflow, payment blocked, no reasonable workaround | `Auth token invalid for all users`, `Payment failed for valid cards`, `Connection timeout on checkout`, `500 Internal Server Error on login` |
+| **medium** | Feature partially broken, incorrect output, validation gap, failed non-critical test, workaround exists, limited user segment affected | `CSV encoding issue with manual export workaround`, `Pagination not working on admin table`, `Wrong date format`, `Missing optional validation` |
+| **low** | Cosmetic issue, minor inconvenience, rare edge case with easy workaround, non-breaking warning, docs/copy issue | `UI misalignment`, `Typo in error message`, `Slow loading on non-critical page`, `Non-breaking warning` |
 
 ## Special Cases
 
-- Failed test → medium (unless test covers critical path, then high)
-- User report with "cannot use app" → high
-- User report with "annoying but works" → low
+- Failed test → medium unless the failed test covers auth, payment, data integrity, security, startup, or another critical path; then high with rationale.
+- User report with "cannot use app" → high only when a primary workflow is blocked and no workaround exists.
+- User report with "annoying but works" → low.
+- User frustration, repeated wording, or "please fix urgently" is not a severity indicator by itself; look for objective impact.
+- Framework or infrastructure bugs are not automatically high; classify by user/runtime impact and workaround availability.
+
+## Mixed Calibration Examples
+
+| Bug | Severity | Priority | Rationale |
+|-----|----------|----------|-----------|
+| Login returns 500 for every valid credential | high | high | Core auth workflow outage with no workaround; high severity maps to high priority. |
+| CSV export corrupts non-ASCII characters but JSON export works | medium | medium | Incorrect output with a workaround; medium severity maps to medium priority. |
+| Settings tooltip has outdated wording | low | low | Cosmetic copy issue only; low severity maps to low priority. |
+
+Anti-pattern: do not generate an all-high bug list unless each bug independently includes high/critical indicators such as core outage, data loss/integrity, security/auth failure, timeout/crash, or no workaround.

package/bundled/skills/feature-planner/SKILL.md

@@ -54,9 +54,22 @@ When the user provides detailed specifications, rules, or implementation require
 1. **Verbatim preservation**: The user's exact wording MUST be preserved in `description` and `acceptance_criteria` fields. Do NOT paraphrase, summarize, abstract, or simplify.
 2. **No autonomous simplification**: A 200-word user specification must NOT become a 30-word description. Match the detail level of the user's input.
 3. **Clarify, don't assume**: If any user-provided rule is ambiguous or potentially conflicts with another, ASK the user to clarify. No limit on clarification rounds. Do NOT proceed with unresolved ambiguities.
-4. **Populate `user_context`**: ALL user-provided materials (supplementary content, rules, file path references) MUST be written into the `user_context` array of each feature in the generated `.prizmkit/plans/feature-list.json`. Format:
-   - Supplementary content or rules → store as-is (verbatim text)
-   - File references → store as path string, e.g. `src/auth/login.ts:42-78` or `src/utils/validate.ts — focus on validateEmail function`
+4. **Task-scoped `user_context`**: In single-feature planning, write the relevant user-provided materials into that feature's `user_context`. In multi-feature planning, multi-feature `user_context` must contain only the user text, file references, and supplementary materials relevant to that specific feature.
+   - Preserve the matching user wording verbatim, but scope it to the item it belongs to.
+   - Do NOT copy the full multi-feature request into every feature.
+   - Ensure there are no unrelated sibling feature descriptions, file references, screenshots, or supplementary materials in a feature's `user_context`.
+   - Shared global context may be copied to every item only when it is explicitly applicable to all generated items.
+   - If a material applies to only one feature, attach it only to that matching feature.
+   - If applicability is unclear, ask the user to map the material to the correct feature before generating the final list.
+5. **`user_context` format**:
+   - Feature-specific supplementary content or rules → store as-is (verbatim text) on the matching feature only
+   - Feature-specific file references → store as path string, e.g. `src/auth/login.ts:42-78` or `src/utils/validate.ts — focus on validateEmail function`
+   - Truly shared global constraints → repeat only when they apply to every generated feature
+
+**Multi-feature isolation example:**
+- User request includes: `Feature A: add saved filters to the dashboard`, `Feature B: export filtered results as CSV`, and `Shared: preserve existing auth permissions`.
+- The saved-filters feature `user_context` includes `Feature A: add saved filters to the dashboard` and the shared auth constraint; it MUST NOT include `Feature B: export filtered results as CSV`.
+- The CSV export feature `user_context` includes `Feature B: export filtered results as CSV` and the shared auth constraint; it MUST NOT include `Feature A: add saved filters to the dashboard`.
 
 ## When to Use
 
@@ -147,6 +160,45 @@ The `global_context` object in `.prizmkit/plans/feature-list.json` provides tech
 
 All `global_context` fields are optional — including recommended fields improves downstream code generation quality. See `.prizmkit/dev-pipeline/templates/feature-list-schema.json` for the full schema definition.
 
+## Priority and Complexity Calibration (Mandatory)
+
+Do not let planner output collapse into uniform `Priority: high` and `estimated_complexity: high`. Medium and low assignments are normal when the documented indicators fit. New framework work or multi-file work is not automatically `high` priority; the feature must satisfy the documented priority criteria independently.
+
+### Priority Rubric
+
+| Priority | Use When | Do NOT Use Merely Because |
+|----------|----------|---------------------------|
+| `critical` | A production-blocking capability, security/compliance requirement, data-loss prevention, or release blocker with no acceptable workaround. | The item is important, large, or requested by a stakeholder. |
+| `high` | Core user workflow or platform capability is blocked, revenue/security/auth/data integrity is at risk, a hard deadline depends on it, or many downstream items cannot proceed without it. | The item is multi-file, framework-related, or described with urgent language but no concrete blocker. |
+| `medium` | Valuable planned feature, quality improvement, integration, or automation that should be scheduled soon but has a workaround or does not block core operation. | It is less exciting than another item; medium is the default for normal planned work. |
+| `low` | Nice-to-have, polish, documentation, cleanup, optional convenience, or isolated improvement with little user/runtime impact. | The item is small; small work can still be high only when it blocks critical outcomes. |
+
+### Complexity Rationale Rules
+
+Assign `estimated_complexity` from concrete scope indicators, not from perceived importance. For each feature, write a short rationale using at least two relevant indicators:
+- affected module count and layer count
+- file count or expected implementation surface
+- API/interface or schema changes
+- architectural impact or new infrastructure
+- dependency depth and cross-feature coupling
+- acceptance-criteria count and edge-case breadth
+- test coverage and verification difficulty
+
+Use `low` for focused changes in 1 module with <=5 acceptance criteria and no public API/schema changes. Use `medium` for normal multi-file or 2-3 module work with bounded interfaces. Use `high` only when multiple concrete high indicators are present, such as 3+ modules plus public API changes, deep dependencies, weak tests, or substantial architectural risk. Use `critical` only for system-wide architectural/infrastructure changes or safety-critical work requiring full-team/multi-critic execution.
+
+### Required Planning Review Summary
+
+Before writing `.prizmkit/plans/feature-list.json`, show a calibration table with rationale columns:
+
+```
+ID    | Title                 | Priority | Priority Rationale                 | Complexity | Complexity Rationale
+F-001 | Auth outage recovery  | high     | Core login blocked; no workaround  | high       | Auth API + middleware + weak tests
+F-002 | Export polish option  | medium   | Useful workflow; not blocking      | medium     | UI + API parameter; bounded tests
+F-003 | Tooltip copy update   | low      | Cosmetic clarity only              | low        | One component; no interface change
+```
+
+Anti-pattern rule: do not assign every generated item `Priority: high` and `Complexity: high` unless each item independently satisfies the documented high criteria and its rationale names those criteria. In feature JSON this means `estimated_complexity: high`; in user-facing review summaries label the column `Complexity`.
+
 
 ---
 
@@ -196,12 +248,13 @@ Execute the planning workflow in conversation mode with mandatory checkpoints:
 4. Refine descriptions and acceptance criteria
    4.1 **Per-feature clarification** — for each feature, if the description, acceptance criteria, or scope is vague or could be interpreted multiple ways, ask the user to clarify before finalizing.
    4.2 **Browser interaction** (mandatory for fullstack/frontend projects) — see §Browser Interaction Planning below. Qualifying features get `browser_interaction` by default. Only confirm with the user as a batch summary; do NOT ask per-feature.
-5. Verify DAG/order/priorities
+5. Verify DAG/order/priorities and show the mandatory priority/complexity calibration table with short rationales for every item
 6. Pre-generation completeness review (see §Pre-Generation Completeness Review below)
 7. Build or append `.prizmkit/plans/feature-list.json`
 8. Apply default testing strategy (see §Testing Defaults below)
 9. Validate and fix until pass
-10. Summarize final feature table
+10. Run the mandatory Post-Generation Plan Review Gate (see §Post-Generation Plan Review Gate below); apply accepted fixes to the draft/source plan, regenerate, and revalidate until pass
+11. Summarize final feature table with review result and validation outcome
 
 ### Checkpoints (Mandatory Gates)
 
@@ -217,6 +270,7 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
 | **CP-FP-3.3** | Completeness Review Passed | All features reviewed for description adequacy and cross-feature gaps | 6 |
 | **CP-FP-4** | `.prizmkit/plans/feature-list.json` Generated | Schema validates, all required keys present | 7-8 |
 | **CP-FP-5** | Final Validation Pass | Python script returns `"valid": true` with zero errors | 9 |
+| **CP-FP-6** | Plan Review Passed | `/prizmkit-code-review` reviewed only newly added/changed feature entries; accepted fixes were regenerated and revalidated | 10 |
 
 **Resume Detection**: If existing artifacts are found, read `${SKILL_DIR}/references/error-recovery.md` §Resume Support for checkpoint-based resumption.
 
@@ -268,7 +322,7 @@ For simple incremental planning, skip detailed Phase 2-3 analysis:
    ```bash
    python3 ${SKILL_DIR}/scripts/validate-and-generate.py generate --input .prizmkit/plans/feature-list.draft.json --output .prizmkit/plans/feature-list.json
    ```
-6. If valid → summarize and recommend next step
+6. If valid → run the mandatory Post-Generation Plan Review Gate, then summarize and recommend next step
 7. If invalid → apply fixes to the draft, re-run generate (max 2 attempts, then escalate to full workflow)
 
 ## Browser Interaction Planning
@@ -321,6 +375,30 @@ python3 ${SKILL_DIR}/scripts/validate-and-generate.py generate --input .prizmkit
 ```
 The script fills in defaults (`$schema`, `created_at`, `created_by`), validates all fields, and writes the final file only if validation passes. If validation fails, fix the draft and retry.
 
+## Post-Generation Plan Review Gate
+
+User requirement preserved verbatim: `每次完成任务规划的时候，应该调用/prizmkit-code-review 对新增的计划内容进行review，确保生成新增的计划的正确行和完整性。`
+
+Run this gate **after** `.prizmkit/plans/feature-list.json` passes the validation/generate script and **before** the final handoff summary recommends `feature-pipeline-launcher`. This gate applies to full workflow and fast-path incremental planning.
+
+1. **Identify review scope**: compare the final validated feature list against the pre-session list when one existed. Review only newly added or changed feature entries. Do not re-review unchanged historical entries except when needed to verify dependency references.
+2. **Invoke `/prizmkit-code-review` as a planning-quality gate** with an explicit prompt that this is a plan-entry review, not an implementation review. The review must check:
+   - schema correctness and compatibility with `dev-pipeline-feature-list-v1`
+   - dependency/DAG soundness, including missing, invalid, circular, or poorly ordered dependencies
+   - description completeness and headless execution readiness
+   - acceptance criteria specificity and measurability
+   - preservation of user-provided wording in `description`, `acceptance_criteria`, and `user_context`
+   - task-scoped `user_context` isolation: no unrelated sibling feature descriptions, file references, or supplementary materials, and shared context appears on multiple items only when explicitly global
+   - priority/complexity calibration: every reviewed feature has a short priority rationale and complexity rationale, medium/low assignments are allowed when criteria fit, and high/high is not used merely because work is framework-related, multi-file, or user-requested
+3. **Keep the review planning-only**: do NOT start `feature-pipeline-launcher`, do NOT run the dev-pipeline, do NOT run tests/builds/installs, and do NOT implement source-code changes.
+4. **Apply accepted review fixes through the draft/source plan**: when a finding is accepted, update `.prizmkit/plans/feature-list.draft.json` or the in-memory draft representation first, then regenerate the final file with:
+   ```bash
+   python3 ${SKILL_DIR}/scripts/validate-and-generate.py generate --input .prizmkit/plans/feature-list.draft.json --output .prizmkit/plans/feature-list.json
+   ```
+   Do not hand-patch the final JSON as the source of truth; map final-output findings back to draft entries before regeneration.
+5. **Revalidate after every accepted fix batch**: the generate script must pass again before the planner can proceed. If validation fails, fix the draft and rerun until pass.
+6. **Report the gate outcome** in the final summary: include `/prizmkit-code-review` verdict, reviewed feature IDs, accepted fixes (or "none"), and final validation result.
+
 ## Testing Defaults (Phase 8)
 
 Set default testing-related fields for each feature. The user can opt out.
@@ -369,10 +447,11 @@ When the session appears to be ending:
 
 ## Handoff Message Template
 
-After successful validation, report:
+After successful validation and the Post-Generation Plan Review Gate, report:
 1. Output file path
 2. Total features + newly added features
 3. Dependency and priority highlights
-4. Recommended next action: `feature-pipeline-launcher`
+4. Review result: `/prizmkit-code-review` verdict, reviewed feature IDs, accepted fixes (or "none"), and final validation result
+5. Recommended next action: `feature-pipeline-launcher`
 
 Then apply the post-planning handoff in §Scope Boundary (ask before proceeding; never auto-execute).

package/bundled/skills/feature-planner/assets/planning-guide.md

@@ -116,12 +116,25 @@ Then [expected outcome]
 
 ## Complexity Estimation Guide
 
-| Complexity | Characteristics | Typical Scope | Pipeline Tier |
-|------------|----------------|---------------|---------------|
-| low | Single module, straightforward CRUD, minimal UI | 1-2 API endpoints, 1-2 pages | lite (1 agent) |
-| medium | Multiple modules, business logic, moderate UI | 3-5 API endpoints, 2-4 pages | lite (1 agent) |
-| high | Cross-cutting concerns, complex state, advanced UI | 5+ API endpoints, complex interactions | standard (3 agents) |
-| critical | Architectural changes, 10+ files, multi-module API surface changes | System-wide refactoring, new infrastructure + app logic | full (5 agents + critic) |
+Complexity is an execution-scope estimate, not a priority or importance signal. Do not default to `high` because a feature is framework work, multi-file work, or strongly requested by the user. Assign complexity from concrete indicators and include a short rationale in the planner's confirmation table.
+
+| Complexity | Concrete Indicators | Typical Scope | Pipeline Tier |
+|------------|---------------------|---------------|---------------|
+| low | 1 module/layer, 1-3 files, no public API/schema change, shallow dependencies, <=5 acceptance criteria, clear existing tests | 1-2 API endpoints, 1-2 pages, focused config or copy behavior | lite (1 agent) |
+| medium | 2-3 modules/layers, 3-6 files, bounded API/interface changes, moderate dependency depth, 4-8 acceptance criteria, standard test updates | 3-5 API endpoints, 2-4 pages, normal integration work | lite (1 agent) |
+| high | 3+ modules/layers plus public API/interface or schema impact, deep dependencies, weak test coverage, complex state, third-party integration risk, or 8+ acceptance criteria | 5+ API endpoints, complex interactions, cross-cutting behavior | standard (3 agents) |
+| critical | System-wide architecture, new infrastructure, 10+ files with multi-module API surface changes, safety/security/data-loss risk requiring multi-critic review | System-wide refactoring, new infrastructure + app logic | full (5 agents + critic) |
+
+### Complexity Indicator Checklist
+
+Use at least two relevant indicators in each `estimated_complexity` rationale:
+- affected module count and layer count
+- expected file count and implementation surface
+- API/interface/schema changes
+- architectural impact or new infrastructure
+- dependency depth and cross-feature coupling
+- acceptance-criteria count and edge-case breadth
+- existing test coverage and verification difficulty
 
 ### Complexity Red Flags
 
@@ -136,10 +149,21 @@ Consider splitting a feature if it exhibits any of the following:
 
 ### Estimation Consistency Rules
 
-- If a feature is marked as "low" complexity, it should not have more than 5 acceptance criteria.
-- If a feature is marked as "high" complexity, it should have a clear justification (e.g., "involves payment processing with webhook handling and idempotency").
-- Use "critical" complexity only for features requiring architectural changes that touch 10+ files, involve cross-module API surface changes, or need multi-critic voting for safety.
-- When in doubt, estimate higher -- it is better to over-allocate than to under-allocate.
+- If a feature is marked as `low` complexity, it should not have more than 5 acceptance criteria and should have no public API/schema changes.
+- If a feature is marked as `medium` complexity, explain why the scope is bounded even if it touches multiple files.
+- If a feature is marked as `high` complexity, it must have a clear concrete justification (e.g., "payment processing with webhook idempotency across API, persistence, and worker modules").
+- Use `critical` complexity only for features requiring architectural changes that touch 10+ files, involve cross-module API surface changes, or need multi-critic voting for safety.
+- When in doubt between two levels, choose the higher level only when the concrete scope indicators support it; do not use `high` as a safe default.
+
+### Mixed Calibration Examples
+
+| Feature | Priority | Complexity | Rationale |
+|---------|----------|------------|-----------|
+| Restore broken login for all users | high | high | Core auth workflow blocked with no workaround; API, middleware, and session tests affected. |
+| Add CSV delimiter option to existing export | medium | medium | Useful workflow improvement with workaround; bounded UI + API parameter and existing tests. |
+| Update tooltip wording on settings page | low | low | Cosmetic clarity only; one component, no interface change, simple visual check. |
+
+Anti-pattern: a generated plan where every item is `Priority: high` and `Complexity: high` is invalid unless every item independently names the documented high-priority and high-complexity indicators it satisfies. In feature JSON this corresponds to `estimated_complexity: high`; review summaries should still show a human-readable `Complexity` column.
 
 ---