prizmkit 1.1.29 → 1.1.31

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.29",
-  "bundledAt": "2026-04-12T12:45:35.203Z",
-  "bundledFrom": "4dc0cee"
+  "frameworkVersion": "1.1.31",
+  "bundledAt": "2026-04-12T23:16:11.230Z",
+  "bundledFrom": "543cd94"
 }

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.29",
+  "version": "1.1.31",
   "skills": {
     "prizm-kit": {
       "description": "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management.",

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

@@ -36,6 +36,8 @@ 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
+4. `.prizmkit/deploy.md` — deployment documentation (created or updated with infrastructure config)
 
 **After planning is complete**, you MUST:
 1. Present the summary of captured project-level context (vision, conventions, architecture decisions, project brief)
@@ -123,6 +125,83 @@ Do NOT use this skill when:
    → Save answers to `CLAUDE.md` / `CODEBUDDY.md` under `### Project Conventions` section (format: one bullet per convention)
    → Output format will naturally vary per project — that is the intended behavior
 
+   **Infrastructure Convention Discovery (Database + Deployment)**
+
+   After project conventions are captured, check `CLAUDE.md` / `CODEBUDDY.md` for `### Infrastructure` section:
+
+   - If `### Infrastructure` section does not exist → this project was not initialized with prizmkit-init's Phase 4.5. Treat as if both database and deployment are undecided — run full inquiry below.
+   - If `<!-- infrastructure: deferred -->` → user explicitly skipped at init time. Ask: "During project init you deferred infrastructure decisions. Would you like to configure them now?" (options: "Yes — configure now (Recommended)", "Skip — decide later")
+   - If `<!-- database: deferred -->` → only database was deferred, run database inquiry only
+   - If `<!-- deployment: deferred -->` or deployment section is missing → run deployment inquiry only
+   - If both sections exist with real values → read existing config, present as "Already decided", ask: "Anything to change?" If no → skip to next phase.
+
+   **Database Convention Deep Inquiry** (AI-driven, context-aware — select from pool based on project):
+
+   AI analyzes the detected database type, ORM, and tech stack, then selects relevant questions from this pool. Do NOT ask all questions — only those that matter for THIS project:
+
+   1. **Table naming convention**: snake_case / camelCase / PascalCase; prefix convention (e.g., `t_`, `tbl_`, none). For brownfield: detect from existing migration files or schema and present as "Already decided" with override option.
+   2. **Field naming convention**: snake_case / camelCase; common fields convention — are `created_at`, `updated_at`, `deleted_at` (soft delete) required on all tables? What about `id` vs `uuid` column naming?
+   3. **Migration conventions**:
+      - File storage directory (e.g., `db/migrations/`, `prisma/migrations/`, `alembic/versions/`)
+      - Naming rule (timestamp prefix `20240101_create_users`, sequence prefix `001_create_users`, ORM auto-generated)
+      - Migration tool (ORM built-in / Flyway / Liquibase / golang-migrate / manual SQL)
+      - For brownfield: detect existing migration directory and naming pattern, present as "Already decided"
+   4. **Primary key strategy**: Auto-increment integer / UUID v4 / ULID / Snowflake ID / Other
+   5. **Index naming convention**: e.g., `idx_{table}_{column}`, `ix_{table}_{column}`, or ORM default
+   6. **Environment separation**: dev/test/prod database separation strategy; connection config management (env vars / config files / secret manager)
+
+   Use `AskUserQuestion` for each batch (up to 4 questions per call). For brownfield projects, show detected patterns as recommended options. Each question MUST include a "Skip — decide later" option.
+
+   **Deployment Configuration Deep Inquiry** (AI-driven, context-aware):
+
+   Read the existing `### Infrastructure` → `#### Deployment` section for the deployment target, then ask relevant follow-up questions:
+
+   1. **Deployment target refinement**:
+      - Own server: SSH access method (key-based / password), OS (Ubuntu / CentOS / other), Docker installed?
+      - SaaS platform: specific platform confirmation, existing account and project? Already deployed before?
+      - Container: orchestration method (Docker Compose / K8s / ECS / Cloud Run)
+   2. **Existing infrastructure**:
+      - Remote machine availability — IP/domain? Existing server configuration?
+      - Existing CI/CD pipeline — GitHub Actions / GitLab CI / Jenkins / other? Already configured?
+      - Domain name and SSL — already owned? DNS provider? SSL management (Let's Encrypt / platform-managed / other)?
+   3. **AI-assisted deployment**:
+      - Whether AI should help execute deploy commands (via SaaS CLI like `vercel deploy`, `fly deploy`, `railway up`, `docker push`, or SSH remote commands)
+      - If yes: collect necessary info — API token storage method (env var name, e.g., `VERCEL_TOKEN`), project name/ID on the platform, target environment (production / staging)
+      - Explicitly inform: "AI will show each command and wait for your confirmation before executing"
+   4. **Environment variable management**: production env var strategy (SaaS platform dashboard / `.env.production` committed to repo / secret manager like AWS Secrets Manager, Vault / CI/CD secrets)
+
+   Use `AskUserQuestion` for each batch. 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
+     ### Infrastructure
+
+     #### Database
+     - **Type**: [database type]
+     - **ORM**: [ORM name]
+     - **Table naming**: [convention, e.g., snake_case, no prefix]
+     - **Field naming**: [convention]; common fields: [list]
+     - **Primary key**: [strategy]
+     - **Migration directory**: [path]
+     - **Migration naming**: [rule]
+     - **Index naming**: [convention]
+     - **Environment separation**: [strategy]
+
+     #### Deployment
+     - **Target**: [platform/method]
+     - **AI-assisted deploy**: [yes/no]
+     - **Domain**: [domain or "not configured"]
+     - **SSL**: [management method]
+     - **CI/CD**: [tool or "not configured"]
+     - **Env var management**: [strategy]
+
+     #### Deployment Credentials Reference
+     - [platform]: [token/auth method description]
+     ```
+   - Update `.prizmkit/deploy.md` if it exists — append deployment details to relevant sections (Prerequisites, Production Deployment, Environment Variables). If it does not exist, create it from the `prizmkit-deploy` template with known information filled in.
+   - Items still marked "Skip — decide later" remain as `<!-- [topic]: deferred -->` in CLAUDE.md for `prizmkit-deploy` to pick up later.
+
 4. **Project brief accumulation** — throughout all interactive phases:
    → Read `${SKILL_DIR}/references/project-brief-guide.md` for template and rules
    → Update after each meaningful user response containing business intent, constraints, or design decisions
@@ -133,6 +212,7 @@ Before questions, check optional context files (never block if absent):
 - `.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)
 
 **Tech stack auto-population from config.json:**
 - If `.prizmkit/config.json` contains a `tech_stack` object, use it to pre-fill tech assumptions.
@@ -314,10 +394,11 @@ 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-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 |
-| **CP-AP-5** | Planning Complete | All project-level context captured: conventions, tech stack, architecture decisions, project brief finalized | 4 |
+| **CP-AP-5** | Planning Complete | All project-level context captured: conventions, infrastructure config, tech stack, architecture decisions, project brief finalized | 4 |
 
 ## Architecture Decision Capture
 
@@ -359,8 +440,10 @@ After all checkpoints pass, present a summary and end the session:
 
 1. **Summary** (as text): List all project-level artifacts produced:
    - Project conventions → `CLAUDE.md` / `CODEBUDDY.md` `### Project Conventions`
+   - Infrastructure config → `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` (database conventions + deployment config)
    - Tech stack → `.prizmkit/config.json`
    - Architecture decisions (if any) → `CLAUDE.md` / `CODEBUDDY.md` `### Architecture Decisions`
+   - Deployment docs → `.prizmkit/deploy.md` (if created/updated)
    - Project brief → `.prizmkit/plans/project-brief.md`
 
 2. **Suggest possible next steps** (as text, NOT auto-invoked):
@@ -368,5 +451,6 @@ After all checkpoints pass, present a summary and end the session:
    > - `feature-planner` — decompose the project into features and generate `feature-list.json`
    > - `prizmkit-plan` — start working on a specific feature directly
    > - `prizmkit-prizm-docs` — initialize or update project documentation
+   > - `prizmkit-deploy` — supplement infrastructure config or execute deployment (if AI-assisted deploy was configured)
 
    **Do NOT invoke any of these.** The user decides what to do next, in their own time.

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

@@ -1,6 +1,6 @@
 ---
 name: "prizmkit-deploy"
-description: "Generate or update .prizmkit/deploy.md with local dev setup, testing, production deployment, and rollback procedures. On-demand skill — trigger when deployment docs are needed. Trigger on: 'deploy docs', 'deployment guide', 'how to deploy', 'deploy.md'. (project)"
+description: "Generate or update .prizmkit/deploy.md with local dev setup, testing, production deployment, and rollback procedures. Can also supplement infrastructure config and execute deployments via SaaS CLI. On-demand skill — trigger when deployment docs are needed or user wants to deploy. Trigger on: 'deploy docs', 'deployment guide', 'how to deploy', 'deploy.md', 'deploy my app', 'help me deploy'. (project)"
 ---
 
 # PrizmKit Deploy
@@ -9,13 +9,14 @@ description: "Generate or update .prizmkit/deploy.md with local dev setup, testi
 - When the project has no deployment documentation yet
 - When new infrastructure components have been added (new database, cache, message queue, etc.)
 - When deployment-related configuration has changed significantly
+- When the user wants to supplement or update infrastructure config (database conventions, deployment settings) that was deferred during init or app-planner
+- When the user wants AI-assisted deployment execution
 - When explicitly requested by user or caller
 
 ### When NOT to Use
-- For actual deployment execution (this skill only produces documentation)
 - When only application logic changed with no infra/config impact
 
-> **On-demand skill** — not part of the default `plan → implement → code-review → retrospective → committer` chain. Invoke independently when deployment documentation needs creation or update.
+> **On-demand skill** — not part of the default `plan → implement → code-review → retrospective → committer` chain. Invoke independently when deployment documentation needs creation or update, or when user wants to deploy.
 
 ### PRECONDITION
 - Project contains deployable artifacts (at least one of: `package.json`, `Dockerfile`, `Makefile`, `go.mod`, `Cargo.toml`, `pyproject.toml`, or equivalent)
@@ -26,9 +27,67 @@ description: "Generate or update .prizmkit/deploy.md with local dev setup, testi
 2. **Project config**: Read `.prizmkit/config.json` for `deploy_strategy` and `tech_stack`
    - If `.prizmkit/config.json` does not exist → proceed without it, infer from project file scanning. Log warning: "No .prizmkit/config.json found — inferring deployment strategy from project files."
 3. **Module detail**: Read relevant `.prizm-docs/<module>.prizm` L1/L2 for INTERFACES and DEPENDENCIES sections that inform deployment topology
+4. **Infrastructure config**: Read `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` section for database conventions and deployment configuration collected by `prizmkit-init` or `app-planner`
+
+## Invocation Mode Detection
+
+This skill behaves differently depending on how it is invoked:
+
+- **User-invoked** (default): user calls `/prizmkit-deploy` directly → display current infrastructure config, allow modifications/supplements, then generate docs and optionally execute deployment
+- **Auto-invoked** (via pipeline or other skill, with `--auto` or `--pipeline` flag): use existing config from `CLAUDE.md` / `CODEBUDDY.md` and `.prizmkit/deploy.md` as-is, no interactive questions → generate/update docs only
+
+Pipeline launcher scripts pass the `--auto` flag automatically. If no flag is present, treat as user-invoked.
 
 ## Execution Steps
 
+**Phase 0 — Configuration Check & Supplement** (user-invoked only — skip entirely if auto-invoked):
+
+1. Read `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` section
+2. Read `.prizmkit/deploy.md` if it exists
+3. **Assess configuration completeness**:
+
+   **If `### Infrastructure` section is missing entirely**:
+   - Show: "No infrastructure configuration found. Let's set it up."
+   - Run full database inquiry + full deployment inquiry (see question pools below)
+
+   **If partial configuration exists** (some fields answered, some still deferred — e.g., database configured but `<!-- deployment: deferred -->` present):
+   - Display current config summary showing both answered and deferred items
+   - Run inquiry for deferred topics only, preserve existing answered items unchanged
+
+   **If `<!-- infrastructure: deferred -->` marker found**:
+   - Show: "Infrastructure configuration was deferred during project setup."
+   - Ask: "Would you like to configure it now?" (options: "Yes — configure now (Recommended)", "Skip — keep deferred")
+   - If yes → run full database inquiry + full deployment inquiry
+
+   **If `<!-- database: deferred -->` found**:
+   - Run database inquiry only
+
+   **If deployment section is missing or `<!-- deployment: deferred -->`**:
+   - Run deployment inquiry only
+
+   **If both sections exist with real values**:
+   - Display current config summary
+   - Ask: "Would you like to update any infrastructure settings?" (options: "Looks good — proceed (Recommended)", "Update database config", "Update deployment config", "Update both")
+
+4. **Database inquiry** (same question pool as app-planner — AI selects relevant questions):
+   - Table naming convention (snake_case / camelCase / PascalCase, prefix)
+   - Field naming convention (common fields: created_at, updated_at, deleted_at)
+   - Migration conventions (directory, naming rule, migration tool)
+   - Primary key strategy (auto-increment / UUID / ULID / Snowflake)
+   - Index naming convention
+   - Environment separation (dev/test/prod, connection config)
+
+5. **Deployment inquiry** (same question pool as app-planner — AI selects relevant questions):
+   - Deployment target refinement (own server details / SaaS platform / container orchestration)
+   - Existing infrastructure (remote machines, CI/CD, domain, SSL)
+   - AI-assisted deployment (whether AI should execute deploy commands, credentials info)
+   - Environment variable management strategy
+
+6. **Write results**:
+   - Update `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` section — replace `<!-- deferred -->` markers with real values, preserve unchanged values
+   - Update `#### Deployment Credentials Reference` section if new auth methods were collected during inquiry
+   - Update `.prizmkit/deploy.md` with new information
+
 **Phase 1 — Project Scanning:**
 1. Scan project for deployment-related files:
    - Container: `Dockerfile`, `docker-compose.yml`, `.dockerignore`
@@ -66,6 +125,49 @@ description: "Generate or update .prizmkit/deploy.md with local dev setup, testi
 9. If interactive session is available → show summary and ask if user wants to review before finishing
 10. Output: `.prizmkit/deploy.md` path, summary of sections generated/updated, list of TODOs if any
 
+**Phase 4 — Deployment Execution** (conditional):
+
+**Trigger**: Read `CLAUDE.md` / `CODEBUDDY.md` `### Infrastructure` → `#### Deployment` → `**AI-assisted deploy**` field. Only execute this phase if the value is `yes`.
+
+If `AI-assisted deploy` is `no` or not present → skip Phase 4 entirely, proceed to HANDOFF.
+
+**Execution flow**:
+
+1. **Read deployment config** from `.prizmkit/deploy.md` (Production Deployment section, Platform-Specific Deploy Commands section, AI Deploy Playbook section)
+2. **Build command sequence** based on the deployment target:
+
+   | Target | Command Sequence |
+   |--------|-----------------|
+   | Vercel | `vercel --version` → `vercel deploy --prod` |
+   | Railway | `railway --version` → `railway up` |
+   | Fly.io | `fly version` → `fly deploy` |
+   | Docker + registry | `docker build -t {tag} .` → `docker push {tag}` |
+   | Docker + SSH | `docker build -t {tag} .` → `docker save` → `scp` → `ssh docker load && docker run` |
+   | Custom | Read custom commands from deploy.md |
+
+3. **Pre-flight checks**:
+   - Verify CLI tools are installed (run version commands)
+   - Verify authentication (check if logged in to the platform)
+   - If auth missing: show instructions for how to authenticate (e.g., "Run `vercel login` or set `VERCEL_TOKEN` env var") and stop
+
+4. **Execute with user confirmation** (safety mechanism):
+   - Display the full command list to the user before executing anything
+   - Ask: "Ready to execute these deployment commands?" (options: "Yes — execute step by step", "Let me review first", "Cancel")
+   - Execute one command at a time:
+     - Show the command about to be executed
+     - Wait for user confirmation (implicit: proceed; explicit: user can say "skip" or "stop")
+     - Execute the command
+     - Show output (stdout + stderr)
+     - If command fails → **stop immediately**, show error details, suggest remediation
+     - If command succeeds → proceed to next command
+   - **Sensitive operations**: if a command involves API tokens, secrets, or irreversible actions (e.g., production database migration), add an explicit warning and require user to type confirmation
+
+5. **Post-deployment verification**:
+   - If Health Check section exists in deploy.md → run the health check commands
+   - Show deployment result summary: success/failure, URL (if SaaS platform returns one), any warnings
+
+6. **Output**: Deployment execution report — commands executed, results, any errors encountered
+
 **HANDOFF:** `/prizmkit-committer` — commit changes including `.prizmkit/deploy.md`.
 
 ## Document Sections

package/bundled/skills/prizmkit-deploy/assets/deploy-template.md

@@ -39,6 +39,35 @@ cp .env.example .env
 # [Local services startup]
 ```
 
+## Database Setup
+<!-- Skip if project does not use a database -->
+
+### Database Type
+[PostgreSQL / MySQL / MongoDB / SQLite / etc.]
+
+### Initial Setup
+```bash
+# [Database creation commands]
+# [Initial migration or schema setup]
+```
+
+### Run Migrations
+```bash
+# [Migration command, e.g., npx prisma migrate deploy, alembic upgrade head]
+```
+
+### Seed Data
+```bash
+# [Seed command if applicable, or "No seed data configured"]
+```
+
+### Database Conventions
+<!-- Auto-populated from CLAUDE.md ### Infrastructure → #### Database -->
+<!-- Filled progressively: basic info from prizmkit-init, detailed conventions from app-planner, verified by prizmkit-deploy -->
+- Table naming: [convention]
+- Migration directory: [path]
+- Migration naming: [rule]
+
 ## Testing
 
 ### Run Tests
@@ -97,6 +126,56 @@ cp .env.example .env
 |-------|-------------------|-----------------|
 | [check name] | [endpoint or command] | [expected output] |
 
+## Platform-Specific Deploy Commands
+<!-- Auto-populated based on deployment target from CLAUDE.md ### Infrastructure → #### Deployment -->
+<!-- Filled progressively: basic target from prizmkit-init, detailed config from app-planner, verified by prizmkit-deploy -->
+
+### [Platform Name]
+```bash
+# Pre-flight
+[version check command]
+[auth check command]
+
+# Deploy
+[deploy command]
+
+# Verify
+[post-deploy verification command]
+```
+
+## AI Deploy Playbook
+<!-- Used by prizmkit-deploy Phase 4 when AI-assisted deploy is enabled -->
+<!-- This section is auto-generated — do not edit manually unless you want to customize the sequence -->
+
+### Pre-flight Checklist
+- [ ] CLI tool installed: [tool name + version command]
+- [ ] Authentication verified: [auth check command or "logged in via [method]"]
+- [ ] Environment variables set: [list of required env vars for deployment]
+- [ ] Build successful: [build command]
+
+### Command Sequence
+<!-- Ordered list of commands AI will execute step-by-step with user confirmation -->
+1. `[command 1]` — [what it does]
+2. `[command 2]` — [what it does]
+3. `[command 3]` — [what it does]
+
+### Post-Deploy Verification
+- [ ] Health check: [command or URL]
+- [ ] Smoke test: [manual or automated check]
+
+### Rollback (if deploy fails)
+```bash
+# [Rollback command specific to the platform]
+```
+
+## Deployment Credentials Reference
+<!-- This information is stored in CLAUDE.md / CODEBUDDY.md ### Infrastructure → #### Deployment Credentials Reference -->
+<!-- Listed here for quick reference during deployment execution -->
+
+| Platform | Auth Method | Location |
+|----------|------------|----------|
+| [platform] | [method, e.g., API token, SSH key, CLI login] | [where stored, e.g., VERCEL_TOKEN env var] |
+
 ## Troubleshooting
 
 | Symptom | Cause | Fix |

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

@@ -91,6 +91,65 @@ BROWNFIELD WORKFLOW (existing project):
 
    **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: Infrastructure Quick Scan**
+
+Detect database and deployment signals, then ask 1-2 brief questions. This phase is **optional** — users can skip and configure later via `app-planner` or `/prizmkit-deploy`.
+
+- **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 `CLAUDE.md` (or `CODEBUDDY.md` based on detected platform) 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 will be added by app-planner or prizmkit-deploy later.
+   - Create `.prizmkit/deploy.md` skeleton from `prizmkit-deploy` template if it does not exist, pre-filling known sections (Prerequisites, basic deployment method)
+   - 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 5: Prizm Documentation Generation**
 Invoke prizmkit-prizm-docs (Init operation), passing the two-tier module structure from Phase 4:
   - Create `.prizm-docs/` directory structure mirroring the source tree (sub-module dirs become subdirectories under `.prizm-docs/<top-level>/`)
@@ -172,6 +231,7 @@ GREENFIELD WORKFLOW (new project):
   - "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.5: 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 via `app-planner` or `/prizmkit-deploy`.
 - Phase 5: Create minimal `.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)
@@ -201,6 +261,12 @@ Tech stack detected:
   Bundler:      Vite
   Project type: fullstack
 
+Infrastructure Quick Scan:
+  Database: PostgreSQL (Prisma) — detected from dependencies
+  Deployment: Vercel — detected from vercel.json
+  → Written to CLAUDE.md ### Infrastructure
+  → Created .prizmkit/deploy.md skeleton
+
 Modules discovered:
   src/routes/     → .prizm-docs/routes.prizm (12 files)
   src/models/     → .prizm-docs/models.prizm (8 files)

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

@@ -22,27 +22,18 @@ User says:
 
 ## Pipeline Recovery (Recommended)
 
-For reliable recovery that completes ALL remaining phases autonomously, use the shell-driven pipeline:
+**IMPORTANT**: In Phase 1.3, you MUST present the user with a choice between pipeline recovery (`run-recovery.sh`) and interactive recovery. **NEVER skip this choice. NEVER decide for the user.** The pipeline approach is recommended because it generates a comprehensive bootstrap prompt that explicitly lists every remaining phase with full instructions, ensuring the AI completes the full workflow — not just the implementation part.
 
-```bash
-# Auto-detect and recover (with confirmation)
-./dev-pipeline/run-recovery.sh
-
-# Detection report only (no execution)
-./dev-pipeline/run-recovery.sh detect
-
-# Generate prompt without executing (inspect it)
-./dev-pipeline/run-recovery.sh run --dry-run
-
-# Skip confirmation (for scripted/daemon use)
-./dev-pipeline/run-recovery.sh run --yes
+Pipeline commands (for reference — Phase 1.3 will present these as a selectable option):
 
-# Override AI model
-./dev-pipeline/run-recovery.sh run --model claude-opus-4.6
+```bash
+./dev-pipeline/run-recovery.sh                    # Auto-detect and recover
+./dev-pipeline/run-recovery.sh detect              # Detection report only
+./dev-pipeline/run-recovery.sh run --dry-run       # Generate prompt, don't execute
+./dev-pipeline/run-recovery.sh run --yes           # Skip confirmation
+./dev-pipeline/run-recovery.sh run --model <model> # Override AI model
 ```
 
-The pipeline approach generates a comprehensive bootstrap prompt that explicitly lists every remaining phase with full instructions, ensuring the AI completes the full workflow — not just the implementation part.
-
 ### When to use pipeline vs interactive recovery
 
 | Scenario | Approach |
@@ -74,10 +65,10 @@ recovery-workflow
   │   ├── Based on artifact presence → infer current phase
   │   └── No match → reject and guide user
   │
-  ├── Phase 1: Report + user confirmation
+  ├── Phase 1: Report + user choice
   │   ├── Display detection results
   │   ├── If code changes exist → run test suite
-  │   └── User confirms "continue" → proceed
+  │   └── User chooses: run-recovery.sh (recommended) | interactive | start fresh
   │
   └── Phase 2: Execute remaining steps
       ├── Read target workflow's SKILL.md
@@ -169,18 +160,55 @@ Include test results in the report:
 - How many tests pass/fail
 - If failures exist — which tests and why
 
-### 1.3 Ask User to Confirm
+### 1.3 Ask User to Choose Recovery Approach
+
+**User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options. **NEVER skip this step. NEVER choose for the user.**
 
 ```
-Ready to resume from Phase 5 (Review). Continue?
+AskUserQuestion:
+  question: "Interrupted {workflow_type} detected at Phase {N} ({phase_name}). How would you like to recover?"
+  header: "Recovery"
+  options:
+    - label: "Run recovery script (Recommended)"
+      description: "Execute ./dev-pipeline/run-recovery.sh — autonomously completes ALL remaining phases (review, commit, merge, etc.) via a dedicated AI session with explicit phase instructions"
+    - label: "Copy command and run manually"
+      description: "I'll give you the exact shell command to paste into your terminal — you run it yourself outside this session"
+    - label: "Resume interactively in this session"
+      description: "Continue from Phase {N} within this conversation — more control, but may not complete all phases if session is interrupted again"
+    - label: "Start fresh"
+      description: "Discard interrupted work and restart the original workflow from scratch"
 ```
 
-If the user declines, suggest alternatives:
-- "Use `/bug-fix-workflow` to start fresh"
-- "Use `/feature-workflow` to start fresh"
-- "Use `/refactor-workflow` to start fresh"
+**If "Run recovery script"** → Execute the pipeline recovery:
+```bash
+./dev-pipeline/run-recovery.sh
+```
+The script handles everything: detection, confirmation, prompt generation, session spawn, and post-session validation. **End this skill after launching the script** — do not proceed to Phase 2.
+
+**If "Copy command and run manually"** → Output the command for the user to copy and run in their own terminal:
+```
+To recover, run this command in your project root:
+
+  ./dev-pipeline/run-recovery.sh
+
+Or with options:
+  ./dev-pipeline/run-recovery.sh run --dry-run    # Preview the recovery prompt first
+  ./dev-pipeline/run-recovery.sh run --yes         # Skip confirmation
+  ./dev-pipeline/run-recovery.sh run --model <model>  # Specify AI model
+```
+**End this skill** — do not proceed to Phase 2. The user will run the command themselves.
+
+**If "Resume interactively"** → Continue to Phase 2 below (execute remaining steps in this session).
+
+**If "Start fresh"** → Suggest the appropriate original workflow skill:
+- bug-fix-workflow → `/bug-fix-workflow`
+- feature-workflow → `/feature-workflow`
+- refactor-workflow → `/refactor-workflow`
+End this skill.
+
+**NEVER proceed to Phase 2 without explicit user selection via `AskUserQuestion`. Do NOT render options as plain text — the user must be able to click/select.**
 
-**CHECKPOINT CP-REC-1**: User confirmed recovery.
+**CHECKPOINT CP-REC-1**: User chose recovery approach.
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prizmkit",
-  "version": "1.1.29",
+  "version": "1.1.31",
   "description": "Create a new PrizmKit-powered project with clean initialization — no framework dev files, just what you need.",
   "type": "module",
   "bin": {