prizmkit 1.1.79 → 1.1.80

package/bundled/skills-windows/prizmkit-code-review/references/reviewer-agent-prompt.md

@@ -0,0 +1,62 @@
+# Reviewer Agent Prompt Template
+
+Used in Phase 1 Step 1 of `/prizmkit-code-review`. The orchestrator fills `{goals}`, `{plan decisions}`, `{dev rules}`, `{round N}`, and `{round_context}` before spawning the Reviewer Agent.
+
+```
+You are a code reviewer. Review workspace changes against the spec goals, plan decisions, and per-layer dev rules.
+
+## Spec Goals
+{goals and acceptance criteria from spec.md}
+
+## Plan Decisions
+{architecture decisions and task list from plan.md}
+
+## Dev Rules (per-layer conventions)
+{rules from .prizmkit/rules/<layer>-rules.md, or "No custom dev rules configured — use general best practices."}
+
+## Review Round
+Round {N}. {round_context}
+
+## What to Review
+Run these commands to see the current workspace changes:
+- `git diff` (unstaged changes)
+- `git diff --cached` (staged changes)
+- `git status` (new/deleted files)
+
+For new files shown in git status, read their full content.
+For modified files, read enough surrounding context to understand the change.
+
+## Review Dimensions
+Evaluate the changes across these dimensions (focus on what's relevant):
+
+1. **Goal alignment**: Do the changes accomplish all goals from spec.md? Anything missing or off-target?
+2. **Defects**: Logic bugs, missing error handling, boundary condition issues, incorrect behavior.
+3. **Completeness**: Files that should have been changed but weren't? Missing tests, types, imports, exports?
+4. **Consistency**: Do changes follow the project's existing patterns, naming conventions, and code style?
+5. **Security**: Hardcoded secrets, injection vulnerabilities, unsafe operations.
+6. **Rules compliance**: (Skip this dimension if no dev rules were provided.) Do changes follow the per-layer dev rules? Flag violations of framework conventions, naming patterns, state management, or other rules defined for that layer.
+
+## Output Format
+Respond with EXACTLY this format:
+
+### Result: PASS | NEEDS_FIXES
+
+### Findings
+(If PASS, write "No issues found.")
+
+#### Finding N
+- **Severity**: high | medium | low
+- **Dimension**: goal-alignment | defect | completeness | consistency | security | rules-compliance
+- **Location**: filepath:line (or "project-level")
+- **Problem**: What is wrong and why it matters
+- **Suggestion**: Recommended fix approach
+- **Verification**: How to confirm the fix is correct
+
+### Summary
+One to two sentences about the overall state of the changes.
+```
+
+## Round Context
+
+- Round 1: "This is the first review. Examine all changes comprehensively."
+- Round 2+: "Previous round found issues that were fixed. Focus on: (1) whether previous fixes are correct, (2) whether fixes introduced new problems, (3) any remaining issues. Do not re-report issues that have already been fixed."

package/bundled/skills-windows/prizmkit-code-review/scripts/check_loop.py

@@ -0,0 +1,186 @@
+#!/usr/bin/env python3
+"""
+Loop Exit Gatekeeper for prizmkit-code-review skill.
+
+Stateless design: all loop state is passed via stdin and returned via stdout.
+The caller (AI model) tracks `findings_history` and `max_rounds` between calls.
+No runtime files are created — the script is a pure function over JSON.
+
+The model supplies the current round in each call — the script does not auto-increment
+rounds, because the gate is called twice per loop iteration (after Reviewer returns
+and after Main Agent filters), and only the model knows when a full cycle completes.
+
+Usage:
+    echo '{"reviewer_result":"NEEDS_FIXES","accepted_count":2,"findings_count":5,"round":1,"findings_history":[],"max_rounds":3,"filtering_done":true}' | python3 check_loop.py
+
+Input JSON schema:
+    {
+        "reviewer_result": "PASS" | "NEEDS_FIXES",
+        "accepted_count": int,
+        "findings_count": int,
+        "round": int,
+        "findings_history": [int, ...],
+        "max_rounds": int,
+        "filtering_done": bool
+    }
+
+Output JSON schema:
+    {
+        "endLoop": bool,
+        "reason": str,
+        "verdict": "PASS" | "NEEDS_FIXES" | null,
+        "round": int,
+        "maxRounds": int,
+        "divergenceWarning": bool,
+        "findings_history": [int, ...]
+    }
+
+Exit conditions (checked in order):
+    1. Reviewer returned PASS          → endLoop=true, verdict=PASS
+    2. NEEDS_FIXES before filtering    → endLoop=false, wait for filtering
+    3. Filtered findings all rejected  → endLoop=true, verdict=PASS
+    4. Max rounds reached after filtering → endLoop=true, verdict=NEEDS_FIXES
+    5. Otherwise                       → endLoop=false
+
+Divergence detection:
+    If findings_count strictly increases for 3 consecutive rounds, set divergenceWarning=true.
+    This is a warning only — it does not force loop exit.
+"""
+
+import json
+import sys
+
+DEFAULT_MAX_ROUNDS = 3
+
+
+def check_divergence(findings_history):
+    """Return True if the last 3 entries in findings_history are strictly increasing."""
+    if len(findings_history) < 3:
+        return False
+    last_three = findings_history[-3:]
+    return last_three[0] < last_three[1] < last_three[2]
+
+
+def record_findings_count(findings_history, current_round, findings_count):
+    """Record findings_count once per round index, updating duplicate calls for the same round."""
+    if current_round <= 0:
+        return findings_history
+
+    target_index = current_round - 1
+    while len(findings_history) < target_index:
+        findings_history.append(0)
+
+    if len(findings_history) == target_index:
+        findings_history.append(findings_count)
+    else:
+        findings_history[target_index] = findings_count
+
+    return findings_history
+
+
+def check_exit_condition(data):
+    """Determine whether the loop should exit. Pure function — no side effects.
+
+    Round is model-supplied — the script does not auto-increment it because
+    the gate is called twice per loop iteration (after Step 2 and Step 3).
+    """
+    reviewer_result = data.get("reviewer_result")
+    accepted_count = data.get("accepted_count", 0)
+    findings_count = data.get("findings_count", 0)
+    current_round = data.get("round", 0)
+    findings_history = list(data.get("findings_history", []))
+    max_rounds = data.get("max_rounds", DEFAULT_MAX_ROUNDS)
+    filtering_done = data.get("filtering_done", reviewer_result == "PASS")
+
+    findings_history = record_findings_count(
+        findings_history, current_round, findings_count
+    )
+    divergence_warning = check_divergence(findings_history)
+
+    # Condition 1: Reviewer returned PASS
+    if reviewer_result == "PASS":
+        return {
+            "endLoop": True,
+            "reason": f"Round {current_round}: Reviewer returned PASS",
+            "verdict": "PASS",
+            "round": current_round,
+            "maxRounds": max_rounds,
+            "divergenceWarning": False,
+            "findings_history": findings_history,
+        }
+
+    # Condition 2: Reviewer returned findings, but filtering has not happened yet
+    if reviewer_result == "NEEDS_FIXES" and not filtering_done:
+        return {
+            "endLoop": False,
+            "reason": f"Round {current_round}: reviewer returned findings; filter before applying exit conditions",
+            "verdict": None,
+            "round": current_round,
+            "maxRounds": max_rounds,
+            "divergenceWarning": divergence_warning,
+            "findings_history": findings_history,
+        }
+
+    # Condition 3: All findings rejected after filtering
+    if reviewer_result == "NEEDS_FIXES" and accepted_count == 0:
+        return {
+            "endLoop": True,
+            "reason": f"Round {current_round}: all findings rejected by main agent",
+            "verdict": "PASS",
+            "round": current_round,
+            "maxRounds": max_rounds,
+            "divergenceWarning": False,
+            "findings_history": findings_history,
+        }
+
+    # Condition 4: Max rounds reached
+    if current_round >= max_rounds:
+        return {
+            "endLoop": True,
+            "reason": f"Hard limit: max {max_rounds} rounds reached",
+            "verdict": "NEEDS_FIXES",
+            "round": current_round,
+            "maxRounds": max_rounds,
+            "divergenceWarning": divergence_warning,
+            "findings_history": findings_history,
+        }
+
+    # Condition 5: Continue loop
+    next_round = current_round + 1
+    return {
+        "endLoop": False,
+        "reason": f"Round {current_round}: {accepted_count} findings accepted, continuing to round {next_round}",
+        "verdict": None,
+        "round": current_round,
+        "maxRounds": max_rounds,
+        "divergenceWarning": divergence_warning,
+        "findings_history": findings_history,
+    }
+
+
+def main():
+    # Read input from stdin
+    try:
+        data = json.load(sys.stdin)
+    except json.JSONDecodeError as e:
+        print(
+            json.dumps(
+                {
+                    "endLoop": False,
+                    "reason": f"Invalid JSON input: {e}",
+                    "verdict": None,
+                    "round": 0,
+                    "maxRounds": DEFAULT_MAX_ROUNDS,
+                    "divergenceWarning": False,
+                    "findings_history": [],
+                }
+            )
+        )
+        sys.exit(1)
+
+    result = check_exit_condition(data)
+    print(json.dumps(result))
+
+
+if __name__ == "__main__":
+    main()

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

@@ -10,6 +10,12 @@ description: "Pure git commit workflow with safety checks. Stages files, generat
 - After `/prizmkit-retrospective` has finished architecture sync
 - The UserPromptSubmit hook will remind to use this skill when commit intent is detected
 
+### When NOT to Use
+- No uncommitted changes exist — nothing to commit
+- .prizmkit/prizm-docs/ not synced — run /prizmkit-retrospective first
+- Code review not passed in pipeline mode — run /prizmkit-code-review first
+- Mid-merge conflict resolution — handle manually with git
+
 **PRECONDITION:**
 
 | Required State | Check | If Missing |

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

@@ -14,6 +14,51 @@ Three possible outcomes depending on what's supported:
 
 When invited, behave as a deployment engineer. Ask until you understand what is being deployed, where it runs, how it is built, how it starts, what secrets it needs, how traffic reaches it, and how health is checked.
 
+### When to Use
+- User says "deploy", "ship it", "take this live", "deploy to Vercel", "deploy to my server"
+- User wants to check deploy status, view logs, restart app, rollback
+- First-time deployment configuration or repair
+- Any deployment, hosting, or server operation question
+
+### When NOT to Use
+- Project has no code to deploy (empty/scaffold project)
+- Local dev environment startup — use the project's dev scripts instead
+- Purely CI/CD pipeline debugging unrelated to deployment
+- User wants to edit application code — use /prizmkit-plan and /prizmkit-implement
+
+## Data Safety Gate
+
+Before executing any command that could **irreversibly destroy, overwrite, or modify data**, pause and get explicit user confirmation. This is a hard gate — the cost of a false negative (losing real data) is catastrophic, while asking one extra question costs nothing.
+
+### Detection
+
+Before running any shell command, scan it for these patterns:
+
+| Category | Dangerous patterns | What's at risk |
+|----------|-------------------|----------------|
+| Database schema | `prisma db push --force-reset`, `prisma db push --accept-data-loss`, `prisma migrate reset`, `prisma migrate dev --create-only` | All existing data dropped, schema reset |
+| Database data | `DROP TABLE`, `DROP DATABASE`, `TRUNCATE`, `DELETE FROM` without `WHERE`, `UPDATE` without `WHERE` | Data deletion or corruption |
+| File system | `rm -rf`, `> /etc/`, overwriting existing configs without backup | Config loss, system breakage |
+| Cloud resources | `terraform destroy`, `kubectl delete`, cloud resource deletion, S3 bucket removal | Infrastructure/service loss |
+
+### Confirmation Flow
+
+When a dangerous pattern is detected:
+
+1. **Stop.** Do not execute. Do not ask "should I proceed?" while already running the command.
+2. **Explain** what the command will do and what data will be lost, in plain language.
+3. **Ask** an explicit yes/no question. Accept only a clear "yes" or equivalent — ambiguous responses ("sure, I guess", "ok go ahead") count as "no" when the consequence is data loss.
+4. **Only proceed** on unambiguous consent. If the user says anything other than a clear affirmative, abort.
+5. **Record** the confirmation decision and the command that was run in deploy history.
+
+### Headless Mode
+
+If a destructive data operation is detected in headless mode, **refuse and exit** with `DATA_SAFETY_DENIED`. Data destruction must never happen without human oversight — an unattended pipeline that runs `--force-reset` could wipe a production database with no one watching.
+
+### Examples
+
+Read `${SKILL_DIR}/references/data-safety-examples.md` for concrete few-shot examples of dangerous commands caught by this gate, including the correct and incorrect ways to handle them.
+
 ## Deployment Discovery
 
 Before doing anything else, discover what you're deploying and where. This phase routes the request to the right adapter or fallback. It runs regardless of mode (interactive or headless), but interactive mode may ask questions; headless mode reads from existing config and exits with `NEEDS_INPUT` if critical details are missing.
@@ -245,39 +290,7 @@ Write `deploy.config.json` with all collected values and `validated: {}` stubs f
 
 Before first deployment, bootstrap the server. 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.
+Read `${SKILL_DIR}/references/ssh-bootstrap-flow.md` for the full bootstrap procedure (preflight, check-and-install, user/dir setup, PM2 startup, deploy key). When the bootstrap reaches firewall or database steps, it routes to `references/firewall-setup.md` and `references/database-setup.md`. Key rules: bootstrap operations must be idempotent, existing config files must be backed up before modification, and each step's result must be recorded.
 
 ### SSH: Direct Upload Deployment
 
@@ -294,7 +307,7 @@ After generating the workflow, verify: the first `git push` to the configured br
 Before SSL, check if the user has a domain pointing to the server.
 
 1. Ask: "你有没有域名要绑定到这个项目？" If no domain → skip DNS + SSL, note in deploy.md.
-2. Check DNS: use `Resolve-DnsName <domain> -Type A` to resolve locally. If resolved → proceed to SSL.
+2. Check DNS: `dig +short <domain> A`. If resolved → proceed to SSL.
 3. If not resolved: show the user DNS setup instructions. Full procedure in `references/dns-setup.md`.
 
 ### SSH: SSL/HTTPS Configuration
@@ -310,37 +323,7 @@ Full procedure in `references/ssl-setup.md`.
 
 ### 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 "没有新的代码变更。确定要重新部署吗？"
-
-**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).
+Read `${SKILL_DIR}/references/ssh-execution-flow.md` for the full 5-group pipeline: pre-flight, fetch & build, stage & health check, switch & verify, cleanup & record. Key invariant: if any step before traffic switch fails, STOP — do not touch the live version.
 
 ### SSH: Blue/Green PM2 + Nginx Strategy
 
@@ -405,14 +388,7 @@ Deploy history records secret presence metadata only (e.g., `{"SUPABASE_SERVICE_
 
 ### SSH: Existing Deployment Takeover
 
-When deploying to a server that already has deployment assets:
-
-1. Detect: existing `/var/www/<project>` directory, existing PM2 processes with similar names, Nginx config referencing the same domain/IP, port conflicts.
-2. 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.
-3. Record takeover decision and validation results in config and history.
+When deploying to a server that already has deployment assets, read `${SKILL_DIR}/references/ssh-takeover.md` for the detection procedure and takeover decision flow. Record takeover decision and validation results in config and history.
 
 ### SSH: Nginx Management
 

package/bundled/skills-windows/prizmkit-deploy/references/data-safety-examples.md

@@ -0,0 +1,120 @@
+# Data Safety Examples
+
+Few-shot examples for the Data Safety Gate in `/prizmkit-deploy`. Read this file when a dangerous command pattern is detected — it shows the correct confirmation flow and illustrates what happens when the gate is skipped.
+
+## Example 1: Prisma Force Reset (the incident)
+
+**Context:** User runs `/prizmkit-deploy` to deploy a Next.js + Prisma project. During database setup, the model needs to sync the Prisma schema with the database.
+
+**Wrong — skipping the gate:**
+```
+Model: I'll sync your database schema now.
+$ prisma db push --force-reset --accept-schema
+→ All tables dropped. All production data lost. No backup. No confirmation.
+```
+This happened in production. `--force-reset` drops and recreates every table. `--accept-schema` bypasses Prisma's own confirmation prompt. The model ran both flags without asking the user whether existing data should be preserved.
+
+**Correct — with the safety gate:**
+```
+Model: I detected that your database needs a schema sync. However, before I do anything:
+
+WARNING: The Prisma schema has changes that could affect existing data.
+- New tables to create: 0
+- Tables that may be modified: 2 (users, orders)
+- If I run `prisma db push --force-reset`, ALL existing data will be DESTROYED.
+
+Options:
+1. prisma db push (safe — only adds missing tables/columns, no data loss)
+2. prisma db push --force-reset (DANGEROUS — drops and recreates all tables, all data lost)
+3. prisma migrate dev (creates a migration file you can review first)
+
+Which approach do you want? (1/2/3)
+```
+
+The `--accept-schema` flag should never be used — it suppresses Prisma's own built-in safety prompts that protect the user.
+
+## Example 2: Prisma Migrate Reset
+
+**Context:** User wants to reset their dev database to a clean state for testing.
+
+**Correct detection and confirmation:**
+```
+Model: `prisma migrate reset` will:
+- Drop the entire database
+- Recreate it from scratch
+- Run all migrations
+
+This is a DESTRUCTIVE operation. All data in the database will be permanently lost.
+
+Are you sure this is a dev/test database with no important data? (yes/no)
+```
+
+In production or any environment with real data: refuse immediately. This command should only run in dev with explicit user confirmation.
+
+## Example 3: Raw SQL Data Modification
+
+**Context:** During deployment, the model considers running a SQL command to fix a data issue.
+
+**Correct detection and confirmation:**
+```
+Model: To fix the duplicate user records, I would run:
+```sql
+DELETE FROM users WHERE email IS NULL AND created_at < '2025-01-01';
+```
+
+This would delete approximately 340 user records. BEFORE I run this:
+
+1. Would you like me to run a SELECT first to show you exactly which rows would be deleted?
+2. Do you want to back up the users table before deletion?
+3. Confirm: Delete these 340 records? (yes/no)
+
+I will not proceed without your explicit confirmation.
+```
+
+## Example 4: Overwriting Production Configuration
+
+**Context:** During bootstrap, the model needs to write an Nginx config, but one already exists at the target path.
+
+**Correct detection and confirmation:**
+```
+Model: Found existing Nginx config at /etc/nginx/sites-enabled/myapp.
+
+This file is NOT managed by PrizmKit (no `# PrizmKit Managed:` marker).
+Overwriting it could break existing site configuration.
+
+Options:
+1. Back up the existing config to /etc/nginx/sites-enabled/myapp.bak, then write new config
+2. Create new config alongside existing one with a different name
+3. Skip — keep the existing config as-is
+
+Which approach? (1/2/3)
+```
+
+## Example 5: Confirmation Dialogue Template
+
+When the gate triggers, use this dialogue structure:
+
+```
+============================================================
+DATA SAFETY GATE — DESTRUCTIVE OPERATION DETECTED
+============================================================
+
+Command: <the dangerous command>
+Risk level: HIGH / CRITICAL
+What will be lost: <plain-language description of affected data>
+
+Current state:
+- Database: <name>, <size>, <table count>
+- Affected tables: <list>
+- Last backup: <date if known, or "unknown — backup recommended">
+
+Recommended safe approach:
+<alternative if one exists>
+
+Do you want to proceed with this destructive operation?
+Type "yes, I understand the data will be lost" to confirm.
+Any other response will abort.
+============================================================
+```
+
+This format forces the user to read and acknowledge the risk before proceeding.

package/bundled/skills-windows/prizmkit-deploy/references/direct-upload.md

@@ -10,9 +10,9 @@ Read this file when `deployStrategy` is `"direct-upload"`. The AI handles the bu
 
 ## Transfer phase (SCP)
 
-```powershell
-scp.exe -P <port> deploy-<releaseId>.tar.gz <runtimeUser>@<host>:/var/www/<project>/releases/
-ssh.exe <runtimeUser>@<host> "cd /var/www/<project>/releases && mkdir <releaseId> && tar xzf deploy-<releaseId>.tar.gz -C <releaseId>"
+```
+scp -P <port> deploy-<releaseId>.tar.gz <runtimeUser>@<host>:/var/www/<project>/releases/
+ssh <runtimeUser>@<host> "cd /var/www/<project>/releases && mkdir <releaseId> && tar xzf deploy-<releaseId>.tar.gz -C <releaseId>"
 ```
 
 ## Server-side setup

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

@@ -0,0 +1,49 @@
+# 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

@@ -0,0 +1,41 @@
+# 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 "没有新的代码变更。确定要重新部署吗？"
+
+## 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

@@ -0,0 +1,20 @@
+# 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.