prizmkit 1.1.6 → 1.1.8

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

@@ -19,7 +19,7 @@ User says:
 
 **Do NOT use this skill when:**
 - User only wants to plan features (use `feature-planner` directly)
-- User only wants to launch pipeline for existing feature-list.json (use `feature-pipeline-launcher`)
+- User only wants to launch pipeline for existing .prizmkit/plans/feature-list.json (use `feature-pipeline-launcher`)
 - User wants to fix bugs (use `bug-planner` + `bugfix-pipeline-launcher`)
 - User wants to refactor code (use `refactor-workflow`)
 
@@ -32,7 +32,7 @@ feature-workflow <idea / requirements>
    │
    ├── Phase 1: Brainstorm → deep interactive Q&A until requirements are crystal clear
    │
-   ├── Phase 2: Plan → feature-planner → feature-list.json
+   ├── Phase 2: Plan → feature-planner → .prizmkit/plans/feature-list.json
    │
    ├── Phase 3: Launch → feature-pipeline-launcher → pipeline execution
    │
@@ -44,7 +44,7 @@ feature-workflow <idea / requirements>
 | Phase | Action | Result |
 |-------|--------|--------|
 | 1 | **Brainstorm** — interactive Q&A with user | Fully clarified requirements document |
-| 2 | Call `feature-planner` with clarified requirements | `feature-list.json` with N features |
+| 2 | Call `feature-planner` with clarified requirements | `.prizmkit/plans/feature-list.json` with N features |
 | 3 | Call `feature-pipeline-launcher` | Pipeline started (execution mode chosen by user via launcher) |
 | 4 | Monitor progress | Status updates, completion report |
 
@@ -52,7 +52,7 @@ feature-workflow <idea / requirements>
 
 Without this skill, users must:
 1. Figure out all requirements themselves
-2. Invoke `feature-planner` → wait for feature-list.json
+2. Invoke `feature-planner` → wait for .prizmkit/plans/feature-list.json
 3. Invoke `feature-pipeline-launcher` → wait for pipeline start
 4. Manually check progress
 
@@ -81,9 +81,9 @@ Natural language description of the project or features. Can be:
 
 Flow: brainstorm → feature-planner → feature-pipeline-launcher → monitor
 
-**Mode B: From existing feature-list.json**
+**Mode B: From existing .prizmkit/plans/feature-list.json**
 
-When user says "run pipeline from existing file" or feature-list.json already exists:
+When user says "run pipeline from existing file" or .prizmkit/plans/feature-list.json already exists:
 - Skip brainstorm and `feature-planner` (file already exists)
 - Invoke `feature-pipeline-launcher` directly
 - Monitor and report progress
@@ -92,7 +92,7 @@ When user says "run pipeline from existing file" or feature-list.json already ex
 
 When user says "add features to existing project" or the project already has features:
 - Brainstorm new feature requirements with the user
-- Invoke `feature-planner` in incremental mode (reads existing feature-list.json)
+- Invoke `feature-planner` in incremental mode (reads existing .prizmkit/plans/feature-list.json)
 - Append new features to existing list
 - Invoke `feature-pipeline-launcher`
 - Monitor and report progress
@@ -232,7 +232,7 @@ Present this summary to the user and get explicit confirmation before proceeding
 
 ## Phase 2: Plan
 
-**Goal**: Generate structured feature-list.json from the clarified requirements.
+**Goal**: Generate structured .prizmkit/plans/feature-list.json from the clarified requirements.
 
 **STEPS**:
 
@@ -240,16 +240,18 @@ 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**: `.prizmkit/plans/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
    - If questions arise, answer from the Phase 1 context or pass through to user
 
 3. **Validate output**:
-   - Confirm `feature-list.json` exists
+   - Confirm `.prizmkit/plans/feature-list.json` exists
    - Show summary: total features, complexity distribution, dependencies
 
-**CHECKPOINT CP-FW-1**: `feature-list.json` generated and validated.
+**CHECKPOINT CP-FW-1**: `.prizmkit/plans/feature-list.json` generated and validated.
 
 **If user says `--from <file>`**: Skip Phase 1 and Phase 2 entirely.
 
@@ -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 `.prizmkit/plans/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
@@ -305,8 +308,8 @@ Present this summary to the user and get explicit confirmation before proceeding
 3. **Periodic progress reports** (when user asks):
    ```bash
    python3 dev-pipeline/scripts/update-feature-status.py \
-     --feature-list feature-list.json \
-     --state-dir dev-pipeline/state \
+     --feature-list .prizmkit/plans/feature-list.json \
+     --state-dir .prizmkit/state/features \
      --action status
    ```
 
@@ -335,12 +338,12 @@ The workflow supports resuming by detecting existing state:
 
 | State Found | Resume From |
 |-------------|------------|
-| No `feature-list.json` | Phase 1: Brainstorm |
-| `feature-list.json` exists, no pipeline state | Phase 3: Launch |
-| `feature-list.json` + pipeline state exists | Phase 4: Monitor (check status) |
+| No `.prizmkit/plans/feature-list.json` | Phase 1: Brainstorm |
+| `.prizmkit/plans/feature-list.json` exists, no pipeline state | Phase 3: Launch |
+| `.prizmkit/plans/feature-list.json` + pipeline state exists | Phase 4: Monitor (check status) |
 | All features completed | Report completion, suggest next steps |
 
-**Resume**: If `feature-list.json` exists, ask user: "Existing feature plan found with N features. Resume pipeline or re-plan?"
+**Resume**: If `.prizmkit/plans/feature-list.json` exists, ask user: "Existing feature plan found with N features. Resume pipeline or re-plan?"
 
 ---
 
@@ -364,7 +367,7 @@ While the pipeline runs, the user can continue the conversation:
 | User's idea is too vague to brainstorm | Ask for more context: "Can you describe the main problem this solves?" |
 | Brainstorming stalls | Offer concrete options: "Would you prefer A or B?" |
 | `feature-planner` cannot parse requirements | Refine the requirements summary and retry |
-| `feature-list.json` generation failed | Show error, retry with refined input |
+| `.prizmkit/plans/feature-list.json` generation failed | Show error, retry with refined input |
 | Pipeline launch failed | Show daemon log, suggest manual start |
 | All features blocked/failed | Show status, suggest retrying specific features |
 | User wants to cancel mid-brainstorming | Save conversation context, offer to resume later |
@@ -375,7 +378,7 @@ While the pipeline runs, the user can continue the conversation:
 
 | Skill | Relationship |
 |-------|-------------|
-| `feature-planner` | **Called by Phase 2** — generates feature-list.json from clarified requirements |
+| `feature-planner` | **Called by Phase 2** — generates .prizmkit/plans/feature-list.json from clarified requirements |
 | `feature-pipeline-launcher` | **Called by Phase 3** — starts pipeline (handles execution mode selection) |
 | `bug-planner` | **Alternative** — for bug fix workflows |
 | `bugfix-pipeline-launcher` | **Alternative** — for bug fix pipelines |
@@ -406,7 +409,7 @@ All internal asset paths use `${SKILL_DIR}` placeholder for cross-IDE compatibil
 ## Output
 
 - Structured requirements summary (Phase 1 artifact)
-- `feature-list.json` (Phase 2 artifact)
+- `.prizmkit/plans/feature-list.json` (Phase 2 artifact)
 - Pipeline execution (Phase 3)
 - Progress updates (Phase 4)
 - Multiple git commits with `feat(<scope>):` prefix

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 .prizmkit/plans/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.