prizmkit 1.0.153 → 1.1.1

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

package/bundled/skills/prizmkit-tool-security-audit/SKILL.md

@@ -1,129 +0,0 @@
----
-name: "prizmkit-tool-security-audit"
-description: [Tier 2] AI-assisted security review checklist via static code analysis. Identifies common vulnerability patterns and hardcoded secrets. Not an automated scanner. (project)
----
-
-# PrizmKit Security Audit
-
-Comprehensive security scanner that identifies vulnerabilities, hardcoded secrets, and insecure patterns across the codebase. Generates a severity-rated report with actionable fix suggestions.
-
-### When to Use
-- User says "security audit", "security review", "check for vulnerabilities"
-- Before deployment or release
-- After adding authentication, authorization, or data handling code
-- During code review of security-sensitive changes
-
-### `/prizmkit-security`-audit
-
-### Steps
-
-#### Step 1: Load Project Context
-Read .prizm-docs/root.prizm for:
-- Project tech stack and languages
-- Architecture overview
-- Module structure
-
-#### Step 2: Scan for Vulnerabilities
-Scan code files across these categories:
-
-**Injection**
-- SQL injection: raw query concatenation, unsanitized user input in queries
-- XSS: unescaped output in templates, innerHTML usage, dangerouslySetInnerHTML
-- Command injection: shell exec with user input, unsanitized system calls
-- LDAP injection: unescaped LDAP filter construction
-
-**Authentication**
-- Weak password handling: plaintext storage, weak hashing (MD5, SHA1)
-- Missing auth checks: unprotected routes/endpoints
-- Session management: predictable session IDs, missing expiration
-
-**Authorization**
-- Broken access control: missing role checks, horizontal privilege escalation
-- IDOR: direct object references without ownership validation
-- Privilege escalation: admin functions without proper guards
-
-**Data Exposure**
-- Hardcoded credentials: API keys, tokens, passwords in source code
-- Sensitive data in logs: PII, credentials, tokens logged in plaintext
-- Unencrypted sensitive data: passwords, SSN, credit cards stored in plain text
-
-**Configuration**
-- Debug mode enabled in production configs
-- Default credentials in configuration files
-- Insecure defaults: CORS *, permissive CSP, disabled CSRF
-
-**Dependencies**
-- Cross-reference package manifests (package.json, requirements.txt, etc.)
-- Flag known vulnerable version ranges where identifiable
-
-**Cryptography**
-- Weak algorithms: DES, RC4, MD5 for security purposes
-- Hardcoded encryption keys or IVs
-- Improper random generation: Math.random() for security tokens
-
-**Input Validation**
-- Missing validation on user inputs
-- Improper sanitization or escaping
-- Regex DoS (ReDoS) patterns
-
-#### Step 3: Check Sensitive File Handling
-- Verify .gitignore covers: .env, credentials.json, *.pem, *.key, *.p12
-- Check for sensitive files already tracked in git
-- Flag any secrets that may have been committed historically
-
-#### Step 4: Classify Findings
-Rate each finding by severity:
-- **CRITICAL**: Actively exploitable, data breach risk, hardcoded production secrets
-- **HIGH**: Significant vulnerability requiring immediate attention
-- **MEDIUM**: Security weakness that should be addressed
-- **LOW**: Minor issue or best practice improvement
-
-Maximum 50 findings per report.
-
-#### Step 5: Generate Report
-Output structured security report to conversation (READ-ONLY, no file modifications):
-
-```markdown
-# Security Audit Report
-Date: YYYY-MM-DD
-Project: <project-name>
-
-## Summary
-- Critical: N | High: N | Medium: N | Low: N
-- Files scanned: N
-- Categories checked: N
-
-## Critical Findings
-### [C-001] <Title>
-- **File**: path/to/file.ext:line
-- **Category**: Injection / Auth / etc.
-- **Description**: What the issue is
-- **Impact**: What could happen if exploited
-- **Fix**: How to remediate
-
-## High Findings
-...
-
-## Medium Findings
-...
-
-## Low Findings
-...
-
-## Recommendations
-1. Immediate actions (Critical + High)
-2. Short-term improvements (Medium)
-3. Long-term hardening (Low + best practices)
-```
-
-#### Step 6: Suggest Fixes
-For CRITICAL and HIGH findings:
-- Provide specific code fix suggestions
-- Reference security best practices
-- Link to relevant documentation where applicable
-
-#### Step 7: Record Findings (Optional)
-If `.prizm-docs/` exists:
-- Update affected module RULES with security conventions discovered
-- Update affected module TRAPS with security pitfalls found
-- Track security posture improvements over time via changelog.prizm

package/bundled/skills/prizmkit-tool-tech-debt-tracker/SKILL.md

@@ -1,138 +0,0 @@
----
-name: "prizmkit-tool-tech-debt-tracker"
-description: [Tier 1] Identify and track technical debt via code pattern analysis. Scans TODOs, complexity hotspots, code smells. AI strength. (project)
----
-
-# PrizmKit Tech Debt Tracker
-
-Systematic technical debt identification and tracking. Scans the codebase for code smells, TODO markers, complexity hotspots, missing tests, and other debt indicators. Generates a prioritized report with actionable recommendations.
-
-### When to Use
-- User says "tech debt", "code quality", "what needs cleanup"
-- During sprint planning to identify maintenance work
-- Before major refactoring efforts
-- Periodically as part of codebase health monitoring
-
-### `/prizmkit-tech`-debt
-
-### Steps
-
-#### Step 1: Load Project Context
-Read .prizm-docs/ for:
-- Project structure and module boundaries
-- Tech stack and language conventions
-- Existing architecture documentation
-
-#### Step 2: Scan for Debt Indicators
-
-**TODO/FIXME/HACK/XXX Markers**
-- Search all source files for marker comments
-- Categorize by file and module
-- Extract context (the comment text and surrounding code)
-
-**Complexity Hotspots**
-- Files exceeding 500 lines of code
-- Deeply nested logic (4+ levels of nesting)
-- Functions/methods exceeding 100 lines
-- High cyclomatic complexity (many branches/conditions)
-
-**Code Duplication**
-- Similar code blocks appearing across multiple files
-- Copy-pasted logic with minor variations
-- Repeated patterns that could be abstracted
-
-**Missing Tests**
-- Source files without corresponding test files
-- Public APIs without test coverage
-- Critical paths without integration tests
-
-**Outdated Patterns**
-- Deprecated API usage
-- Old language syntax (var instead of let/const, callbacks instead of async/await)
-- Legacy framework patterns
-
-**Dead Code**
-- Unused imports and variables
-- Unreachable code blocks
-- Commented-out code blocks (>5 lines)
-- Exported functions with no consumers
-
-**Poor Naming**
-- Single-letter variables outside of loops/lambdas
-- Misleading names (obvious cases only)
-- Inconsistent naming conventions within a module
-
-**Missing Documentation**
-- Public APIs without doc comments
-- Complex functions without explanatory comments
-- Missing README in significant directories
-
-#### Step 3: Calculate Debt Score
-Per module:
-- CRITICAL issues: weight x4 (security-adjacent, data-loss risk)
-- HIGH issues: weight x3 (maintainability blockers)
-- MEDIUM issues: weight x2 (code quality)
-- LOW issues: weight x1 (best practices)
-
-Normalize by module size (lines of code) to get debt density.
-
-#### Step 4: Generate Prioritized Report
-Write to .prizmkit/tech-debt.md (overwrite each run):
-
-```markdown
-# Technical Debt Report
-Generated: YYYY-MM-DD
-
-## Summary
-- Total debt items: N
-- Critical: N | High: N | Medium: N | Low: N
-- Modules scanned: N
-
-## Top 10 Hotspots (by debt score)
-| Rank | Module/File | Score | Top Issues |
-|------|-------------|-------|------------|
-| 1    | path/file   | 42    | complexity, missing tests |
-
-## Debt by Category
-| Category | Count | Severity Breakdown |
-|----------|-------|--------------------|
-| TODO markers | N | H:N M:N L:N |
-| Complexity | N | C:N H:N M:N |
-| Missing tests | N | H:N M:N |
-| Dead code | N | M:N L:N |
-| Duplication | N | M:N L:N |
-| Documentation | N | L:N |
-
-## Trend
-(If previous report exists in .prizmkit/):
-- Previous total: N → Current: N (improving/degrading)
-- Categories improving: ...
-- Categories degrading: ...
-
-## Detailed Findings
-
-### Critical
-- [File:Line] Description | Impact | Suggested Fix
-
-### High
-- [File:Line] Description | Impact | Suggested Fix
-
-### Medium
-...
-
-### Low
-...
-```
-
-#### Step 5: Output Summary
-Display to conversation:
-- Overall debt score and trend
-- Top 3 highest-impact items to address first
-- Estimated effort categories (quick fix / medium effort / large refactor)
-
-#### Step 6: Suggest Action Items
-Recommend top 3 highest-impact debt items to address first, considering:
-- Severity (critical > high > medium > low)
-- Blast radius (how many modules affected)
-- Effort to fix (prefer quick wins)
-- Risk if left unaddressed