prizmkit 1.1.154 → 1.1.156

package/bundled/skills/prizmkit-deploy/references/cloud-platform-deploy.md

@@ -40,7 +40,23 @@ Platform rollback is instant — no release-based rollback needed.
 
 ### Vercel
 
-Vercel auto-detects Next.js projects — no config file required for basic deployments. Generate `vercel.json` only for custom rewrites, redirects, or headers.
+Vercel auto-detects Next.js projects — no config file is generated for basic deployments. When confirmed custom routing or static build settings require `vercel.json`, start from this minimal platform-native shape and include only established keys:
+
+```json
+{
+  "$schema": "https://openapi.vercel.sh/vercel.json",
+  "buildCommand": "npm run build",
+  "outputDirectory": "dist",
+  "rewrites": [
+    {
+      "source": "/(.*)",
+      "destination": "/index.html"
+    }
+  ]
+}
+```
+
+Omit `buildCommand`/`outputDirectory` when framework detection owns them, and omit `rewrites` unless the application actually needs SPA fallback or a confirmed route. Validate generated configuration with the installed Vercel CLI before deployment.
 
 Key behaviors:
 - Next.js: framework auto-detected, build command and output directory inferred automatically
@@ -77,7 +93,7 @@ app = "<app-name>"
 primary_region = "lhr"
 
 [build]
-  builder = "dockerfile"
+  dockerfile = "Dockerfile"
 
 [http_service]
   internal_port = 3000
@@ -85,7 +101,7 @@ primary_region = "lhr"
 ```
 
 Key behaviors:
-- Builder: `dockerfile` (default, uses Dockerfile) or `static` (static site hosting)
+- Build source: `dockerfile = "Dockerfile"` for project-owned images, or a confirmed platform-supported image/build configuration; static sites still need a valid serving image rather than an invented `static` builder value
 - Secrets: `fly secrets set <KEY>=<VALUE>` for runtime environment variables
 - Scale: `fly scale count <N>` to adjust VM instances
 - Volumes: for persistent data, configure `[mounts]` in fly.toml

package/bundled/skills/prizmkit-deploy/references/database-setup.md

@@ -12,12 +12,13 @@ During Discovery Step 1 (Project Detection), database drivers were already scann
 
 ## Secrets file safety
 
-Before writing `.prizmkit/deploy/secrets.local.json`:
+Before writing `.prizmkit/deploy/secrets.local.env`:
 
-1. Verify `.gitignore` or an equivalent ignore rule covers `.prizmkit/deploy/secrets.local.json` and any `.prizmkit/deploy/*.local.json` pattern used by the project.
-2. If the ignore rule is missing, pause and add or request the ignore rule before writing secrets.
-3. Set the secrets file permissions to current-user read/write only, for example `chmod 600 .prizmkit/deploy/secrets.local.json` on POSIX systems.
-4. Record only presence metadata in deploy config, docs, reports, and history. Never copy raw passwords, connection strings, passphrases, decryption keys, unsalted hashes, or full env var values into committed files.
+1. Verify `.gitignore` or an equivalent ignore rule covers the exact `.prizmkit/deploy/secrets.local.env` path or a compatible `.prizmkit/deploy/*.local.env` pattern.
+2. If the ignore rule is missing, pause and add or request it before writing secrets.
+3. Create/update the file with restrictive creation permissions (for example `umask 077` on POSIX), atomically replace it without widening permissions, set mode `600`, and verify it is ignored by Git.
+4. Use dotenv syntax: one `KEY=value` assignment per line, UTF-8, no JSON braces or commas. Preserve unrelated existing assignments and reject malformed or duplicate keys.
+5. Record only presence metadata in deploy config, docs, reports, and history. Never copy raw passwords, connection strings, passphrases, decryption keys, unsalted hashes, or full env var values into committed files.
 
 ```
 apt-get install -y postgresql postgresql-contrib
@@ -26,10 +27,19 @@ sudo -u postgres psql -c "CREATE USER <project> WITH PASSWORD '<random-password>
 sudo -u postgres psql -c "GRANT ALL ON DATABASE <project> TO <project>;"
 ```
 
-- Generate a secure random password (32 chars, alphanumeric + symbols).
-- Write the connection string to `.prizmkit/deploy/secrets.local.json`: `DATABASE_URL=postgresql://<project>:<password>@localhost:5432/<project>`.
-- Set `.prizmkit/deploy/secrets.local.json` permissions to current-user read/write only after writing.
-- In deploy.md, write: "PostgreSQL installed, connection info recorded in `.prizmkit/deploy/secrets.local.json` (gitignored; raw value not committed)".
+- Generate a cryptographically secure 32-character URL-safe password using letters, digits, `_`, and `-`, with no whitespace, quotes, `#`, or `=`.
+- Write or replace the single dotenv assignment `DATABASE_URL=postgresql://<project>:<password>@localhost:5432/<project>` in `.prizmkit/deploy/secrets.local.env`.
+- Re-verify ignore status and current-user-only permissions after atomic replacement.
+- In `deploy.md`, record only: "PostgreSQL connection information is stored in ignored local secret storage; raw values are not committed."
+
+## Legacy Local-Secret Migration
+
+If `.prizmkit/deploy/secrets.local.json` already exists from an earlier installation, treat the filename as legacy input only, never as a current output:
+
+1. Verify it is ignored by Git and restricted to the current user before reading it.
+2. Detect either a JSON object containing string values or strict dotenv `KEY=value` lines; reject mixed, malformed, duplicate, or non-string content without printing values.
+3. Convert the validated assignments to `.prizmkit/deploy/secrets.local.env` through the restrictive atomic-write rules above.
+4. Compare key names and presence only. Remove the legacy file only after successful conversion and explicit user confirmation; otherwise leave it untouched and report migration pending.
 
 ## MySQL setup (future)
 
@@ -44,12 +54,12 @@ redis-cli CONFIG REWRITE
 ```
 
 - Bind to localhost only (modify `/etc/redis/redis.conf` if needed).
-- Write `REDIS_URL=redis://:<password>@localhost:6379` to `.prizmkit/deploy/secrets.local.json`.
-- Set `.prizmkit/deploy/secrets.local.json` permissions to current-user read/write only after writing.
+- Write or replace the single dotenv assignment `REDIS_URL=redis://:<password>@localhost:6379` in `.prizmkit/deploy/secrets.local.env` using the same URL-safe password and atomic permission rules.
+- Re-verify ignore status and current-user-only permissions after replacement.
 
 ## Security notes
 
 - Never write database passwords to deploy.md, because deploy.md may be committed to git and passwords would leak.
-- Passwords stored in `.prizmkit/deploy/secrets.local.json` only after verifying the file is ignored by git and locked down to current-user read/write permissions.
+- Passwords are stored only in `.prizmkit/deploy/secrets.local.env` after verifying the file is ignored by Git and locked down to current-user read/write permissions.
 - Default: database binds to localhost, no external access, because most indie projects only need local connections.
 - Record a `"database-setup"` event in deploy history (presence metadata only, no passwords).

package/bundled/skills/prizmkit-deploy/references/deploy-config-schema.md

@@ -26,12 +26,14 @@ This file is the machine-readable deployment configuration. Always read it befor
 {
   "releaseRetention": 5,
   "credentialMode": "ai-assisted|user-managed",
-  "secretStorage": "ask-every-time|encrypted-local|plaintext-local|user-managed-on-server-only",
+  "secretStorage": "ask-every-time|ignored-local-env|user-managed-on-server-only",
   "rollbackOnFailure": true,
   "headlessDefaultEnvironment": "test"
 }
 ```
 
+`ignored-local-env` means `.prizmkit/deploy/secrets.local.env` after exact ignore and permission verification. Legacy `plaintext-local` may be migrated only through the local-secret migration contract. Legacy `encrypted-local` is unsupported because this Skill has no encryption/key-management implementation; block deployment and require the user to select a supported mode without exposing secret values.
+
 ## environments
 
 Keyed by environment name. Each entry:

package/bundled/skills/prizmkit-deploy/references/deploy-history-schema.md

@@ -1,17 +1,18 @@
 # Deploy History Record Schema
 
-Each event in `.prizmkit/deploy/deploy-history/<id>.json` follows this schema:
+Each immutable event is written atomically to `.prizmkit/deploy/deploy-history/<eventId>.json`. The filename stem must equal the JSON `eventId` exactly.
 
 ```json
 {
-  "eventId": "<releaseId or event id>",
-  "eventType": "deploy|rollback|status|validation|failed-deploy|user-aborted|takeover|adapter-gap",
-  "timestamp": "<ISO 8601>",
+  "eventId": "deploy-20260430T142233Z-22783a3",
+  "eventType": "deploy|rollback|status|validation|failed-deploy|user-aborted|takeover|adapter-gap|database-setup",
+  "timestamp": "<ISO 8601 UTC>",
+  "releaseId": "20260430T142233Z-22783a3 or null",
   "serverId": "<server id from deploy.config.json>",
   "appIds": ["<app ids involved>"],
   "branch": "<git branch>",
   "commitSha": "<full or short commit SHA>",
-  "releasePath": "<full server path, e.g. /var/www/prizm-ideas/releases/20260430-22783a3>",
+  "releasePath": "<full server path, e.g. /var/www/prizm-ideas/releases/20260430T142233Z-22783a3>",
   "previousReleasePath": "<previous release path or null for first deploy>",
   "targetPort": 3101,
   "targetColor": "blue|green",
@@ -45,9 +46,24 @@ Each event in `.prizmkit/deploy/deploy-history/<id>.json` follows this schema:
 }
 ```
 
+## Event and File Identity
+
+Generate every `eventId` as:
+
+```text
+<event-type>-<UTC-compact-timestamp>-<short-sha-or-none>[-NN]
+```
+
+Rules:
+
+- `UTC-compact-timestamp` is the event time formatted `YYYYMMDDTHHMMSSZ`.
+- `short-sha` is the lowercase 7-12 hexadecimal commit prefix when a commit exists; otherwise use literal `none`.
+- If the candidate filename already exists, append the lowest available two-digit suffix from `-01` through `-99`; never overwrite a history record. If all suffixes are occupied, stop with a recording error.
+- Use the exact event ID as the filename stem. Example: `rollback-20260430T151000Z-22783a3.json`.
+- `releaseId` is a separate deployment/release-directory identity. Set it to the affected release for deploy, failed-deploy, and rollback events; otherwise use `null` when no release applies.
+
 ## Field Notes
 
-- `eventId`: Use `<releaseId>` for deploy events, `<releaseId>-rollback` for rollbacks.
 - `eventType`: Use `failed-deploy` when deploy fails before traffic switch, `deploy` when it succeeds. Use `adapter-gap` when no adapter exists for the detected project type or target — include `detectedProjectType`, `missingAdapter`, and `fallbackOutput` in the record.
 - `phases`: Only include phases that were attempted. Skip phases that were never reached.
 - `healthCheckResults`: Include all configured health checks. `pass` = actual status matches one of the expected status codes.

package/bundled/skills/prizmkit-deploy/references/deploy-metadata-schema.json

@@ -0,0 +1,49 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "PrizmKit Server Deployment Metadata",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "schema_version",
+    "activeColor",
+    "activePort",
+    "lastReleaseId",
+    "lastOperationEventId",
+    "updatedAt"
+  ],
+  "properties": {
+    "schema_version": {
+      "const": 1
+    },
+    "activeColor": {
+      "enum": ["blue", "green"]
+    },
+    "activePort": {
+      "type": "integer",
+      "minimum": 1,
+      "maximum": 65535
+    },
+    "lastReleaseId": {
+      "type": "string",
+      "pattern": "^[0-9]{8}T[0-9]{6}Z-[0-9a-f]{7,12}(?:-[0-9]{2})?$"
+    },
+    "lastOperationEventId": {
+      "type": "string",
+      "pattern": "^[a-z][a-z-]*-[0-9]{8}T[0-9]{6}Z-(?:[0-9a-f]{7,12}|none)(?:-[0-9]{2})?$"
+    },
+    "updatedAt": {
+      "type": "string",
+      "format": "date-time"
+    }
+  },
+  "examples": [
+    {
+      "schema_version": 1,
+      "activeColor": "blue",
+      "activePort": 3101,
+      "lastReleaseId": "20260430T142233Z-22783a3",
+      "lastOperationEventId": "deploy-20260430T142233Z-22783a3",
+      "updatedAt": "2026-04-30T14:22:33Z"
+    }
+  ]
+}

package/bundled/skills/prizmkit-deploy/references/live-validation-notes.md

@@ -12,7 +12,7 @@ These findings from the first PrizmKit deployment (PrizmIdeas) guide edge-case h
 
 5. **`pm2 startup` needs explicit PATH.** Always use `env PATH=$PATH:/usr/bin pm2 startup ...`, because the pm2 binary may not be on root's default PATH.
 
-6. **Persist deploy metadata on server.** Write `activeColor`, `activePort`, `lastReleaseId`, `lastDeployTimestamp` to `shared/deploy-metadata.json`, because subsequent deploys and rollbacks depend on knowing the current active slot.
+6. **Persist deploy metadata on server.** After public health and history recording succeed, atomically write `shared/deploy-metadata.json` from `${SKILL_DIR}/references/deploy-metadata-schema.json`, including active color/port, release identity, operation event identity, and UTC update time. Subsequent deploys and rollbacks depend on this active-slot record.
 
 7. **Detect first deployment.** If no `current` symlink and no PM2 process for the app, skip rollback safety checks and use blue (3101) as initial color.
 

package/bundled/skills/prizmkit-deploy/references/pending-input-schema.json

@@ -0,0 +1,164 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "PrizmKit Deployment Pending Input",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "schema_version",
+    "result",
+    "operation",
+    "environment",
+    "known_context",
+    "questions"
+  ],
+  "properties": {
+    "schema_version": {
+      "const": 1
+    },
+    "result": {
+      "const": "NEEDS_INPUT"
+    },
+    "operation": {
+      "enum": [
+        "configure",
+        "deploy",
+        "status",
+        "logs",
+        "restart",
+        "rollback",
+        "health",
+        "history",
+        "validate"
+      ]
+    },
+    "environment": {
+      "enum": ["dev", "test", null]
+    },
+    "known_context": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["project_type", "target", "config_path"],
+      "properties": {
+        "project_type": {
+          "type": ["string", "null"]
+        },
+        "target": {
+          "type": ["string", "null"]
+        },
+        "config_path": {
+          "const": ".prizmkit/deploy/deploy.config.json"
+        }
+      }
+    },
+    "questions": {
+      "type": "array",
+      "minItems": 1,
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": [
+          "id",
+          "prompt",
+          "answer_type",
+          "required",
+          "config_pointer",
+          "options"
+        ],
+        "properties": {
+          "id": {
+            "type": "string",
+            "pattern": "^[a-z][a-z0-9_]{0,63}$"
+          },
+          "prompt": {
+            "type": "string",
+            "minLength": 1
+          },
+          "answer_type": {
+            "enum": ["text", "single_choice", "multi_choice", "boolean", "integer"]
+          },
+          "required": {
+            "type": "boolean"
+          },
+          "config_pointer": {
+            "type": "string",
+            "pattern": "^/(?:[^~/]|~[01])+(?:/(?:[^~/]|~[01])*)*$"
+          },
+          "options": {
+            "type": "array",
+            "items": {
+              "type": "object",
+              "additionalProperties": false,
+              "required": ["value", "label"],
+              "properties": {
+                "value": {
+                  "type": ["string", "number", "boolean"]
+                },
+                "label": {
+                  "type": "string",
+                  "minLength": 1
+                }
+              }
+            }
+          }
+        },
+        "allOf": [
+          {
+            "if": {
+              "properties": {
+                "answer_type": {
+                  "enum": ["single_choice", "multi_choice"]
+                }
+              }
+            },
+            "then": {
+              "properties": {
+                "options": {
+                  "minItems": 1
+                }
+              }
+            },
+            "else": {
+              "properties": {
+                "options": {
+                  "maxItems": 0
+                }
+              }
+            }
+          }
+        ]
+      }
+    }
+  },
+  "examples": [
+    {
+      "schema_version": 1,
+      "result": "NEEDS_INPUT",
+      "operation": "configure",
+      "environment": null,
+      "known_context": {
+        "project_type": "Node.js",
+        "target": null,
+        "config_path": ".prizmkit/deploy/deploy.config.json"
+      },
+      "questions": [
+        {
+          "id": "deployment_target",
+          "prompt": "Which deployment target should this project use?",
+          "answer_type": "single_choice",
+          "required": true,
+          "config_pointer": "/deploymentMode",
+          "options": [
+            {
+              "value": "ssh",
+              "label": "SSH Linux server"
+            },
+            {
+              "value": "docker",
+              "label": "Docker"
+            }
+          ]
+        }
+      ]
+    }
+  ]
+}

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

@@ -47,7 +47,7 @@ Server-side layout:
   deploy-logs/
 ```
 
-`shared/.env.production` must be mode `600` and owned by the runtime user.
+`shared/.env.production` is strict UTF-8 dotenv data with one unique `KEY=value` assignment per line; update it atomically, keep mode `600`, and require runtime-user ownership. `shared/deploy-metadata.json` must conform to `${SKILL_DIR}/references/deploy-metadata-schema.json`, be written atomically after successful live verification, and contain no secrets.
 
 ## 3. First-Run Configuration Wizard
 
@@ -59,7 +59,7 @@ Collect:
 2. Repository access only for `ci-cd-pull`: Git URL, branch, deploy-key or other auth.
 3. App configuration: app id, path, package manager, install/build/start commands, blue/green port pair, health checks.
 4. Environment variables: scan source for env references, ask for values or storage strategy.
-5. Persist `deploy.config.json` and `deploy.md`.
+5. Persist `deploy.config.json` and render/update `deploy.md` from `${SKILL_DIR}/assets/deploy-document-template.md`.
 
 Validate SSH immediately with a harmless connectivity command before collecting deeper config. If SSH fails, stop and fix connectivity first.
 
@@ -132,7 +132,7 @@ Failure rules:
 ## 8. Blue/Green PM2 + Nginx Invariants
 
 - Default ports: blue `3101`, green `3102`.
-- Active color is persisted in `shared/deploy-metadata.json`.
+- Active color is persisted in `shared/deploy-metadata.json` using `${SKILL_DIR}/references/deploy-metadata-schema.json`.
 - PM2 process name: `<project>-<app>-<color>`.
 - Nginx managed blocks include `# PrizmKit Managed: <project> — DO NOT EDIT MANUALLY`.
 - First creation or modification of non-PrizmKit Nginx config requires user confirmation.
@@ -157,8 +157,9 @@ Steps:
 3. Start PM2 on the target release/port.
 4. Update Nginx upstream.
 5. Run `nginx -t` and reload.
-6. Run health checks.
-7. Write rollback event.
+6. Run public health checks; if they fail, restore the prior verified upstream.
+7. Allocate and atomically write the rollback history event through `${SKILL_DIR}/references/deploy-history-schema.md`.
+8. Atomically update `shared/deploy-metadata.json` through `${SKILL_DIR}/references/deploy-metadata-schema.json` with the restored release/color/port and rollback event identity.
 
 If no previous release exists, state clearly that rollback is not possible.
 
@@ -177,13 +178,13 @@ Run app commands as `runtimeUser`.
 Supported storage modes:
 
 - `ask-every-time`
-- `encrypted-local`
-- `plaintext-local`
+- `ignored-local-env`
 - `user-managed-on-server-only`
 
 Rules:
 
-- `plaintext-local` must be gitignored; stop if tracked by git.
+- `ignored-local-env` uses `.prizmkit/deploy/secrets.local.env`, must be ignored by Git and current-user-only, and follows `${SKILL_DIR}/references/database-setup.md` dotenv/migration safety.
+- Legacy `plaintext-local` requires explicit migration to `ignored-local-env`; legacy `encrypted-local` is unsupported and requires user selection of a supported mode before deployment.
 - Server runtime secrets live in `shared/.env.production` with mode `600`.
 - Deploy history records secret presence metadata only.
 - Never record raw secret values, passphrases, decryption keys, or unsalted hashes.

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

@@ -9,7 +9,7 @@ Show what will be deployed using `git log --oneline <last-deployed-commit>..HEAD
 ## Group 1 — Pre-flight & Prepare
 
 - Verify SSH, runtime user, tools, deploy key, port availability.
-- Generate `releaseId`: `YYYYMMDD-<short-commit-sha>`. Create `releases/<releaseId>`.
+- Generate `releaseId`: `YYYYMMDDTHHMMSSZ-<short-commit-sha>` in UTC. If that release directory already exists, select the lowest free suffix from `-01` through `-99`; never reuse or overwrite a release directory, and stop if the suffix space is exhausted. 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
@@ -28,14 +28,14 @@ Show what will be deployed using `git log --oneline <last-deployed-commit>..HEAD
 
 - 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.
+- Run health checks against the public endpoint. If any fails, rollback immediately and do not record the candidate as active.
 
 ## 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.
+- Allocate the collision-safe deploy event ID and atomically write deploy-history JSON using `${SKILL_DIR}/references/deploy-history-schema.md`, with event identity separate from `releaseId`.
+- After the history record succeeds, atomically write `shared/deploy-metadata.json` from `${SKILL_DIR}/references/deploy-metadata-schema.json` with the verified `activeColor`, `activePort`, `lastReleaseId`, operation event ID, and UTC update time. If either record write fails, preserve both processes/releases, report a recording failure, and require the next operation to rediscover active state from Nginx plus the `current` symlink before retrying metadata repair.
+- Stop the old PM2 process. Remove oldest releases beyond `releaseRetention` count. Run `pm2 save` and 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).
+Output a summary (project, URL, version, duration, health status) and update the matching sections of `deploy.md` from `${SKILL_DIR}/assets/deploy-document-template.md`; do not append duplicate headings or an event log. If `deployStrategy` is `"direct-upload"`, offer CI/CD upgrade (see §SSH: Post-Deploy CI/CD Upgrade).

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

@@ -1,35 +1,34 @@
 ---
 name: "prizmkit-implement"
-description: "Execute the reviewed plan for a formal PrizmKit requirement, update task checkpoints, preserve the shared workflow artifact directory, and hand off to prizmkit-code-review. Use after prizmkit-plan or when resuming implementation repair. (project)"
+description: "Execute one caller-supplied spec.md/plan.md change, including explicitly scoped repairs, focused verification, and task-marker updates. Returns IMPLEMENTED or IMPLEMENT_BLOCKED. (project)"
 ---
 
 # PrizmKit Implement
 
-`/prizmkit-implement` executes the tasks in one formal requirement's `plan.md`. It is the implementation stage, including implementation repairs requested by code review or testing.
+`/prizmkit-implement` executes tasks from one caller-supplied `plan.md`, including concrete repair findings explicitly included in the request.
 
 ## When to Use
 
-- After `/prizmkit-plan` reports `PLAN_READY`.
-- When workflow state routes a review or test repair back to implementation.
-- When `plan.md` contains unchecked tasks for the active requirement.
+- A caller supplies reviewed `spec.md` and `plan.md` artifacts with incomplete tasks.
+- A caller supplies an explicit repair scope and findings for implementation repair.
+- `plan.md` contains unchecked or explicitly reopened tasks, or the caller requests validation of completed task markers against the current change.
 - User says "implement", "build", "code it", "start coding", "develop", or "execute".
 
 ## When NOT to Use
 
-- No `spec.md` and `plan.md` exist for the formal requirement.
-- All planned tasks are complete and no repair scope is recorded.
+- No `spec.md` and `plan.md` exist for the supplied change.
+- All planned tasks are complete and the caller already has a valid implementation result for the unchanged current work.
 - The user is still deciding scope or asking for planning.
-- The request is a direct low-risk edit outside the formal requirement lifecycle.
+- The request has no reviewed implementation artifact and does not need a formal plan.
 
 ## Preconditions and Artifact Identity
 
 | Required artifact | Check | If missing |
 |---|---|---|
-| `plan.md` with Tasks | Exists and contains incomplete or explicitly repairable work | Return `IMPLEMENT_BLOCKED` and direct the user to `/prizmkit-plan`. |
-| `spec.md` | Exists in the same artifact directory | Return `IMPLEMENT_BLOCKED` and direct the user to `/prizmkit-plan`. |
-| Workflow state | Reusable or reconstructable | Reconstruct from artifacts and report the result when absent or stale. |
+| `plan.md` with Tasks | Exists; contains incomplete/repairable work or completed markers requiring current-change validation | Return `IMPLEMENT_BLOCKED` with the missing-input reason. |
+| `spec.md` | Exists in the same artifact directory | Return `IMPLEMENT_BLOCKED` with the missing-input reason. |
 
-Accept `artifact_dir` from the preceding skill or workflow state. Do not scan for a different most-recent plan when invoked as a handoff. A single requirement must reuse the same `artifact_dir` throughout all stages.
+Require the caller to supply or confirm `artifact_dir`. Do not discover a different recent artifact. Optional repair input must include the exact findings and `repair_scope`; do not infer them from caller state.
 
 ## Context Loading
 
@@ -37,17 +36,17 @@ Before editing:
 
 1. Read `plan.md`, `spec.md`, and only relevant companion artifacts.
 2. Read `.prizmkit/prizm-docs/root.prizm` when present.
-3. Read relevant L1 docs and relevant L2 docs when present.
-4. If an affected L2 doc is missing, read the target source files as fallback and record that no L2 context was available. Do not create L2 merely because it was read; retrospective decides whether durable knowledge warrants it.
+3. Follow its pointers to only the relevant module and detail documentation.
+4. If relevant detail documentation is missing, read the target source files as fallback and record that detailed context was unavailable. Context loading does not create or modify documentation.
 5. Read referenced layer rules when present. If a rule conflicts with the plan, stop and ask the user unless the plan clearly supersedes the rule.
 
 ## Optional Inline Delegation
 
-The default is direct Main-Agent implementation. If a narrow slice is delegated, use `prompt_reference: ${SKILL_DIR}/references/implementation-subagent-procedure.md` and follow its active-checkout/no-worktree constraints. Delegation is optional implementation detail and does not alter lifecycle handoff or ownership.
+The default is direct Main-Agent implementation. If a narrow slice is delegated, use `prompt_reference: ${SKILL_DIR}/references/implementation-subagent-procedure.md` and follow its active-checkout/no-worktree constraints. Delegation is an implementation-stage detail and does not change this Skill's output contract.
 
 ## Atomic Stage Boundary
 
-`prizmkit-implement` owns only execution of plan tasks and implementation repairs. It writes its truthful terminal result and `next_stage`, then returns control. When an external orchestrator is active, it must not invoke code review or test itself. The active orchestrator owns the next-stage invocation.
+`prizmkit-implement` owns only execution of supplied plan tasks and explicitly scoped implementation repairs. It returns `IMPLEMENTED` or `IMPLEMENT_BLOCKED` and stops.
 
 ## Execution
 
@@ -61,15 +60,15 @@ For each unchecked or explicitly repair-scoped task, in plan order:
 4. Avoid unrelated edits and preserve the requirement's artifact identity.
 5. Mark a task complete immediately after its implementation is complete.
 6. Stop dependent tasks on failure; run `[P]` tasks in parallel only when safe.
-7. Execute only local implementation verification here. The mandatory full lifecycle code review follows implementation and the mandatory auditable test stage follows code review.
+7. Execute focused implementation verification appropriate to the changed task; do not expand into a separate broad audit unrelated to implementation.
 
 ### Repair Scope
 
-When routed from a failed test or review, read `repair_scope` from workflow state and constrain edits accordingly:
+When the caller requests repair, require an explicit `repair_scope` and concrete findings:
 
-- `production`, `runtime`, `schema`, `dependency`, or `public-interface`: production-affecting changes. Completion must hand off to `prizmkit-code-review`.
-- `test-infrastructure`: tests, fixtures, test runner configuration, or evidence setup only. Completion may hand off directly to `prizmkit-test`.
-- `unknown`: stop and ask the user; do not guess which downstream gates can be skipped.
+- `production`, `runtime`, `schema`, `dependency`, or `public-interface`: constrain edits to the supplied production concern.
+- `test-infrastructure`: constrain edits to tests, fixtures, runner configuration, or evidence setup.
+- missing or `unknown`: return `IMPLEMENT_BLOCKED`; do not guess the intended repair.
 
 ## Recovery
 
@@ -77,53 +76,18 @@ If interrupted:
 
 - Reuse completed task markers and the same `artifact_dir`.
 - Inspect any partially edited files before continuing.
-- Reconcile workflow state with the plan and current diff.
-- Never report `IMPLEMENTED` when incomplete tasks or unresolved repair work remain.
+- Reconcile plan task markers with the current diff.
+- Never report `IMPLEMENTED` when tasks or supplied repair findings remain unresolved.
 
-## Workflow State
+## Output
 
-Before reading or updating workflow state, read `${SKILL_DIR}/references/workflow-state-protocol.md`.
-
-On successful implementation, update `.prizmkit/state/workflows/<requirement-slug>.json` with:
-
-```json
-{
-  "stage": "implement",
-  "status": "completed",
-  "stage_result": "IMPLEMENTED",
-  "completed_stages": ["plan", "implement"],
-  "repair_round": 0,
-  "repair_scope": null,
-  "next_stage": "code-review",
-  "resume_from": "prizmkit-code-review"
-}
-```
-
-For a repair, increment `repair_round`, set `status=failed` and `stage_result=IMPLEMENT_REPAIR`, preserve the triggering failure in the state, and select the next stage according to `repair_scope`. The outer workflow permits at most three repair rounds; the implementation stage must return a blocked result rather than start a fourth round.
-
-## Output and Handoff
-
-Report:
+Return only implementation-stage outputs:
 
+- `artifact_dir`;
 - implementation summary;
-- completed and remaining tasks;
-- files changed;
-- local verification performed;
-- workflow state path and status;
-- exact next stage.
-
-On initial implementation or a production-affecting repair:
-
-```text
-IMPLEMENTED
-  → /prizmkit-code-review
-```
-
-On a test-infrastructure-only repair:
-
-```text
-IMPLEMENTED
-  → /prizmkit-test
-```
+- completed and remaining task markers;
+- changed paths;
+- focused verification performed;
+- `IMPLEMENTED` when all supplied work is complete, otherwise `IMPLEMENT_BLOCKED` with exact blockers.
 
-If workflow state names an active `orchestrator`, return the terminal result, state path, and selected next stage to it; do not invoke another stage independently. For direct stage use, provide the deterministic next invocation with the same `artifact_dir`; a host may perform that semantic handoff on the user's behalf.
+Return only the listed implementation outputs. Do not invoke another Skill.