prizmkit 1.1.5 → 1.1.7

package/bundled/skills/bugfix-pipeline-launcher/SKILL.md

@@ -117,16 +117,20 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    Use `AskUserQuestion` to present the following configuration choices. Each question is a separate selectable option:
 
-   **Question 1 — Verbose logging** (multiSelect: false):
+   **Question 1 — Critic review** (multiSelect: false):
+   - Off (default) — Skip adversarial review
+   - On — Enable critic review after bug fix (+2-5 min/bug for critical/high severity)
+
+   **Question 2 — Verbose logging** (multiSelect: false):
    - On (default) — Detailed AI session logs including tool calls and subagent activity
    - Off — Minimal logging
 
-   **Question 2 — Max retries** (multiSelect: false):
+   **Question 3 — Max retries** (multiSelect: false):
    - 3 (default)
    - 1
    - 5
 
-   **Question 3 — Session timeout** (multiSelect: false):
+   **Question 4 — Session timeout** (multiSelect: false):
    - None (default) — No timeout
    - 30 min — `SESSION_TIMEOUT=1800`
    - 1 hour — `SESSION_TIMEOUT=3600`
@@ -138,6 +142,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
    | Config choice | Environment variable |
    |-----------|---------------------|
+   | Critic: On | `ENABLE_CRITIC=true` |
    | Verbose: Off | `VERBOSE=0` |
    | Verbose: On | `VERBOSE=1` |
    | Max retries: N | `MAX_RETRIES=N` |
@@ -204,7 +209,7 @@ Detect user intent from their message, then follow the corresponding workflow:
    **If foreground**: Pipeline runs to completion in the terminal. After it finishes:
    - Summarize results: total bugs, fixed, failed, skipped
    - If all fixed: each bug session has already run `prizmkit-retrospective` (structural sync) internally. Ask user what's next.
-   - If some failed: show failed bug IDs and suggest `retry-bugfix.sh <B-XXX>` or `reset-bug.sh <B-XXX> --clean --run`
+   - If some failed: show failed bug IDs and suggest `retry-bugfix.sh <B-XXX>` or `dev-pipeline/reset-bug.sh <B-XXX> --clean --run`
 
    **If background daemon**:
    1. Verify launch:

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

@@ -79,15 +79,31 @@ Do NOT use this skill when:
    ```bash
    python3 ${SKILL_DIR}/scripts/validate-and-generate.py validate --input <output-path> --mode <new|incremental>
    ```
+   
+   If the script is not available, perform these manual validation checks:
+   1. **ID sequence**: All feature IDs are sequential (F-001, F-002, F-003, ...)
+   2. **No circular dependencies**: No feature depends (directly or transitively) on itself
+   3. **Description length**: Minimum 15 words per description (error), 30/50/80 recommended
+   4. **Dependency references**: All referenced features in dependencies exist in features array
+   5. **Priority enums**: All priority values are exactly "high", "medium", or "low" (case-sensitive)
+   6. **Status enum**: All status values are one of: pending, in_progress, completed, failed, skipped, split, auto_skipped
+   7. **Acceptance criteria**: At least 1 criterion per feature, each is a concrete, measurable statement
+   8. **Browser interaction**: If present, has url, verify_steps array, and optional setup_command
+   9. **Complexity enum**: If present, is one of: low, medium, high
+   10. **Model field**: If present, is a non-empty string
+   11. **Critic field**: If present, is boolean; if true, critic_count should be 1 or 3
+   12. **Root schema**: Has $schema='dev-pipeline-feature-list-v1', project_name, and non-empty features array
 
 5. **Use script output as source of truth** — if validation fails, fix and re-run until pass
 
 ## Prerequisites
 
 Before questions, check optional context files (never block if absent):
-- `.prizm-docs/root.prizm` (architecture/project context)
+- `.prizm-docs/root.prizm` (architecture/project context — typically created by app-planner with captured decisions)
 - `.prizmkit/config.json` (existing stack preferences and detected tech stack)
+- `project-brief.md` (project context from app-planner, if available)
 - existing `feature-list.json` (required for incremental mode)
+- `.prizmkit/project-conventions.json` (project conventions from app-planner, if available)
 - If `.prizm-docs/root.prizm` is absent and the project has existing source code, scan the directory structure to understand the codebase layout:
   ```bash
   find . -maxdepth 2 -type d -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/dist/*' -not -path '*/build/*' -not -path '*/__pycache__/*' -not -path '*/vendor/*' | sed -e 's;[^/]*/;|____;g;s;____|; |;g'
@@ -98,6 +114,62 @@ Before questions, check optional context files (never block if absent):
 - Map config fields to global_context: `language`, `runtime`, `frontend_framework`, `frontend_styling`, `backend_framework`, `database`, `orm`, `testing` → `testing_strategy`, `bundler`, `project_type`.
 - Do NOT re-ask the user for tech stack info already present in config.json. Show detected stack and confirm.
 
+## Global Context Population
+
+The `global_context` object in `feature-list.json` provides technology stack information to the pipeline for intelligent code generation.
+
+### Recommended Fields by Project Type
+
+**Frontend-only projects:**
+- `language` (required) — e.g., "TypeScript", "JavaScript"
+- `frontend_framework` (required) — e.g., "React", "Vue", "Svelte"
+- `frontend_styling` (recommended) — e.g., "Tailwind CSS", "styled-components"
+- `testing_strategy` (recommended) — e.g., "Jest + React Testing Library"
+
+**Backend-only projects:**
+- `language` (required) — e.g., "TypeScript", "Python", "Go"
+- `backend_framework` (required) — e.g., "Express", "Django", "FastAPI"
+- `database` (required if applicable) — e.g., "PostgreSQL", "MongoDB"
+- `testing_strategy` (recommended) — e.g., "Jest", "pytest"
+
+**Full-stack projects (include both frontend AND backend fields):**
+- `language`, `frontend_framework`, `backend_framework`, `database`, `testing_strategy` (all recommended)
+- Additional: `frontend_styling`, `orm`, `bundler`, `runtime`
+
+### Auto-Population from app-planner
+
+If the project was planned with `app-planner`, `feature-planner` will automatically read:
+- `.prizmkit/config.json` (tech stack detected by app-planner)
+- `project-brief.md` (tech choices made during planning)
+- `.prizm-docs/root.prizm` (architecture decisions)
+
+**Recommendation**: Always run `app-planner` before `feature-planner` to ensure `global_context` is pre-populated correctly. This reduces planning time and improves code generation consistency.
+
+### Manual Population (if no app-planner context)
+
+If planning features directly without app-planner:
+1. During Phase 1 (Scope Clarification), identify the project's tech stack
+2. Ask user or read from existing `package.json` / `pyproject.toml` / `go.mod`
+3. Populate `global_context` in `feature-list.json` with detected values
+4. Confirm with user: "Using tech stack: [language] + [frameworks]. Correct?"
+
+### Pipeline Behavior with Missing Fields
+
+| Missing Field | Pipeline Behavior |
+|---------------|-------------------|
+| `language` | Uses generic pseudocode patterns; code generation may be generic |
+| `frontend_framework` | Frontend features generate generic HTML/JavaScript; no framework-specific patterns |
+| `backend_framework` | Backend features generate generic API patterns; no framework-specific scaffolding |
+| `database` | Assumes no persistent storage; generates unit tests only with mocks |
+| `testing_strategy` | Defaults to Jest (if JavaScript/TypeScript); pytest (if Python) |
+| All fields empty | Pipeline still works but code quality/consistency may suffer; recommend re-running with app-planner |
+
+### Note
+
+**global_context fields are all optional** — pipeline can execute without them. However, including the recommended fields dramatically improves code generation quality and framework-specific best practices.
+
+---
+
 ## Scenario Routing
 
 Classify user intent first:

package/bundled/skills/feature-planner/references/error-recovery.md

@@ -21,7 +21,7 @@ Group errors by type and apply targeted fixes:
 
 | Error Type | Symptom | Fix Offered | Auto-Fix? |
 |-----------|---------|------------|-----------|
-| **Schema mismatch** | `$schema` invalid, missing `app_name`, wrong `features` type | "Set `$schema` to `dev-pipeline-feature-list-v1`, `app_name` to string" | Yes |
+| **Schema mismatch** | `$schema` invalid, missing `project_name`, wrong `features` type | "Set `$schema` to `dev-pipeline-feature-list-v1`, `project_name` to string" | Yes |
 | **Feature ID issues** | Invalid format (not `F-NNN`), duplicate IDs, undefined refs | "Suggest corrected IDs, show duplicates" | Yes |
 | **Dependency errors** | Circular dependency, undefined target features | "Show cycle chain (e.g., `F-003 → F-005 → F-003`), suggest break point" | No |
 | **Missing fields** | Feature missing required keys (title, description, AC) | "List each feature + missing keys, guide patch" | Partial |

package/bundled/skills/feature-planner/scripts/validate-and-generate.py

@@ -174,9 +174,10 @@ def validate_feature_list(data, planning_mode="new"):
             "$schema must be '{}', got '{}'".format(SCHEMA_VERSION, schema)
         )
 
-    app_name = data.get("app_name")
+    # Support both project_name (canonical) and app_name (legacy)
+    app_name = data.get("project_name", data.get("app_name"))
     if not isinstance(app_name, str) or not app_name.strip():
-        errors.append("app_name must be a non-empty string")
+        errors.append("project_name must be a non-empty string")
 
     features = data.get("features")
     if not isinstance(features, list) or len(features) == 0:
@@ -441,8 +442,8 @@ def generate_template():
 
     return {
         "$schema": SCHEMA_VERSION,
-        "app_name": "YOUR_APP_NAME",
-        "app_description": "YOUR_APP_DESCRIPTION",
+        "project_name": "YOUR_PROJECT_NAME",
+        "project_description": "YOUR_PROJECT_DESCRIPTION",
         "created_at": now,
         "created_by": "feature-planner",
         "source_spec": "",
@@ -545,7 +546,7 @@ def _build_dependency_graph_text(features):
 
 def generate_summary_markdown(data):
     """Generate a markdown summary of the feature list."""
-    app_name = data.get("app_name", "Unknown")
+    app_name = data.get("project_name", data.get("app_name", "Unknown"))
     features = data.get("features", [])
 
     lines = []
@@ -634,7 +635,7 @@ def generate_summary_json(data):
         })
 
     return {
-        "app_name": data.get("app_name", ""),
+        "project_name": data.get("project_name", data.get("app_name", "")),
         "features": feature_summaries,
         "stats": {
             "total_features": len(features),

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

@@ -240,6 +240,8 @@ Present this summary to the user and get explicit confirmation before proceeding
    - Pass the structured requirements summary as input — NOT the raw user conversation
    - For new projects: standard planning mode
    - For existing projects with `--incremental`: incremental planning mode
+   - **Input**: Markdown requirements summary (feature descriptions, user stories, constraints)
+   - **Output**: `feature-list.json` (schema: `dev-pipeline-feature-list-v1`) containing `project_name`, `features[]` with id (F-NNN), title, description, priority, dependencies, acceptance_criteria, status
 
 2. **Interactive planning** (if feature-planner requires clarification):
    - Because Phase 1 was thorough, feature-planner should need minimal clarification
@@ -272,11 +274,12 @@ Present this summary to the user and get explicit confirmation before proceeding
    ```
 
 2. **Invoke `feature-pipeline-launcher` skill**:
+   - **Input**: Path to validated `feature-list.json`
    - The launcher handles all prerequisites checks
    - The launcher presents execution mode choices to the user (foreground/background/manual)
    - The launcher asks whether to enable Critic Agent (adversarial review) — passes `--critic` flag if chosen
    - Do NOT duplicate execution mode or critic selection here — let the launcher handle it
-   - Returns PID/status and log file location
+   - **Output**: PID/status, log file path, execution mode selected
 
 3. **Verify launch success**:
    - Confirm pipeline is running

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

@@ -17,6 +17,7 @@ description: "Pure git commit workflow with safety checks. Stages files, generat
 | Uncommitted changes exist | `git status` shows modified/added/untracked files | Inform user "nothing to commit" and stop |
 | `.prizm-docs/` synced (feature/refactor) | `/prizmkit-retrospective` has run | Run `/prizmkit-retrospective` first |
 | Code review passed (pipeline mode) | `context-snapshot.md` has Review Notes with PASS/PASS_WITH_WARNINGS | Run `/prizmkit-code-review` first |
+| `DEPLOY.md` updated (if applicable) | If `/prizmkit-deploy` ran, `DEPLOY.md` is staged | Run `/prizmkit-deploy` or skip if no infrastructure changes |
 
 ### Workflow
 

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

@@ -25,6 +25,7 @@ description: "Generate or update DEPLOY.md with local dev setup, testing, produc
 1. Read `.prizmkit/config.json`:
    - `deploy_strategy` — user's confirmed deployment approach (may be absent)
    - `tech_stack` — detected or user-provided technology stack
+   - **If `.prizmkit/config.json` does not exist**: proceed without it — infer deployment approach entirely from project file scanning in steps 2-3. Log a warning: "No .prizmkit/config.json found — inferring deployment strategy from project files. Run `/prizmkit-init` to generate config."
 2. Scan project for deployment-related files:
    - Container: `Dockerfile`, `docker-compose.yml`, `.dockerignore`
    - Cloud platforms: `vercel.json`, `netlify.toml`, `fly.toml`, `app.yaml` (GCP), `appspec.yml` (AWS)

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

@@ -1,5 +1,5 @@
 # Deployment Guide: [PROJECT_NAME]
-<!-- Replace [PROJECT_NAME] with: app_name from feature-list.json, or name from package.json, or the project root directory name (in that priority order) -->
+<!-- Replace [PROJECT_NAME] with: project_name from feature-list.json, or name from package.json, or the project root directory name (in that priority order) -->
 
 > Generated by PrizmKit Deploy
 

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

@@ -89,5 +89,5 @@ If a session is interrupted mid-implementation:
 
 - Code files created/modified as specified in plan.md Tasks section
 - `plan.md` Tasks section updated with completion markers `[x]`
-- `deploy_guide.md` created/updated (only when new frameworks/tools were added)
+- `DEPLOY.md` created/updated (only when new frameworks/tools were added)
 - Implementation summary output to conversation

package/bundled/skills/prizmkit-implement/references/deploy-guide-protocol.md

@@ -1,6 +1,6 @@
 # Deploy Guide Update Protocol
 
-When dependency manifests change during implementation, update `deploy_guide.md` at the project root.
+When dependency manifests change during implementation, update `DEPLOY.md` at the project root.
 
 ## Detection
 
@@ -16,7 +16,7 @@ When dependency manifests change during implementation, update `deploy_guide.md`
 
 ## Recording
 
-For each genuinely new framework/tool, record in `deploy_guide.md` at project root:
+For each genuinely new framework/tool, record in `DEPLOY.md` at project root:
 
 | Field | Description | Source |
 |-------|-------------|--------|
@@ -27,7 +27,7 @@ For each genuinely new framework/tool, record in `deploy_guide.md` at project ro
 | **Key Config** | Config files or env vars needed | Config files you just created/modified |
 | **Notes** | Setup gotchas, required services | Docker services, manual steps, env vars |
 
-## Template for `deploy_guide.md`
+## Template for `DEPLOY.md`
 
 ```markdown
 # Deploy Guide
@@ -66,4 +66,4 @@ For each genuinely new framework/tool, record in `deploy_guide.md` at project ro
 
 ## Final Step
 
-Stage the file: `git add deploy_guide.md`
+Stage the file: `git add DEPLOY.md`

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

@@ -30,9 +30,9 @@ Transforms natural language into a structured spec. Skip this phase when:
 2. Auto-generate 2-4 word feature slug from description
 3. Determine next feature number by scanning `.prizmkit/specs/`:
    - List existing `###-*` directories, find highest numeric prefix
-   - Next = highest + 1 (zero-padded to 3 digits), append `-MMDD` timestamp suffix for collision prevention
+   - Next = highest + 1 (zero-padded to 3 digits)
    - If empty or doesn't exist, start at `001`
-4. Create directory: `.prizmkit/specs/###-feature-name-MMDD/`
+4. Create directory: `.prizmkit/specs/###-feature-name/`
 5. Load project context (use first available):
    - If `context-snapshot.md` exists in the feature dir → read Section 3 'Prizm Context' (skip re-reading .prizm-docs/)
    - Otherwise → read `.prizm-docs/root.prizm` and relevant L1/L2 docs
@@ -101,7 +101,7 @@ If no input document exists, prompt user to describe the feature (triggers Phase
 
 **Input:** "I want users to upload avatars"
 
-**Phase 0 output:** `.prizmkit/specs/003-user-avatar-0402/spec.md`
+**Phase 0 output:** `.prizmkit/specs/003-user-avatar/spec.md`
 ```markdown
 # Feature: User Avatar Upload
 ## User Stories

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

@@ -24,12 +24,34 @@ For initial doc setup, validation, or migration, use `/prizmkit-prizm-docs` inst
 - User says "retrospective", "retro", "update docs", "sync docs", "wrap up"
 - After refactoring or bugfix cycles (structural sync + optional TRAPS update)
 
+## PRECONDITION
+
+| Mode | Required Input | Expected Source | If Missing |
+|---|---|---|---|
+| **Feature** | Code review verdict (PASS/PASS_WITH_WARNINGS) | `.prizmkit/specs/###-feature-name/` context-snapshot.md Review Notes | Run `/prizmkit-code-review` |
+| **Refactor** | Code review verdict + behavior preservation evidence | `.prizmkit/refactor/<slug>/` context-snapshot.md | Run `/prizmkit-code-review` in refactor mode |
+| **Bugfix** | Code review verdict + regression test evidence | `.prizmkit/bugfix/<BUG_ID>/` context-snapshot.md | Run `/prizmkit-code-review` in bugfix mode |
+| **Standalone** (user-invoked) | Code changes in working tree | `git diff` output | No prerequisite — runs structural sync only |
+
 ## When NOT to Use
 
 - Only comments, whitespace, or formatting changed — no structural/knowledge change
 - Only test files changed — no module-level impact
 - Only .prizm files changed — avoid circular updates
 
+## PRECONDITION: Review Verdict Gate
+
+Before executing, check the most recent `/prizmkit-code-review` verdict from the current session context:
+
+| Verdict | Action |
+|---------|--------|
+| `PASS` | Proceed normally |
+| `PASS_WITH_WARNINGS` | Proceed normally (warnings are informational) |
+| `NEEDS_FIXES` | **ABORT** — do not sync docs for code that failed review. Output: "Code review verdict is NEEDS_FIXES. Fix the issues identified in code review first, then re-run `/prizmkit-code-review` before proceeding to retrospective." |
+| No verdict found | Proceed with warning: "No code review verdict found — running retrospective without review gate. Consider running `/prizmkit-code-review` first." |
+
+This gate prevents updating `.prizm-docs/` for code that hasn't passed review, which would create a false impression that the codebase is in a consistent, reviewed state.
+
 ---
 
 ### Job 1: Structural Sync (always runs)
@@ -79,12 +101,27 @@ The pipeline enforces a **docs pass condition**: `.prizm-docs/` must show change
 
 | From | To | Condition |
 |------|----|-----------|
-| `prizmkit-code-review` | **this skill** | Review passes or work is complete |
-| **this skill** | `prizmkit-deploy` (conditional) | Architecture synced; deploy only if new tech stack detected |
-| **this skill** | `prizmkit-committer` (direct) | Architecture synced, no deployment doc update needed |
+| `prizmkit-code-review` | **this skill** | Review verdict is PASS or PASS_WITH_WARNINGS |
+| **this skill** | `prizmkit-deploy` (conditional) | Architecture synced; deploy only if new infrastructure components detected (new DB, cache, MQ, etc.) |
+| **this skill** | `prizmkit-committer` (direct) | Architecture synced, no new infrastructure components |
 | `prizmkit-deploy` | `prizmkit-committer` | Deploy docs updated, ready to commit |
 | `prizmkit-committer` | — | Committed |
 
+### Deploy Decision Logic
+
+After structural sync and knowledge injection are complete, decide the next step:
+
+1. **Check if this is a fast-path change** (bugfix, config tweak, simple refactor) → skip deploy, go to `/prizmkit-committer`
+2. **Check `.prizmkit/config.json`** for `deploy_strategy` field:
+   - If absent → skip deploy (project hasn't configured deployment yet)
+   - If present → continue to step 3
+3. **Scan this session's changes** for new infrastructure indicators:
+   - New `Dockerfile`, `docker-compose.yml`, cloud config files (vercel.json, fly.toml, etc.)
+   - New database migrations, new cache/queue dependencies in package.json/requirements.txt
+   - New environment variables added to source code
+   - If any found → invoke `/prizmkit-deploy`
+   - If none found → go to `/prizmkit-committer`
+
 ## Output
 
 - `.prizm-docs/*.prizm` — Structurally synced + TRAPS/RULES/DECISIONS enriched

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

@@ -0,0 +1,281 @@
+---
+name: "prizmkit-verify"
+description: "Automated framework verification for PrizmKit's 4-layer architecture (Skill → Pipeline → Workflow → Script). Use this skill to validate structural integrity, contract consistency between layers, cross-scenario alignment, and adapter/installer correctness. Trigger whenever: verifying framework health, checking skill contracts, auditing layer integration, running pre-release checks, or after significant framework modifications."
+---
+
+# PrizmKit Framework Verification
+
+Verify PrizmKit's four-layer architecture for structural integrity, contract consistency, and cross-scenario alignment.
+
+## Execution Modes
+
+Parse the user's arguments to determine scope and depth:
+
+| Command | What Runs | When to Use |
+|---------|-----------|-------------|
+| `/prizmkit-verify light` | Light checks only (R1-R4) | Quick CI gate, seconds |
+| `/prizmkit-verify medium` | Light + Medium (R1-R4) | Regular development, recommended default |
+| `/prizmkit-verify full` | All rounds (R1-R6) including E2E | Pre-release, after major changes |
+| `/prizmkit-verify --round R1` | Specific round only | Targeted check after editing a layer |
+| `/prizmkit-verify` (no args) | Same as `medium` | Default |
+
+## Architecture Context
+
+PrizmKit has four layers, bottom to top:
+
+```
+L1 Skill layer     → core/skills/prizmkit-skill/         (10 skills, dev lifecycle)
+L2 Pipeline layer   → core/skills/orchestration-skill/pipelines/  (7 skills, planners + launchers)
+L3 Workflow layer   → core/skills/orchestration-skill/workflows/  (4 skills, scenario entry points)
+L4 Script layer     → dev-pipeline/                       (Bash + Python runtime engine)
+```
+
+Three verification depths, cumulative:
+- **Light**: Structural/static checks, scriptable, zero tokens
+- **Medium**: AI reads SKILL.md content, verifies inter-layer contracts
+- **Deep**: End-to-end scenario traces through all 4 layers
+
+## Execution
+
+### Phase 0: Setup
+
+1. Create output directory: `.prizmkit/verify/` (timestamp-based run dir)
+2. Determine which rounds to run based on user args
+3. Initialize the report structure
+
+### Phase 1: Horizontal Verification (R1-R4)
+
+Run rounds sequentially. For each round, run Light first, then Medium if in scope.
+
+---
+
+#### R1: L1 Skill Layer
+
+**Target**: All skills in `core/skills/prizmkit-skill/` (expect ~10)
+
+**Light checks** — run `${SKILL_DIR}/scripts/verify-light.py --round R1` if available, otherwise check manually:
+
+| Check | How | Pass Criteria |
+|-------|-----|---------------|
+| Frontmatter validity | Read each SKILL.md YAML header | `name` + `description` present; `name` is lowercase-hyphens; `name` matches directory name |
+| Asset reference integrity | Grep `${SKILL_DIR}` in each SKILL.md, resolve path relative to skill dir | Every referenced file exists on disk |
+| Cross-skill references | Grep `/prizmkit-*` references in each SKILL.md | Every referenced skill exists under `core/skills/` |
+| Orphaned assets | List files in each skill's `assets/`, `scripts/`, `references/` dirs | Every file is referenced by SKILL.md (warn if not) |
+| Lint: ESLint | Run `npm run lint` | 0 errors (warnings OK) |
+| Lint: Ruff | Run `npm run lint:py` | 0 errors |
+
+**Medium checks** — read each SKILL.md FULLY and verify artifact chain contracts:
+
+For each adjacent skill pair in the chain:
+`prizmkit-plan → prizmkit-analyze → prizmkit-implement → prizmkit-code-review → prizmkit-retrospective → prizmkit-committer → prizmkit-deploy`
+
+| Verification Point | What to Check |
+|-------------------|---------------|
+| Output format defined? | Does the producer skill explicitly describe its output structure (file name, format, key sections)? |
+| Input expectation defined? | Does the consumer skill explicitly state what it reads and in what format? |
+| Format match | Do output and input specifications agree on structure, field names, file paths? |
+| Path convention | Do both skills reference the same directory convention (e.g., `.prizmkit/specs/###-feature-name/`)? |
+| Error handling | What happens if upstream artifact is missing or malformed? Is fallback defined? |
+| Quality gate | Does each consumer check preconditions before proceeding? |
+
+Record each pair as: `PASS` / `WARN (gap described)` / `FAIL (mismatch described)`
+
+---
+
+#### R2: L2 Pipeline Layer
+
+**Target**: All skills in `core/skills/orchestration-skill/pipelines/` (expect 7)
+
+**Light checks**:
+
+| Check | How | Pass Criteria |
+|-------|-----|---------------|
+| Frontmatter validity | Same as R1 | `name` + `description`; name matches dir |
+| Asset reference integrity | Same as R1 | All `${SKILL_DIR}` refs resolve |
+| Planner→Launcher coupling | For each scenario (feature/bugfix/refactor): check planner mentions correct JSON filename, launcher references correct script | All 3 pairs coupled correctly |
+| Script path references | Launchers reference `dev-pipeline/run-*.sh` | All referenced scripts exist and are executable |
+| Schema consistency | Compare planner SKILL.md output schema with `dev-pipeline/templates/*-list-schema.json` | Field names, types, required fields match |
+| Schema version match | Compare `dev-pipeline/templates/*-list-schema.json` const value with `dev-pipeline/scripts/init-*-pipeline.py` EXPECTED_SCHEMA | Versions identical |
+
+**Medium checks** — read each SKILL.md FULLY:
+
+For each scenario (feature, bugfix, refactor):
+1. What JSON format does the planner produce? What fields, what validation?
+2. What JSON format does the launcher expect? What fields does it read?
+3. Do they match? Any fields the launcher expects but planner doesn't produce?
+4. What command does the launcher assemble? What env vars? Do they match `run-*.sh` expectations?
+
+---
+
+#### R3: L3 Workflow Layer
+
+**Target**: All skills in `core/skills/orchestration-skill/workflows/` (expect 4)
+
+**Light checks**:
+
+| Check | How | Pass Criteria |
+|-------|-----|---------------|
+| Frontmatter validity | Same as R1 | `name` + `description`; name matches dir |
+| Pipeline skill references | Grep each workflow for planner/launcher skill names | All referenced pipeline skills exist |
+| Checkpoint naming | Grep for `CP-` patterns | Follows `CP-{XW}-{N}` convention |
+| Flow completeness markers | Each workflow has: When to Use, Execution phases, Error handling table, Relationship table | All sections present |
+
+**Medium checks** — read each SKILL.md FULLY:
+
+| Verification Point | What to Check |
+|-------------------|---------------|
+| Workflow → Pipeline handoff | What does workflow pass to each pipeline skill? Is the input format documented? |
+| Flow completeness | feature-workflow: requirements→planning→launch→monitor? bug-fix-workflow: diagnosis→triage→fix→review→commit? refactor-workflow: goals→planning→launch→monitor? recovery-workflow: detect→diagnose→recover? |
+| Fast path integration | If fast path exists, is there a decision tree for when to use it? |
+| Cross-workflow consistency | Same checkpoint naming, phase structure, error handling patterns? |
+
+---
+
+#### R4: L4 Script Layer
+
+**Target**: `dev-pipeline/` directory
+
+**Light checks**:
+
+| Check | How | Pass Criteria |
+|-------|-----|---------------|
+| Shell scripts executable | `ls -la dev-pipeline/*.sh` | All `.sh` files have `+x` permission |
+| Python scripts compile | `python3 -m py_compile` each `.py` file | All compile without error |
+| Bash lib sourcing | Grep `run-*.sh` for `source.*lib/` | Each sources common.sh, heartbeat.sh, branch.sh |
+| JSON templates valid | `python3 -c "import json; json.load(open(f))"` for each `.json` in `templates/` | All parse without error |
+| Ruff Python lint | `ruff check dev-pipeline/scripts/` | 0 errors |
+| Test file existence | List `dev-pipeline/tests/` | At least test files exist for prompt generation |
+
+**Medium checks** — read key scripts:
+
+| Verification Point | What to Check |
+|-------------------|---------------|
+| Shell → Python integration | For each `run-*.sh`: list all Python scripts invoked, verify each exists, verify argument names match |
+| Bootstrap prompt generation | Read `generate-bootstrap-prompt.py` (or per-scenario variant): does it reference correct skill names? Are all `{{PLACEHOLDER}}` variables populated? |
+| State management | Read `init-*-pipeline.py`: correct schema validation? Proper state dir initialization? |
+| Cross-scenario consistency | Compare `run-feature.sh` vs `run-bugfix.sh` vs `run-refactor.sh`: same structure? Same error handling patterns? Note intentional divergences vs unintentional gaps |
+
+---
+
+### Phase 2: Vertical E2E Verification (R5-R6)
+
+Only runs in `full` mode. For each scenario, trace data flow through all 4 layers.
+
+#### R5: Feature Scenario
+
+Trace "Add user authentication with JWT" through:
+
+1. **L3→L2**: feature-workflow → feature-planner → feature-pipeline-launcher
+   - What format does workflow pass to planner?
+   - What JSON does planner produce?
+   - What command does launcher assemble?
+
+2. **L2→L4**: feature-pipeline-launcher → run-feature.sh
+   - What args/env vars are passed?
+   - How does init-pipeline.py consume feature-list.json?
+   - What bootstrap prompt does generate-bootstrap-prompt.py produce?
+
+3. **L4→L1**: run-feature.sh → AI CLI → Skills
+   - What skills does the bootstrap prompt reference?
+   - In what order?
+   - Are skill names correct?
+
+At each transition, verify: **format match**, **field completeness**, **path consistency**, **error propagation**.
+
+#### R6: Bugfix + Refactor Scenarios
+
+Same trace for:
+- Bugfix: "Fix login crash when email is empty"
+- Refactor: "Extract authentication logic into shared module"
+
+Then cross-scenario comparison:
+- Layer transition patterns structurally similar?
+- Schema conventions consistent (F-NNN / B-NNN / R-NNN)?
+- Bootstrap prompt patterns consistent?
+- State management patterns consistent?
+- Intentional divergences documented?
+
+---
+
+### Phase 3: Supplementary Checks
+
+These address gaps identified in the first verification run. Include in `medium` and `full` modes.
+
+#### S1: Adapter Layer Verification
+
+| Check | How |
+|-------|-----|
+| Claude adapter output | Run `node adapters/claude/command-adapter.js` on a sample skill, verify output format |
+| CodeBuddy adapter output | Run `node adapters/codebuddy/skill-adapter.js` on same skill, verify output |
+| Cross-platform equivalence | Diff the two outputs for semantic equivalence |
+| ${SKILL_DIR} resolution | Verify Claude resolves to `.claude/command-assets/`, CodeBuddy to `.codebuddy/skills/` |
+
+#### S2: Installer & Distribution Verification
+
+| Check | How |
+|-------|-----|
+| _metadata.json completeness | All skills listed in `core/skills/_metadata.json` suites? |
+| Bundle sync | `npm run bundle && npm run bundle:verify` passes |
+| Skill count | Bundled skill count matches source skill count |
+
+#### S3: Rules Consistency
+
+| Check | How |
+|-------|-----|
+| Rules exist | All files in `core/rules/` referenced by `_rules-metadata.json` |
+| Rule-skill alignment | Rules reference skill names that exist |
+
+---
+
+## Report Format
+
+Generate the verification report at `.prizmkit/verify/verify-report-{timestamp}.md`:
+
+```markdown
+# PrizmKit Verification Report
+**Date**: {date}  **Mode**: {light|medium|full}
+
+## Summary
+| Round | Layer | Light | Medium | Deep | Issues |
+|-------|-------|-------|--------|------|--------|
+| R1 | L1 Skill | PASS/WARN/FAIL | PASS/WARN/FAIL | — | count |
+| R2 | L2 Pipeline | ... | ... | — | count |
+| R3 | L3 Workflow | ... | ... | — | count |
+| R4 | L4 Script | ... | ... | — | count |
+| R5 | E2E Feature | — | — | PASS/WARN/FAIL | count |
+| R6 | E2E Bug+Refactor | — | — | PASS/WARN/FAIL | count |
+| S1 | Adapters | ... | ... | — | count |
+| S2 | Distribution | ... | ... | — | count |
+| S3 | Rules | ... | ... | — | count |
+
+## Issues by Severity
+### Critical
+- [C1] Description... (Round, Layer, Location)
+
+### High
+- [H1] Description...
+
+### Medium
+- [M1] Description...
+
+## Cross-Scenario Comparison (full mode only)
+| Dimension | Feature | Bugfix | Refactor | Consistent? |
+|-----------|---------|--------|----------|-------------|
+| ...       | ...     | ...    | ...      | ✅/⚠️      |
+
+## Recommendations
+1. **P0**: ...
+2. **P1**: ...
+```
+
+## Parallelization Strategy
+
+For efficiency, run independent checks concurrently:
+- R1 Light + R2 Light + R3 Light + R4 Light can run in parallel
+- R1 Medium depends on R1 Light passing
+- R5/R6 depend on R1-R4 completing (need full picture of each layer)
+- S1/S2/S3 can run in parallel with R1-R4
+
+## Previous Verification Findings
+
+Reference `docs/framework-verification-report.md` for the baseline findings from the initial verification run. This helps track whether previously identified issues have been resolved.