prizmkit 1.1.99 → 1.1.101

package/bundled/skills-windows/prizmkit-deploy/references/ssh-bootstrap-flow.md

@@ -1,49 +0,0 @@
-# SSH Bootstrap Flow
-
-Bootstraps the server before first deployment. Present a plan showing every privileged action before executing anything.
-
-## Always-Run Preflight
-
-```
-locale-gen en_US.UTF-8           # fix locale warnings on bare Ubuntu
-apt-get update -qq               # refresh package list
-```
-
-## Check-and-Install (idempotent)
-
-Node.js, npm, PM2, Nginx, Git. Use v22 LTS if v25 not available.
-
-## Detect Port Conflicts
-
-`ss -tlnp | grep :80 || true`. If port 80/443 is occupied, report and ask how to resolve.
-
-## User and Directory Setup
-
-```
-useradd -m -s /bin/bash <runtimeUser>   # if not exists
-mkdir -p /var/www/<project>/{releases,shared,deploy-logs}
-chown -R <runtimeUser>:<runtimeUser> /var/www/<project>
-```
-
-## PM2 Startup
-
-```
-env PATH=$PATH:/usr/bin pm2 startup systemd -u <runtimeUser> --hp /home/<runtimeUser>
-```
-
-## Deploy Key (Pull mode only)
-
-```
-sudo -u <runtimeUser> ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ""
-sudo -u <runtimeUser> ssh-keyscan -H github.com >> ~/.ssh/known_hosts
-```
-
-## Security Baseline (Firewall)
-
-After core tools are installed, ask whether to configure ufw. If user agrees, read `references/firewall-setup.md` for the full interactive flow and rule templates.
-
-## Database Setup
-
-If Discovery detected database drivers, ask whether to install the database on the server. If user agrees, read `references/database-setup.md` for platform-specific setup commands and security notes.
-
-After each bootstrap step, record the result. Bootstrap operations must be idempotent. Back up any existing config files before modifying them.

package/bundled/skills-windows/prizmkit-deploy/references/ssh-execution-flow.md

@@ -1,41 +0,0 @@
-# SSH: Deployment Execution Flow
-
-Pipeline runs in strict order. Each group must complete before the next begins. If any step before traffic switch fails, STOP — do not touch the live version.
-
-## Pre-flight — Change Summary
-
-Show what will be deployed using `git log --oneline <last-deployed-commit>..HEAD`. If first deployment, show last 5 commits. If no new commits, warn "No new code changes. Are you sure you want to redeploy?"
-
-## Group 1 — Pre-flight & Prepare
-
-- Verify SSH, runtime user, tools, deploy key, port availability.
-- Generate `releaseId`: `YYYYMMDD-<short-commit-sha>`. Create `releases/<releaseId>`.
-- Determine target color: read `activeColor` from `shared/deploy-metadata.json` and use the opposite. If first deploy (no metadata, no `current` symlink), default to blue (port 3101).
-
-## Group 2 — Fetch & Build
-
-- **CI/CD Pull mode** (server-side build): git clone → install → copy `.env.production` before build (NEXT_PUBLIC_* vars are baked at build time) → build. If build fails: STOP.
-- **CI/CD Push mode** (runner-side build): extract tarball, skip install/build.
-- **Direct-upload mode**: build was already done locally and SCP'd. Skip this group.
-
-## Group 3 — Stage & Health Check
-
-- Start new version on inactive port via PM2: `pm2 start npm --name <project>-<app>-<color> -- run start -- -p <inactivePort>`.
-- PM2 process naming: `<project>-<app>-<color>` (e.g., `prizm-ideas-web-green`).
-- Wait 3-5 seconds, run health checks against new port. If any fails: STOP, do NOT switch traffic.
-
-## Group 4 — Switch & Verify
-
-- Update Nginx upstream to new port. Run `nginx -t` — abort on failure.
-- `systemctl reload nginx`. Update `current` symlink to new release.
-- Write `shared/deploy-metadata.json` with new `activeColor`, `activePort`, `lastReleaseId`.
-- Run health checks against public endpoint. If any fails: rollback immediately.
-
-## Group 5 — Cleanup & Record
-
-- Stop old PM2 process. Remove oldest releases beyond `releaseRetention` count. `pm2 save`.
-- Write deploy-history JSON. Update `deploy.config.json` validation status.
-
-## Post-deploy — Completion Summary
-
-Output a summary (project, URL, version, duration, health status) and append to deploy.md. If `deployStrategy` is `"direct-upload"`, offer CI/CD upgrade (see §SSH: Post-Deploy CI/CD Upgrade).

package/bundled/skills-windows/prizmkit-deploy/references/ssh-takeover.md

@@ -1,20 +0,0 @@
-# SSH: Existing Deployment Takeover
-
-When deploying to a server that already has deployment assets.
-
-## Detection
-
-1. Check for existing `/var/www/<project>` directory
-2. Check for existing PM2 processes with similar names
-3. Check Nginx config referencing the same domain/IP
-4. Check for port conflicts
-
-## Decision Flow
-
-Report findings and ask for takeover decision:
-
-- **Take over and backup**: Back up existing config, then proceed.
-- **Coexist**: Use different directory/ports/process names.
-- **Manual resolve**: Stop and let the user handle it.
-
-Record takeover decision and validation results in config and history.

package/bundled/skills-windows/prizmkit-deploy/references/ssl-setup.md

@@ -1,56 +0,0 @@
-# SSL/HTTPS Configuration (Let's Encrypt + Certbot)
-
-Read this file when DNS is confirmed pointing to the server and SSL needs to be configured.
-
-## Step 1 — Detect cloud vendor
-
-```
-# Try metadata endpoints to detect cloud vendor
-curl -s --connect-timeout 2 http://100.100.100.200/latest/meta-data/ && echo "ALIBABA"
-curl -s --connect-timeout 2 http://metadata.tencentyun.com/latest/meta-data/ && echo "TENCENT"
-curl -s --connect-timeout 2 http://169.254.169.254/latest/meta-data/ && echo "AWS/GCP/AZURE"
-```
-Also check `/etc/hostname` for vendor patterns.
-
-## Step 2 — Choose SSL strategy
-
-- **Cloud vendor detected** → ask user:
-  > "Detected the server is running on <cloud-vendor>. Which SSL approach?"
-  > - **A. Let's Encrypt free certificate (recommended)** — one command for permanent auto-renewal, hassle-free
-  > - **B. <cloud-vendor> native certificate** — manual download/config, 1-year validity requires manual renewal
-  >
-  > Choose A and I'll set it up for you; choose B and you'll need to download the certificate from the cloud console and tell me the path.
-- **No cloud vendor / unknown** → use certbot directly, no choice needed.
-
-## Step 3 — Certbot install & certificate request
-
-```
-# Install certbot (idempotent)
-which certbot || apt-get install -y certbot python3-certbot-nginx
-
-# Request certificate
-certbot --nginx -d <domain> -d www.<domain> --non-interactive --agree-tos --email <user-email>
-```
-
-**Collect from user before running:**
-- Email address (Let's Encrypt expiry notifications)
-- Confirm domain list (e.g., `example.com, www.example.com`)
-
-## Step 4 — Verify auto-renewal
-
-```
-systemctl status certbot.timer
-certbot renew --dry-run
-```
-If timer is inactive, enable it: `systemctl enable --now certbot.timer`.
-
-## Step 5 — Record
-
-- Write SSL configuration summary to deploy.md: certificate paths, auto-renewal status, expiry date.
-- Record a `"ssl-setup"` event in deploy history.
-
-## Edge cases
-
-- **DNS not yet propagated** → certbot challenge fails. Tell user to wait and retry: `/prizmkit-deploy setup-ssl`.
-- **Existing certificate found** → check expiry date (`certbot certificates`). If expiring within 30 days, warn. Otherwise skip.
-- **Port 80/443 occupied by non-Nginx process** → report and ask how to resolve before proceeding.

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

@@ -1,71 +0,0 @@
----
-name: "prizmkit-implement"
-description: "Execute plan.md tasks with TDD approach. Respects task ordering and dependencies. Use after /prizmkit-plan. Trigger on: 'implement', 'build', 'code it', 'start coding', 'execute', 'write the code'. (project)"
----
-
-# PrizmKit Implement
-
-### When to Use
-- After `/prizmkit-plan` when ready to write code
-- 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)
-
-### When NOT to Use
-- No plan.md exists — run /prizmkit-plan first
-- All tasks in plan.md are already checked off — nothing to implement
-- Trivial one-line changes (typo, config tweak) — edit directly without the full workflow
-- Design/planning phase — use /prizmkit-plan to produce spec and plan first
-
-**PRECONDITION:**
-
-| Required Artifact | Check | If Missing |
-|---|---|---|
-| `plan.md` with Tasks section | File exists + unchecked tasks | Run `/prizmkit-plan` |
-| `spec.md` | File exists in same directory as plan.md | Run `/prizmkit-plan` |
-
-**Artifact directory**: Accept `artifact_dir` from caller. If not provided, scan `.prizmkit/` subdirectories for the most recently modified `plan.md` with unchecked tasks. When invoked as a handoff step in a skill chain, reuse the `artifact_dir` from the previous skill rather than re-detecting — re-detection can resolve to a different feature's directory in a multi-task workspace.
-
-## Input
-
-| Parameter | Required | Description |
-|-----------|----------|-------------|
-| `artifact_dir` | No | Directory containing spec.md + plan.md. If omitted, auto-detect per precondition above. |
-
-## Context Loading
-
-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 `.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).
-3. **Dev rules** (if configured): Check `.prizmkit/prizm-docs/root.prizm` for a `RULES:` line — if present, read all referenced `.prizmkit/rules/<layer>-rules.md` files. If a referenced file does not exist, skip it silently and continue. These define per-layer conventions (frameworks, naming, patterns, state management, etc.) that AI must follow when generating code for that layer. Apply these rules during implementation — if a rule conflicts with what plan.md describes, call it out and ask the user.
-
-> `.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
-
-For each unchecked task in plan.md, in order:
-
-1. Read L1/L2 doc for the target file's module — check TRAPS and DECISIONS before modifying files
-2. 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.
-   - **Internal ID hygiene**: Do not place PrizmKit feature/bug/refactor IDs (`F-001`, `B-001`, `R-001`), task IDs, session IDs, run IDs, branch names, absolute worktree paths, or `.prizmkit/specs` / `.prizmkit/dev-pipeline` artifact paths in `.prizmkit/prizm-docs/`, user-visible UI text, API responses, emails, notifications, or tests that assert visible product copy. Translate internal references into durable product/domain language before writing memory docs, tests, or UI copy.
-   - **Cover three paths for each function**: happy path (valid inputs producing expected behavior), edge cases (boundary values specific to the parameter type and domain — e.g., zero/min/max for numeric, empty collection, boundary index), and error conditions (inputs that should trigger error handling). Determine edge cases from the function's parameter types and domain logic, not from a fixed checklist. If a function has no edge or error paths, don't force them.
-   - **No redundant tests**: Check if a test for this behavior already exists before writing. Each test must verify a uniquely different code path — don't write multiple tests that exercise the same logic.
-   - **Test your own code only**: Don't test framework behavior, third-party library internals, or language built-ins. For library calls, test the integration point (correct parameters passed, return value correctly handled), not the library itself.
-3. Mark task as `[x]` in `plan.md` immediately after completion — not batched at the end. Immediate marking means plan.md always reflects true progress, even if the session is interrupted.
-4. **Parallel tasks**: If task has `[P]` marker, it can run in parallel with other `[P]` tasks in the same group. Sequential tasks stop on failure (later tasks may depend on this one). Parallel `[P]` tasks continue — report all failures at the end.
-5. **Checkpoint tasks** (`CP:` prefix in plan.md): When a checkpoint task is reached, verify build passes and tests pass before continuing. Checkpoints catch integration errors early — skipping them means cascading failures in later phases.
-6. After all tasks complete: run full test suite.
-
-## Recovery
-
-If a session is interrupted mid-implementation:
-- Completed tasks are already marked `[x]` in plan.md (because we mark immediately)
-- Resume by re-running `/prizmkit-implement` — it picks up from the first unchecked `[ ]` task
-
-**HANDOFF:** `/prizmkit-code-review`
-
-## Output
-
-- Code files created/modified as specified in plan.md Tasks section
-- `plan.md` Tasks section updated with completion markers `[x]`
-- Implementation summary output to conversation

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

@@ -1,356 +0,0 @@
----
-name: "prizmkit-init"
-description: "Project takeover and bootstrap. Scans any project, generates Prizm docs and project brief. Use this skill whenever a user opens a new project for the first time, says 'initialize', 'set up PrizmKit', 'take over this project', 'bootstrap', 'scan this codebase', 'init', or when .prizmkit/prizm-docs/ doesn't exist yet. Also use when PrizmKit was just installed via npx but not yet initialized. (project)"
----
-
-# PrizmKit Init
-
-Project takeover and bootstrap skill. Scans any project (brownfield or greenfield), generates Prizm documentation and project brief. Supports Codex, Claude Code, CodeBuddy, and multi-platform installations.
-
-### When to Use
-- Taking over a new project (brownfield or greenfield)
-- User says "initialize PrizmKit", "set up PrizmKit", "take over this project"
-- First time using PrizmKit on a project
-- After `npx prizmkit install` when project has no `.prizmkit/prizm-docs/`
-
-### When NOT to Use
-- All artifacts exist and are up to date → use `/prizmkit-prizm-docs` (Update) instead if you only want to resync docs
-- User just wants to update stale docs → use `/prizmkit-prizm-docs` (Update or Rebuild) instead (faster, targeted)
-- User wants to start a feature on an already-initialized project → skip init, go to `/prizmkit-plan`
-
-### Error Handling
-- If artifacts already exist: idempotent status check offers regenerate/skip choices (see Phase 3: Idempotent Status Check)
-- If no source files found in any directory: fall back to greenfield mode
-
-## Execution Steps
-
-**Phase 1: Platform Detection**
-1. Detect which platform is running (Codex, Claude Code, or CodeBuddy) via AI CLI environment.
-2. Hold detected platform value in memory — written to disk in Phase 6 along with other config fields.
-
-**Phase 2: Mode Detection**
-- If project has source code: brownfield mode
-- If project is nearly empty: greenfield mode
-
-**Phase 3: Idempotent Status Check**
-
-Scan all init artifacts and display their status:
-
-| Artifact | Path | Check |
-|----------|------|-------|
-| Prizm docs | `.prizmkit/prizm-docs/` | Directory exists + `root.prizm` present |
-| Runtime config | `.prizmkit/config.json` | File exists |
-| Project brief | `.prizmkit/plans/project-brief.md` | File exists |
-
-Display status table to user:
-```
-Init Status Check:
-  [exists]  .prizmkit/prizm-docs/          (N files)
-  [exists]  .prizmkit/config.json
-  [missing] .prizmkit/plans/project-brief.md
-```
-
-- **If all missing**: skip interaction, proceed to generate everything.
-- **If some exist**: ask user once:
-  - **[A] Regenerate all** — overwrite all existing artifacts (fresh start)
-  - **[B] Only generate missing** — skip existing, fill gaps (default)
-  - **[C] Pick per item** — ask for each existing artifact: regenerate or skip
-
-Each subsequent phase checks its artifact's action before executing:
-- `action == skip` → output "Skipped (exists)" and move on
-- `action == generate | regenerate` → run normally
-- **Special case for `.prizmkit/prizm-docs/`**:
-  - `skip` = **Update** mode: preserve existing L1/L2 docs, re-scan tech stack, merge changes, check for missing docs (see `${SKILL_DIR}/references/update-supplement.md`)
-  - `regenerate` = **Reinitialize**: overwrite everything
-
-BROWNFIELD WORKFLOW (existing project):
-
-**Phase 4: Project Scanning**
-1. Detect tech stack from build files (`package.json`, `requirements.txt`, `go.mod`, `pom.xml`, `Cargo.toml`, etc.)
-2. Map directory structure using a TWO-TIER model — flat structures lose the nesting relationships that AI needs to navigate the codebase:
-   - TOP-LEVEL modules: directories directly under project root that contain source files or sub-directories with source files (e.g. `src/`, `internal/`, `lib/`)
-   - SUB-MODULES: directories INSIDE a top-level module (e.g. `src/routes/`, `src/models/`)
-   - A sub-module maps to `.prizmkit/prizm-docs/<M>/<S>.prizm`, never to `.prizmkit/prizm-docs/<S>.prizm` — flattening would create ambiguous paths when two modules have identically-named sub-modules
-   - Exclude: `.git/`, `node_modules/`, `vendor/`, `build/`, `dist/`, `__pycache__/`, `target/`, `bin/`, `.agents/`, `.codex/`, `.claude/`, `.codebuddy/`, `.prizmkit/`
-   - **Scan command** — run this to get a 2-level directory tree (excludes noise directories):
-     ```powershell
-     Get-ChildItem -Path . -Directory -Recurse -Depth 2 -Force -ErrorAction SilentlyContinue |
-       Where-Object {
-         $_.FullName -notmatch '\\(node_modules|\.git|dist|build|__pycache__|vendor|\.agents|\.codex|\.claude|\.codebuddy|\.prizmkit|target)(\\|$)'
-       } |
-       ForEach-Object {
-         $relative = Resolve-Path -Relative $_.FullName
-         $depth = (($relative -replace '^[.][\\/]', '') -split '[\\/]').Count - 1
-         ('  ' * [Math]::Max(0, $depth)) + ($relative -replace '^[.][\\/]', '')
-       }
-     ```
-3. Identify entry points by language convention
-4. Catalog dependencies (external packages)
-5. Count source files per directory
-6. Detect detailed tech stack (adaptive — only include fields that apply):
-   → Read `${SKILL_DIR}/references/tech-stack-catalog.md` for the full field catalog.
-
-   **IMPORTANT**: Not all projects have all fields. A pure backend API will have no `frontend_framework` or `frontend_styling`. A library may have no database. Only record what is actually detected — never generate empty or placeholder values.
-
-**Phase 4.5: Layer Detection**
-
-After tech stack detection, determine which development layers exist in the project — these are code domains that may benefit from custom dev rules (frontend, backend, database, mobile). This is a quick detection step, not an interactive Q&A — rules can be configured later based on detected layers.
-
-1. Read `${SKILL_DIR}/references/rules/layer-detection.md` for the detection signal table and AI judgment guidelines.
-2. Scan the project against each signal, and supplement with your own judgment — the signal table is a guide, not exhaustive. If you see clear evidence of a layer not covered by the table, include it. If a signal matches but context is misleading, downgrade or ignore it:
-   - **frontend**: React/Vue/Angular/etc. in dependencies, or `src/components/` with UI files
-   - **backend**: Express/FastAPI/Gin/etc. in dependencies, or `routes/`/`controllers/` with server code
-   - **database**: Prisma/TypeORM/SQLAlchemy/etc. in dependencies, or `migrations/`/`prisma/` directory
-   - **mobile**: `pubspec.yaml` (Flutter), `react-native` in package.json, or simultaneous `ios/`+`android/` directories
-3. For mobile signals — if ambiguous (e.g., monorepo with web + ios/android dirs), use `AskUserQuestion` to confirm: "Mobile platform signals detected. Is this project a mobile app?" Options: "Yes, this is a mobile app" / "No, these are for another purpose".
-4. Assemble `detected_layers` array (e.g., `["frontend", "backend", "database"]`). If no layers detected (library/CLI project), array is empty.
-
-**Phase 4.6: Infrastructure Quick Scan**
-
-Detect database and deployment signals, then ask 1-2 brief questions. This phase is **optional** — users can skip and configure later.
-
-- **BROWNFIELD**: Auto-detect infrastructure signals from existing files, then ask 1-2 brief questions (pre-filled with detection results)
-- **GREENFIELD**: No auto-detection possible — ask the 2 brief questions directly (database need and deployment target)
-
-1. **Auto-detect infrastructure signals** (no user interaction):
-   - **Database signals**: ORM/database client dependencies in `package.json`, `requirements.txt`, `go.mod`, `Cargo.toml`, `pyproject.toml` (look for: prisma, typeorm, sequelize, mongoose, sqlalchemy, django, gorm, diesel, sqlx, pg, mysql2, etc.); directories named `migrations/`, `db/`, `schema/`, `prisma/`; environment variables `DATABASE_URL`, `DB_HOST`, `DB_NAME`, `MONGO_URI` in `.env*` files
-   - **Deployment signals**: `Dockerfile`, `docker-compose.yml`, `vercel.json`, `fly.toml`, `railway.json`, `netlify.toml`, `cloudflare.json`, `.github/workflows/`, `Procfile`, `app.yaml`, `serverless.yml`, `terraform/`, `pulumi/`
-
-2. **Brief inquiry** (using `AskUserQuestion`, max 2 questions):
-
-   **Question 1 — Database**:
-   - If database signals detected: pre-fill with detected info
-   - Question: "Does your project use a database?"
-   - Options:
-     - "Yes — {detected ORM/DB}" (if detected, mark as Recommended)
-     - "Yes — different database" (let user specify)
-     - "No database needed"
-     - "Skip — decide later"
-   - If "Yes": follow up to confirm database type (MySQL / PostgreSQL / MongoDB / SQLite / Other) — skip this follow-up if already clear from detection
-
-   **Question 2 — Deployment target**:
-   - If deployment signals detected: pre-fill with detected info
-   - Question: "Where will this project be deployed?"
-   - Options:
-     - "{Detected platform}" (if detected, e.g., "Vercel" from vercel.json, mark as Recommended)
-     - "Own server / VPS"
-     - "SaaS platform" (if no specific platform detected)
-     - "Container (Docker / K8s)"
-     - "Skip — decide later"
-   - If "SaaS platform": follow up with platform selection (Vercel / Railway / Fly.io / Cloudflare / AWS / Other)
-
-3. **Write results**:
-   - Append `### Infrastructure` section to the detected platform instruction file (`AGENTS.md` for Codex, `CLAUDE.md` for Claude Code, `CODEBUDDY.md` for CodeBuddy) with detection results and user answers. Format:
-     ```markdown
-     ### Infrastructure
-
-     #### Database
-     - **Type**: [PostgreSQL / MySQL / MongoDB / SQLite / none]
-     - **ORM**: [detected ORM or "none detected"]
-
-     #### Deployment
-     - **Target**: [platform name or "undecided"]
-     ```
-     → This is intentionally minimal (Quick Scan). Full conventions and deployment details can be added later.
-   - If user selects "Skip — decide later" for BOTH topics: write deferred marker instead:
-     ```markdown
-     ### Infrastructure
-     <!-- infrastructure: deferred -->
-     ```
-   - If user skips only one topic, write the answered one normally and mark the skipped one:
-     ```markdown
-     #### Database
-     <!-- database: deferred -->
-     ```
-
-**Phase 4.7: Rules Quick Entry**
-
-After Infrastructure Quick Scan completes, check if `detected_layers` is non-empty (from Phase 4.5). If layers were detected, offer a lightweight entry point for rules configuration.
-
-1. If `detected_layers` is empty (library/CLI project) → skip this phase entirely, proceed to Phase 5.
-2. If layers detected, use `AskUserQuestion`:
-
-   **Question**: "Detected **{list detected layers}** code. Would you like to set up custom development rules for AI to follow? This helps AI generate code that matches your conventions."
-   - **Configure later (Recommended)** — Record layers and configure rules later
-   - **Skip entirely** — no custom rules, AI uses general best practices
-
-3. If user picked "Skip entirely" → clear `detected_layers` to empty array, proceed to Phase 5.
-4. If user picked "Configure later" → keep `detected_layers`, proceed to Phase 5. The layers will be written to config.json in Phase 6.
-
-**Phase 5: Prizm Documentation Generation**
-Invoke prizmkit-prizm-docs (Init operation), passing the two-tier module structure from Phase 4:
-  - Create `.prizmkit/prizm-docs/` directory structure mirroring the source tree (sub-module dirs become subdirectories under `.prizmkit/prizm-docs/<top-level>/`)
-  - Generate `root.prizm` (L0) with project meta and MODULE_INDEX listing only top-level modules. If module count > 15, use MODULE_GROUPS format instead (group by functional domain).
-  - For each module entry in MODULE_INDEX/MODULE_GROUPS, include keyword tags extracted from the module's source files — scan for: exported symbols, imported packages, domain terms in file/directory names. Format: `- module-name [tag1, tag2, tag3]: ...`. Tags help AI match user intent to relevant modules.
-  - Generate L1 docs for top-level modules at `.prizmkit/prizm-docs/<M>.prizm` and for sub-modules at `.prizmkit/prizm-docs/<M>/<S>.prizm`
-  - Skip L2 (lazy generation) — L2 is generated on first file modification, saving tokens upfront
-  - Do not create auxiliary `changelog.prizm`, CHANGELOG sections/files, UPDATED/date metadata, feature/bug/refactor/task/session/run/pipeline/workflow IDs, branch names, absolute worktree paths, or `.prizmkit/specs` / `.prizmkit/dev-pipeline` artifact paths; git history is the source of change history
-
-**Phase 6: Workspace Initialization**
-6a. Create `.prizmkit/` directory structure (if missing):
-  - `.prizmkit/config.json` (adoption_mode, speckit_hooks_enabled, platform)
-  - `.prizmkit/specs/` (empty)
-  - `.prizmkit/plans/` (empty — needed by Phase 7 and future pipeline tasks)
-
-6b. Write detected tech stack to `.prizmkit/config.json`:
-   → Read `${SKILL_DIR}/references/config-schema.md` for merge strategy, field definitions, and examples.
-
-6c. Write `detected_layers` to `.prizmkit/config.json` (alongside `tech_stack`):
-   - Field: `"detected_layers": ["frontend", "backend"]` — the layers from Phase 4.5
-   - If user chose "Skip entirely" in Phase 4.7, write empty array `[]`
-   - For greenfield projects (Phase 4.5 skipped): write `[]` — no code layers to configure rules for yet; user can configure rules later when code exists
-   - This field indicates which development layers exist in the project and can be used to determine available rule configuration options.
-
-**Phase 7: Project Brief Generation**
-
-If action for project brief == skip, output "Project brief: skipped (exists)" and proceed to Phase 8 (Report).
-
-Otherwise, generate a project brief to capture the user's overall product vision. This file is referenced by `root.prizm` so every new AI session understands the project goals.
-
-→ Read `${SKILL_DIR}/assets/project-brief-template.md` for the brief format rules and checklist template.
-
-**Brownfield** (existing codebase):
-1. Infer project goals from:
-   - Generated `root.prizm` (tech stack, module structure, module groups)
-   - `README.md` (if exists)
-   - Package metadata (`package.json` description, `pyproject.toml`, etc.)
-   - Quick scan of key entry points identified in L1 docs
-2. Generate a draft in the checklist format defined in the template
-3. Present the draft to the user and ask:
-   - Is this inference correct?
-   - Anything to add, remove, or modify?
-4. Apply user edits and write to `.prizmkit/plans/project-brief.md`
-
-**Greenfield** (new/empty project):
-1. Use **progressive questioning** (defined in template) to fully understand the user's intent:
-   - Round 1: Problem & Vision → Round 2: Scope & Features → Round 3: Technical Constraints → Round 4: Clarification (adaptive)
-   - Stop when completion criteria are met: problem, users, core features, boundaries, and technical direction are all clear
-   - If answers are vague, probe deeper — don't accept shallow responses
-2. Generate brief from answers in checklist format
-3. Present to user for confirmation/editing
-4. Write to `.prizmkit/plans/project-brief.md`
-
-**After writing the brief**:
-- Check if `root.prizm` already contains a `PROJECT_BRIEF:` line
-- If exact match `PROJECT_BRIEF: .prizmkit/plans/project-brief.md` exists: skip (already correct)
-- If `PROJECT_BRIEF:` exists with a different path: warn user and ask to confirm update or keep old path
-- If not present: add `PROJECT_BRIEF: .prizmkit/plans/project-brief.md` at the end of `root.prizm`, after all standard sections
-- This ensures every AI session that loads L0 knows to read the project brief
-
-**Phase 8: Report**
-Output summary: platform detected, tech stack detected (with detail), modules discovered, L1 docs generated, project brief status, next recommended steps.
-
-Tech stack report format (only show detected fields, adapt to project type):
-```
-Tech stack detected:
-  Language:     TypeScript
-  Runtime:      Node.js 20
-  Frontend:     React + Tailwind CSS
-  Backend:      Express.js
-  Database:     PostgreSQL (Prisma)
-  Testing:      Vitest
-  Bundler:      Vite
-  Project type: fullstack
-```
-
-Adapt fields to match project type — only show detected fields.
-
-Saved to: `.prizmkit/config.json` → `tech_stack` field
-
-Next step: "Use `/prizmkit-plan` to start your first feature"
-
-GREENFIELD WORKFLOW (new project):
-- Skip Phase 4 code scanning (no code to scan — Phase 4.5 Layer Detection and Phase 4.7 Rules Quick Entry are skipped; no layers to detect yet):
-  - Ask the user about their intended tech stack:
-  - "What language/framework will you use?" (e.g. React + Node.js, Python + FastAPI, etc.)
-  - Record answers in `config.json` `tech_stack` with `"_auto_detected": false` (user-provided, not auto-detected)
-  - If user is unsure, skip tech_stack — it can be populated later on re-init after code exists
-- Phase 4.6: Run Infrastructure Quick Scan — in greenfield mode, no auto-detection is possible, so only ask the 2 brief questions (database need and deployment target). If user is unsure, skip — these can be configured later.
-- Phase 5: Create minimal `.prizmkit/prizm-docs/` with just `root.prizm` skeleton (populate TECH_STACK from user answers if provided)
-- Phase 7: Generate project brief (greenfield flow — ask user about project goals, see Phase 7 above)
-- Phases 6, 8: Same as brownfield (Phase 8 Report recommends `/prizmkit-plan` for first feature)
-
-## Example
-
-**Brownfield init on a fullstack Node.js project:**
-```
-$ /prizmkit-init
-
-Platform detected: Claude Code
-Init Status Check:
-  [missing] .prizmkit/prizm-docs/
-  [missing] .prizmkit/config.json
-  [missing] .prizmkit/plans/project-brief.md
-→ All missing, generating everything.
-
-Mode: Brownfield (154 source files found)
-
-Tech stack detected:
-  Language:     TypeScript
-  Runtime:      Node.js 20
-  Frontend:     React + Tailwind CSS
-  Backend:      Express.js
-  Database:     PostgreSQL (Prisma)
-  Testing:      Vitest
-  Bundler:      Vite
-  Project type: fullstack
-
-Layer Detection:
-  Detected layers: frontend, backend, database (from dependency + directory signals)
-  → Stored for config.json
-
-Infrastructure Quick Scan:
-  Database: PostgreSQL (Prisma) — detected from dependencies
-  Deployment: Vercel — detected from vercel.json
-  → Written to the detected platform instruction file `### Infrastructure`
-
-Rules Quick Entry:
-  Matched layers: frontend (React), backend (Express.js), database (Prisma) → keeping default rules
-
-Modules discovered:
-  src/routes/     → .prizmkit/prizm-docs/routes.prizm (12 files)
-  src/models/     → .prizmkit/prizm-docs/models.prizm (8 files)
-  src/services/   → .prizmkit/prizm-docs/services.prizm (15 files)
-  src/middleware/  → .prizmkit/prizm-docs/middleware.prizm (5 files)
-
-Project brief: inferred from codebase → confirmed by user
-  → .prizmkit/plans/project-brief.md
-
-Generated: root.prizm + 4 L1 docs
-Saved: .prizmkit/config.json (tech_stack + detected_layers recorded)
-
-Next: Use /prizmkit-plan to start your first feature
-```
-
-UPDATE SUPPLEMENT (runs after tech stack merge in Update mode):
-→ Read `${SKILL_DIR}/references/update-supplement.md` for the 5-step gap-fill procedure.
-
-**Re-init after PrizmKit upgrade (existing config preserved):**
-```
-$ /prizmkit-init
-
-Init Status Check:
-  [exists]  .prizmkit/prizm-docs/          (12 files)
-  [exists]  .prizmkit/config.json
-  [missing] .prizmkit/plans/project-brief.md
-
-Missing items will be generated.
-For existing items: [A] Regenerate all  [B] Only generate missing (default)  [C] Pick per item
-> B (Only generate missing)
-
-Tech stack changes detected:
-  + bundler: Vite (newly detected)
-  ~ testing: Jest → Vitest (updated)
-  = language: TypeScript (unchanged)
-  = frontend: React (unchanged)
-
-Documentation gap-fill:
-  + app/share/[token].prizm (L2) — created (3 source files, meaningful logic)
-  = routes.prizm (L1) — up to date
-  ~ models.prizm (L1) — FILES count updated (8 → 10)
-
-Project brief: inferred from codebase → confirmed by user
-  → .prizmkit/plans/project-brief.md (generated)
-
-Merged into .prizmkit/config.json (2 fields updated, user overrides preserved)
-```