prizmkit 1.0.152 → 1.1.0

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