prizmkit 1.0.67 → 1.0.74

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

@@ -1,6 +1,6 @@
 ---
 name: "bugfix-pipeline-launcher"
-description: "Launch and manage the bugfix pipeline from within an AI CLI session. Start pipeline in background, monitor logs, check status, stop pipeline. Use this skill whenever the user wants to start fixing bugs, run the bugfix pipeline, check bugfix progress, or stop the bugfix pipeline. Trigger on: 'start fixing bugs', 'run bugfix pipeline', 'bugfix status', 'stop bug fix', '启动 bug 修复', '开始修复 bug', '修复进度', '停止修复'. (project)"
+description: "Launch and manage the bugfix pipeline from within an AI CLI session. Start pipeline in background, monitor logs, check status, stop pipeline. Use this skill whenever the user wants to start fixing bugs, run the bugfix pipeline, check bugfix progress, or stop the bugfix pipeline. Trigger on: 'start fixing bugs', 'run bugfix pipeline', 'bugfix status', 'stop bug fix', 'launch bug fix', 'start fixing bugs', 'fix progress', 'stop fixing'. (project)"
 ---
 
 # Bugfix-Pipeline Launcher
@@ -16,21 +16,21 @@ Always use daemon mode via `dev-pipeline/launch-bugfix-daemon.sh` for start/stop
 **Start bugfix pipeline** -- User says:
 - "start fixing bugs", "run bugfix pipeline", "launch bug fixes", "fix all bugs"
 - "start bug fix", "run bug fix", "execute bug list", "begin fixing"
-- "启动 bug 修复", "开始修复 bug", "运行 bug 修复流水线", "开始修 bug"
-- "修复所有 bug", "批量修复", "启动修复流水线"
-- After bug-planner completes: "fix them", "开始修复"
+- "launch bug fix", "start fixing bugs", "run bug fix pipeline", "start fixing bugs"
+- "fix all bugs", "batch fix", "launch fix pipeline"
+- After bug-planner completes: "fix them", "start fixing"
 
 **Check status** -- User says:
 - "bugfix status", "check bug fixes", "how's the fixing going", "bug fix progress"
-- "修复进度", "bug 修复状态", "查看修复进度", "修复到哪了"
+- "fix progress", "bug fix status", "check fix progress", "how far along are the fixes"
 
 **Stop bugfix pipeline** -- User says:
 - "stop bug fix", "stop fixing", "halt bugfix", "pause bug fix"
-- "停止修复", "暂停 bug 修复", "停止修复流水线"
+- "stop fixing", "pause bug fix", "stop fix pipeline"
 
 **Show logs** -- User says:
 - "bugfix logs", "show fix logs", "what's being fixed"
-- "查看修复日志", "修复日志", "看看修复情况"
+- "view fix logs", "fix logs", "check fix status"
 
 **Do NOT use this skill when:**
 - User wants to plan/collect bugs (use `bug-planner` instead)
@@ -203,9 +203,9 @@ When user specifies custom settings, map to environment variables:
 
 | User says | Environment variable |
 |-----------|---------------------|
-| "timeout 2 hours" / "超时2小时" | `SESSION_TIMEOUT=7200` |
-| "max 5 retries" / "最多重试5次" | `MAX_RETRIES=5` |
-| "verbose mode" / "详细模式" | `VERBOSE=1` |
+| "timeout 2 hours" | `SESSION_TIMEOUT=7200` |
+| "max 5 retries" | `MAX_RETRIES=5` |
+| "verbose mode" | `VERBOSE=1` |
 | "heartbeat every 60s" | `HEARTBEAT_INTERVAL=60` |
 
 Pass via `--env`:
@@ -217,7 +217,7 @@ dev-pipeline/launch-bugfix-daemon.sh start bug-fix-list.json --env "SESSION_TIME
 
 #### Intent F: Retry Single Bug
 
-When user says "retry B-001" or "重试 B-001":
+When user says "retry B-001":
 
 ```bash
 dev-pipeline/retry-bug.sh B-001 bug-fix-list.json

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

@@ -1,6 +1,6 @@
 ---
 name: "dev-pipeline-launcher"
-description: "Launch and manage the dev-pipeline from within an AI CLI session. Start pipeline in background, monitor logs, check status, stop pipeline. Use this skill whenever the user wants to start building features, run the pipeline, check pipeline progress, retry features, or stop the pipeline. Trigger on: 'run pipeline', 'start pipeline', 'start building', 'pipeline status', 'stop pipeline', 'retry feature', '启动流水线', '开始实现', '流水线状态', '停止流水线'. (project)"
+description: "Launch and manage the dev-pipeline from within an AI CLI session. Start pipeline in background, monitor logs, check status, stop pipeline. Use this skill whenever the user wants to start building features, run the pipeline, check pipeline progress, retry features, or stop the pipeline. Trigger on: 'run pipeline', 'start pipeline', 'start building', 'pipeline status', 'stop pipeline', 'retry feature', 'launch pipeline', 'start implementing', 'check pipeline status', 'stop the pipeline'. (project)"
 ---
 
 # Dev-Pipeline Launcher
@@ -9,32 +9,41 @@ Launch the autonomous development pipeline from within an AI CLI conversation. T
 
 ### Execution Mode
 
-Always use daemon mode via `dev-pipeline/launch-daemon.sh` for start/stop/status/log actions. Foreground `run.sh` can be terminated by AI CLI session timeout, while daemon mode survives session closure — this prevents half-finished features that leave the codebase in an inconsistent state.
+**Default: Foreground mode** via `dev-pipeline/run.sh run` — this provides visible output and direct error feedback. Use `launch-daemon.sh` only when the user explicitly requests background execution (e.g., "run in background", "detached mode").
+
+Foreground `run.sh` is preferred because:
+- Immediate visibility of errors and progress
+- No orphaned processes if something goes wrong
+- Session summary artifacts are written reliably
+
+Use daemon mode (`launch-daemon.sh`) only when:
+- User explicitly requests background/detached execution
+- Pipeline must survive AI CLI session closure
 
 ### When to Use
 
 **Start pipeline** -- User says:
 - "run pipeline", "start pipeline", "start building", "launch dev-pipeline"
 - "run the features", "execute feature list", "start implementing"
-- "启动流水线", "开始实现", "运行流水线", "开始自动开发"
-- "实现接下来的步骤", "执行 feature list", "开始构建"
-- After app-planner completes: "build it", "按 feature list 开始开发"
+- "launch pipeline", "start implementing", "run the pipeline", "start auto-development"
+- "implement next steps", "execute feature list", "start building"
+- After app-planner completes: "build it", "start developing from the feature list"
 
 **Check status** -- User says:
 - "pipeline status", "check pipeline", "how's it going", "progress"
-- "流水线状态", "查看进度", "现在什么情况"
+- "pipeline status", "check progress", "what's the current situation"
 
 **Stop pipeline** -- User says:
 - "stop pipeline", "kill pipeline", "halt", "pause"
-- "停止流水线", "暂停流水线"
+- "stop the pipeline", "pause the pipeline"
 
 **Show logs** -- User says:
 - "show logs", "pipeline logs", "tail logs", "what's happening"
-- "查看日志", "流水线日志", "看看日志"
+- "view logs", "pipeline logs", "check the logs"
 
 **Retry single feature node** -- User says:
 - "retry F-003", "retry this feature", "retry this node"
-- "重试 F-003", "重试这个节点", "重跑这个 feature"
+- "retry F-003", "retry this node", "re-run this feature"
 
 **Do NOT use this skill when:**
 - User wants to plan features (use `app-planner` instead)
@@ -98,31 +107,36 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```
 
 4. **Ask execution mode**: Present the user with a choice before launching:
-   - **(1) Background daemon (recommended)**: Pipeline runs fully detached via `launch-daemon.sh`. Survives session closure.
-   - **(2) Foreground in session**: Pipeline runs in the current session via `run.sh run`. Visible output but will stop if session times out.
+   - **(1) Foreground in session (recommended)**: Pipeline runs in the current session via `run.sh run`. Visible output and direct error feedback.
+   - **(2) Background daemon**: Pipeline runs fully detached via `launch-daemon.sh`. Survives session closure. Use only when user explicitly requests background execution.
    - **(3) Manual — show commands**: Display the exact commands the user can run themselves. No execution.
 
-   Default to option 1 if user says "just run it" or doesn't specify.
+   Default to option 1 if user says "just run it" or doesn't specify. Default to option 2 only if user explicitly says "background", "detached", or "run in background".
 
-   **If option 2 (foreground)**:
+   **If option 1 (foreground)**:
    ```bash
    dev-pipeline/run.sh run feature-list.json
    ```
-   Note: This will block the session. Warn user about timeout risk.
 
-   **If option 3 (manual)**: Print commands and stop. Do not execute anything.
-   ```
-   # To run in background (recommended):
+   **If option 2 (background)**:
+   ```bash
    dev-pipeline/launch-daemon.sh start feature-list.json
+   ```
+   Note: Pipeline runs fully detached. Survives session closure.
 
-   # To run in foreground:
+   **If option 3 (manual)**: Print commands and stop. Do not execute anything.
+   ```
+   # To run in foreground (recommended):
    dev-pipeline/run.sh run feature-list.json
 
+   # To run in background (detached):
+   dev-pipeline/launch-daemon.sh start feature-list.json
+
    # To check status:
-   dev-pipeline/launch-daemon.sh status
+   dev-pipeline/run.sh status feature-list.json
    ```
 
-5. **Ask user to confirm**: "Ready to launch the pipeline? It will process N features in the background."
+5. **Ask user to confirm**: "Ready to launch the pipeline? It will process N features."
 
 6. **Launch**:
    ```bash
@@ -225,9 +239,9 @@ When user specifies custom settings, map to environment variables:
 
 | User says | Environment variable |
 |-----------|---------------------|
-| "timeout 2 hours" / "超时2小时" | `SESSION_TIMEOUT=7200` |
-| "max 5 retries" / "最多重试5次" | `MAX_RETRIES=5` |
-| "verbose mode" / "详细模式" | `VERBOSE=1` |
+| "timeout 2 hours" | `SESSION_TIMEOUT=7200` |
+| "max 5 retries" | `MAX_RETRIES=5` |
+| "verbose mode" | `VERBOSE=1` |
 | "heartbeat every 60s" | `HEARTBEAT_INTERVAL=60` |
 
 Pass via `--env`:
@@ -239,13 +253,13 @@ dev-pipeline/launch-daemon.sh start feature-list.json --env "SESSION_TIMEOUT=720
 
 #### Intent F: Retry Single Feature Node
 
-When user says "retry F-003" or "重试 F-003":
+When user says "retry F-003":
 
 ```bash
 dev-pipeline/retry-feature.sh F-003 feature-list.json
 ```
 
-When user says "从头重试 F-003" or "clean retry F-003":
+When user says "clean retry F-003" or "retry F-003 from scratch":
 
 ```bash
 dev-pipeline/reset-feature.sh F-003 --clean --run feature-list.json

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

@@ -1,7 +1,7 @@
 ---
 name: "feature-workflow"
 tier: companion
-description: "One-stop entry point for feature development. Orchestrates app-planner → dev-pipeline-launcher → background execution. Handles multi-feature batch development from a single request. Use this skill whenever the user wants to build an app, develop multiple features at once, or go from idea to running code in one step. Trigger on: 'build an app', 'develop features', 'implement all features', 'one-stop development', 'batch implement', '开发一个新应用', '构建系统', '一键完成', '批量实现'. (project)"
+description: "One-stop entry point for feature development. Orchestrates app-planner → dev-pipeline-launcher → background execution. Handles multi-feature batch development from a single request. Use this skill whenever the user wants to build an app, develop multiple features at once, or go from idea to running code in one step. Trigger on: 'build an app', 'develop features', 'implement all features', 'one-stop development', 'batch implement', 'build a new application', 'build a system', 'one-click complete', 'batch implement'. (project)"
 ---
 
 # Feature Workflow
@@ -11,10 +11,10 @@ One-stop entry point for feature development. Orchestrates the complete flow fro
 ## When to Use
 
 User says:
-- "开发一个新应用", "构建 XXX 系统", "做一个项目"
-- "一键完成这些特性", "批量实现这些需求"
-- "从零开始做一个任务管理 App"
-- "帮我实现用户登录、注册、头像上传这些功能"
+- "Build a new application", "Build XXX system", "Create a project"
+- "One-click complete these features", "Batch implement these requirements"
+- "Build a task management App from scratch"
+- "Help me implement user login, registration, and avatar upload features"
 - After receiving a batch of related feature requests
 
 **Do NOT use this skill when:**
@@ -28,7 +28,7 @@ User says:
 ## Overview
 
 ```
-feature-workflow <需求描述>
+feature-workflow <requirements description>
    │
    ├── Phase 1: Plan → app-planner → feature-list.json
    │
@@ -53,7 +53,7 @@ Without this skill, users must:
 3. Manually check progress
 
 With this skill, users can:
-1. Say "开发一个任务管理 App" and walk away
+1. Say "Build a task management App" and walk away
 2. All planning + execution happens automatically
 
 ---
@@ -63,9 +63,9 @@ With this skill, users can:
 **Mode A: From natural language requirements** (default)
 
 Natural language description of the project or features. Can be:
-- A project vision: "开发一个任务管理 App，支持用户登录、任务增删改查、任务分类"
-- A batch of features: "实现用户注册、登录、找回密码这三个功能"
-- An incremental request: "给现有系统追加用户头像上传和昵称修改功能"
+- A project vision: "Build a task management App with user login, task CRUD, and task categories"
+- A batch of features: "Implement user registration, login, and password recovery features"
+- An incremental request: "Add user avatar upload and nickname modification to the existing system"
 
 Flow: app-planner → dev-pipeline-launcher → monitor
 
@@ -196,9 +196,9 @@ While the pipeline runs in background, the user can continue the conversation:
 
 | User says | Action |
 |-----------|--------|
-| "status" / "进度" | Show current progress |
-| "logs" / "日志" | Show recent log activity |
-| "stop" / "停止" | Stop the pipeline (state preserved) |
+| "status" / "progress" | Show current progress |
+| "logs" | Show recent log activity |
+| "stop" | Stop the pipeline (state preserved) |
 | "show F-002 logs" | Show specific feature's session log |
 
 ---

package/bundled/skills/prizm-kit/SKILL.md

@@ -74,13 +74,18 @@ All documentation records are for: features, projects, code logic, and module in
 
 ## Architecture
 
-PrizmKit produces two complementary knowledge layers:
+PrizmKit produces three complementary knowledge layers:
 
 ```
-.prizm-docs/           → Project "what is" (static: structure, interfaces, rules, traps, decisions)
+.prizm-docs/           → Architecture Index (structure, interfaces, dependencies, traps, rules)
 .prizmkit/specs/       → Feature "what to do" (workflow: spec → plan → code(implement))
+CLAUDE.md / CODEBUDDY.md → Project Memory (decisions, interface conventions, project-level rules)
 ```
 
+**Reading guide**:
+- Need code structure/modules/interfaces/traps? → `.prizm-docs/`
+- Need past decisions/conventions/why? → `CLAUDE.md` (Claude Code) or `CODEBUDDY.md` + `memory/MEMORY.md` (CodeBuddy)
+
 ## Skill Inventory
 
 ### Foundation (3)
@@ -95,7 +100,7 @@ PrizmKit produces two complementary knowledge layers:
 - **prizmkit-analyze** — Cross-document consistency analysis (spec ↔ plan ↔ tasks)
 - **prizmkit-implement** — Execute tasks following TDD approach
 - **prizmkit-code-review** — Review code against spec and plan
-- **prizmkit-retrospective** — Sole .prizm-docs/ maintainer: structural sync + knowledge injection (TRAPS/RULES/DECISIONS)
+- **prizmkit-retrospective** — Sole .prizm-docs/ maintainer: structural sync + TRAPS/RULES injection. Also sediments DECISIONS to platform memory files
 - **prizmkit-committer** — Pure git commit: diff analysis, safety checks, Conventional Commits
 
 ### Quality Assurance (5)

package/bundled/skills/prizm-kit/assets/project-memory-template.md

@@ -5,7 +5,7 @@ This project uses PrizmKit with the Prizm documentation system for AI-optimized
 ### Progressive Loading Protocol
 - ON SESSION START: Always read `.prizm-docs/root.prizm` first (L0 — project map)
 - ON TASK: Read L1 (`.prizm-docs/<module>.prizm`) for relevant modules referenced in MODULE_INDEX
-- ON FILE EDIT: Read L2 (`.prizm-docs/<module>/<submodule>.prizm`) before modifying files. Pay attention to TRAPS and DECISIONS.
+- ON FILE EDIT: Read L2 (`.prizm-docs/<module>/<submodule>.prizm`) before modifying files. Pay attention to TRAPS.
 - NEVER load all .prizm docs at once. Load only what is needed for the current task.
 
 ### Auto-Update Protocol

package/bundled/skills/prizmkit-code-review/SKILL.md

@@ -25,8 +25,10 @@ Perform a comprehensive code review against the feature spec, implementation pla
    - If `refactor-analysis.md` exists → **Refactor mode**: read `refactor-analysis.md` + `plan.md` as baseline. Review dimensions shift: replace "spec compliance" with **behavior preservation** (observable behavior unchanged), replace "plan adherence" with **structural improvement** (is the code measurably better?). Also check test integrity and code quality.
    - If `fix-plan.md` exists → **Bugfix mode**: read `fix-plan.md` as baseline. Review dimensions: bug is actually fixed, no regressions, reproduction test passes, minimal change scope.
    - If none found → prompt user: "No review baseline found. Which workflow are you in? (feature/refactor/bugfix)"
-2. Read `.prizm-docs/root.prizm` RULES for project conventions
-3. Scan all code files referenced in completed tasks
+2. Read **architecture index**: `.prizm-docs/root.prizm` RULES and PATTERNS for project conventions
+3. Read **project memory**: platform memory file (`CLAUDE.md` for Claude Code, `CODEBUDDY.md` + `memory/MEMORY.md` for CodeBuddy) for past DECISIONS — helps verify implementation respects established conventions
+4. Read `agents/dev-*.md` in the feature directory (if exists) — understand Dev's implementation decisions, trade-offs, and discovered interfaces. This context helps distinguish intentional design choices from accidental patterns during review.
+5. Scan all code files referenced in completed tasks
 4. Review across 6 dimensions:
    - **Spec compliance**: Does code implement all acceptance criteria? Missing criteria are the #1 source of "it works but it's wrong" bugs
    - **Plan adherence**: Does implementation follow architectural decisions in plan.md? Deviations may be improvements or may break assumptions other components depend on

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

@@ -1,17 +1,17 @@
 ---
 name: "prizmkit-committer"
-description: "Pure git commit workflow with safety checks. Stages files, analyzes diff, generates Conventional Commits message, and commits. Does NOT modify .prizm-docs/ — memory maintenance is handled by /prizmkit-retrospective before this skill is invoked. Trigger on: 'commit', '提交', 'finish', 'done', 'ship it', 'save my work'. (project)"
+description: "Pure git commit workflow with safety checks. Stages files, analyzes diff, generates Conventional Commits message, and commits. Does NOT modify .prizm-docs/ or memory files — architecture sync and memory sedimentation are handled by /prizmkit-retrospective before this skill is invoked. Trigger on: 'commit', 'submit', 'finish', 'done', 'ship it', 'save my work'. (project)"
 ---
 
 # PrizmKit Committer
 
 Pure git commit workflow. Analyzes changes, generates a Conventional Commits message, performs safety checks, and commits.
 
-**This skill is a pure git commit tool. It does NOT modify any project files — no `.prizm-docs/`, no source code, no documentation.** It only reads diffs, generates a commit message, and commits. For feature/refactor workflows, run `/prizmkit-retrospective` before this skill to sync `.prizm-docs/`. For bug fixes, skip retrospective entirely — bug fixes do not update `.prizm-docs/`.
+**This skill is a pure git commit tool. It does NOT modify any project files — no `.prizm-docs/`, no memory files, no source code.** It only reads diffs, generates a commit message, and commits. For feature/refactor workflows, run `/prizmkit-retrospective` before this skill to sync `.prizm-docs/` (architecture index) and sediment DECISIONS to memory files. For bug fixes, skip retrospective entirely — bug fixes do not update `.prizm-docs/`.
 
 ### When to Use
-- User says "commit", "提交", "finish", "done with this task", "ship it"
-- After `/prizmkit-retrospective` has finished memory maintenance
+- User says "commit", "submit", "finish", "done with this task", "ship it"
+- After `/prizmkit-retrospective` has finished architecture sync and memory sedimentation
 - The UserPromptSubmit hook will remind to use this skill when commit intent is detected
 
 ### Workflow

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

@@ -1,6 +1,6 @@
 ---
 name: "prizmkit-implement"
-description: "Execute implementation following plan.md tasks. Respects task ordering, dependencies, and TDD approach. Marks tasks complete as they finish. Use this skill whenever you're ready to write code for a planned feature, or for fast-path changes where the user describes a simple fix directly. Trigger on: 'implement', 'build', 'code it', 'start coding', '开发', 'write the code'. (project)"
+description: "Execute implementation following plan.md tasks. Respects task ordering, dependencies, and TDD approach. Marks tasks complete as they finish. Use this skill whenever you're ready to write code for a planned feature, or for fast-path changes where the user describes a simple fix directly. Trigger on: 'implement', 'build', 'code it', 'start coding', 'develop', 'write the code'. (project)"
 ---
 
 # PrizmKit Implement
@@ -9,7 +9,7 @@ Execute implementation by following the task breakdown in plan.md. Respects task
 
 ### When to Use
 - After `/prizmkit-plan` (or `/prizmkit-analyze`) when ready to write code
-- User says "implement", "build", "code it", "start coding", "开发"
+- User says "implement", "build", "code it", "start coding", "develop"
 - For fast-path: user describes a simple change directly (fast-path skips specify, but still requires a simplified plan.md with Tasks section)
 
 **PRECONDITION (multi-mode):**
@@ -29,14 +29,20 @@ Execute implementation by following the task breakdown in plan.md. Respects task
      - **Bugfix mode**: read `fix-plan.md` in the same directory
 2. Load project context — use the most efficient source available:
    - If `context-snapshot.md` exists in the feature directory → read it. Section 3 has Prizm docs + TRAPS, Section 4 has source files. This snapshot was built in Phase 1 of the pipeline to avoid re-reading dozens of individual files, saving significant tokens.
-   - Otherwise → read relevant `.prizm-docs/` L1/L2 for affected modules. Pay special attention to TRAPS (gotchas, race conditions) and DECISIONS (past architectural choices you should respect).
+   - Otherwise → **self-service context fallback**:
+     1. Read `agents/*.md` in the feature directory (if any exist) — other agents may have already built context
+     2. Read **architecture index**: `.prizm-docs/root.prizm` and relevant L1/L2 for affected modules. Pay special attention to TRAPS (gotchas, race conditions).
+     3. Read **project memory**: platform memory file (`CLAUDE.md` for Claude Code, `CODEBUDDY.md` + `memory/MEMORY.md` for CodeBuddy) for past DECISIONS and interface conventions you should respect.
+     4. Scan needed source files
+     5. Write CONTEXT_BUILT entries to your own `agents/<role>.md` (e.g., `agents/dev-1.md`) so future agents don't need to re-scan
 3. Check if checkpoint tasks are complete before proceeding to next phase
 4. For each unchecked task in order:
    a. If task has `[P]` marker, it can run in parallel with other `[P]` tasks in the same group
    b. Read L2 doc for target file's module (if exists) — TRAPS save you from repeating known mistakes
    c. Apply TDD where applicable: write a failing test first, then implement until it passes. For UI components or configuration changes where unit tests don't apply, skip the test-first step.
    d. Mark task as `[x]` in `plan.md` Tasks section immediately — not batched at the end. Immediate marking means the plan always reflects true progress, even if the session is interrupted.
-   e. Error handling: sequential tasks stop on failure (later tasks may depend on this one). Parallel `[P]` tasks continue — report all failures at the end.
+   e. If notable FINDINGS, DECISIONS, or INTERFACES were discovered during this task, append them to your `agents/<role>.md` knowledge doc (if agent knowledge docs are in use for this session).
+   f. Error handling: sequential tasks stop on failure (later tasks may depend on this one). Parallel `[P]` tasks continue — report all failures at the end.
 5. At each checkpoint: verify build passes and tests pass. Checkpoints catch integration errors early — skipping them means cascading failures in later phases that are much harder to debug.
 6. After all tasks: run full test suite
 7. Output implementation summary with pass/fail status

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

@@ -106,7 +106,7 @@ User can change mode in `.prizmkit/config.json`: `"adoption_mode": "passive" | "
 | Concept | CodeBuddy | Claude Code |
 |---------|-----------|-------------|
 | Command invocation | `/prizmkit-xxx` | `/prizmkit-xxx` |
-| Project memory | `CODEBUDDY.md` | `CLAUDE.md` |
+| Project memory | `CODEBUDDY.md` + `memory/MEMORY.md` | `CLAUDE.md` |
 | Settings | `.codebuddy/settings.json` | `.claude/settings.json` |
 | Skills/Commands | `.codebuddy/skills/` | `.claude/commands/` |
 | Agents | `.codebuddy/agents/` | `.claude/agents/` |

package/bundled/skills/prizmkit-prizm-docs/SKILL.md

@@ -32,7 +32,7 @@ This skill handles 6 operations. When invoked, determine the user's intent and e
 | **When** | Project setup, health checks, migrations | After feature completion, before commit |
 | **Writes** | Initial .prizm-docs/ structure (init, rebuild, migrate) | Incremental updates to existing .prizm-docs/ |
 | **Reads** | Source code structure (for init/rebuild) | git diff + code changes (for sync) |
-| **Knowledge** | Defines format rules, size limits, loading protocol | Extracts TRAPS/RULES/DECISIONS from work done |
+| **Knowledge** | Defines format rules, size limits, loading protocol | Extracts TRAPS/RULES into `.prizm-docs/`, sediments DECISIONS to memory files |
 
 **Key principle**: `/prizmkit-prizm-docs` defines WHAT the docs should look like and bootstraps them. `/prizmkit-retrospective` is the SOLE WRITER that keeps docs in sync with code during ongoing development.
 
@@ -162,14 +162,14 @@ When working in a project with .prizm-docs/:
 
 - ON SESSION START: Always read .prizm-docs/root.prizm (L0). This is the project map.
 - ON TASK: Read L1 docs for relevant modules referenced in MODULE_INDEX.
-- ON FILE EDIT: Read L2 doc before modifying files. Check TRAPS and DECISIONS sections.
+- ON FILE EDIT: Read L2 doc before modifying files. Check TRAPS section. For past DECISIONS, read platform memory file instead (`CLAUDE.md` or `CODEBUDDY.md` + `memory/MEMORY.md`).
 - ON DEEP READ: If you need deep understanding of a module without modifying it, generate L2 if it doesn't exist.
 - NEVER load all .prizm docs at once. Progressive loading saves tokens.
 - BUDGET: Typical task should consume 3000-5000 tokens of Prizm docs total.
 
 ## Auto-Update Protocol
 
-- BEFORE EVERY COMMIT: Run `/prizmkit-retrospective` which is the **sole maintainer** of .prizm-docs/. It handles both structural sync and knowledge injection.
+- BEFORE EVERY COMMIT: Run `/prizmkit-retrospective` which is the **sole maintainer** of .prizm-docs/. It handles structural sync and TRAPS/RULES injection to `.prizm-docs/`, plus sediments DECISIONS to platform memory files.
 - The UserPromptSubmit hook will remind you automatically when commit intent is detected.
 - `/prizmkit-committer` does NOT update .prizm-docs/ — it only commits what is already staged.
 - NEVER rewrite entire .prizm files. Only update affected sections.

package/bundled/skills/prizmkit-prizm-docs/assets/PRIZM-SPEC.md

@@ -664,9 +664,9 @@ STEPS:
    - Known issues and traps
 
 3. MAP_TO_PRIZM_LEVELS:
-   Project-wide info -> root.prizm (L0): PROJECT, LANG, FRAMEWORK, RULES, PATTERNS, DECISIONS
+   Project-wide info -> root.prizm (L0): PROJECT, LANG, FRAMEWORK, RULES, PATTERNS
    Module-level info -> L1 docs: MODULE, RESPONSIBILITY, INTERFACES, DEPENDENCIES
-   Detailed module info -> L2 docs: KEY_FILES, TRAPS, domain-specific sections, DECISIONS
+   Detailed module info -> L2 docs: KEY_FILES, TRAPS, domain-specific sections
 
 4. CONVERT_FORMAT:
    Strip markdown formatting (headers, tables, horizontal rules, emphasis)
@@ -678,7 +678,7 @@ STEPS:
 5. GENERATE_PRIZM_DOCS:
    Follow standard init procedure (Section 9) but seed with extracted information
    Merge source-code-scanned data with documentation-extracted data
-   Prefer documentation-extracted RULES and DECISIONS (they capture rationale)
+   Prefer documentation-extracted RULES (they capture rationale)
    Prefer source-code-scanned INTERFACES and DEPENDENCIES (they are current)
 
 6. VALIDATE:
@@ -713,7 +713,7 @@ JSON:
         "hooks": [
           {
             "type": "command",
-            "command": "echo 'PRIZMKIT_MEMORY_MAINTENANCE_REQUIRED: Before committing, you MUST run /prizmkit-retrospective to maintain .prizm-docs/ project memory. It handles both structural sync (KEY_FILES, INTERFACES, DEPENDENCIES) and knowledge injection (TRAPS, RULES, DECISIONS). After retrospective completes, proceed with /prizmkit-committer for the actual git commit.'"
+            "command": "echo 'PRIZMKIT_MAINTENANCE_REQUIRED: Before committing, you MUST run /prizmkit-retrospective. It maintains: (1) .prizm-docs/ architecture index — structural sync (KEY_FILES, INTERFACES, DEPENDENCIES) + TRAPS/RULES injection, (2) platform memory files — sediment DECISIONS and interface conventions to CLAUDE.md (Claude Code) or CODEBUDDY.md + memory/MEMORY.md (CodeBuddy). After retrospective completes, proceed with /prizmkit-committer for the actual git commit.'"
           }
         ]
       }
@@ -761,7 +761,7 @@ TEXT:
   ### Progressive Loading Protocol
   - ON SESSION START: Always read .prizm-docs/root.prizm first
   - ON TASK: Read L1 (.prizm-docs/<module>.prizm) for relevant modules referenced in MODULE_INDEX
-  - ON FILE EDIT: Read L2 (.prizm-docs/<module>/<submodule>.prizm) before modifying files. Pay attention to TRAPS and DECISIONS.
+  - ON FILE EDIT: Read L2 (.prizm-docs/<module>/<submodule>.prizm) before modifying files. Pay attention to TRAPS.
   - ON DEEP READ: If you need deep understanding of a module without modifying it, generate L2 if it does not exist.
   - NEVER load all .prizm docs at once. Load only what is needed for the current task.
 
@@ -875,7 +875,7 @@ CONTEXT: When multiple developers (human or AI) work on the same project, .prizm
 
 APPEND_ONLY_SECTIONS:
 - changelog.prizm: Append-only. Use standard git merge. Both sides' entries are kept. Sort by date descending after merge.
-- DECISIONS (in any .prizm file): Append-only. Keep all entries from both sides. Never discard decisions.
+- DECISIONS (in any .prizm file): Legacy — new DECISIONS go to platform memory files (CLAUDE.md / CODEBUDDY.md + memory/MEMORY.md). Existing DECISIONS in .prizm files are kept for backward compatibility. On merge conflicts, keep all entries from both sides.
 - REJECTED (in any .prizm file): Append-only. Keep all entries from both sides.
 - CHANGELOG (in L2 docs): Append-only. Keep all entries from both sides.