prizmkit 1.0.0 → 1.0.1

package/bundled/skills/prizmkit-ci-cd-generator/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: "prizmkit-ci-cd-generator"
+tier: 2
+description: "[Tier 2] Generate CI/CD pipeline config templates for GitHub Actions/GitLab CI/Jenkins. Cannot validate or test pipelines. (project)"
+---
+
+# PrizmKit CI/CD Generator
+
+Generate production-ready CI/CD pipeline configurations derived from your project's tech stack context.
+
+## Commands
+
+### prizmkit.ci-cd
+
+Generate a CI/CD pipeline configuration for the project.
+
+**STEPS:**
+
+1. Read `.prizm-docs/root.prizm` for tech stack context (LANG, FRAMEWORK, BUILD, TEST)
+2. Ask user: target platform
+   - GitHub Actions
+   - GitLab CI
+   - Jenkins
+   - Other (specify)
+3. Ask user: environments to configure (dev, staging, production)
+4. Generate pipeline config with stages:
+   - **Install dependencies**: Use project's package manager (npm, pip, cargo, etc.)
+   - **Lint/format check**: Run linter and formatter configured in project
+   - **Run tests**: Execute test suite with coverage reporting
+   - **Build artifact**: Compile/bundle project output
+   - **Deploy**: Per-environment deployment steps
+5. Include in generated config:
+   - Dependency caching (language-appropriate cache keys)
+   - Artifact management (build outputs, test reports)
+   - Environment variable placeholders with descriptive comments
+6. Write config to standard location:
+   - GitHub Actions: `.github/workflows/ci.yml` and `.github/workflows/deploy.yml`
+   - GitLab CI: `.gitlab-ci.yml`
+   - Jenkins: `Jenkinsfile`
+7. Add environment-specific secrets as placeholders with `# TODO: Configure in CI/CD settings` comments
+8. Generate a README section documenting the CI/CD setup:
+   - Pipeline overview
+   - Required secrets and environment variables
+   - How to trigger deployments
+   - How to add new stages
+
+## Path References
+
+All internal asset paths MUST use `${SKILL_DIR}` placeholder for cross-IDE compatibility.
+
+## Output
+
+- Pipeline configuration file(s) in the appropriate standard location
+- README section or standalone CI/CD documentation

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

@@ -0,0 +1,52 @@
+---
+name: "prizmkit-clarify"
+description: "Interactive requirement clarification. Resolves ambiguities in feature specs by asking sequential questions. Invoke after 'specify' or when spec has NEEDS CLARIFICATION markers. (project)"
+---
+
+# PrizmKit Clarify
+
+Interactive requirement clarification that resolves ambiguities in feature specifications. Asks focused questions one at a time, updating the spec atomically after each answer.
+
+## Commands
+
+### prizmkit.clarify
+
+Resolve ambiguities and underspecified areas in a feature specification.
+
+**PRECONDITION:** `spec.md` exists in current feature directory (`.prizmkit/specs/###-feature-name/`)
+
+**STEPS:**
+
+1. Read `spec.md` from `.prizmkit/specs/###-feature-name/`
+2. Scan for `[NEEDS CLARIFICATION]` markers and underspecified areas
+3. Categorize ambiguities by dimension:
+   - Functional scope
+   - Data model
+   - UX flow
+   - Non-functional requirements
+   - Error handling
+   - Edge cases
+   - Integration points
+   - Security
+   - Performance
+   - Accessibility
+4. Ask questions ONE AT A TIME (not all at once), max 5 questions
+5. For each question: provide a recommended answer with rationale
+6. After each answer: immediately update `spec.md` atomically (not batch)
+7. Support early termination: user says "done" or "stop"
+8. Remove resolved `[NEEDS CLARIFICATION]` markers
+9. After all questions resolved or user terminates: output summary of changes made
+
+**KEY RULES:**
+- NEVER ask all questions at once — sequential, one at a time
+- ALWAYS provide a recommended answer with rationale for each question
+- Updates to `spec.md` MUST be atomic (after each answer, not batched)
+- Max 5 questions per session
+- Respect early termination — "done" or "stop" ends the session immediately
+- Do NOT introduce implementation details — keep spec at WHAT/WHY level
+
+**HANDOFF:** `prizmkit.plan`
+
+## Output
+
+Updates are made directly to `.prizmkit/specs/###-feature-name/spec.md`. No new files are created.

package/bundled/skills/prizmkit-code-review/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: "prizmkit-code-review"
+description: "Code review against spec, plan, and best practices. Read-only analysis with severity ratings. Invoke after implementation or when user requests review. (project)"
+---
+
+# PrizmKit Code Review
+
+Perform a comprehensive code review against the feature spec, implementation plan, and project best practices. Produces a structured review report with severity ratings. This skill is strictly read-only and does not modify any files.
+
+## Commands
+
+### prizmkit.code-review
+
+Review implemented code against spec and plan.
+
+**PRECONDITION:** `spec.md`, `plan.md`, `tasks.md` exist in `.prizmkit/specs/###-feature-name/` with completed tasks
+
+**STEPS:**
+
+1. Read `spec.md`, `plan.md`, `tasks.md` as review baseline
+2. Read `.prizm-docs/root.prizm` RULES for project conventions
+3. Scan all code files referenced in completed tasks
+4. Review across 6 dimensions:
+   - **Spec compliance**: Does code implement all acceptance criteria?
+   - **Plan adherence**: Does implementation follow architectural decisions?
+   - **Code quality**: Naming, structure, complexity, DRY
+   - **Security**: Common vulnerabilities (injection, auth, data exposure)
+   - **Consistency**: Follows project patterns from `.prizm-docs/` PATTERNS
+   - **Test coverage**: Are critical paths tested?
+5. Generate findings with severity: `CRITICAL` > `HIGH` > `MEDIUM` > `LOW`
+6. Max 30 findings
+7. Verdict: `PASS` | `PASS WITH WARNINGS` | `NEEDS FIXES`
+8. OUTPUT: Structured review report (to conversation only, NOT written to file)
+
+**KEY RULES:**
+- This is STRICTLY READ-ONLY — does NOT modify any files
+- Output goes to conversation ONLY, not to any file
+- Max 30 findings to keep review actionable
+- Every CRITICAL finding MUST include a specific fix suggestion
+- Spec compliance failures are always rated HIGH or CRITICAL
+- Security findings are always rated HIGH or CRITICAL
+
+**VERDICT CRITERIA:**
+- `PASS`: No CRITICAL or HIGH findings
+- `PASS WITH WARNINGS`: No CRITICAL findings, some HIGH findings
+- `NEEDS FIXES`: Any CRITICAL findings present
+
+**HANDOFF:** `prizmkit.summarize` (if PASS) or `prizmkit.implement` (if NEEDS FIXES)
+
+## Output
+
+Review report is output to conversation only. No files are created or modified.
+
+**Report Format:**
+```
+## Code Review: [Feature Name]
+
+### Summary
+- Files reviewed: N
+- Findings: N (Critical: N, High: N, Medium: N, Low: N)
+- Verdict: [PASS | PASS WITH WARNINGS | NEEDS FIXES]
+
+### Findings
+
+#### [SEVERITY] Finding Title
+- File: path/to/file:line
+- Dimension: [spec-compliance | plan-adherence | code-quality | security | consistency | test-coverage]
+- Description: [What was found]
+- Suggestion: [How to fix]
+```

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

@@ -0,0 +1,117 @@
+---
+name: "prizmkit-committer"
+description: "Commit workflow with automatic Prizm doc updates, changelog management, and learning capture. Invoke when user wants to commit, finish task, or ship changes. (project)"
+---
+
+# PrizmKit Committer
+
+Automated commit workflow that keeps Prizm documentation in sync, manages changelog entries, and captures learnings from each commit.
+
+### When to Use
+- User says "commit", "提交", "finish", "done with this task", "ship it"
+- After implementing a feature or fixing a bug
+- CodeBuddy: the UserPromptSubmit hook will remind to use this skill
+- Claude Code: the `.claude/rules/prizm-commit-workflow.md` rule will enforce this
+
+### Workflow
+
+Follow these steps STRICTLY in order:
+
+#### Step 1: Status Check
+```bash
+git status
+```
+- If "nothing to commit, working tree clean": inform user and stop
+- If there are changes: proceed
+
+#### Step 2: Prizm Documentation Update (CRITICAL — must complete before commit)
+
+2a. Get changed files:
+```bash
+git diff --cached --name-status
+```
+If nothing staged, also check:
+```bash
+git diff --name-status
+```
+
+2b. Read .prizm-docs/root.prizm to get MODULE_INDEX
+
+2c. Map each changed file to its module using MODULE_INDEX paths
+
+2d. For each affected module:
+- IF L2 doc exists (.prizm-docs/<module>/<submodule>.prizm):
+  - Update KEY_FILES (add new files, remove deleted, note modified)
+  - Update INTERFACES (if public signatures changed)
+  - Update DEPENDENCIES (if imports changed)
+  - Append to module CHANGELOG section
+  - Update UPDATED timestamp
+- IF L1 doc exists (.prizm-docs/<module>.prizm):
+  - Update FILES count
+  - Update KEY_FILES (if major files added/removed)
+  - Update UPDATED timestamp
+- Update root.prizm:
+  - Update MODULE_INDEX file counts (only if counts changed)
+  - UPDATED timestamp (only if structural changes)
+
+2e. Append to .prizm-docs/changelog.prizm:
+Format: `- YYYY-MM-DD | <module-path> | <verb>: <one-line description>`
+Verbs: add, update, fix, remove, refactor, rename, deprecate
+
+2f. Stage prizm docs:
+```bash
+git add .prizm-docs/
+```
+
+SKIP CONDITIONS for doc update:
+- Only internal implementation changed (no interface/dependency change)
+- Only comments, whitespace, or formatting changed
+- Only test files changed
+- Only .prizm files changed (avoid circular updates)
+- Bug fixes to existing features (bugs are incomplete features being refined, not new functionality — no new doc entries needed)
+
+#### Step 3: Diff Analysis
+```bash
+git diff HEAD
+```
+Analyze:
+- Type: feat, fix, refactor, docs, test, chore, perf, style, ci, build
+- Scope: affected module name
+- Description: imperative mood summary
+
+#### Step 4: Update CHANGELOG.md
+If CHANGELOG.md exists, append entry following Keep a Changelog format.
+If manage_changelog.py exists in skill scripts:
+```bash
+python3 ${SKILL_DIR}/scripts/manage_changelog.py add --type <type> --message "<description>"
+```
+
+#### Step 5: Git Commit
+```bash
+git add .
+git commit -m "<type>(<scope>): <description>"
+```
+Follow Conventional Commits format.
+
+#### Step 6: Verification
+```bash
+git log -1 --stat
+```
+Confirm the commit was recorded.
+
+Then verify working tree is clean:
+```bash
+git status
+```
+- If "nothing to commit, working tree clean": commit verified successfully, proceed
+- If there are uncommitted changes remaining: **STOP** and report error — all changes must be captured in the commit. Run `git add . && git commit --amend --no-edit` to include missed files, then re-verify
+
+#### Step 7: Optional Push
+Ask user: "Push to remote?"
+- Yes: `git push`
+- No: Stop
+
+### Error Handling
+- If git diff is empty but untracked files exist: run `git add -N .` first
+- If CHANGELOG.md script fails: update manually or ask user
+- If .prizm-docs/ doesn't exist: skip Step 2 entirely (project not initialized)

package/bundled/skills/prizmkit-db-migration/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: "prizmkit-db-migration"
+tier: 2
+description: "[Tier 2] Database migration script generation with rollback plans. Cannot validate against actual database. (project)"
+---
+
+# PrizmKit Database Migration
+
+Plan safe database schema changes with forward and backward migration scripts, risk assessment, and verification queries.
+
+## Commands
+
+### prizmkit.db-migrate
+
+Generate a database migration plan with scripts and rollback procedures.
+
+**STEPS:**
+
+1. Read current data model from `.prizmkit/specs/` or `.prizm-docs/` (entity definitions, relationships, constraints)
+2. Ask user: describe the schema change needed
+   - What tables/collections are affected
+   - What is the desired end state
+   - Any data transformation requirements
+3. Analyze change type:
+   - **Additive** (safe): New tables, new nullable columns, new indexes
+   - **Destructive** (risky): Drop tables, drop columns, change types with data loss
+   - **Transformative** (complex): Rename columns, split/merge tables, data backfill
+4. Generate migration plan:
+   - **Pre-migration**:
+     - Backup command for affected tables
+     - List of affected tables and estimated row counts
+     - Estimated downtime (if any)
+   - **Forward migration**: SQL or ORM migration script
+     - Schema DDL statements
+     - Data migration DML statements (if applicable)
+     - Index creation (CONCURRENTLY where supported)
+   - **Backward migration (rollback)**: Reverse SQL or ORM script
+     - Reverse DDL statements
+     - Data restoration approach
+     - MUST be tested before deploying forward migration
+   - **Data verification**: Queries to validate migration success
+     - Row count comparisons
+     - Data integrity checks
+     - Constraint validation
+5. Risk assessment:
+   - **Data loss potential**: NONE / LOW / MEDIUM / HIGH
+   - **Downtime estimate**: Zero / Seconds / Minutes / Hours
+   - **Recommended deployment strategy**: Online migration vs offline migration
+   - **Lock contention risk**: Which tables will be locked and for how long
+6. Write migration files to project's migration directory convention (detect from existing migrations or ask user)
+7. Generate `migration-plan.md` with complete procedure:
+   - Step-by-step execution guide
+   - Monitoring queries to run during migration
+   - Success criteria
+   - Abort conditions
+
+## Path References
+
+All internal asset paths MUST use `${SKILL_DIR}` placeholder for cross-IDE compatibility.
+
+## Output
+
+- Migration script file(s) in the project's migration directory
+- Rollback script file(s) alongside migration scripts
+- `migration-plan.md`: Complete migration procedure with risk assessment

package/bundled/skills/prizmkit-dependency-health/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: "prizmkit-dependency-health"
+tier: 2
+description: "[Tier 2] Dependency review based on manifest files. Analyzes version patterns; cannot query package registries for real-time vulnerability data. (project)"
+---
+
+# PrizmKit Dependency Health
+
+Audit project dependencies across all supported ecosystems. Identifies outdated packages, known vulnerabilities, license conflicts, and abandoned projects. Generates a health report with prioritized upgrade recommendations.
+
+### When to Use
+- User says "check dependencies", "dependency audit", "are my packages up to date"
+- Before a major release or deployment
+- Periodically as part of maintenance workflow
+- After security advisories are published
+
+### prizmkit.dependency-health
+
+### Steps
+
+#### Step 1: Detect Dependency Files
+Scan project root and subdirectories for:
+- **Node.js**: package.json + package-lock.json / yarn.lock / pnpm-lock.yaml
+- **Python**: requirements.txt / Pipfile / pyproject.toml / setup.py
+- **Go**: go.mod / go.sum
+- **Rust**: Cargo.toml / Cargo.lock
+- **Java**: pom.xml / build.gradle / build.gradle.kts
+- **Ruby**: Gemfile / Gemfile.lock
+- **PHP**: composer.json / composer.lock
+- **.NET**: *.csproj / packages.config
+
+#### Step 2: Analyze Each Dependency
+For each dependency found:
+- Current version pinned in manifest
+- Latest available version (if determinable from lock files or version patterns)
+- Major/minor/patch version delta
+- Known security advisories (if detectable from version ranges)
+- License type and compatibility
+
+#### Step 3: Classify Health Status
+- **HEALTHY**: Up to date or within 1 minor version, no known issues
+- **STALE**: 1+ major version behind latest
+- **VULNERABLE**: Known security advisory for current version
+- **ABANDONED**: No updates in 2+ years (based on available metadata)
+- **INCOMPATIBLE**: License conflict with project license
+
+#### Step 4: Generate Recommendations
+Prioritized by risk:
+
+**Safe Updates** (low risk):
+- Patch version bumps (bug fixes only)
+- Minor version bumps within same major (backward compatible)
+
+**Breaking Updates** (medium risk):
+- Major version bumps — list known breaking changes where identifiable
+- Suggest migration steps if available
+
+**Replacements** (high effort):
+- For abandoned packages — suggest actively maintained alternatives
+- For packages with unresolved vulnerabilities — suggest secure alternatives
+
+#### Step 5: Generate Report
+Output health report to conversation (READ-ONLY):
+
+```markdown
+# Dependency Health Report
+Date: YYYY-MM-DD
+Project: <project-name>
+
+## Summary
+- Total dependencies: N
+- Healthy: N | Stale: N | Vulnerable: N | Abandoned: N
+
+## Ecosystem: <Node.js / Python / etc.>
+
+### Vulnerable (Action Required)
+| Package | Current | Latest | Advisory | Severity |
+|---------|---------|--------|----------|----------|
+| example | 1.2.3   | 1.2.5  | CVE-XXX  | HIGH     |
+
+### Stale (Upgrade Recommended)
+| Package | Current | Latest | Versions Behind |
+|---------|---------|--------|-----------------|
+| example | 2.0.0   | 4.1.0  | 2 major         |
+
+### Abandoned (Consider Replacing)
+| Package | Last Update | Suggested Alternative |
+|---------|-------------|----------------------|
+| example | 2021-01-01  | better-example       |
+
+### Healthy
+N packages up to date.
+
+## Recommended Actions
+1. Run: <package-manager-specific update commands>
+2. Review breaking changes for: <packages>
+3. Evaluate replacements for: <packages>
+```
+
+#### Step 6: Suggest Update Commands
+Provide copy-paste commands for the project's package manager:
+
+**Node.js**:
+```bash
+npm update                          # safe updates
+npm install <pkg>@latest            # major updates (one at a time)
+npx npm-check-updates -u            # update all to latest
+```
+
+**Python**:
+```bash
+pip install --upgrade <pkg>         # upgrade specific
+pip install -r requirements.txt --upgrade  # upgrade all
+```
+
+**Go**:
+```bash
+go get -u ./...                     # update all
+go get <pkg>@latest                 # update specific
+go mod tidy                         # clean up
+```
+
+Adapt commands to the detected package manager.

package/bundled/skills/prizmkit-deployment-strategy/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: "prizmkit-deployment-strategy"
+tier: 2
+description: "[Tier 2] Deployment planning with rollback procedures for blue-green/canary/rolling strategies. Planning only, cannot execute. (project)"
+---
+
+# PrizmKit Deployment Strategy
+
+Plan comprehensive deployment strategies with rollback procedures tailored to your project's infrastructure.
+
+## Commands
+
+### prizmkit.deploy-plan
+
+Generate a deployment plan with rollback procedures.
+
+**STEPS:**
+
+1. Read project context from `.prizm-docs/` (architecture, tech stack, infrastructure references)
+2. Ask user: deployment target
+   - Cloud provider (AWS, GCP, Azure)
+   - Container orchestration (Kubernetes, Docker Swarm, ECS)
+   - Bare metal / VM-based
+   - Serverless (Lambda, Cloud Functions, Vercel)
+3. Ask user: strategy preference
+   - **Blue-green**: Zero-downtime with full environment swap
+   - **Canary**: Gradual traffic shift to new version
+   - **Rolling**: Incremental instance replacement
+   - **Recreate**: Stop old, start new (accepts brief downtime)
+4. Generate `deployment-plan.md` containing:
+   - **Pre-deployment checklist**:
+     - All tests passing on target branch
+     - Database migrations prepared and tested
+     - Backups completed (database, config, artifacts)
+     - Monitoring and alerting confirmed operational
+     - Communication sent to stakeholders
+   - **Deployment steps**: Specific commands for the chosen strategy and target
+   - **Health check configuration**: Endpoints, thresholds, intervals
+   - **Rollback procedure**: Step-by-step commands to revert to previous version
+   - **Monitoring points**: What to watch during and after deployment
+   - **Post-deployment verification**:
+     - Smoke test endpoints
+     - Key metric baselines to compare
+     - User-facing feature verification
+5. Generate rollback script (`rollback.sh`) if applicable:
+   - Automated rollback with safety checks
+   - Confirmation prompts before destructive operations
+   - Logging of rollback actions
+6. Write to `.prizmkit/deployment-plan.md`
+
+## Path References
+
+All internal asset paths MUST use `${SKILL_DIR}` placeholder for cross-IDE compatibility.
+
+## Output
+
+- `.prizmkit/deployment-plan.md`: Complete deployment procedure
+- `rollback.sh` (if applicable): Executable rollback script

package/bundled/skills/prizmkit-error-triage/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: "prizmkit-error-triage"
+tier: 2
+description: "[Tier 2] Error categorization and root cause analysis via pattern matching. Checks Prizm TRAPS for known issues; no runtime debugger. (project)"
+---
+
+# PrizmKit Error Triage
+
+Systematically categorize errors, perform root cause analysis, and check Prizm docs TRAPS for known patterns.
+
+## Commands
+
+### prizmkit.error-triage \<error-description-or-log\>
+
+Triage an error by classifying it, identifying root cause, and suggesting fixes.
+
+**STEPS:**
+
+1. Parse error input (stack trace, error message, log snippet, or user description)
+2. Classify error category:
+   - **Runtime**: null reference, type error, out of bounds, division by zero
+   - **Network**: timeout, DNS resolution, connection refused, SSL/TLS handshake
+   - **Auth**: 401/403 responses, token expired, permission denied, CORS
+   - **Data**: validation failure, serialization error, encoding mismatch, corruption
+   - **Resource**: OOM, disk full, connection pool exhausted, file handle leak
+   - **Logic**: incorrect output, race condition, deadlock, infinite loop
+   - **Config**: missing env var, wrong endpoint, version mismatch, malformed config
+   - **External**: third-party API failure, dependency bug, upstream service degradation
+3. Check `.prizm-docs/` for known issues:
+   - Read TRAPS sections of affected modules for documented pitfalls
+   - Check DECISIONS sections for prior choices that may relate to the error
+4. If known trap matches:
+   - Suggest documented solution from TRAPS
+   - Reference the specific `.prizm-docs/` file and entry
+5. If no match: analyze root cause from first principles:
+   a. Identify the error origin (file, line, function) from stack trace or context
+   b. Trace the call chain to find the triggering condition
+   c. Identify the most likely root cause
+   d. Suggest fix approach with specific code pointers
+6. Generate structured triage report:
+   - **Category and subcategory**: e.g., Runtime > NullReference
+   - **Root cause**: confirmed or suspected, with reasoning
+   - **Affected files/modules**: list of files involved in the error path
+   - **Suggested fix**: concrete steps or code changes to resolve
+   - **Prevention**: what check, test, or guard would have caught this earlier
+7. Suggest updating `.prizm-docs/` TRAPS section with newly discovered pitfalls to prevent recurrence
+
+## Path References
+
+All internal asset paths MUST use `${SKILL_DIR}` placeholder for cross-IDE compatibility.
+
+## Output
+
+- Structured triage report printed to console
+- Suggestion to update `.prizm-docs/` TRAPS with new findings

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

@@ -0,0 +1,47 @@
+---
+name: "prizmkit-implement"
+description: "Execute implementation following tasks.md. Respects task ordering, dependencies, and TDD approach. Marks tasks complete as they finish. Invoke with 'implement' or 'build'. (project)"
+---
+
+# PrizmKit Implement
+
+Execute implementation by following the task breakdown in tasks.md. Respects task ordering, dependency constraints, and applies a TDD approach where applicable. Marks each task complete as it finishes.
+
+## Commands
+
+### prizmkit.implement
+
+Implement the feature by executing tasks from tasks.md.
+
+**PRECONDITION:** `tasks.md` exists in `.prizmkit/specs/###-feature-name/` with unchecked tasks
+
+**STEPS:**
+
+1. Read `tasks.md`, `plan.md`, `spec.md` for full context
+2. Read relevant `.prizm-docs/` L1/L2 for affected modules (check TRAPS and DECISIONS sections)
+3. Check if checkpoint tasks are complete before proceeding to next phase
+4. For each unchecked task in order:
+   a. If task has `[P]` marker and previous parallel tasks are running, can proceed in parallel
+   b. Read L2 doc for target file's module (if exists)
+   c. Implement following TDD: write test first if applicable
+   d. Mark task as `[x]` in `tasks.md`
+   e. If error occurs: for sequential tasks, stop and report; for parallel tasks, continue others
+5. At each checkpoint: verify build passes and tests pass
+6. After all tasks: run full test suite
+7. Output: implementation summary with pass/fail status
+
+**KEY RULES:**
+- NEVER skip a checkpoint — build and tests MUST pass before proceeding to next phase
+- Sequential tasks MUST execute in order — stop on failure
+- Parallel tasks (`[P]` marker) MAY continue if one fails, but report all failures
+- TDD approach: write test first, then implement, then verify test passes
+- Read `.prizm-docs/` TRAPS section before implementing to avoid known pitfalls
+- Mark each task `[x]` in `tasks.md` immediately upon completion (not batched)
+
+**HANDOFF:** `prizmkit.code-review`
+
+## Output
+
+- Code files created/modified as specified in tasks.md
+- `tasks.md` updated with completion markers `[x]`
+- Implementation summary output to conversation