prizmkit 1.1.42 → 1.1.46

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

@@ -36,7 +36,7 @@ If you believe the task is better suited for a different workflow, you MUST:
 **Your ONLY writable outputs are:**
 1. `.prizmkit/plans/project-brief.md` (`.prizmkit/plans/` — accumulated project context brief)
 2. Project conventions and architecture decisions appended to `CLAUDE.md` / `CODEBUDDY.md` (with user consent)
-3. Infrastructure configuration (database conventions + deployment config) appended to `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` section
+3. Infrastructure configuration (database conventions, deployment config, **cloud services**) appended to `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` section
 
 **After planning is complete**, you MUST:
 1. Present the summary of captured project-level context (vision, conventions, architecture decisions, project brief)
@@ -171,6 +171,27 @@ Do NOT use this skill when:
 
    Use `AskUserQuestion` for each batch. Each question MUST include a "Skip — decide later" option.
 
+   **Cloud Services Deep Inquiry** (Two-round AskUserQuestion):
+
+   Many projects depend on third-party cloud services (object storage, CDN, managed DB, auth, domain, email, SMS, payment, AI APIs). Capture them now so feature-planner and prizmkit-deploy can reference them later.
+
+   *Round 1 — Cloud Vendors* (multi-select via `AskUserQuestion`):
+   - "Which cloud vendors will this project integrate with?"
+   - Options: `AWS`, `Aliyun`, `Tencent Cloud`, `Cloudflare`, `Vercel`, `Other` (free text), `None — skip`
+   - If `None — skip`, write `<!-- cloud-services: none -->` to the `#### Cloud Services` subsection and exit this inquiry.
+
+   *Round 2 — Service Types* (multi-select, only if Round 1 returned any vendor):
+   - "Which types of cloud services will you use?"
+   - Options: `Object Storage (COS/S3/OSS)`, `CDN`, `Managed Database`, `Functions/Serverless`, `Auth (OAuth/JWT/IDaaS)`, `Domain & DNS`, `Email`, `SMS`, `Payment`, `AI API (OpenAI/Anthropic/...)`, `Other`
+   - The list is multi-select. Skip the question entirely if user picks "None" in Round 1.
+
+   *After both rounds, write to `#### Cloud Services`*:
+   - For each chosen (vendor × service) pair, append a row to the subsection (see template below)
+   - **Do NOT** prompt for env var names, credentials, region, or SDK details — those belong to `prizmkit-deploy`'s scope, not planning
+   - If the user is unsure of the mapping, store the vendors and service types separately; deploy skill can refine later
+
+   Use `AskUserQuestion` for both rounds. Each question MUST include a "Skip — decide later" option.
+
    **After infrastructure inquiry**:
    - Update `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` section with all collected information. Replace `<!-- deferred -->` markers with real values. Preserve any existing values that were confirmed unchanged. Full format:
      ```markdown
@@ -197,6 +218,13 @@ Do NOT use this skill when:
 
      #### Deployment Credentials Reference
      - [platform]: [token/auth method description]
+
+     #### Cloud Services
+     - **Vendors**: [comma-separated list, e.g., "AWS, Cloudflare" or "none"]
+     - **Services**:
+       - [vendor]: [service type] — [optional one-line note, e.g., "user-upload images"]
+       - [vendor]: [service type]
+     <!-- If user picked "None" in Round 1, replace this block with: cloud-services: none -->
      ```
    - Items still marked "Skip — decide later" remain as `<!-- [topic]: deferred -->` in CLAUDE.md for `prizmkit-deploy` to pick up later.
 
@@ -207,7 +235,7 @@ Do NOT use this skill when:
 ## Prerequisites
 
 Before questions, check optional context files (never block if absent):
-- `.prizm-docs/root.prizm` (architecture/project context)
+- `.prizmkit/prizm-docs/root.prizm` (architecture/project context)
 - `.prizmkit/config.json` (existing stack preferences and detected tech stack)
 - `CLAUDE.md` / `CODEBUDDY.md` `### Project Conventions` section (previously answered project conventions)
 - `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` section (database and deployment config from prizmkit-init or previous app-planner run)
@@ -221,7 +249,7 @@ Before questions, check optional context files (never block if absent):
 Note:
 - This skill **reads** `.prizmkit/config.json` if present.
 - This skill does **not** create `.prizmkit/config.json` directly.
-- Creation/update is handled by bootstrap/init flows (e.g., `prizmkit-init`, `dev-pipeline/scripts/init-dev-team.py`).
+- Creation/update is handled by bootstrap/init flows (e.g., `prizmkit-init`, `.prizmkit/dev-pipeline/scripts/init-dev-team.py`).
 
 ## Interaction Style (Hard Rule)
 
@@ -306,7 +334,7 @@ Before ANY planning work, check if AI-essential project context files exist:
 
 | File | Purpose | Status |
 |------|---------|--------|
-| `.prizm-docs/root.prizm` | Project architecture context for AI | exists / missing |
+| `.prizmkit/prizm-docs/root.prizm` | Project architecture context for AI | exists / missing |
 | `.prizmkit/config.json` | Tech stack + runtime config | exists / missing |
 | `.prizmkit/plans/project-brief.md` | Product vision checklist | exists / missing |
 
@@ -336,7 +364,7 @@ Do NOT ask the user to describe their project — read it yourself first:
    - `go.mod` → Go module info
    - `README.md` → project description and goals
    - `.prizmkit/config.json` → previously detected tech stack
-   - `.prizm-docs/root.prizm` → existing architecture context
+   - `.prizmkit/prizm-docs/root.prizm` → existing architecture context
 
 3. **Read key source files** (entry points, main routes, core models) to understand what the project actually does — don't rely solely on metadata.
 
@@ -392,7 +420,7 @@ Checkpoints catch cascading errors early — skipping one means the next phase b
 |-----------|----------------|----------|-------|
 | **CP-AP-0** | Intent Confirmed | User confirmed session goal (produce / explore) | 1 |
 | **CP-AP-1** | Conventions Checked | Project conventions loaded or asked; `### Project Conventions` section in `CLAUDE.md` / `CODEBUDDY.md` up to date | 1 |
-| **CP-AP-1.5** | Infrastructure Checked | Infrastructure config loaded or asked; `### Infrastructure` section in `CLAUDE.md` / `CODEBUDDY.md` addressed — configured or explicitly deferred | 1-2 |
+| **CP-AP-1.5** | Infrastructure Checked | Infrastructure config loaded or asked; `### Infrastructure` section in `CLAUDE.md` / `CODEBUDDY.md` addressed — database, deployment **and cloud services** each configured or explicitly deferred | 1-2 |
 | **CP-AP-2** | Vision Summary | Goal/users/differentiators confirmed by user. For brownfield: existing purpose confirmed or refined. | 1-2 |
 | **CP-AP-3** | Frontend Design Evaluated | For frontend projects: checked for existing UI/UX design system; user was asked if missing. **Auto-pass** for backend-only or non-UI projects. | 2 |
 | **CP-AP-4** | Project Brief Accumulated | `.prizmkit/plans/project-brief.md` exists at `.prizmkit/plans/` with at least 3 ideas listed. For brownfield: already-implemented items marked `[x]` count toward this total. | 3 |
@@ -405,7 +433,7 @@ After Phase 2, if framework-shaping architecture decisions emerged during planni
 **How it works**:
 1. If decisions are captured → append to `CLAUDE.md` / `CODEBUDDY.md` under `### Architecture Decisions` section
 2. Downstream skills (feature-planner, prizmkit-plan, etc.) read `CLAUDE.md` / `CODEBUDDY.md` as standard context, so they automatically receive these decisions
-3. Do NOT write directly to `.prizm-docs/root.prizm` — that file is maintained by `prizmkit-prizm-docs` and `prizmkit-retrospective`. If the project needs `.prizm-docs/`, recommend the user run `prizmkit-prizm-docs` init after planning.
+3. Do NOT write directly to `.prizmkit/prizm-docs/root.prizm` — that file is maintained by `prizmkit-prizm-docs` and `prizmkit-retrospective`. If the project needs `.prizmkit/prizm-docs/`, recommend the user run `prizmkit-prizm-docs` init after planning.
 
 ## Project Brief Accumulation
 

package/bundled/skills/bug-fix-workflow/SKILL.md

@@ -212,11 +212,11 @@ AskUserQuestion:
 
 **Goal**: Locate affected code, identify root cause, classify severity.
 
-> **Triage**: Classify error into: Runtime / Network / Auth / Data / Resource / Logic / Config / External. Check `.prizm-docs/` TRAPS for known patterns first. If a TRAPS match is found, use documented solution and reference the specific `.prizm-docs/` entry. If no match, trace the call chain from the stack frame to identify root cause from first principles.
+> **Triage**: Classify error into: Runtime / Network / Auth / Data / Resource / Logic / Config / External. Check `.prizmkit/prizm-docs/` TRAPS for known patterns first. If a TRAPS match is found, use documented solution and reference the specific `.prizmkit/prizm-docs/` entry. If no match, trace the call chain from the stack frame to identify root cause from first principles.
 
-1. **Read project context**: `.prizm-docs/root.prizm` → relevant L1/L2 docs for affected modules
+1. **Read project context**: `.prizmkit/prizm-docs/root.prizm` → relevant L1/L2 docs for affected modules
 2. **Locate affected code**: read the files mentioned in the error/stack trace or identified during diagnosis
-3. **Check known issues**: search `.prizm-docs/` TRAPS sections for matching patterns
+3. **Check known issues**: search `.prizmkit/prizm-docs/` TRAPS sections for matching patterns
 4. **If database-related**: read existing schema/model files to understand the data layer
    ```bash
    find . -maxdepth 4 -type f \( -name "*.prisma" -o -name "*.sql" -o -path "*/migrations/*" -o -path "*/models/*" -o -name "schema.*" -o -name "*.entity.*" \) -not -path '*/node_modules/*' -not -path '*/.git/*' | head -20
@@ -259,7 +259,7 @@ If the bug is hard to reproduce automatically (e.g. environment-specific):
 1. **Implement the fix**:
    - Change the minimum amount of code to fix the root cause
    - Do NOT refactor or add unrelated improvements — fix the bug only
-   - Follow existing code conventions (read from `.prizm-docs/` RULES/PATTERNS)
+   - Follow existing code conventions (read from `.prizmkit/prizm-docs/` RULES/PATTERNS)
    - If the fix involves database changes: read existing schema first, follow existing naming/constraint conventions
 2. **Run the reproduction test** → must **pass** (green)
 3. **Run the full module test suite** → must pass (no regressions)
@@ -316,7 +316,7 @@ If user reports the fix is NOT working:
    - Commit message: `fix(<scope>): <description>`
    - Include both fix code and reproduction test
    - Do NOT push (user decides when to push)
-   - `/prizmkit-committer` is a pure commit tool — it does NOT modify `.prizm-docs/` or any project files
+   - `/prizmkit-committer` is a pure commit tool — it does NOT modify `.prizmkit/prizm-docs/` or any project files
    - No `/prizmkit-retrospective` — bug fixes are incomplete features, not new architecture worth documenting
 2. **Ask merge preference**:
    ```
@@ -392,7 +392,7 @@ Only 2 artifact files per bug, consistent with the pipeline convention.
 | Cannot reproduce the bug | Ask for more context, try alternative reproduction |
 | Fix causes regressions | Revert, analyze, retry (max 3 rounds) |
 | Root cause unclear after investigation | Present findings, ask user for guidance |
-| Affected files are in unfamiliar module | Read `.prizm-docs/` L1/L2 for that module first |
+| Affected files are in unfamiliar module | Read `.prizmkit/prizm-docs/` L1/L2 for that module first |
 | Branch conflict during merge | Show conflict, ask user to resolve or keep branch |
 
 ## HANDOFF

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)