prizmkit 1.1.42 → 1.1.47

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

@@ -107,13 +107,13 @@ 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)
-   - `.prizm-docs/root.prizm` (project overview section)
+   - `.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):
    - `.prizmkit/config.json` `tech_stack` (preferred — contains language, frameworks, DB, etc.)
-   - `.prizm-docs/root.prizm` (architecture section)
+   - `.prizmkit/prizm-docs/root.prizm` (architecture section)
    - Auto-detect from project files (`package.json`, `requirements.txt`, `go.mod`, etc.)
    - If none found, ask the user
 3. **Identify testing framework**: Read from `.prizmkit/config.json` `tech_stack.testing`, or auto-detect from package.json/requirements.txt/etc., or ask user
@@ -223,7 +223,7 @@ Only proceed to Phase 5 after user confirms.
 
 ### Phase 5: Generate & Validate
 
-1. **Generate `.prizmkit/plans/bug-fix-list.json`**: Conform to `dev-pipeline/templates/bug-fix-list-schema.json`
+1. **Generate `.prizmkit/plans/bug-fix-list.json`**: Conform to `.prizmkit/dev-pipeline/templates/bug-fix-list-schema.json`
 2. **Validate against schema**: Run `python3 ${SKILL_DIR}/scripts/validate-bug-list.py .prizmkit/plans/bug-fix-list.json --feature-list .prizmkit/plans/feature-list.json`. If the script is unavailable, use the checklist in `${SKILL_DIR}/references/schema-validation.md`.
 3. **Write file** to `.prizmkit/plans/` (or user-specified path)
 4. **Output**: File path, summary, and next steps
@@ -287,7 +287,7 @@ Batch-parse failed test output:
 Validate existing `.prizmkit/plans/bug-fix-list.json`:
 
 1. Check JSON syntax
-2. Validate against `dev-pipeline/templates/bug-fix-list-schema.json`
+2. Validate against `.prizmkit/dev-pipeline/templates/bug-fix-list-schema.json`
 3. Check for:
    - Duplicate IDs
    - Missing required fields
@@ -351,6 +351,6 @@ Common errors handled inline:
 
 ## Output
 
-- `.prizmkit/plans/bug-fix-list.json` conforming to `dev-pipeline/templates/bug-fix-list-schema.json`
+- `.prizmkit/plans/bug-fix-list.json` conforming to `.prizmkit/dev-pipeline/templates/bug-fix-list-schema.json`
 - Validation report (if validation run)
 - Summary report (if summary run)

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

@@ -11,8 +11,8 @@ Launch the autonomous bug fix pipeline from within an AI CLI conversation. Suppo
 
 Three execution modes are available. The user chooses one before configuring other options:
 
-1. **Foreground** (recommended) — `dev-pipeline/run-bugfix.sh run`. Visible output, direct error feedback, no orphaned processes.
-2. **Background daemon** — `dev-pipeline/launch-bugfix-daemon.sh`. Runs fully detached, survives AI CLI session closure.
+1. **Foreground** (recommended) — `.prizmkit/dev-pipeline/run-bugfix.sh run`. Visible output, direct error feedback, no orphaned processes.
+2. **Background daemon** — `.prizmkit/dev-pipeline/launch-bugfix-daemon.sh`. 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 documentation**: When the user chooses background/daemon mode, record the choice and PID in `.prizmkit/bugfix-pipeline-run.log` (append-only) with timestamp, so the decision is traceable:
@@ -47,7 +47,7 @@ Three execution modes are available. The user chooses one before configuring oth
 
 Before any action, validate:
 
-1. **bugfix pipeline exists**: Confirm `dev-pipeline/launch-bugfix-daemon.sh` and `dev-pipeline/run-bugfix.sh` are present and executable
+1. **bugfix pipeline exists**: Confirm `.prizmkit/dev-pipeline/launch-bugfix-daemon.sh` and `.prizmkit/dev-pipeline/run-bugfix.sh` are present and executable
 2. **For start**: `.prizmkit/plans/bug-fix-list.json` must exist in `.prizmkit/plans/` (or user-specified path)
 3. **Dependencies**: `jq`, `python3`, AI CLI (`cbc` or `claude`) must be in PATH
 4. **Browser tools** (optional): If any bug has `browser_interaction` field, check the corresponding tool is available. Bugs may specify `tool: "playwright-cli"`, `tool: "opencli"`, or `tool: "auto"` (AI chooses at runtime).
@@ -80,7 +80,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 2. **Check not already running**:
    ```bash
-   dev-pipeline/launch-bugfix-daemon.sh status 2>/dev/null
+   .prizmkit/dev-pipeline/launch-bugfix-daemon.sh status 2>/dev/null
    ```
    If running, inform user and ask: "Bugfix pipeline is already running. Want to restart it, check status, or view logs?"
 
@@ -106,7 +106,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```
    If pipeline state already exists, use the status command instead:
    ```bash
-   python3 dev-pipeline/scripts/update-bug-status.py \
+   python3 .prizmkit/dev-pipeline/scripts/update-bug-status.py \
      --bug-list .prizmkit/plans/bug-fix-list.json \
      --state-dir .prizmkit/state/bugfix \
      --action status 2>/dev/null
@@ -196,34 +196,34 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    **Foreground command:**
    ```bash
-   VERBOSE=1 dev-pipeline/run-bugfix.sh run .prizmkit/plans/bug-fix-list.json
+   VERBOSE=1 .prizmkit/dev-pipeline/run-bugfix.sh run .prizmkit/plans/bug-fix-list.json
    ```
    With all options:
    ```bash
    VERBOSE=1 MAX_RETRIES=5 SESSION_TIMEOUT=3600 ENABLE_DEPLOY=1 \
-     dev-pipeline/run-bugfix.sh run .prizmkit/plans/bug-fix-list.json
+     .prizmkit/dev-pipeline/run-bugfix.sh run .prizmkit/plans/bug-fix-list.json
    ```
 
    **Background daemon command:**
    ```bash
-   dev-pipeline/launch-bugfix-daemon.sh start .prizmkit/plans/bug-fix-list.json --env "VERBOSE=1"
+   .prizmkit/dev-pipeline/launch-bugfix-daemon.sh start .prizmkit/plans/bug-fix-list.json --env "VERBOSE=1"
    ```
    With all options:
    ```bash
-   dev-pipeline/launch-bugfix-daemon.sh start .prizmkit/plans/bug-fix-list.json \
+   .prizmkit/dev-pipeline/launch-bugfix-daemon.sh start .prizmkit/plans/bug-fix-list.json \
      --env "VERBOSE=1 MAX_RETRIES=5 ENABLE_DEPLOY=1"
    ```
 
    **Manual mode**: Print the assembled command(s) and **stop here**. Do not execute anything. Do not proceed to step 7.
    ```
    # To run in foreground:
-   VERBOSE=1 dev-pipeline/run-bugfix.sh run .prizmkit/plans/bug-fix-list.json
+   VERBOSE=1 .prizmkit/dev-pipeline/run-bugfix.sh run .prizmkit/plans/bug-fix-list.json
 
    # To run in background (detached):
-   dev-pipeline/launch-bugfix-daemon.sh start .prizmkit/plans/bug-fix-list.json --env "VERBOSE=1"
+   .prizmkit/dev-pipeline/launch-bugfix-daemon.sh start .prizmkit/plans/bug-fix-list.json --env "VERBOSE=1"
 
    # To check status:
-   dev-pipeline/run-bugfix.sh status .prizmkit/plans/bug-fix-list.json
+   .prizmkit/dev-pipeline/run-bugfix.sh status .prizmkit/plans/bug-fix-list.json
    ```
 
 7. **Confirm and launch** (Foreground and Background only — Manual mode ends at step 6):
@@ -237,12 +237,12 @@ Detect user intent from their message, then follow the corresponding workflow:
    **If foreground**: Pipeline runs to completion in the terminal. After it finishes:
    - 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 `dev-pipeline/reset-bug.sh <B-XXX> --clean --run` for a fresh retry
+   - If some failed: show failed bug IDs and suggest `.prizmkit/dev-pipeline/reset-bug.sh <B-XXX> --clean --run` for a fresh retry
 
    **If background daemon**:
    1. Verify launch:
       ```bash
-      dev-pipeline/launch-bugfix-daemon.sh status
+      .prizmkit/dev-pipeline/launch-bugfix-daemon.sh status
       ```
    2. Start log monitoring — Use the Bash tool with `run_in_background: true`:
       ```bash
@@ -260,12 +260,12 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 1. **Check daemon status**:
    ```bash
-   dev-pipeline/launch-bugfix-daemon.sh status
+   .prizmkit/dev-pipeline/launch-bugfix-daemon.sh status
    ```
 
 2. **Show bug-level progress**:
    ```bash
-   python3 dev-pipeline/scripts/update-bug-status.py \
+   python3 .prizmkit/dev-pipeline/scripts/update-bug-status.py \
      --bug-list .prizmkit/plans/bug-fix-list.json \
      --state-dir .prizmkit/state/bugfix \
      --action status
@@ -284,12 +284,12 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 1. **Stop the daemon**:
    ```bash
-   dev-pipeline/launch-bugfix-daemon.sh stop
+   .prizmkit/dev-pipeline/launch-bugfix-daemon.sh stop
    ```
 
 2. **Verify stopped**:
    ```bash
-   dev-pipeline/launch-bugfix-daemon.sh status 2>/dev/null || true
+   .prizmkit/dev-pipeline/launch-bugfix-daemon.sh status 2>/dev/null || true
    ```
 
 3. **Inform user**: "Bugfix pipeline stopped. State is preserved -- you can resume later with 'start bug fix' and it will pick up where it left off."
@@ -300,7 +300,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 1. **Check if running**:
    ```bash
-   dev-pipeline/launch-bugfix-daemon.sh status 2>/dev/null
+   .prizmkit/dev-pipeline/launch-bugfix-daemon.sh status 2>/dev/null
    ```
 
 2. **If running** -- Start live tail with Bash tool `run_in_background: true`:
@@ -328,7 +328,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 When user says "retry B-001":
 
 ```bash
-dev-pipeline/reset-bug.sh B-001 --clean --run .prizmkit/plans/bug-fix-list.json
+.prizmkit/dev-pipeline/reset-bug.sh B-001 --clean --run .prizmkit/plans/bug-fix-list.json
 ```
 
 **Note:** `reset-bug.sh --clean --run` performs a full clean (deletes session history and artifacts) before retrying — this gives a fresh start.
@@ -347,7 +347,7 @@ dev-pipeline/reset-bug.sh B-001 --clean --run .prizmkit/plans/bug-fix-list.json
 | `playwright-cli` not installed | Browser verification skipped for playwright bugs (non-blocking). Suggest: `npm install -g @playwright/cli@latest && playwright-cli install --skills` |
 | `opencli` not installed | Browser verification skipped for opencli bugs (non-blocking). Install opencli for Chrome session-based browser verification |
 | Deploy session failed | Pipeline completed but deploy session exited non-zero. Check `.prizmkit/state/bugfix/deploy/<session_id>/logs/session.log`. Retry manually: `/prizmkit-deploy`. |
-| Permission denied on script | Run `chmod +x dev-pipeline/launch-bugfix-daemon.sh dev-pipeline/run-bugfix.sh` |
+| Permission denied on script | Run `chmod +x .prizmkit/dev-pipeline/launch-bugfix-daemon.sh .prizmkit/dev-pipeline/run-bugfix.sh` |
 
 ### Integration Notes
 

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

@@ -11,8 +11,8 @@ Launch the autonomous development pipeline from within an AI CLI conversation. T
 
 Three execution modes are available. The user chooses one before configuring other options:
 
-1. **Foreground** (recommended) — `dev-pipeline/run-feature.sh run`. Visible output, direct error feedback, no orphaned processes.
-2. **Background daemon** — `dev-pipeline/launch-feature-daemon.sh`. Runs fully detached, survives AI CLI session closure.
+1. **Foreground** (recommended) — `.prizmkit/dev-pipeline/run-feature.sh run`. Visible output, direct error feedback, no orphaned processes.
+2. **Background daemon** — `.prizmkit/dev-pipeline/launch-feature-daemon.sh`. 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.
 
 ### When to Use
@@ -48,7 +48,7 @@ Three execution modes are available. The user chooses one before configuring oth
 
 Before any action, validate:
 
-1. **dev-pipeline exists**: Confirm `dev-pipeline/launch-feature-daemon.sh` is present and executable
+1. **dev-pipeline exists**: Confirm `.prizmkit/dev-pipeline/launch-feature-daemon.sh` is present and executable
 2. **For start**: `.prizmkit/plans/feature-list.json` must exist in `.prizmkit/plans/` (or user-specified path)
 3. **Dependencies**: `jq`, `python3`, AI CLI (`cbc` or `claude`) must be in PATH
 4. **Python version**: Requires Python 3.8+ for dev-pipeline scripts
@@ -82,7 +82,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 2. **Check not already running**:
    ```bash
-   dev-pipeline/launch-feature-daemon.sh status 2>/dev/null
+   .prizmkit/dev-pipeline/launch-feature-daemon.sh status 2>/dev/null
    ```
    If running, inform user and ask: "Pipeline is already running. Want to restart it, check status, or view logs?"
 
@@ -100,7 +100,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    ```
    If pipeline state already exists, use the status command instead:
    ```bash
-   python3 dev-pipeline/scripts/update-feature-status.py \
+   python3 .prizmkit/dev-pipeline/scripts/update-feature-status.py \
      --feature-list .prizmkit/plans/feature-list.json \
      --state-dir .prizmkit/state/features \
      --action status 2>/dev/null
@@ -216,34 +216,34 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    **Foreground command:**
    ```bash
-   VERBOSE=1 dev-pipeline/run-feature.sh run .prizmkit/plans/feature-list.json
+   VERBOSE=1 .prizmkit/dev-pipeline/run-feature.sh run .prizmkit/plans/feature-list.json
    ```
    With all options:
    ```bash
    VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 SESSION_TIMEOUT=3600 ENABLE_DEPLOY=1 \
-     dev-pipeline/run-feature.sh run .prizmkit/plans/feature-list.json --features F-001:F-005
+     .prizmkit/dev-pipeline/run-feature.sh run .prizmkit/plans/feature-list.json --features F-001:F-005
    ```
 
    **Background daemon command:**
    ```bash
-   dev-pipeline/launch-feature-daemon.sh start .prizmkit/plans/feature-list.json --env "VERBOSE=1"
+   .prizmkit/dev-pipeline/launch-feature-daemon.sh start .prizmkit/plans/feature-list.json --env "VERBOSE=1"
    ```
    With all options:
    ```bash
-   dev-pipeline/launch-feature-daemon.sh start .prizmkit/plans/feature-list.json --features F-001:F-005 \
+   .prizmkit/dev-pipeline/launch-feature-daemon.sh start .prizmkit/plans/feature-list.json --features F-001:F-005 \
      --env "VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 ENABLE_DEPLOY=1"
    ```
 
    **Manual mode**: Print the assembled command(s) and **stop here**. Do not execute anything. Do not proceed to step 8.
    ```
    # To run in foreground:
-   VERBOSE=1 dev-pipeline/run-feature.sh run .prizmkit/plans/feature-list.json
+   VERBOSE=1 .prizmkit/dev-pipeline/run-feature.sh run .prizmkit/plans/feature-list.json
 
    # To run in background (detached):
-   dev-pipeline/launch-feature-daemon.sh start .prizmkit/plans/feature-list.json --env "VERBOSE=1"
+   .prizmkit/dev-pipeline/launch-feature-daemon.sh start .prizmkit/plans/feature-list.json --env "VERBOSE=1"
 
    # To check status:
-   dev-pipeline/run-feature.sh status .prizmkit/plans/feature-list.json
+   .prizmkit/dev-pipeline/run-feature.sh status .prizmkit/plans/feature-list.json
    ```
 
 8. **Confirm and launch** (Foreground and Background only — Manual mode ends at step 7):
@@ -263,7 +263,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    **If background daemon**:
    1. Verify launch:
       ```bash
-      dev-pipeline/launch-feature-daemon.sh status
+      .prizmkit/dev-pipeline/launch-feature-daemon.sh status
       ```
    2. Start log monitoring — Use the Bash tool with `run_in_background: true`:
       ```bash
@@ -281,12 +281,12 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 1. **Check daemon status**:
    ```bash
-   dev-pipeline/launch-feature-daemon.sh status
+   .prizmkit/dev-pipeline/launch-feature-daemon.sh status
    ```
 
 2. **Show feature-level progress**:
    ```bash
-   python3 dev-pipeline/scripts/update-feature-status.py \
+   python3 .prizmkit/dev-pipeline/scripts/update-feature-status.py \
      --feature-list .prizmkit/plans/feature-list.json \
      --state-dir .prizmkit/state/features \
      --action status
@@ -305,12 +305,12 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 1. **Stop the daemon**:
    ```bash
-   dev-pipeline/launch-feature-daemon.sh stop
+   .prizmkit/dev-pipeline/launch-feature-daemon.sh stop
    ```
 
 2. **Verify stopped**:
    ```bash
-   dev-pipeline/launch-feature-daemon.sh status 2>/dev/null || true
+   .prizmkit/dev-pipeline/launch-feature-daemon.sh status 2>/dev/null || true
    ```
 
 3. **Inform user**: "Pipeline stopped. State is preserved -- you can resume later with 'start pipeline' and it will pick up where it left off."
@@ -321,7 +321,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 1. **Check if running**:
    ```bash
-   dev-pipeline/launch-feature-daemon.sh status 2>/dev/null
+   .prizmkit/dev-pipeline/launch-feature-daemon.sh status 2>/dev/null
    ```
 
 2. **If running** -- Start live tail with Bash tool `run_in_background: true`:
@@ -349,7 +349,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 When user says "retry F-003" or "clean retry F-003":
 
 ```bash
-dev-pipeline/reset-feature.sh F-003 --clean --run .prizmkit/plans/feature-list.json
+.prizmkit/dev-pipeline/reset-feature.sh F-003 --clean --run .prizmkit/plans/feature-list.json
 ```
 
 Notes:
@@ -406,10 +406,10 @@ After pipeline completion, if features have `browser_interaction` fields and the
 | PID file stale (process dead) | `launch-feature-daemon.sh` auto-cleans, retry start |
 | Launch failed (process died immediately) | Show last 20 lines of log: `tail -20 .prizmkit/state/features/pipeline-daemon.log` |
 | Feature stuck/blocked | Use `reset-feature.sh <F-XXX> --clean --run` for a fresh retry |
-| All features blocked/failed | Show status, suggest daemon-safe recovery: `dev-pipeline/reset-feature.sh <F-XXX> --clean --run .prizmkit/plans/feature-list.json` |
+| All features blocked/failed | Show status, suggest daemon-safe recovery: `.prizmkit/dev-pipeline/reset-feature.sh <F-XXX> --clean --run .prizmkit/plans/feature-list.json` |
 | `playwright-cli` not installed | Browser verification skipped for playwright features (non-blocking). Suggest: `npm install -g @playwright/cli@latest && playwright-cli install --skills` |
 | `opencli` not installed | Browser verification skipped for opencli features (non-blocking). Install opencli for Chrome session-based browser verification |
-| Permission denied on script | Run `chmod +x dev-pipeline/launch-feature-daemon.sh dev-pipeline/run-feature.sh` |
+| Permission denied on script | Run `chmod +x .prizmkit/dev-pipeline/launch-feature-daemon.sh .prizmkit/dev-pipeline/run-feature.sh` |
 | Pipeline stop failed (process won't die) | Process may be stuck in I/O wait. Try `kill -9 <PID>` manually. Check for orphaned child processes with `ps aux \| grep claude` |
 | Deploy session failed | Pipeline completed but deploy session exited non-zero. Check `.prizmkit/state/features/deploy/<session_id>/logs/session.log`. Retry manually: `/prizmkit-deploy`. |
 | `.env.local` missing or incomplete | Warn: database connection variables not found. Suggest creating env file with required connection variables for the project's database |

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

@@ -107,12 +107,12 @@ Do NOT use this skill when:
 ## Prerequisites
 
 Before questions, check optional context files (never block if absent):
-- `.prizm-docs/root.prizm` (architecture/project context — typically created by app-planner with captured decisions)
+- `.prizmkit/prizm-docs/root.prizm` (architecture/project context — typically created by app-planner with captured decisions)
 - `.prizmkit/config.json` (existing stack preferences and detected tech stack)
 - `.prizmkit/plans/project-brief.md` (project context from app-planner, if available)
 - existing `.prizmkit/plans/feature-list.json` (required for incremental mode)
 - `CLAUDE.md` / `CODEBUDDY.md`
-- If `.prizm-docs/root.prizm` is absent and the project has existing source code, scan the directory structure to understand the codebase layout:
+- If `.prizmkit/prizm-docs/root.prizm` is absent and the project has existing source code, scan the directory structure to understand the codebase layout:
   ```bash
   find . -maxdepth 2 -type d -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/dist/*' -not -path '*/build/*' -not -path '*/__pycache__/*' -not -path '*/vendor/*' | sed -e 's;[^/]*/;|____;g;s;____|; |;g'
   ```
@@ -144,7 +144,7 @@ The `global_context` object in `.prizmkit/plans/feature-list.json` provides tech
 - `language`, `frontend_framework`, `backend_framework`, `database`, `testing_strategy` (all recommended)
 - Additional: `frontend_styling`, `orm`, `bundler`, `runtime`
 
-All `global_context` fields are optional — including recommended fields improves downstream code generation quality. See `dev-pipeline/templates/feature-list-schema.json` for the full schema definition.
+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.
 
 
 ---
@@ -183,7 +183,7 @@ Execute the planning workflow in conversation mode with mandatory checkpoints:
    > "Do you have any reference materials I should review before planning? This can include:
    > - **Code paths** — files or directories I should read to understand existing implementation
    > - **Documents** — design docs, PRDs, API specs, architecture proposals, or internal wiki pages
-   > - **Knowledge docs** — `.prizm-docs/` files, README files, or project-specific documentation
+   > - **Knowledge docs** — `.prizmkit/prizm-docs/` files, README files, or project-specific documentation
    > - **Images** — wireframes, mockups, architecture diagrams, or screenshots
    > - **Web links** — reference implementations, API documentation pages, or relevant articles
    >
@@ -291,7 +291,7 @@ A feature is **exempt** when ANY true:
 
 ## Output Rules
 
-`.prizmkit/plans/feature-list.json` must conform to `dev-pipeline/templates/feature-list-schema.json` (`$schema` = `dev-pipeline-feature-list-v1`).
+`.prizmkit/plans/feature-list.json` must conform to `.prizmkit/dev-pipeline/templates/feature-list-schema.json` (`$schema` = `dev-pipeline-feature-list-v1`).
 
 Key requirements:
 - non-empty `features` array

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

@@ -124,7 +124,7 @@ Ask the user to describe what they want to build. Listen for:
 Ask:
 1. **Existing code** — "Is there existing code I should look at? Which files or directories are relevant?"
 2. **Design documents** — "Do you have any design docs, wireframes, API specs, or PRDs I should read?"
-3. **Knowledge docs** — "Are there related `.prizm-docs/`, README files, or internal wiki pages?"
+3. **Knowledge docs** — "Are there related `.prizmkit/prizm-docs/`, README files, or internal wiki pages?"
 4. **Reference projects** — "Any reference implementations or similar projects I should look at for inspiration?"
 
 Record everything the user provides — these become inputs for Step 1.3.
@@ -139,7 +139,7 @@ Record everything the user provides — these become inputs for Step 1.3.
 |-------|-------------|---------|
 | Agent A | User-provided code paths — read existing source files | Understand current architecture, patterns, conventions |
 | Agent B | User-provided documents — design docs, specs, PRDs | Understand intended requirements and constraints |
-| Agent C | `.prizm-docs/` — root.prizm, L1/L2 docs, TRAPS, RULES | Understand existing architecture knowledge and known pitfalls |
+| Agent C | `.prizmkit/prizm-docs/` — root.prizm, L1/L2 docs, TRAPS, RULES | Understand existing architecture knowledge and known pitfalls |
 | Agent D | Database/schema files + `.prizmkit/config.json` | Understand data model and tech stack preferences |
 
 **Also gather** (can be included in any agent's task):
@@ -156,7 +156,7 @@ Record everything the user provides — these become inputs for Step 1.3.
 Present what you learned from the parallel reading:
 - Current project structure and patterns (with specific references)
 - Existing data model and schema conventions
-- Known TRAPS and pitfalls from `.prizm-docs/`
+- Known TRAPS and pitfalls from `.prizmkit/prizm-docs/`
 - Integration points with existing modules
 
 Then ask targeted questions based on what you read. **Adapt question depth to the feature complexity** — a simple CRUD feature needs fewer questions than a real-time collaboration system.
@@ -251,7 +251,7 @@ Once brainstorming is complete, produce a structured requirements summary:
 - [Requirement]
 
 ### Reference Materials Reviewed
-- [List of code paths, documents, .prizm-docs/ files that were read]
+- [List of code paths, documents, .prizmkit/prizm-docs/ files that were read]
 
 ### Confirmed by user: ✓
 ```
@@ -292,7 +292,7 @@ AskUserQuestion:
   2. Invoke `/prizmkit-implement` to execute the plan
   3. After implementation, run `/prizmkit-code-review` for quality check
   4. Commit via `/prizmkit-committer` with `feat(<scope>):` prefix
-  5. Run `/prizmkit-retrospective` to sync `.prizm-docs/`
+  5. Run `/prizmkit-retrospective` to sync `.prizmkit/prizm-docs/`
   6. **End workflow** — skip Phase 2/3/4
 - **Add to feature list** → Continue to Phase 2 (Plan via pipeline)
 
@@ -392,7 +392,7 @@ AskUserQuestion:
 
 1. **Initial status check**:
    ```bash
-   dev-pipeline/launch-feature-daemon.sh status
+   .prizmkit/dev-pipeline/launch-feature-daemon.sh status
    ```
 
 2. **Offer monitoring options**:
@@ -402,7 +402,7 @@ AskUserQuestion:
 
 3. **Periodic progress reports** (when user asks):
    ```bash
-   python3 dev-pipeline/scripts/update-feature-status.py \
+   python3 .prizmkit/dev-pipeline/scripts/update-feature-status.py \
      --feature-list .prizmkit/plans/feature-list.json \
      --state-dir .prizmkit/state/features \
      --action status
@@ -508,4 +508,4 @@ All internal asset paths use `${SKILL_DIR}` placeholder for cross-IDE compatibil
 - Pipeline execution (Phase 3)
 - Progress updates (Phase 4)
 - Multiple git commits with `feat(<scope>):` prefix
-- Updated `.prizm-docs/` (via prizmkit-retrospective per feature)
+- Updated `.prizmkit/prizm-docs/` (via prizmkit-retrospective per feature)

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

@@ -17,15 +17,15 @@ read docs → plan → implement → code-review → retrospective → committer
 Each task begins by reading context at two levels:
 
 **Application level** (read every session):
-- `.prizm-docs/root.prizm` — L0 project architecture index (modules, tech stack, conventions)
+- `.prizmkit/prizm-docs/root.prizm` — L0 project architecture index (modules, tech stack, conventions)
 - `.prizmkit/plans/project-brief.md` — user's product vision checklist (generated by app-planner)
 - `.prizmkit/config.json` — tech stack config, deploy strategy
 
 **Task level** (read for the specific task):
 - `spec.md` / `plan.md` — task specification and implementation plan
-- `.prizm-docs/<module>.prizm` (L1/L2) — architecture docs for affected modules (TRAPS, DECISIONS, INTERFACES)
+- `.prizmkit/prizm-docs/<module>.prizm` (L1/L2) — architecture docs for affected modules (TRAPS, DECISIONS, INTERFACES)
 
-Each cycle produces spec, plan, and task artifacts that create a traceable record of what was built and why. `.prizm-docs/` stays in sync through retrospective, so the next session starts with up-to-date context.
+Each cycle produces spec, plan, and task artifacts that create a traceable record of what was built and why. `.prizmkit/prizm-docs/` stays in sync through retrospective, so the next session starts with up-to-date context.
 
 **Fast path** — for small, well-scoped changes, always ask user whether to use fast path:
 ```
@@ -42,13 +42,13 @@ PrizmKit supports any development scenario through the same skill chain. `/prizm
 | **Bug Fix** | `spec.md` → `plan.md` → code | Complex defects, regressions, crash fixes. Simple bugs can use fast path directly. |
 | **Refactor** | `spec.md` → `plan.md` → code | Restructure, extract, rename, performance. No behavior change. |
 
-All three follow the same per-task flow. Detailed documentation policies (when to update `.prizm-docs/`, when to skip steps) are defined within each skill — not here.
+All three follow the same per-task flow. Detailed documentation policies (when to update `.prizmkit/prizm-docs/`, when to skip steps) are defined within each skill — not here.
 
 ### Best Practices for AI-Driven Development
 
 **Monorepo structure recommended**: Keep frontend, backend, and shared libraries in one repository. AI needs visibility into the full call chain — cross-repo references are invisible to it. If you have a multi-repo setup, add all related repos to the AI workspace so module boundaries and API contracts are discoverable.
 
-**Module organization**: Ensure every meaningful module has a `.prizm-docs/` L1 doc. AI reads TRAPS and DECISIONS before modifying files — undocumented modules get no guardrails.
+**Module organization**: Ensure every meaningful module has a `.prizmkit/prizm-docs/` L1 doc. AI reads TRAPS and DECISIONS before modifying files — undocumented modules get no guardrails.
 
 **Small, focused tasks**: Break large features into tasks that can each be completed in one AI session. The pipeline handles this automatically via `/prizmkit-plan` task decomposition.
 
@@ -59,23 +59,23 @@ All three follow the same per-task flow. Detailed documentation policies (when t
 | `/prizmkit-plan` | Specify + plan: natural language → spec.md → plan.md + tasks | "specify", "plan", "new feature", "I want to add...", "architect", "break it down" |
 | `/prizmkit-implement` | Execute plan.md tasks, write code (TDD) | "implement", "build", "code it", "start coding" |
 | `/prizmkit-code-review` | Diagnose issues + produce Fix Instructions | "review", "check code", "is it ready to commit" |
-| `/prizmkit-retrospective` | Sync .prizm-docs/ with code changes | "retrospective", "retro", "sync docs", "wrap up" |
+| `/prizmkit-retrospective` | Sync .prizmkit/prizm-docs/ with code changes | "retrospective", "retro", "sync docs", "wrap up" |
 | `/prizmkit-committer` | Safe git commit with Conventional Commits | "commit", "submit", "finish", "ship it" |
 | `/prizmkit-deploy` | Generate/update deployment documentation | "deploy docs", "deployment guide", "how to deploy" |
-| `/prizmkit-init` | Project bootstrap + .prizm-docs/ setup | "init", "initialize", "take over this project" |
+| `/prizmkit-init` | Project bootstrap + .prizmkit/prizm-docs/ setup | "init", "initialize", "take over this project" |
 | `/prizmkit-prizm-docs` | Doc management (init/status/rebuild/validate) | "check docs", "rebuild docs", "validate docs" |
 
 **Reading guide**:
-- Need code structure/modules/interfaces/traps/decisions? → `.prizm-docs/`
+- Need code structure/modules/interfaces/traps/decisions? → `.prizmkit/prizm-docs/`
 
 ## Quick Start (First-Time Setup)
 
 1. `npx prizmkit install .` → installs skills, rules (`prizm-documentation.md`, `prizm-commit-workflow.md`), hooks, platform scaffolding
-2. `/prizmkit-init` → scans project code, generates `.prizm-docs/`, detects tech stack, populates `.prizmkit/config.json`
+2. `/prizmkit-init` → scans project code, generates `.prizmkit/prizm-docs/`, detects tech stack, populates `.prizmkit/config.json`
 3. `/prizmkit-plan` → specify your first feature → produces spec.md + plan.md
 4. `/prizmkit-implement` → TDD implementation following the plan
 5. `/prizmkit-code-review` → review before commit
-6. `/prizmkit-retrospective` → sync `.prizm-docs/` with changes
+6. `/prizmkit-retrospective` → sync `.prizmkit/prizm-docs/` with changes
 7. `/prizmkit-committer` → safe Conventional Commit
 
 > **Note**: Rules and hooks are installed by `npx prizmkit install`, not by `/prizmkit-init`.

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

@@ -1,6 +1,6 @@
 ---
 name: "prizmkit-committer"
-description: "Pure git commit workflow with safety checks. Stages files, generates Conventional Commits message, and commits. Does NOT modify .prizm-docs/ — run /prizmkit-retrospective first. Trigger on: 'commit', 'submit', 'finish', 'done', 'ship it'. (project)"
+description: "Pure git commit workflow with safety checks. Stages files, generates Conventional Commits message, and commits. Does NOT modify .prizmkit/prizm-docs/ — run /prizmkit-retrospective first. Trigger on: 'commit', 'submit', 'finish', 'done', 'ship it'. (project)"
 ---
 
 # PrizmKit Committer
@@ -15,7 +15,7 @@ description: "Pure git commit workflow with safety checks. Stages files, generat
 | Required State | Check | If Missing |
 |---|---|---|
 | Uncommitted changes exist | `git status` shows modified/added/untracked files | Inform user "nothing to commit" and stop |
-| `.prizm-docs/` synced (feature/refactor) | `/prizmkit-retrospective` has run | Run `/prizmkit-retrospective` first |
+| `.prizmkit/prizm-docs/` synced (feature/refactor) | `/prizmkit-retrospective` has run | Run `/prizmkit-retrospective` first |
 | Code review passed (pipeline mode) | `review-report.md` in artifact directory has `## Verdict: PASS` | Run `/prizmkit-code-review` first |
 
 ### Workflow

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

@@ -30,9 +30,9 @@ description: "Execute plan.md tasks with TDD approach. Respects task ordering an
 Before implementation, load context once:
 
 1. **Task context**: Read `plan.md` (including Tasks section) and `spec.md` from the artifact directory. If other companion documents exist in the directory (e.g., `refactor-analysis.md`), read them for additional context.
-2. **Architecture context**: Read `.prizm-docs/root.prizm` (L0 — project overview, module index, tech stack, conventions) and relevant L1/L2 docs for affected modules. Pay special attention to TRAPS (known pitfalls) and DECISIONS (architectural choices).
+2. **Architecture context**: Read `.prizmkit/prizm-docs/root.prizm` (L0 — project overview, module index, tech stack, conventions) and relevant L1/L2 docs for affected modules. Pay special attention to TRAPS (known pitfalls) and DECISIONS (architectural choices).
 
-> `.prizm-docs/` uses a 3-level hierarchy: L0 (`root.prizm`) is the project-wide index. L1 (e.g., `auth.prizm`) covers a module — its key files, interfaces, dependencies, traps, and decisions. L2 is for sub-modules with their own complexity. Implement reads these docs to avoid repeating known mistakes; `/prizmkit-retrospective` is responsible for updating them after implementation.
+> `.prizmkit/prizm-docs/` uses a 3-level hierarchy: L0 (`root.prizm`) is the project-wide index. L1 (e.g., `auth.prizm`) covers a module — its key files, interfaces, dependencies, traps, and decisions. L2 is for sub-modules with their own complexity. Implement reads these docs to avoid repeating known mistakes; `/prizmkit-retrospective` is responsible for updating them after implementation.
 
 ## Execution