prizmkit 1.1.7 → 1.1.9

package/bundled/skills/prizmkit-code-review/rules/dimensions-feature.md

@@ -1,43 +0,0 @@
-# Review Dimensions — Feature Mode
-
-Review code against `spec.md` and `plan.md` across 6 dimensions:
-
-## 1. Spec Compliance
-Does code implement all acceptance criteria? Missing criteria are the #1 source of "it works but it's wrong" bugs.
-- Check every acceptance criterion in spec.md has a corresponding implementation
-- Verify edge cases mentioned in spec are handled
-- Confirm scope boundaries are respected (no over-implementation, no under-implementation)
-
-## 2. Plan Adherence
-Does implementation follow architectural decisions in plan.md? Deviations may be improvements or may break assumptions other components depend on.
-- Check component structure matches plan's architecture approach
-- Verify data model matches plan's schema design
-- Confirm API contracts (endpoints, request/response) match plan
-
-## 3. Code Quality
-Naming, structure, complexity, DRY. Focus on maintainability — will someone understand this code in 6 months?
-- Function/variable names are descriptive and consistent with project conventions
-- No unnecessary complexity (cyclomatic complexity, deep nesting)
-- No copy-paste duplication that should be abstracted
-- Error messages are informative for debugging
-
-## 4. Security
-Injection (SQL, XSS, command), auth/authz gaps, sensitive data exposure, insecure defaults. Security issues are always HIGH+ because they're the hardest to catch later.
-- User input is validated and sanitized before use in queries, HTML, or commands
-- Authentication and authorization checks are present on protected routes
-- Sensitive data (passwords, tokens, PII) is not logged or exposed in responses
-- Cryptographic operations use established libraries, not custom implementations
-
-## 5. Consistency
-Follows project patterns from `.prizm-docs/` PATTERNS section. Inconsistent patterns increase cognitive load for every future reader.
-- Code style matches existing codebase conventions
-- Error handling follows established patterns
-- File organization follows project structure conventions
-- Naming conventions align with `.prizm-docs/` RULES
-
-## 6. Test Coverage
-Are critical paths tested? Focus on paths that handle user input, money, or state transitions.
-- Happy path tests exist for each user story
-- Error/edge case tests for critical paths
-- Tests are deterministic (no flaky timing dependencies)
-- Test names clearly describe what they verify

package/bundled/skills/prizmkit-code-review/rules/dimensions-refactor.md

@@ -1,25 +0,0 @@
-# Review Dimensions — Refactor Mode
-
-Review code against `refactor-analysis.md` goals. Standard dimensions (code quality, security, consistency, test coverage) still apply — load `${SKILL_DIR}/rules/dimensions-feature.md` §3–§6 for those.
-
-## Refactor-Specific Dimensions
-
-### Behavior Preservation (replaces Spec Compliance)
-Observable behavior must remain unchanged. This is the #1 refactor risk — "improving" code that subtly changes behavior.
-- All existing tests still pass without modification (test changes during refactor are a red flag)
-- Public API signatures are unchanged (parameter types, return types, error types)
-- Side effects (logging, metrics, events) are preserved unless explicitly scoped for removal
-- Edge case handling is preserved — refactors often silently drop edge case branches
-
-### Structural Improvement (replaces Plan Adherence)
-Is the code measurably better against the refactor goals?
-- Complexity metrics improved (fewer nested conditions, shorter functions)
-- Coupling reduced (fewer cross-module imports, clearer boundaries)
-- Duplication reduced (DRY violations eliminated per refactor-analysis.md scope)
-- Readability improved (naming, organization, documentation)
-
-### Test Integrity
-Refactors must not weaken the test suite.
-- No tests were deleted or skipped
-- Test coverage percentage is equal or higher
-- If tests were rewritten, they cover the same behavioral scenarios

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

@@ -1,69 +0,0 @@
-# Deploy Guide Update Protocol
-
-When dependency manifests change during implementation, update `DEPLOY.md` at the project root.
-
-## Detection
-
-1. Check if any dependency manifests were modified in this session:
-   ```bash
-   git diff --name-only HEAD -- package.json requirements*.txt Pipfile pyproject.toml go.mod Cargo.toml pom.xml build.gradle Gemfile composer.json docker-compose*.yml Dockerfile .tool-versions 2>/dev/null
-   ```
-2. If no manifest files changed → skip this step entirely
-3. If manifest files changed, scan for **newly added** dependencies (not version bumps):
-   ```bash
-   git diff -U0 HEAD -- package.json requirements*.txt Pipfile pyproject.toml go.mod Cargo.toml pom.xml build.gradle Gemfile composer.json docker-compose*.yml Dockerfile .tool-versions 2>/dev/null | grep '^\+' | grep -v '^\+\+\+' | head -30
-   ```
-
-## Recording
-
-For each genuinely new framework/tool, record in `DEPLOY.md` at project root:
-
-| Field | Description | Source |
-|-------|-------------|--------|
-| **Name** | Framework/tool name | Package name from manifest |
-| **Version** | Installed version or constraint | Version spec from manifest |
-| **Purpose** | Why it was introduced | You just added it — you know why |
-| **Install Command** | How to install locally | Standard install command for the ecosystem |
-| **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.md`
-
-```markdown
-# Deploy Guide
-
-> Auto-maintained by PrizmKit. Manual edits are preserved.
-> Last updated: YYYY-MM-DD
-
-## Frameworks & Tools
-
-### <Framework Name>
-
-- **Version**: <version constraint>
-- **Purpose**: <why this framework is used>
-- **Install**:
-  ```bash
-  <install command>
-  ```
-- **Key Config**:
-  - `<config file or env var>`: <description>
-- **Notes**:
-  - <any setup gotchas, required external services, manual steps>
-```
-
-## Update Rules
-
-- Create file if absent; append new sections if file exists
-- Update version if framework already documented
-- Preserve manually added content
-- Keep entries sorted alphabetically
-
-## Filter Out
-
-- Patch version bumps of existing deps
-- Dev-only tools needing no setup (linters, formatters)
-- Transitive/lock-file-only changes
-
-## Final Step
-
-Stage the file: `git add DEPLOY.md`

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

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