prizmkit 1.1.112 → 1.1.114

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

@@ -283,42 +283,37 @@ 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. **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
+4. **Run the mandatory Local Generated-Plan Review Gate** (see §Local Generated-Plan Review Gate below): load `${SKILL_DIR}/references/generated-plan-review.md` and review only newly added/changed bug entries after validation passes and before success output.
+5. **Output**: File path, summary, local generated-plan 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.
+**Gate → CP-BP-6**: Local generated-plan review loaded `${SKILL_DIR}/references/generated-plan-review.md`, reviewed only newly added/changed bug entries, applied accepted fixes through draft/source data, regenerated, and revalidated.
 
-## Post-Generation Plan Review Gate
+## Local Generated-Plan Review Gate
 
-User requirement preserved verbatim: `每次完成任务规划的时候，应该调用/prizmkit-code-review 对新增的计划内容进行review，确保生成新增的计划的正确行和完整性。`
+User requirement preserved verbatim: `there is a litter bug for prizm-code-review will to check git diff in working space and staged space , however the .prizmkit will be gitignored in most situation.  so do you think the content should be change to inline a new reference file instead of use prizmkit-code-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.
+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 append-to-existing bug list flows when the current session generated, appended, or rewrote final bug planning content. For Validate, Summary, or draft-save flows with no new final planning content, report: `Local generated-plan review: not applicable — no new final planning content written.`
 
-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:
+1. **Load the local reference**: read `${SKILL_DIR}/references/generated-plan-review.md` and follow it as the source of truth for this planner-output review loop.
+2. **Read actual planning artifacts directly**: inspect `.prizmkit/plans/bug-fix-list.json`, `.prizmkit/plans/bug-fix-list.draft.json` when present, and any pre-session or in-memory draft snapshot. Do not rely on `git status`, `git diff`, or `git diff --cached`, because `.prizmkit` planning artifacts are often gitignored or untracked.
+3. **Identify review scope**: compare by stable bug IDs and item fields against the pre-session list when one existed. Ignore root generator metadata such as `$schema`, `created_at`, and `created_by`. Review only newly added or changed bug entries; preserve unchanged historical entries except when needed to verify duplicate/root-cause overlap or dependency references.
+4. **Run the local checklist** from the reference: schema compatibility, dependency/DAG consistency, duplicate handling, root-cause overlap, description completeness, expected vs actual behavior, reproduction path, code-location hints, acceptance criteria measurability, user-provided wording preservation, task-scoped `user_context` isolation, and severity/priority calibration.
+5. **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.
+6. **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.
+7. **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.
+8. **Report the gate outcome** in the final summary: include local generated-plan 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
+Local generated-plan review: PASS, reviewed B-001..B-003, accepted fixes: none, final validation: PASS
 
 Next steps:
 - Review: cat .prizmkit/plans/bug-fix-list.json
@@ -336,7 +331,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 |
+| **CP-BP-6** | Local Plan Review Passed | Local generated-plan review loaded `${SKILL_DIR}/references/generated-plan-review.md`, reviewed only newly added/changed bug entries, applied accepted fixes through draft/source data, 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.
 
@@ -363,7 +358,7 @@ Batch-parse error logs with minimal interaction: parse automatically, then requi
    ```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`.
+7. If validation passes, run the mandatory Local Generated-Plan Review Gate before summarizing or recommending `bugfix-pipeline-launcher`.
 
 ## Operation: From Tests
 
@@ -381,7 +376,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`.
+7. If validation passes, run the mandatory Local Generated-Plan Review Gate before summarizing or recommending `bugfix-pipeline-launcher`.
 
 ## Operation: Validate
 
@@ -436,7 +431,7 @@ Recommend invoking `bugfix-pipeline-launcher` to configure and launch the pipeli
 
 After `.prizmkit/plans/bug-fix-list.json` is generated, validated, and reviewed, present:
 1. Summary of generated bugs (count, severity breakdown)
-2. Review result: `/prizmkit-code-review` verdict, reviewed bug IDs, accepted fixes (or "none"), and final validation result
+2. Local generated-plan review result: 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`
 

package/bundled/skills/bug-planner/references/generated-plan-review.md

@@ -0,0 +1,63 @@
+# Generated Plan Review — Bug Planner
+
+Use this local review loop after `.prizmkit/plans/bug-fix-list.json` has been generated and validated. This is a planner-output review, not an implementation/code-diff review.
+
+## Trigger
+
+Run only when the current `bug-planner` session generated, appended, or rewrote final bug planning content. For validate-only, summary-only, or draft-save flows with no new final planning content, report: `Local generated-plan review: not applicable — no new final planning content written.`
+
+## Direct Artifact Reads
+
+Planning artifacts may be gitignored, untracked, or absent from staged and unstaged diffs. Read the actual files directly:
+
+- Final list: `.prizmkit/plans/bug-fix-list.json`
+- Draft/source list when present: `.prizmkit/plans/bug-fix-list.draft.json`
+- Pre-session final list snapshot if captured in memory before edits
+- In-memory draft object if the session has not written a draft file yet
+
+Do not rely on `git status`, `git diff`, or `git diff --cached` to decide whether planner output exists or changed. Do not invoke `/prizmkit-code-review` for this planner-output gate; `/prizmkit-code-review` remains the implementation/code-diff review gate after `/prizmkit-implement`.
+
+## Review Scope
+
+1. If a pre-session final list exists, compare by stable bug IDs (`B-*`).
+2. Treat bugs as changed only when item fields changed. Ignore root generator metadata and formatting-only differences such as `$schema`, `created_at`, and `created_by`.
+3. Review newly added bug IDs and changed bug IDs.
+4. Preserve unchanged historical bugs. Read unchanged entries only when needed to verify dependency references, duplicate handling, or root-cause overlap with reviewed bugs.
+5. If no snapshot exists, review all bug entries produced by the current generation flow.
+
+## Review Checklist
+
+For every reviewed bug entry, check:
+
+- Schema compatibility with `dev-pipeline-bug-fix-list-v1` and `.prizmkit/dev-pipeline/templates/bug-fix-list-schema.json`
+- Dependency/DAG consistency, duplicate handling, and root-cause overlap
+- Description completeness: expected vs actual behavior, reproduction path, code-location hints, affected environment, and headless execution readiness
+- Acceptance criteria specificity and measurable verification method
+- User-provided wording preservation in `description`, `acceptance_criteria`, and `user_context`
+- Task-scoped `user_context` isolation: no unrelated sibling bug descriptions, logs, stack traces, reproduction steps, expected/actual behavior notes, or supplementary materials; shared context appears on multiple bugs 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
+- Browser interaction and verification fields for UI-reproducible bugs when applicable
+
+## Fix Loop
+
+1. Present findings with IDs, severity, evidence, and suggested draft/source changes.
+2. Accept only findings that improve planner correctness, completeness, or downstream bug-fix execution readiness.
+3. Apply accepted fixes to `.prizmkit/plans/bug-fix-list.draft.json` or the in-memory draft object first.
+4. Regenerate the final list through the existing generator:
+
+```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
+```
+
+5. Re-run validation/generation until valid. Do not hand-patch `.prizmkit/plans/bug-fix-list.json` as the source of truth.
+6. Repeat the local review only for entries changed by accepted fixes.
+
+## Report Format
+
+Report in the final handoff summary:
+
+- `Local generated-plan review: PASS` or `NEEDS_FIXES`
+- Reviewed bug IDs
+- Accepted fixes, or `none`
+- Final validation result
+- Note when review was not applicable because no new final planning content was written

package/bundled/skills/bug-planner/scripts/validate-bug-list.py

@@ -34,6 +34,38 @@ BUG_ID_PATTERN = re.compile(r"^B-\d{3}$")
 SCHEMA_VERSION = "dev-pipeline-bug-fix-list-v1"
 
 
+def _find_dependency_cycle(dep_map, item_ids):
+    """Return one dependency cycle as a list of bug IDs, or an empty list."""
+    visiting = set()
+    visited = set()
+    stack = []
+
+    def visit(node):
+        visiting.add(node)
+        stack.append(node)
+        for dep in dep_map.get(node, []):
+            if dep not in item_ids:
+                continue
+            if dep in visiting:
+                start = stack.index(dep)
+                return stack[start:] + [dep]
+            if dep not in visited:
+                cycle = visit(dep)
+                if cycle:
+                    return cycle
+        stack.pop()
+        visiting.remove(node)
+        visited.add(node)
+        return []
+
+    for bug_id in sorted(item_ids):
+        if bug_id not in visited:
+            cycle = visit(bug_id)
+            if cycle:
+                return cycle
+    return []
+
+
 def _err(msg):
     """Print an error message to stderr."""
     print("ERROR: {}".format(msg), file=sys.stderr)
@@ -181,15 +213,23 @@ def validate(data, feature_ids=None):
         for bug in bugs
         if BUG_ID_PATTERN.match(str(bug.get("id", "")))
     }
+    dep_map = {bug_id: [] for bug_id in known_ids}
     for i, bug in enumerate(bugs):
         bug_id = bug.get("id", "")
         deps = bug.get("dependencies", []) or []
         if not isinstance(deps, list):
             continue
         for dep in deps:
-            if isinstance(dep, str) and BUG_ID_PATTERN.match(dep) and dep not in known_ids:
-                errors.append("bugs[{}] ({}): dependency '{}' does not exist".format(
-                    i, bug_id, dep))
+            if isinstance(dep, str) and BUG_ID_PATTERN.match(dep):
+                if dep not in known_ids:
+                    errors.append("bugs[{}] ({}): dependency '{}' does not exist".format(
+                        i, bug_id, dep))
+                elif BUG_ID_PATTERN.match(str(bug_id)):
+                    dep_map.setdefault(bug_id, []).append(dep)
+
+    cycle = _find_dependency_cycle(dep_map, known_ids)
+    if cycle:
+        errors.append("Dependency cycle detected: {}".format(" -> ".join(cycle)))
 
     return {
         "valid": len(errors) == 0,

package/bundled/skills/bugfix-pipeline-launcher/SKILL.md

@@ -5,7 +5,7 @@ description: "Launch and manage the bugfix pipeline from within an AI CLI sessio
 
 # Bugfix-Pipeline Launcher
 
-Launch the autonomous bug fix pipeline from within an AI CLI conversation. Supports foreground and background execution modes.
+Launch the autonomous bug fix pipeline from within an AI CLI conversation. Only Background daemon mode is fully detached and survives AI CLI session closure; Foreground runs in the current session, and Manual prints commands without launching.
 
 ### Execution Mode
 
@@ -15,7 +15,7 @@ Three execution modes are available. The user chooses one before configuring oth
 2. **Background daemon** — `python3 ./.prizmkit/dev-pipeline/cli.py daemon bugfix start .prizmkit/plans/bug-fix-list.json`. Runs fully detached, survives AI CLI session closure.
 3. **Manual** — Display the assembled command(s) only. Do not execute anything. User runs them on their own.
 
-**Background mode traceability**: Daemon mode metadata and logs are written by the Python runtime (`daemon bugfix start/status/logs`). Do not append a separate skill-managed audit log.
+**Background mode traceability**: Daemon mode metadata and logs are written by the Python runtime (`daemon bugfix start/status/logs`). Do not create any extra launcher-managed audit file.
 
 ### When to Use
 
@@ -90,7 +90,6 @@ Detect user intent from their message, then follow the corresponding workflow:
        data = json.load(f)
    bugs = data.get('bugs', [])
    severity_order = {'critical': 0, 'high': 1, 'medium': 2, 'low': 3}
-   bugs_sorted = sorted(bugs, key=lambda b: (severity_order.get(b.get('severity', 'medium'), 2), b.get('priority', 99)))
    print(f'Total bugs: {len(bugs)}')
    sev_counts = {}
    for b in bugs:
@@ -98,7 +97,7 @@ Detect user intent from their message, then follow the corresponding workflow:
        sev_counts[s] = sev_counts.get(s, 0) + 1
    print(f'By severity: {dict(sorted(sev_counts.items(), key=lambda x: severity_order.get(x[0], 2)))}')
    print()
-   for b in bugs_sorted:
+   for b in bugs:
        print(f\"  {b['id']}: [{b.get('severity','?').upper()}] {b.get('title', 'untitled')}\")
    "
    ```
@@ -165,6 +164,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    - Summarize results: total bugs, fixed, failed, skipped
    - If all fixed: each bug session has already run `prizmkit-retrospective` internally (structural sync by default; full retrospective when the fix changed interfaces, dependencies, or observable behavior). Ask user what's next.
    - If some failed: show failed bug IDs and suggest `python3 ./.prizmkit/dev-pipeline/cli.py reset bugfix <B-XXX> --clean --run` for a fresh retry
+   - **Browser verification**: Bug sessions with `browser_interaction` perform their own verification attempts during execution. After completion, use `python3 ./.prizmkit/dev-pipeline/cli.py bugfix status .prizmkit/plans/bug-fix-list.json` and per-bug session logs as the source of truth before summarizing browser verification results.
 
    **If background daemon**:
    1. Verify launch:
@@ -264,9 +264,9 @@ Read `${SKILL_DIR}/references/configuration.md` for the full error handling tabl
 ### Integration Notes
 
 - **After bug-planner**: This is the natural next step. When user finishes bug planning and has `.prizmkit/plans/bug-fix-list.json`, suggest launching the bugfix pipeline.
-- **Session independence**: In daemon mode, the bugfix pipeline runs completely detached. User can close the AI CLI, open a new session later, and use this skill to check progress or stop the pipeline.
+- **Session independence**: Only Background daemon mode runs detached. Foreground runs in the current AI CLI session, and Manual mode prints commands without launching.
 - **Single instance per family**: Only one bugfix pipeline can run at a time. Different pipeline families may coexist because they use separate daemon metadata and state directories.
-- **Feature pipeline coexistence**: Bugfix and feature pipelines use separate state directories (`.prizmkit/state/bugfix/` vs `.prizmkit/state/features/`), so they can run simultaneously without conflict.
+- **Pipeline coexistence**: Bugfix, feature, and refactor pipelines use separate state directories (`.prizmkit/state/bugfix/`, `.prizmkit/state/features/`, `.prizmkit/state/refactor/`), so all three can run simultaneously without conflict.
 - **State preservation**: Stopping and restarting the bugfix pipeline resumes from where it left off -- completed bugs are not re-fixed.
 - **Bug ordering**: Dependencies are active. Runtime selects eligible bugs in stable list order after dependencies are completed; planners should order unrelated bugs by severity/priority before launch.
 - **Background mode traceability**: Daemon mode metadata/logging is runtime-owned; use `daemon bugfix status` and `daemon bugfix logs`.

package/bundled/skills/feature-pipeline-launcher/SKILL.md

@@ -309,22 +309,13 @@ Notes:
 
 After pipeline completion, if features have `browser_interaction` fields and the corresponding browser tool (`playwright-cli` or `opencli`) is installed:
 
-If list status may be stale, prefer the runtime status command before deciding which completed features qualify:
+If list status may be stale, use the runtime status command as the source of truth for completion state:
 `python3 ./.prizmkit/dev-pipeline/cli.py feature status .prizmkit/plans/feature-list.json`.
 
-1. **Check which features qualify**:
-   ```bash
-   python3 -c "
-   import json
-   with open('.prizmkit/plans/feature-list.json') as f:
-       data = json.load(f)
-   for feat in data.get('features', []):
-       bi = feat.get('browser_interaction')
-       if bi and feat.get('status') == 'completed':
-           tool = bi.get('tool', 'auto') if isinstance(bi, dict) else 'auto'
-           print(f\"  {feat['id']}: {feat.get('title','')} (tool: {tool})\")
-   " 2>/dev/null
-   ```
+1. **Check which completed features have browser verification configured**:
+   - Read `browser_interaction` configuration from `.prizmkit/plans/feature-list.json`.
+   - Use the runtime status command output to decide which configured features are actually completed.
+   - Do not rely on list-file `status` alone when runtime state exists, because daemon/foreground bookkeeping may be newer than the plan file.
 
 2. **Ask user**: "N features have browser verification configured. Run browser verification now? (Y/n)"
 
@@ -352,8 +343,8 @@ Read `${SKILL_DIR}/references/configuration.md` for the full error handling tabl
 ### Integration Notes
 
 - **After feature-planner**: This is the natural next step. When user finishes planning and has `.prizmkit/plans/feature-list.json`, suggest launching the pipeline.
-- **Session independence**: The pipeline runs completely detached. User can close the AI CLI session, open a new session later, and use this skill to check progress or stop the pipeline.
+- **Session independence**: Only Background daemon mode runs detached. Foreground runs in the current AI CLI session, and Manual mode prints commands without launching.
 - **Single instance per family**: Only one feature pipeline can run at a time. Different pipeline families may coexist because they use separate daemon metadata and state directories.
-- **Pipeline coexistence**: Feature and bugfix pipelines use separate state directories (`.prizmkit/state/features/` vs `.prizmkit/state/bugfix/`), so they can run simultaneously without conflict.
+- **Pipeline coexistence**: Feature, bugfix, and refactor pipelines use separate state directories (`.prizmkit/state/features/`, `.prizmkit/state/bugfix/`, `.prizmkit/state/refactor/`), so all three can run simultaneously without conflict.
 - **State preservation**: Stopping and restarting the pipeline resumes from where it left off -- completed features are not re-run.
 - **HANDOFF**: After pipeline completes all features, each session has already run `prizmkit-retrospective` internally. Ask user what's next.

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

@@ -253,8 +253,8 @@ Execute the planning workflow in conversation mode with mandatory checkpoints:
 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. 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
+10. Run the mandatory Local Generated-Plan Review Gate (see §Local Generated-Plan Review Gate below); apply accepted fixes to the draft/source plan, regenerate, and revalidate until pass
+11. Summarize final feature table with local review result and validation outcome
 
 ### Checkpoints (Mandatory Gates)
 
@@ -270,7 +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 |
+| **CP-FP-6** | Local Plan Review Passed | Local generated-plan review loaded `${SKILL_DIR}/references/generated-plan-review.md`, reviewed only newly added/changed feature entries, applied accepted fixes through draft/source data, regenerated, and revalidated | 10 |
 
 **Resume Detection**: If existing artifacts are found, read `${SKILL_DIR}/references/error-recovery.md` §Resume Support for checkpoint-based resumption.
 
@@ -320,7 +320,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 → run the mandatory Post-Generation Plan Review Gate, then summarize and recommend next step
+6. If valid → run the mandatory Local Generated-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
@@ -373,29 +373,24 @@ 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
+## Local Generated-Plan Review Gate
 
-User requirement preserved verbatim: `每次完成任务规划的时候，应该调用/prizmkit-code-review 对新增的计划内容进行review，确保生成新增的计划的正确行和完整性。`
+User requirement preserved verbatim: `there is a litter bug for prizm-code-review will to check git diff in working space and staged space , however the .prizmkit will be gitignored in most situation.  so do you think the content should be change to inline a new reference file instead of use prizmkit-code-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.
+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 when the current session generated, appended, or rewrote final feature planning content. For validate-only, summary-only, or draft-save flows with no new final planning content, report: `Local generated-plan review: not applicable — no new final planning content written.`
 
-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:
+1. **Load the local reference**: read `${SKILL_DIR}/references/generated-plan-review.md` and follow it as the source of truth for this planner-output review loop.
+2. **Read actual planning artifacts directly**: inspect `.prizmkit/plans/feature-list.json`, `.prizmkit/plans/feature-list.draft.json` when present, and any pre-session or in-memory draft snapshot. Do not rely on `git status`, `git diff`, or `git diff --cached`, because `.prizmkit` planning artifacts are often gitignored or untracked.
+3. **Identify review scope**: compare by stable feature IDs and item fields against the pre-session list when one existed. Ignore root generator metadata such as `$schema`, `created_at`, and `created_by`. Review only newly added or changed feature entries; preserve unchanged historical entries except when needed to verify dependency references.
+4. **Run the local checklist** from the reference: schema compatibility, dependency/DAG soundness, description completeness, headless execution readiness, acceptance criteria measurability, user-provided wording preservation, task-scoped `user_context` isolation, priority/complexity calibration, and browser interaction fields when applicable.
+5. **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.
+6. **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.
+7. **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.
+8. **Report the gate outcome** in the final summary: include local generated-plan review verdict, reviewed feature IDs, accepted fixes (or "none"), and final validation result.
 
 ## Testing Defaults (Phase 8)
 
@@ -445,11 +440,11 @@ When the session appears to be ending:
 
 ## Handoff Message Template
 
-After successful validation and the Post-Generation Plan Review Gate, report:
+After successful validation and the Local Generated-Plan Review Gate, report:
 1. Output file path
 2. Total features + newly added features
 3. Dependency and priority highlights
-4. Review result: `/prizmkit-code-review` verdict, reviewed feature IDs, accepted fixes (or "none"), and final validation result
+4. Local generated-plan review result: 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/references/generated-plan-review.md

@@ -0,0 +1,63 @@
+# Generated Plan Review — Feature Planner
+
+Use this local review loop after `.prizmkit/plans/feature-list.json` has been generated and validated. This is a planner-output review, not an implementation/code-diff review.
+
+## Trigger
+
+Run only when the current `feature-planner` session generated, appended, or rewrote final feature planning content. For validate-only, summary-only, or draft-save flows with no new final planning content, report: `Local generated-plan review: not applicable — no new final planning content written.`
+
+## Direct Artifact Reads
+
+Planning artifacts may be gitignored, untracked, or absent from staged and unstaged diffs. Read the actual files directly:
+
+- Final list: `.prizmkit/plans/feature-list.json`
+- Draft/source list when present: `.prizmkit/plans/feature-list.draft.json`
+- Pre-session final list snapshot if captured in memory before edits
+- In-memory draft object if the session has not written a draft file yet
+
+Do not rely on `git status`, `git diff`, or `git diff --cached` to decide whether planner output exists or changed. Do not invoke `/prizmkit-code-review` for this planner-output gate; `/prizmkit-code-review` remains the implementation/code-diff review gate after `/prizmkit-implement`.
+
+## Review Scope
+
+1. If a pre-session final list exists, compare by stable feature IDs (`F-*`).
+2. Treat features as changed only when item fields changed. Ignore root generator metadata and formatting-only differences such as `$schema`, `created_at`, and `created_by`.
+3. Review newly added feature IDs and changed feature IDs.
+4. Preserve unchanged historical features. Read unchanged entries only when needed to verify dependency references from reviewed features.
+5. If no snapshot exists, review all feature entries produced by the current generation flow.
+
+## Review Checklist
+
+For every reviewed feature entry, check:
+
+- Schema compatibility with `dev-pipeline-feature-list-v1` and `.prizmkit/dev-pipeline/templates/feature-list-schema.json`
+- Dependency/DAG soundness: dependencies exist, no cycles, no poorly ordered prerequisite chains
+- Description completeness and headless execution readiness
+- Acceptance criteria specificity, measurability, and coverage of the described behavior
+- User-provided wording preservation in `description`, `acceptance_criteria`, and `user_context`
+- Task-scoped `user_context` isolation: no unrelated sibling feature descriptions, file references, or supplementary materials; shared context appears on multiple items only when explicitly global
+- Priority/complexity calibration: every reviewed feature has short priority and complexity rationales, 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
+- Browser interaction fields for qualifying frontend/fullstack features when applicable
+
+## Fix Loop
+
+1. Present findings with IDs, severity, evidence, and suggested draft/source changes.
+2. Accept only findings that improve planner correctness, completeness, or downstream execution readiness.
+3. Apply accepted fixes to `.prizmkit/plans/feature-list.draft.json` or the in-memory draft object first.
+4. Regenerate the final list through the existing generator:
+
+```bash
+python3 ${SKILL_DIR}/scripts/validate-and-generate.py generate --input .prizmkit/plans/feature-list.draft.json --output .prizmkit/plans/feature-list.json
+```
+
+5. Re-run validation/generation until valid. Do not hand-patch `.prizmkit/plans/feature-list.json` as the source of truth.
+6. Repeat the local review only for entries changed by accepted fixes.
+
+## Report Format
+
+Report in the final handoff summary:
+
+- `Local generated-plan review: PASS` or `NEEDS_FIXES`
+- Reviewed feature IDs
+- Accepted fixes, or `none`
+- Final validation result
+- Note when review was not applicable because no new final planning content was written

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

@@ -87,7 +87,7 @@ For existing-project feature work:
 Question: How would you like to proceed?
 Header: Approach
 Options:
-- Implement now (Fast Path) — current session/current workspace via /prizmkit-plan -> /prizmkit-implement -> review/retro/commit
+- Implement now (Fast Path) — current session/current workspace via simplified /prizmkit-plan -> /prizmkit-implement -> conditional test/review/retro -> /prizmkit-committer
 - Use Pipeline Path — feature-planner creates/reviews feature-list.json, then feature-pipeline-launcher configures execution
 - Continue clarifying — ask a few more route-level questions before choosing
 ```
@@ -166,12 +166,13 @@ Do not generate `feature-list.json` inside this workflow; `feature-planner` owns
 
 Use Fast Path only after explicit user selection.
 
-1. Invoke `/prizmkit-plan` with the handoff brief.
+1. Invoke `/prizmkit-plan` with the handoff brief; use simplified planning for this scoped feature.
 2. Invoke `/prizmkit-implement` after the plan is ready.
-3. Run `/prizmkit-code-review` as the quality gate.
-4. Run `/prizmkit-retrospective` for feature changes before commit.
-5. Run `/prizmkit-committer` with a `feat(<scope>):` message.
-6. End the workflow after commit; do not call `feature-planner`, `feature-pipeline-launcher`, or monitoring.
+3. Run `/prizmkit-test` only when risk triggers match: behavior, public interface, data model, security/permission/payment, deployment readiness, or explicit user verification request.
+4. Run `/prizmkit-code-review` when the user requested review, implementation uncertainty is high, or Full-path-level risk appears during implementation.
+5. Run `/prizmkit-retrospective` only when structure, interfaces, dependencies, behavior, or durable project knowledge changed.
+6. Run `/prizmkit-committer` with a `feat(<scope>):` message.
+7. End the workflow after commit; do not call `feature-planner`, `feature-pipeline-launcher`, or monitoring.
 
 If implementation scope grows beyond the Fast Path criteria, pause and ask whether to switch to Pipeline Path.
 
@@ -236,6 +237,6 @@ For start/stop/logs/retry execution, hand off to `feature-pipeline-launcher`; do
 
 ## Output
 
-- Fast Path: `spec.md`, `plan.md`, code changes, review result, Prizm docs sync, and one feature commit.
+- Fast Path: concise `spec.md`, simplified `plan.md`, code changes, conditional test/review evidence when triggered, Prizm docs sync only when durable knowledge changed, and one feature commit.
 - Pipeline Path: handoff brief, validated `.prizmkit/plans/feature-list.json` from `feature-planner`, and pipeline launch/status handled by `feature-pipeline-launcher`.
 - Greenfield path: app-level planning artifacts from `app-planner`, optionally followed by feature planning and launch.

package/bundled/skills/prizmkit-code-review/references/reviewer-agent-prompt.md

@@ -12,7 +12,7 @@ You are the dedicated PrizmKit Reviewer agent (`prizm-dev-team-reviewer`). Revie
 {architecture decisions and task list from plan.md}
 
 ## Scoped Test Report
-{summary from artifact_dir/test-report-path.txt and test-report.md, including Scope, Generated / Updated Tests, In-Scope Failures, Baseline Failures, Out of Scope Gaps, Boundary Matrix / Boundary Completion Gate if present, and Verdict. If no scoped report exists for a feature artifact, write "No scoped /prizmkit-test report found (expected for pre-test review)." Treat that absence as informational unless the calling workflow explicitly requires a prior test report.}
+{summary from artifact_dir/test-report-path.txt and test-report.md, including Scope, Generated / Updated Tests, In-Scope Failures, Baseline Failures, Out of Scope Gaps, Boundary Matrix / Boundary Completion Gate if present, and Verdict. If no scoped report exists for a change artifact, write "No scoped /prizmkit-test report found (expected for pre-test review)." Treat that absence as informational unless the calling workflow explicitly requires a prior test report.}
 
 ## Workspace Context
 {git status, unstaged diff summary, staged diff summary, current working directory, expected active checkout git top-level, and new-file paths captured by the Main Agent in Phase 0 from the active checkout. This is your primary review scope — use this context to understand what changed. Request targeted file reads only when you need specific line-level detail for a finding, not to re-discover or re-index the repository. Do not read files that are not in the workspace context unless you need them to verify impact (callers, dependents, shared patterns). Do not switch to a separate worktree or repository copy — the Main Agent has provided everything needed to understand the change set.}
@@ -49,7 +49,7 @@ Evaluate the changes across these dimensions (focus on what's relevant):
 3. **Completeness**: Files that should have been changed but weren't? Missing tests, types, imports, exports?
 4. **Consistency**: Do changes follow the project's existing patterns, naming conventions, and code style?
 5. **Security**: Hardcoded secrets, injection vulnerabilities, unsafe operations.
-6. **Test quality**: If a scoped `/prizmkit-test` report is present, verify the report scope is `this-change`, the artifact dir matches the feature, generated/updated tests assert real behavior rather than mock success or empty assertions, in-scope failures are not mislabeled as baseline failures, baseline failures are genuinely unrelated or pre-existing, out-of-scope gaps were not turned into unrelated test changes, and the report verdict is compatible with proceeding.
+6. **Test quality**: If a scoped `/prizmkit-test` report is present, verify the report scope is `this-change`, the artifact dir matches the reviewed change, generated/updated tests assert real behavior rather than mock success or empty assertions, in-scope failures are not mislabeled as baseline failures, baseline failures are genuinely unrelated or pre-existing, out-of-scope gaps were not turned into unrelated test changes, and the report verdict is compatible with proceeding.
 7. **Rules compliance**: (Skip this dimension if no dev rules were provided.) Do changes follow the per-layer dev rules? Flag violations of framework conventions, naming patterns, state management, or other rules defined for that layer.
 
 ## Output Format

package/bundled/skills/prizmkit-deploy/references/database-setup.md

@@ -10,7 +10,14 @@ During Discovery Step 1 (Project Detection), database drivers were already scann
 > - **Yes** → proceed with database installation
 > - **No** → skip, record in deploy.md with note "database must be configured by user"
 
-## PostgreSQL setup
+## Secrets file safety
+
+Before writing `.prizmkit/deploy/secrets.local.json`:
+
+1. Verify `.gitignore` or an equivalent ignore rule covers `.prizmkit/deploy/secrets.local.json` and any `.prizmkit/deploy/*.local.json` pattern used by the project.
+2. If the ignore rule is missing, pause and add or request the ignore rule before writing secrets.
+3. Set the secrets file permissions to current-user read/write only, for example `chmod 600 .prizmkit/deploy/secrets.local.json` on POSIX systems.
+4. Record only presence metadata in deploy config, docs, reports, and history. Never copy raw passwords, connection strings, passphrases, decryption keys, unsalted hashes, or full env var values into committed files.
 
 ```
 apt-get install -y postgresql postgresql-contrib
@@ -21,7 +28,8 @@ sudo -u postgres psql -c "GRANT ALL ON DATABASE <project> TO <project>;"
 
 - Generate a secure random password (32 chars, alphanumeric + symbols).
 - Write the connection string to `.prizmkit/deploy/secrets.local.json`: `DATABASE_URL=postgresql://<project>:<password>@localhost:5432/<project>`.
-- In deploy.md, write: "PostgreSQL installed, connection info recorded in `.prizmkit/deploy/secrets.local.json` (not committed to git)".
+- Set `.prizmkit/deploy/secrets.local.json` permissions to current-user read/write only after writing.
+- In deploy.md, write: "PostgreSQL installed, connection info recorded in `.prizmkit/deploy/secrets.local.json` (gitignored; raw value not committed)".
 
 ## MySQL setup (future)
 
@@ -37,10 +45,11 @@ redis-cli CONFIG REWRITE
 
 - Bind to localhost only (modify `/etc/redis/redis.conf` if needed).
 - Write `REDIS_URL=redis://:<password>@localhost:6379` to `.prizmkit/deploy/secrets.local.json`.
+- Set `.prizmkit/deploy/secrets.local.json` permissions to current-user read/write only after writing.
 
 ## Security notes
 
 - Never write database passwords to deploy.md, because deploy.md may be committed to git and passwords would leak.
-- Passwords stored in `.prizmkit/deploy/secrets.local.json` (gitignored).
+- Passwords stored in `.prizmkit/deploy/secrets.local.json` only after verifying the file is ignored by git and locked down to current-user read/write permissions.
 - Default: database binds to localhost, no external access, because most indie projects only need local connections.
 - Record a `"database-setup"` event in deploy history (presence metadata only, no passwords).

package/bundled/skills/prizmkit-init/SKILL.md

@@ -140,7 +140,7 @@ Detect database and deployment signals, then ask 1-2 brief questions. This phase
    - If "SaaS platform": follow up with platform selection (Vercel / Railway / Fly.io / Cloudflare / AWS / Other)
 
 3. **Write results**:
-   - Append `### Infrastructure` section to the detected platform instruction file (`AGENTS.md` for Codex, `CLAUDE.md` for Claude Code, `CODEBUDDY.md` for CodeBuddy) with detection results and user answers. Format:
+   - Append `### Infrastructure` section to the detected **main** platform instruction file (`AGENTS.md` for Codex, `CLAUDE.md` for Claude Code, `CODEBUDDY.md` for CodeBuddy). Do not write Infrastructure to `AGENTS.private.md`, `CLAUDE.private.md`, or `CODEBUDDY.private.md`; private files are reserved for PrizmKit framework protocol imports. Format:
      ```markdown
      ### Infrastructure
 
@@ -302,7 +302,7 @@ Layer Detection:
 Infrastructure Quick Scan:
   Database: PostgreSQL (Prisma) — detected from dependencies
   Deployment: Vercel — detected from vercel.json
-  → Written to the detected platform instruction file `### Infrastructure`
+  → Written to the detected main platform instruction file `### Infrastructure` (not `.private.md`)
 
 Rules Quick Entry:
   Matched layers: frontend (React), backend (Express.js), database (Prisma) → keeping default rules