prizmkit 1.0.153 → 1.1.1

package/bundled/skills/prizmkit-tool-adr-manager/assets/adr-template.md

@@ -1,26 +0,0 @@
-# [NUMBER]. [TITLE]
-
-**Date**: YYYY-MM-DD
-**Status**: Proposed | Accepted | Deprecated | Superseded by [ADR-NNNN]
-
-## Context
-
-[What is the issue that we're seeing that is motivating this decision or change?]
-
-## Decision
-
-[What is the change that we're proposing and/or doing?]
-
-## Consequences
-
-### Positive
-- [Consequence 1]
-
-### Negative
-- [Consequence 1]
-
-## Alternatives Considered
-
-### [Alternative 1]
-- **Description**: [What it is]
-- **Reason rejected**: [Why not chosen]

package/bundled/skills/prizmkit-tool-api-doc-generator/SKILL.md

@@ -1,55 +0,0 @@
----
-name: "prizmkit-tool-api-doc-generator"
-description: [Tier 2] Extract API documentation from source code into OpenAPI/Markdown. May miss undocumented or dynamically generated endpoints. (project)
----
-
-# PrizmKit API Doc Generator
-
-Generate API documentation from source code by scanning routes, controllers, and handlers. Produces OpenAPI 3.0 specs or Markdown reference docs.
-
-## Commands
-
-### `/prizmkit-api`-docs [api-directory]
-
-Generate API documentation from source code.
-
-**STEPS:**
-
-1. Read `.prizm-docs/` for project tech stack (framework, language, API style: REST / GraphQL / gRPC)
-2. Scan API source files (routes, controllers, handlers):
-   - Detect routing patterns based on framework:
-     - Express/Fastify: `app.get()`, `router.post()`, etc.
-     - Django/Flask: `@app.route()`, `urlpatterns`
-     - Spring: `@GetMapping`, `@PostMapping`, etc.
-     - Go: `http.HandleFunc`, gorilla/mux, chi routes
-   - If `api-directory` is specified, limit scan to that directory
-3. Extract for each endpoint:
-   - **HTTP method and path**: GET /api/users/:id
-   - **Request parameters**:
-     - Path parameters (with types)
-     - Query parameters (with types and defaults)
-     - Request body schema (from types, validation decorators, or inline definitions)
-   - **Response body schemas**: Success and error response structures
-   - **Authentication requirements**: Which auth mechanism is required (JWT, API key, session, none)
-   - **Error responses**: Common error codes and their meanings (400, 401, 403, 404, 500)
-   - **Description**: From JSDoc comments, docstrings, or function/handler names
-4. Generate documentation in requested format:
-   - **OpenAPI 3.0 YAML** (default): Full spec with schemas, security definitions, and server info
-   - **Markdown API reference**: Human-readable endpoint documentation
-   - **Both**: Generate both formats
-5. Include examples for each endpoint:
-   - Sample request (curl command)
-   - Sample success response (JSON)
-   - Sample error response (JSON)
-6. Write to `docs/api/` directory:
-   - `docs/api/openapi.yaml` for OpenAPI spec
-   - `docs/api/API_REFERENCE.md` for Markdown docs
-
-## Path References
-
-All internal asset paths MUST use `.claude/commands/prizmkit-api-doc-generator` placeholder for cross-IDE compatibility.
-
-## Output
-
-- `docs/api/openapi.yaml`: OpenAPI 3.0 specification
-- `docs/api/API_REFERENCE.md`: Markdown API reference

package/bundled/skills/prizmkit-tool-bug-reproducer/SKILL.md

@@ -1,61 +0,0 @@
----
-name: "prizmkit-tool-bug-reproducer"
-description: [Tier 1] Generate minimal reproduction scripts and test cases from bug descriptions. AI strength in test/script generation. (project)
----
-
-# PrizmKit Bug Reproducer
-
-Generate minimal reproduction scripts and test cases from bug descriptions to isolate, confirm, and verify fixes.
-
-## Commands
-
-### `/prizmkit-bug`-reproduce \<bug-description\>
-
-Generate a minimal reproduction for a reported bug.
-
-**STEPS:**
-
-1. Parse bug description: extract expected vs actual behavior, steps to reproduce (if given), environment details
-2. Read `.prizm-docs/` for relevant module context, paying special attention to TRAPS sections that may document known pitfalls
-3. Identify affected code path from description:
-   - Map user-facing behavior to source code modules
-   - Identify entry points and data flow
-4. Generate minimal reproduction based on bug type:
-   a. **For API bugs**: Generate curl/HTTP request sequence
-      - Include headers, authentication, request body
-      - Show expected vs actual response
-      - Add assertions on status code and response body
-   b. **For UI bugs**: Generate step-by-step user interaction guide
-      - Numbered steps with specific UI elements to interact with
-      - Screenshot annotation points (where to look)
-      - Browser/device requirements if relevant
-   c. **For logic bugs**: Generate unit test that demonstrates the failure
-      - Minimal test case with clear arrange/act/assert
-      - Test name describes the expected behavior
-      - Comments explaining why this should pass
-   d. **For data bugs**: Generate seed data + query sequence
-      - Minimal dataset that triggers the issue
-      - Query or operation sequence to reproduce
-      - Expected vs actual result comparison
-5. Write reproduction script/test to a temporary file:
-   - Use project's existing test framework and conventions
-   - Include setup and teardown
-   - Make it self-contained and runnable
-6. Include assertions that:
-   - FAIL with current (buggy) behavior
-   - PASS with expected (correct) behavior
-   - Serve as regression test after fix is applied
-7. Output:
-   - Reproduction file path
-   - Minimal steps document describing how to run
-   - Suggested fix investigation starting points
-
-## Path References
-
-All internal asset paths MUST use `.claude/commands/prizmkit-bug-reproducer` placeholder for cross-IDE compatibility.
-
-## Output
-
-- Reproduction script or test file written to project's test directory
-- Minimal steps document printed to console
-- Investigation pointers for the fix

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

@@ -1,53 +0,0 @@
----
-name: "prizmkit-tool-ci-cd-generator"
-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 `.claude/commands/prizmkit-ci-cd-generator` 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-tool-db-migration/SKILL.md

@@ -1,64 +0,0 @@
----
-name: "prizmkit-tool-db-migration"
-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 `.claude/commands/prizmkit-db-migration` 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-tool-dependency-health/SKILL.md

@@ -1,122 +0,0 @@
----
-name: "prizmkit-tool-dependency-health"
-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-tool-deployment-strategy/SKILL.md

@@ -1,57 +0,0 @@
----
-name: "prizmkit-tool-deployment-strategy"
-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 `.claude/commands/prizmkit-deployment-strategy` placeholder for cross-IDE compatibility.
-
-## Output
-
-- `.prizmkit/deployment-plan.md`: Complete deployment procedure
-- `rollback.sh` (if applicable): Executable rollback script

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

@@ -1,54 +0,0 @@
----
-name: "prizmkit-tool-error-triage"
-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 `.claude/commands/prizmkit-error-triage` 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-tool-log-analyzer/SKILL.md

@@ -1,54 +0,0 @@
----
-name: "prizmkit-tool-log-analyzer"
-description: [Tier 2] Log pattern recognition via text analysis. Identifies error frequencies and correlations from provided log content. (project)
----
-
-# PrizmKit Log Analyzer
-
-Analyze log files to identify anomaly patterns, frequency trends, and error correlations for production issue investigation.
-
-## Commands
-
-### `/prizmkit-analyze`-logs \<log-file-or-directory\>
-
-Analyze log files and produce a structured report of findings.
-
-**STEPS:**
-
-1. Read and parse log files (auto-detect format):
-   - JSON structured logs
-   - Structured text (key=value pairs)
-   - Syslog format
-   - Custom formats (infer delimiter and field positions)
-2. Extract entries with normalized fields:
-   - **Timestamp**: parse to comparable datetime
-   - **Level**: DEBUG, INFO, WARN, ERROR, FATAL
-   - **Source**: service name, module, class, or file
-   - **Message**: the log message body
-   - **Metadata**: request ID, user ID, trace ID (if present)
-3. Analyze patterns:
-   - **Error frequency**: count by type and time window (per minute, per hour)
-   - **Correlation**: errors that consistently appear together or in sequence
-   - **Anomaly detection**: sudden spikes in error rate, new error types not seen before
-   - **Timeline**: when did behavior change relative to deployments or config changes
-   - **Request tracing**: follow request IDs across log entries to reconstruct flows
-4. Identify top issues:
-   - Most frequent errors (by count)
-   - Most recent new errors (not seen in earlier log entries)
-   - Errors with increasing trend (getting worse over time)
-   - Errors correlated with specific endpoints, users, or time windows
-5. Generate analysis report:
-   - **Timeline of events**: chronological summary of significant changes
-   - **Top 10 error patterns**: with frequency, first/last occurrence, and sample messages
-   - **Correlation findings**: errors that co-occur or cascade
-   - **Anomaly alerts**: unusual patterns that warrant investigation
-   - **Recommended investigation priorities**: ranked list of what to look at first
-
-## Path References
-
-All internal asset paths MUST use `.claude/commands/prizmkit-log-analyzer` placeholder for cross-IDE compatibility.
-
-## Output
-
-- Structured analysis report printed to console
-- Summary suitable for sharing with team or pasting into incident reports

package/bundled/skills/prizmkit-tool-monitoring-setup/SKILL.md

@@ -1,74 +0,0 @@
----
-name: "prizmkit-tool-monitoring-setup"
-description: [Tier 2] Generate monitoring config templates for Prometheus/Grafana/CloudWatch/etc. Cannot test or validate actual metrics collection. (project)
----
-
-# PrizmKit Monitoring Setup
-
-Generate comprehensive monitoring, alerting, and log collection configurations for your project's observability stack.
-
-## Commands
-
-### `/prizmkit-monitoring`
-
-Generate monitoring and observability configurations.
-
-**STEPS:**
-
-1. Read `.prizm-docs/root.prizm` for tech stack and architecture (services, databases, external dependencies)
-2. Ask user: monitoring stack
-   - Prometheus + Grafana
-   - ELK (Elasticsearch, Logstash, Kibana)
-   - CloudWatch (AWS)
-   - Datadog
-   - Other (specify)
-3. Identify key metrics to monitor:
-   - **Application (RED metrics)**:
-     - Request **R**ate: requests per second by endpoint
-     - **E**rror rate: 4xx/5xx responses, exception counts
-     - **D**uration: latency percentiles (p50, p95, p99)
-   - **System**:
-     - CPU utilization and saturation
-     - Memory usage and swap
-     - Disk I/O and space
-     - Network throughput and errors
-   - **Business**:
-     - Feature-specific metrics derived from spec (signups, transactions, etc.)
-     - SLA/SLO compliance indicators
-   - **Database**:
-     - Connection pool utilization
-     - Query latency by type (read/write)
-     - Replication lag
-     - Slow query count
-4. Generate monitoring configs:
-   - **Metrics collection**: Scrape configs, exporters, or agent configurations
-   - **Alert rules** with severity levels:
-     - Critical: immediate page (service down, data loss risk)
-     - Warning: investigate soon (degraded performance, approaching limits)
-     - Info: awareness (deployment events, scaling events)
-   - **Dashboard definition**: JSON/YAML for Grafana or equivalent
-     - Overview dashboard: service health at a glance
-     - Detail dashboard: per-service deep dive
-   - **Log format and collection config**:
-     - Structured log format recommendation
-     - Log shipping configuration
-     - Log retention policy
-5. Generate health check endpoint code if not existing:
-   - Liveness probe: process is running
-   - Readiness probe: dependencies are available
-   - Startup probe: initialization complete
-6. Write configs to standard locations:
-   - Prometheus: `monitoring/prometheus.yml`, `monitoring/alerts.yml`
-   - Grafana: `monitoring/dashboards/`
-   - Application: health check endpoint in source code
-
-## Path References
-
-All internal asset paths MUST use `.claude/commands/prizmkit-monitoring-setup` placeholder for cross-IDE compatibility.
-
-## Output
-
-- Monitoring configuration files in `monitoring/` directory
-- Alert rule definitions
-- Dashboard JSON/YAML files
-- Health check endpoint code (if generated)