prizmkit 1.0.153 → 1.1.0

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)

package/bundled/skills/prizmkit-tool-onboarding-generator/SKILL.md

@@ -1,69 +0,0 @@
----
-name: "prizmkit-tool-onboarding-generator"
-description: [Tier 2] Generate onboarding documentation from Prizm docs context. Quality depends on existing .prizm-docs/ completeness. (project)
----
-
-# PrizmKit Onboarding Generator
-
-Generate a comprehensive developer onboarding guide from project context, covering everything a new team member needs to be productive.
-
-## Commands
-
-### `/prizmkit-onboarding`
-
-Generate a complete onboarding guide for new developers.
-
-**STEPS:**
-
-1. Read `.prizm-docs/root.prizm` for complete project overview (tech stack, architecture, conventions)
-2. Read `.prizm-docs/` L1 module docs for detailed module information
-3. Read existing `README.md`, `CONTRIBUTING.md` if present (avoid duplicating existing docs; reference them instead)
-4. Generate `ONBOARDING.md` covering:
-   - **Environment Setup**:
-     - Prerequisites (language runtimes, tools, accounts)
-     - Step-by-step install commands (copy-paste ready)
-     - Configuration files to create or modify
-     - Verification commands to confirm setup works
-   - **Architecture Overview**:
-     - High-level system description (from root.prizm ARCHITECTURE and LAYERS)
-     - Key services/modules and their responsibilities
-     - Data flow between components
-     - External dependencies and integrations
-   - **Key Directories**:
-     - What each top-level directory contains
-     - Where to find specific types of code (models, controllers, tests, configs)
-   - **Build and Test Commands**:
-     - How to build the project
-     - How to run the full test suite
-     - How to run specific tests
-     - How to run linters and formatters
-   - **Development Workflow**:
-     - Branch naming convention
-     - Development cycle: branch, develop, test, commit, PR
-     - Code review expectations
-     - CI/CD pipeline overview
-   - **Key Concepts and Domain Terminology**:
-     - Domain-specific terms and their meanings
-     - Acronyms used in the codebase
-   - **Common Tasks** (step-by-step guides):
-     - Adding a new API endpoint
-     - Adding a new database migration
-     - Creating a new test
-     - Deploying to staging
-   - **Debugging Tips and Common Pitfalls**:
-     - Known gotchas from TRAPS sections
-     - Common setup issues and solutions
-     - Useful debugging commands
-   - **Where to Find Help**:
-     - Documentation locations
-     - Team contacts or channels
-     - Issue tracker and how to file bugs
-5. Write to `ONBOARDING.md` in project root
-
-## Path References
-
-All internal asset paths MUST use `.claude/commands/prizmkit-onboarding-generator` placeholder for cross-IDE compatibility.
-
-## Output
-
-- `ONBOARDING.md` in project root: complete onboarding guide for new developers

package/bundled/skills/prizmkit-tool-perf-profiler/SKILL.md

@@ -1,54 +0,0 @@
----
-name: "prizmkit-tool-perf-profiler"
-description: [Tier 2] Static analysis for potential performance issues with profiling tool recommendations. Does not measure actual runtime performance. (project)
----
-
-# PrizmKit Performance Profiler
-
-Identify performance bottlenecks through static code analysis and profiling guidance. Suggests targeted optimizations with expected impact.
-
-## Commands
-
-### `/prizmkit-perf`-profile [module-or-file]
-
-Analyze code for performance bottlenecks and generate optimization recommendations.
-
-**STEPS:**
-
-1. Read `.prizm-docs/` for architecture and module relationships (dependencies, data flow, hot paths)
-2. If specific file/module given: focus analysis on that scope; otherwise analyze project-wide critical paths
-3. Analyze for common bottleneck patterns:
-   - **N+1 queries**: ORM/database calls inside loops
-   - **Missing indexes**: queries filtering or sorting on unindexed columns
-   - **Synchronous blocking in async code**: blocking I/O in async handlers, missing await
-   - **Unnecessary serialization/deserialization**: repeated JSON parse/stringify, redundant marshaling
-   - **Memory leaks**: growing collections without bounds, unclosed resources, event listener accumulation
-   - **Inefficient algorithms**: O(n^2) where O(n) or O(n log n) is possible, nested loops over large datasets
-   - **Missing caching opportunities**: repeated expensive computations or external calls with stable inputs
-   - **Excessive logging in hot paths**: string formatting and I/O in tight loops
-   - **Large payload transfers**: over-fetching from database, sending unnecessary fields to client
-   - **Connection management**: not reusing connections, missing connection pooling
-4. Generate profiling recommendations:
-   - Suggest profiling tools appropriate for the project's tech stack:
-     - Node.js: `--prof`, `clinic.js`, `0x`
-     - Python: `cProfile`, `py-spy`, `line_profiler`
-     - Java: JFR, async-profiler, VisualVM
-     - Go: `pprof`, `trace`
-     - Rust: `perf`, `flamegraph`, `criterion`
-   - Provide specific commands to run the profiler against the identified hot paths
-   - Identify measurement baselines to establish before optimizing
-5. Output performance report:
-   - **Suspected bottlenecks**: ranked by likely impact (HIGH / MEDIUM / LOW)
-   - **Suggested optimizations**: for each bottleneck, concrete code changes or architectural adjustments
-   - **Profiling commands**: copy-paste ready commands to validate each suspicion
-   - **Expected impact**: qualitative assessment of improvement (e.g., "Eliminates N+1, expect ~10x query reduction for list endpoints")
-6. Suggest updating `.prizm-docs/` TRAPS section with discovered performance pitfalls for future reference
-
-## Path References
-
-All internal asset paths MUST use `.claude/commands/prizmkit-perf-profiler` placeholder for cross-IDE compatibility.
-
-## Output
-
-- Performance analysis report printed to console
-- Profiling command suggestions ready to execute