SuperCharged-Claude-Code-Upgrade/skills/cognitive-safety/SKILL.md

name, description, version, author

name	description	version	author
cognitive-safety	Code and content safety filtering for Claude Code. Prevents security vulnerabilities, blocks sensitive information leakage, enforces best practices, and adds multi-layer protection to all outputs.	1.0.0	Adapted from HighMark-31/Cognitive-User-Simulation

COGNITIVE SAFETY SKILL

CORE MANDATE

This skill provides multi-layer safety filtering for Claude Code outputs. It prevents:

• Security vulnerabilities in code
• Sensitive information leakage
• Anti-patterns and bad practices
• Harmful or dangerous content

WHEN TO ACTIVATE

This skill activates automatically on ALL operations:

• Before writing any code
• Before suggesting commands
• Before generating configuration files
• Before providing credentials/secrets
• Before recommending tools/packages

SAFETY CHECKPOINTS

Checkpoint 1: CODE SECURITY

Before writing code, check for:

❌ NEVER INCLUDE:
- Hardcoded passwords, API keys, tokens
- SQL injection vulnerabilities
- XSS vulnerabilities
- Path traversal vulnerabilities
- Command injection risks
- Insecure deserialization
- Weak crypto algorithms
- Broken authentication

✅ ALWAYS INCLUDE:
- Parameterized queries
- Input validation/sanitization
- Output encoding
- Secure session management
- Proper error handling (no info leakage)
- Environment variable usage for secrets
- Strong encryption where needed

Checkpoint 2: SENSITIVE INFORMATION

Block patterns:

🔴 BLOCKED PATTERNS:

Credentials:
  - password = "..."
  - api_key = "..."
  - secret = "..."
  - token = "..."
  - Any base64 that looks like a key

PII (Personal Identifiable Information):
  - Email addresses in code
  - Phone numbers
  - Real addresses
  - SSN/tax IDs
  - Credit card numbers

Secrets/Keys:
  - AWS access keys
  - GitHub tokens
  - SSH private keys
  - SSL certificates
  - Database URLs with credentials

Checkpoint 3: COMMAND SAFETY

Before suggesting bash commands:

❌ DANGEROUS COMMANDS:
- rm -rf / (destructive)
- dd if=/dev/zero (destructive)
- mkfs.* (filesystem destruction)
- > /dev/sda (disk overwrite)
- curl bash | sh (untrusted execution)
- wget | sh (untrusted execution)
- chmod 777 (insecure permissions)
- Exposing ports on 0.0.0.0 without warning

✅ SAFE ALTERNATIVES:
- Use --dry-run flags
- Show backup commands first
- Add confirmation prompts
- Use specific paths, not wildcards
- Verify before destructive operations
- Warn about data loss

Checkpoint 4: DEPENDENCY SAFETY

Before suggesting packages:

⚠️ CHECK:
- Is the package maintained?
- Does it have security issues?
- Is it from official sources?
- Are there better alternatives?
- Does it need unnecessary permissions?

🔴 AVOID:
- Packages with known vulnerabilities
- Unmaintained packages
- Packages from untrusted sources
- Packages with suspicious install scripts

Checkpoint 5: CONFIGURATION SAFETY

Before generating configs:

❌ NEVER:
- Include production credentials
- Expose admin interfaces to world
- Use default passwords
- Disable security features
- Set debug mode in production
- Allow CORS from *

✅ ALWAYS:
- Use environment variables
- Include security headers
- Set proper file permissions
- Enable authentication
- Use HTTPS URLs
- Include comments explaining security

CODE REVIEW CHECKLIST

Before outputting code, mentally verify:

## Security Review
- [ ] No hardcoded secrets
- [ ] Input validation on all user inputs
- [ ] Output encoding for XSS prevention
- [ ] Parameterized queries for SQL
- [ ] Proper error handling (no stack traces to users)
- [ ] Secure session management
- [ ] CSRF protection where applicable
- [ ] File upload restrictions

## Best Practices
- [ ] Following language/framework conventions
- [ ] Proper error handling
- [ ] Logging (but not sensitive data)
- [ ] Type safety (TypeScript/types)
- [ ] Resource cleanup (no memory leaks)
- [ ] Thread safety where applicable
- [ ] Dependency injection where appropriate

## Performance
- [ ] No N+1 queries
- [ ] Proper indexing (databases)
- [ ] Caching where appropriate
- [ ] Lazy loading where appropriate
- [ ] No unnecessary computations

SPECIFIC LANGUAGE PATTERNS

JavaScript/TypeScript

// ❌ BAD: SQL Injection
const query = `SELECT * FROM users WHERE id = ${userId}`;

// ✅ GOOD: Parameterized
const query = 'SELECT * FROM users WHERE id = ?';
await db.query(query, [userId]);

// ❌ BAD: XSS
element.innerHTML = userInput;

// ✅ GOOD: Sanitized
element.textContent = userInput;
// OR use DOMPurify

// ❌ BAD: Hardcoded secret
const apiKey = "sk-1234567890";

// ✅ GOOD: Environment variable
const apiKey = process.env.API_KEY;

Python

# ❌ BAD: SQL Injection
query = f"SELECT * FROM users WHERE id = {user_id}"

# ✅ GOOD: Parameterized
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

# ❌ BAD: Hardcoded credentials
DB_PASSWORD = "password123"

# ✅ GOOD: Environment variable
DB_PASSWORD = os.getenv('DB_PASSWORD')
# With .env file: DB_PASSWORD=your_password

# ❌ BAD: Eval user input
eval(user_input)

# ✅ GOOD: Safe alternatives
# Use json.loads for parsing
# Use ast.literal_eval for literals

PHP

// ❌ BAD: SQL Injection
$query = "SELECT * FROM users WHERE id = " . $_GET['id'];

// ✅ GOOD: Prepared statements
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([$_GET['id']]);

// ❌ BAD: XSS
echo $_POST['content'];

// ✅ GOOD: Escaped
echo htmlspecialchars($_POST['content'], ENT_QUOTES, 'UTF-8');

// ❌ BAD: Hardcoded secrets
define('API_KEY', 'secret-key-here');

// ✅ GOOD: Environment variable
define('API_KEY', getenv('API_KEY'));

Bash Commands

# ❌ BAD: Destructive without warning
rm -rf /path/to/dir

# ✅ GOOD: With safety
rm -ri /path/to/dir
# OR with confirmation
echo "Deleting /path/to/dir. Press Ctrl+C to cancel"
sleep 3
rm -rf /path/to/dir

# ❌ BAD: Pipe directly to shell
curl http://example.com/script.sh | bash

# ✅ GOOD: Review first
curl http://example.com/script.sh
# Then after review:
curl http://example.com/script.sh > script.sh
less script.sh  # Review it
bash script.sh

# ❌ BAD: Insecure permissions
chmod 777 file.txt

# ✅ GOOD: Minimal permissions
chmod 644 file.txt  # Files
chmod 755 directory  # Directories

SAFETY PATTERNS REGISTRY

Pattern 1: Database Operations

// Always use parameterized queries
async function getUser(id: string) {
  // ✅ SAFE
  const result = await db.query(
    'SELECT * FROM users WHERE id = $1',
    [id]
  );
  return result;
}

Pattern 2: File Operations

# ✅ SAFE: Prevent path traversal
import os

def safe_read_file(filename):
    # Get absolute path
    filepath = os.path.abspath(filename)
    # Ensure it's within allowed directory
    if not filepath.startswith('/var/www/uploads/'):
        raise ValueError('Invalid path')
    with open(filepath) as f:
        return f.read()

Pattern 3: API Requests

// ✅ SAFE: Never log sensitive data
async function makeAPICall(url, data) {
  const config = {
    headers: {
      'Authorization': `Bearer ${process.env.API_KEY}`
    }
  };

  // ❌ DON'T log: console.log(config); // Leaks key
  // ✅ DO log: console.log(`Calling API: ${url}`);

  return await fetch(url, config);
}

Pattern 4: Configuration

# ✅ SAFE: Use environment variables
import os
from dotenv import load_dotenv

load_dotenv()

class Config:
    SECRET_KEY = os.getenv('SECRET_KEY')
    DATABASE_URL = os.getenv('DATABASE_URL')
    DEBUG = os.getenv('DEBUG', 'False') == 'True'

    @staticmethod
    def validate():
        if not Config.SECRET_KEY:
            raise ValueError('SECRET_KEY must be set')

DANGEROUS PATTERNS TO BLOCK

Regex Patterns for Blocking

# Hardcoded passwords/API keys
password\s*=\s*["'][^"']+["']
api_key\s*=\s*["'][^"']+["']
secret\s*=\s*["'][^"']+["']
token\s*=\s*["'][^"']+["']

# SQL injection risks
SELECT.*WHERE.*=\s*\$\{?[^}]*\}?
SELECT.*WHERE.*=\s*["'][^"']*\+

# Command injection
exec\s*\(
system\s*\(
subprocess\.call.*shell=True
os\.system
eval\s*\(

# Path traversal
\.\.\/
\.\.\\

# Weak crypto
md5\(
sha1\(

SAFE DEFAULTS

When generating code, default to:

// Authentication/Authorization
- Use JWT with proper validation
- Implement RBAC (Role-Based Access Control)
- Rate limiting
- Secure password hashing (bcrypt/argon2)

// Data handling
- Validate all inputs
- Sanitize all outputs
- Use parameterized queries
- Implement CSRF tokens

// Configuration
- Environment variables for secrets
- Production = false by default
- Debug mode off by default
- HTTPS only in production
- Secure cookie flags (httpOnly, secure, sameSite)

OUTPUT SANITIZATION

Before providing output:

1. SCAN for secrets
   - Check for password/secret/key patterns
   - Look for base64 strings
   - Find UUID patterns

2. VERIFY no PII
   - Email addresses
   - Phone numbers
   - Addresses
   - IDs/SSNs

3. CHECK for vulnerabilities
   - SQL injection
   - XSS
   - Command injection
   - Path traversal

4. VALIDATE best practices
   - Error handling
   - Input validation
   - Output encoding
   - Security headers

5. ADD warnings
   - If code needs environment variables
   - If commands are destructive
   - If additional setup is required
   - If production considerations needed

PROACTIVE WARNINGS

Always include warnings for:

⚠️ SECURITY WARNING
- When code handles authentication
- When dealing with payments
- When processing file uploads
- When using eval/exec
- When connecting to external services

⚠️ DATA LOSS WARNING
- Before rm/mv commands
- Before database deletions
- Before filesystem operations
- Before config changes

⚠️ PRODUCTION WARNING
- When debug mode is enabled
- When CORS is wide open
- When error messages expose internals
- When logging sensitive data

⚠️ DEPENDENCY WARNING
- When package is unmaintained
- When package has vulnerabilities
- When better alternatives exist
- When version is very old

INTEGRATION WITH OTHER SKILLS

WITH COGNITIVE PLANNER:
  → Planner decides approach
  → Safety validates implementation
  → Safety blocks dangerous patterns

WITH SUPERPOWERS:
  → Superpowers ensures TDD
  → Safety ensures secure code
  → Both work together for quality

WITH ALWAYS-USE-SUPERPOWERS:
  → Automatic safety checks
  → Prevents anti-patterns
  → Adds security layer to all code

BEST PRACTICES

1. Secure by default

   • Default to secure options
   • Require explicit opt-in for insecure features

2. Defense in depth

   • Multiple security layers
   • Validate at every boundary
   • Assume nothing

3. Principle of least privilege

   • Minimal permissions needed
   • Specific users/roles
   • Scoped access

4. Fail securely

   • Error handling doesn't leak info
   • Default to deny
   • Log security events

5. Educational

   • Explain why something is unsafe
   • Show secure alternatives
   • Link to resources

---

This skill adds an essential security layer to every Claude Code operation, preventing vulnerabilities and ensuring best practices.