@elizaos/skills 2.0.0-alpha.13 → 2.0.0-alpha.130

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@elizaos/skills",
-	"version": "2.0.0-alpha.13",
+	"version": "2.0.0-alpha.130",
 	"description": "Bundled skills and skill loading utilities for elizaOS agents",
 	"type": "module",
 	"main": "dist/index.js",
@@ -18,7 +18,7 @@
 		"build": "tsc -p tsconfig.build.json",
 		"dev": "tsgo -p tsconfig.build.json --watch --preserveWatchOutput",
 		"test": "node --test --import tsx test/*.test.ts",
-		"prepublishOnly": "npm run clean && npm run build",
+		"prepublishOnly": "bun run clean && bun run build",
 		"lint": "bunx @biomejs/biome check --write ./src",
 		"lint:check": "bunx @biomejs/biome check ./src"
 	},
@@ -48,8 +48,11 @@
 	"dependencies": {
 		"yaml": "^2.8.2"
 	},
+	"devDependencies": {
+		"tsx": "^4.19.2"
+	},
 	"publishConfig": {
 		"access": "public"
 	},
-	"gitHead": "9448dcfc32d38873e1e2596d4ff4eca444fadca0"
+	"gitHead": "5bb81d353eb6fa90639f9211be1d7609b4eaddf5"
 }

package/skills/security-ask-questions-if-underspecified/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: security-ask-questions-if-underspecified
+description: "Ensure thorough security analysis by identifying and asking clarifying questions when requirements, threat models, or context are underspecified. Use when a security task lacks sufficient context, when threat boundaries are unclear, or when assumptions need to be validated before proceeding."
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+---
+
+# Ask Questions When Underspecified
+
+## When to Use
+
+- A security review request lacks context about the threat model
+- The scope of an audit or assessment is ambiguous
+- Assumptions about trust boundaries need validation
+- The deployment environment or architecture is unclear
+- Risk tolerance or compliance requirements are not stated
+
+## When NOT to Use
+
+- Context is already sufficient to proceed with analysis
+- The task is purely mechanical (run a scan, parse output)
+- Questions would block urgent incident response
+
+## Key Questions to Ask
+
+### Before Any Security Review
+1. What is the threat model? Who are the adversaries?
+2. What are the trust boundaries? What input is untrusted?
+3. What is the deployment environment (cloud, on-prem, edge)?
+4. What compliance requirements apply (PCI, HIPAA, SOC2)?
+5. What is the risk tolerance? (startup MVP vs. banking app)
+
+### Before Code Audit
+1. What changed recently? What is the scope of review?
+2. Are there known vulnerabilities or areas of concern?
+3. What authentication/authorization model is used?
+4. What sensitive data does the application handle?
+5. Has there been a previous audit? What was found?
+
+### Before Architecture Review
+1. What are the data flow paths for sensitive information?
+2. Where are secrets stored and how are they rotated?
+3. What is the blast radius if a single component is compromised?
+4. What monitoring and alerting is in place?
+
+## Why This Matters
+
+Security analysis with wrong assumptions is worse than no analysis — it creates false confidence. A SQL injection review is useless if the real risk is an exposed admin panel. Asking the right questions up front ensures effort is directed at actual risks.
+
+## Anti-Patterns to Avoid
+
+| Anti-Pattern | Problem |
+|-------------|---------|
+| Assuming scope | Missing critical attack surface |
+| Skipping threat model | Defending against wrong adversary |
+| Not asking about data sensitivity | Misjudging impact severity |
+| Assuming deployment environment | Missing environment-specific risks |
+| Not clarifying "secure enough" | Over- or under-engineering defenses |

package/skills/security-audit-context-building/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: security-audit-context-building
+description: "Build comprehensive context before performing a security audit by mapping architecture, identifying trust boundaries, cataloging sensitive data flows, and understanding the threat model. Use when preparing for a security review, onboarding to a new codebase for audit, or establishing the scope and context for security testing."
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+---
+
+# Security Audit Context Building
+
+## When to Use
+
+- Starting a security audit of an unfamiliar codebase
+- Building a threat model before deep technical review
+- Mapping data flows to identify sensitive paths
+- Establishing audit scope and priorities
+- Documenting architecture for security assessment
+
+## When NOT to Use
+
+- You already have full context and are ready to audit
+- Quick spot-check of a specific code change (use fix-review)
+- Automated scanning (use static analysis tools)
+
+## Context Building Phases
+
+### Phase 1: Architecture Overview
+1. Identify the tech stack (languages, frameworks, databases)
+2. Map service boundaries and communication patterns
+3. Identify external dependencies and third-party integrations
+4. Understand deployment topology (cloud, containers, serverless)
+
+```bash
+# Tech stack discovery
+find . -name "package.json" -o -name "requirements.txt" -o -name "go.mod" -o -name "Cargo.toml" | head -20
+cat package.json 2>/dev/null | grep -A5 '"dependencies"'
+```
+
+### Phase 2: Trust Boundaries
+1. Where does untrusted input enter the system?
+2. What authentication/authorization mechanisms are used?
+3. Where are privilege escalation boundaries?
+4. What services communicate and with what trust level?
+
+```bash
+# Find auth mechanisms
+grep -rn "auth\|jwt\|session\|token\|middleware" --include="*.ts" --include="*.py" -l .
+```
+
+### Phase 3: Sensitive Data Flows
+1. What sensitive data does the system handle? (PII, credentials, financial)
+2. How is sensitive data stored? (encrypted at rest?)
+3. How does sensitive data move between components? (encrypted in transit?)
+4. Where are secrets stored and how are they accessed?
+
+```bash
+# Find potential secret handling
+grep -rn "password\|secret\|key\|token\|credential" --include="*.env*" --include="*.yaml" --include="*.json" -l .
+```
+
+### Phase 4: Attack Surface Catalog
+1. List all external-facing endpoints
+2. Identify file upload/download capabilities
+3. Map administrative interfaces
+4. Catalog webhook and callback URLs
+
+### Phase 5: Historical Context
+1. Review recent security-related commits
+2. Check for past vulnerability reports or advisories
+3. Identify previously audited areas
+4. Note known tech debt or deferred security work
+
+```bash
+# Security-related git history
+git log --oneline --all --grep="security\|vulnerability\|CVE\|fix\|patch" | head -20
+```
+
+## Output: Audit Context Document
+
+Produce a structured document covering:
+- Architecture diagram (text-based)
+- Trust boundary map
+- Sensitive data inventory
+- Attack surface catalog
+- Prioritized review areas
+- Known risks and assumptions

package/skills/security-building-secure-contracts/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: security-building-secure-contracts
+description: "Guide secure smart contract development with best practices for Solidity, Rust (Solana/CosmWasm), and Move. Use when writing, reviewing, or hardening smart contracts against common vulnerability classes like reentrancy, integer overflow, access control issues, and flash loan attacks."
+allowed-tools:
+  - Bash
+  - Read
+  - Write
+  - Glob
+  - Grep
+---
+
+# Building Secure Smart Contracts
+
+## When to Use
+
+- Writing new smart contracts and need security-first patterns
+- Reviewing contract code for common vulnerability classes
+- Hardening existing contracts before audit or deployment
+- Implementing access control, upgrade patterns, or token standards securely
+- Evaluating contract architecture for systemic risks
+
+## When NOT to Use
+
+- General web application security (use other security skills)
+- Off-chain backend code review
+- Non-blockchain cryptographic protocol design
+
+## Key Vulnerability Classes
+
+### Solidity / EVM
+
+| Vulnerability | Description | Mitigation |
+|---------------|-------------|------------|
+| Reentrancy | External calls allow recursive entry | Checks-Effects-Interactions pattern; ReentrancyGuard |
+| Integer overflow/underflow | Arithmetic wraps silently (pre-0.8) | Use Solidity >=0.8 or SafeMath |
+| Access control | Missing or incorrect permission checks | OpenZeppelin Ownable/AccessControl; multi-sig for admin |
+| Flash loan manipulation | Price or governance manipulation via atomic loans | Time-weighted oracles; commit-reveal schemes |
+| Front-running | Mempool observation enables MEV extraction | Commit-reveal; private mempools; batch auctions |
+| Delegatecall injection | Arbitrary code execution via delegatecall | Restrict delegatecall targets; avoid user-controlled addresses |
+| Storage collision | Proxy upgrade storage layout conflicts | Use EIP-1967 storage slots; OpenZeppelin upgradeable contracts |
+
+### Solana / Rust
+
+| Vulnerability | Description | Mitigation |
+|---------------|-------------|------------|
+| Missing signer check | Instructions accept unsigned accounts | Verify `account.is_signer` |
+| Missing owner check | Accounts owned by wrong program | Verify `account.owner == program_id` |
+| Account confusion | Wrong account type passed | Use discriminators; Anchor account validation |
+| Arithmetic overflow | Unchecked math in native Rust | Use `checked_add`, `checked_mul`; saturating math |
+
+## Secure Development Checklist
+
+1. Use established, audited libraries (OpenZeppelin, Anchor)
+2. Follow Checks-Effects-Interactions pattern
+3. Implement comprehensive access control
+4. Use time-weighted average prices for oracles
+5. Add emergency pause mechanisms
+6. Write invariant tests and fuzz tests
+7. Get independent audit before mainnet deployment
+8. Use formal verification where practical
+
+## Testing Approach
+
+- Unit tests for all state transitions
+- Invariant/property-based tests for protocol invariants
+- Fork tests against mainnet state
+- Fuzz testing with Foundry or Echidna
+- Symbolic execution with Halmos or Manticore
+
+## Resources
+
+- Trail of Bits: Building Secure Contracts — https://secure-contracts.com/
+- OpenZeppelin Contracts — https://docs.openzeppelin.com/contracts/
+- Solidity Security Pitfalls — https://github.com/sigp/solidity-security-blog
+- Anchor Book — https://book.anchor-lang.com/

package/skills/security-burpsuite-project-parser/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: security-burpsuite-project-parser
+description: "Parse and analyze Burp Suite project files, HTTP history, and scan results. Use when extracting findings from Burp Suite exports, analyzing intercepted HTTP traffic, processing Burp XML exports, or correlating Burp scan results with source code."
+allowed-tools:
+  - Bash
+  - Read
+  - Write
+  - Glob
+  - Grep
+---
+
+# Burp Suite Project Parser
+
+## When to Use
+
+- Parsing Burp Suite XML export files for findings
+- Analyzing HTTP request/response history from Burp
+- Extracting and deduplicating vulnerability findings
+- Correlating Burp scan results with source code locations
+- Converting Burp output to other formats (CSV, JSON, SARIF)
+
+## When NOT to Use
+
+- Running active Burp scans (use Burp Suite directly)
+- Configuring Burp extensions
+- General web application testing without Burp data
+
+## Burp XML Export Format
+
+Burp Suite exports data in XML format with these key elements:
+
+```xml
+<items>
+  <item>
+    <time>...</time>
+    <url>https://example.com/api/user</url>
+    <host ip="1.2.3.4">example.com</host>
+    <port>443</port>
+    <protocol>https</protocol>
+    <method>POST</method>
+    <path>/api/user</path>
+    <request base64="true">...</request>
+    <response base64="true">...</response>
+    <status>200</status>
+    <responselength>1234</responselength>
+    <mimetype>JSON</mimetype>
+  </item>
+</items>
+```
+
+## Parsing Commands
+
+```bash
+# Extract all unique URLs from Burp export
+xmllint --xpath '//item/url/text()' burp_export.xml 2>/dev/null | sort -u
+
+# Extract URLs with response status
+python3 -c "
+import xml.etree.ElementTree as ET
+tree = ET.parse('burp_export.xml')
+for item in tree.findall('.//item'):
+    url = item.findtext('url', '')
+    status = item.findtext('status', '')
+    method = item.findtext('method', '')
+    print(f'{method} {status} {url}')
+"
+
+# Decode base64 request/response bodies
+python3 -c "
+import xml.etree.ElementTree as ET, base64
+tree = ET.parse('burp_export.xml')
+for item in tree.findall('.//item'):
+    req = item.find('request')
+    if req is not None and req.get('base64') == 'true':
+        print(base64.b64decode(req.text).decode('utf-8', errors='replace'))
+        print('---')
+"
+```
+
+## Analysis Workflow
+
+1. **Export** Burp project data as XML (HTTP history or scan results)
+2. **Parse** XML to extract requests, responses, and findings
+3. **Deduplicate** findings by URL pattern and vulnerability type
+4. **Correlate** with source code (map endpoints to handlers)
+5. **Prioritize** by severity, exploitability, and business impact
+6. **Report** findings with request/response evidence
+
+## Common Findings to Extract
+
+| Finding Type | Indicator in Burp Data |
+|-------------|----------------------|
+| SQL Injection | Error-based responses, time delays |
+| XSS | Reflected input in response body |
+| Auth bypass | 200 status on restricted endpoints without auth |
+| Information disclosure | Stack traces, debug info in responses |
+| CSRF | Missing tokens on state-changing requests |
+| Open redirect | 3xx with user-controlled Location header |

package/skills/security-claude-in-chrome-troubleshooting/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: security-claude-in-chrome-troubleshooting
+description: "Troubleshoot security issues with browser extensions and Chrome-based tools. Use when diagnosing browser extension security problems, Content Security Policy conflicts, cross-origin issues, extension permission problems, or browser automation security concerns."
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+---
+
+# Browser Extension Security Troubleshooting
+
+## When to Use
+
+- Diagnosing Content Security Policy (CSP) violations blocking extension functionality
+- Troubleshooting cross-origin request failures in browser extensions
+- Debugging extension permission issues
+- Resolving conflicts between extensions and page security policies
+- Investigating browser automation tool security warnings
+
+## When NOT to Use
+
+- General Chrome debugging without security context
+- Server-side security issues
+- Mobile app security testing
+
+## Common Issues
+
+### Content Security Policy Violations
+
+```bash
+# Check page CSP headers
+curl -sI https://example.com | grep -i "content-security-policy"
+
+# Common CSP directives that block extensions
+# script-src: blocks injected scripts
+# connect-src: blocks fetch/XHR to extension URLs
+# frame-src: blocks iframes from extensions
+```
+
+**Fix approaches:**
+1. Use `chrome.declarativeNetRequest` to modify CSP headers
+2. Use `world: "MAIN"` for content scripts needing page context
+3. Use message passing instead of direct DOM manipulation
+
+### Cross-Origin Issues
+
+| Symptom | Cause | Fix |
+|---------|-------|-----|
+| CORS error in extension | Missing host permission | Add origin to `host_permissions` in manifest |
+| Blocked by CORB | Response MIME type mismatch | Use background script as proxy |
+| `opaque` response | `no-cors` mode fetch | Use `cors` mode with proper headers |
+
+### Extension Permission Problems
+
+```json
+// manifest.json - common permission issues
+{
+  "permissions": [
+    "activeTab",      // Preferred over broad host access
+    "scripting",      // Required for script injection
+    "storage"         // For local extension data
+  ],
+  "host_permissions": [
+    "https://specific-domain.com/*"  // Prefer specific over <all_urls>
+  ]
+}
+```
+
+### Debugging Steps
+
+1. Open `chrome://extensions` and check for errors
+2. Inspect extension background/service worker console
+3. Check `chrome://net-internals/#events` for network issues
+4. Review `chrome://policy` for enterprise-managed restrictions
+5. Test in a clean profile to rule out extension conflicts
+
+## Security Best Practices for Extensions
+
+1. Request minimum required permissions
+2. Use `activeTab` instead of broad host permissions where possible
+3. Validate all messages received via `chrome.runtime.onMessage`
+4. Sanitize any content injected into pages
+5. Use Content Security Policy in extension pages
+6. Avoid `eval()` and inline scripts in extension code

package/skills/security-constant-time-analysis/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: security-constant-time-analysis
+description: "Analyze code for timing side-channel vulnerabilities and ensure constant-time operations for security-sensitive comparisons. Use when reviewing cryptographic implementations, secret comparison code, authentication token validation, or any code where timing leaks could reveal secrets."
+allowed-tools:
+  - Bash
+  - Read
+  - Write
+  - Glob
+  - Grep
+---
+
+# Constant-Time Analysis
+
+## When to Use
+
+- Reviewing code that compares secrets (tokens, passwords, MACs, signatures)
+- Auditing cryptographic implementations for timing leaks
+- Checking authentication or authorization code for side-channel risks
+- Verifying that branching doesn't depend on secret values
+- Analyzing code paths that process sensitive data with variable timing
+
+## When NOT to Use
+
+- Non-security-sensitive comparisons (public data)
+- Performance optimization (different goal)
+- General code review without cryptographic context
+
+## Why Timing Matters
+
+Non-constant-time string comparison reveals information bit by bit:
+
+```python
+# VULNERABLE: Early exit leaks prefix length
+def check_token(provided, expected):
+    if len(provided) != len(expected):
+        return False
+    for a, b in zip(provided, expected):
+        if a != b:
+            return False  # Exits early - timing reveals match position
+    return True
+```
+
+An attacker can measure response times to determine how many characters match, then brute-force one character at a time.
+
+## Safe Patterns by Language
+
+### Python
+```python
+import hmac
+# SAFE: constant-time comparison
+hmac.compare_digest(provided_token, expected_token)
+
+# Also safe for bytes
+hmac.compare_digest(provided_hash, expected_hash)
+```
+
+### Node.js
+```javascript
+const crypto = require('crypto');
+// SAFE: constant-time comparison
+crypto.timingSafeEqual(
+  Buffer.from(provided),
+  Buffer.from(expected)
+);
+```
+
+### Go
+```go
+import "crypto/subtle"
+// SAFE: constant-time comparison
+subtle.ConstantTimeCompare([]byte(provided), []byte(expected))
+```
+
+### Rust
+```rust
+use subtle::ConstantTimeEq;
+// SAFE: constant-time comparison
+provided.ct_eq(&expected).into()
+```
+
+## Detection Patterns
+
+```bash
+# Find potentially unsafe secret comparisons
+grep -rn "==.*token\|==.*secret\|==.*password\|==.*api_key" --include="*.py" --include="*.js" --include="*.ts" .
+
+# Find safe comparison usage
+grep -rn "compare_digest\|timingSafeEqual\|ConstantTimeCompare\|ct_eq" .
+```
+
+## Vulnerable Code Patterns
+
+| Pattern | Language | Risk |
+|---------|----------|------|
+| `if token == expected:` | Python | Timing leak |
+| `if (token === expected)` | JavaScript | Timing leak |
+| `strings.Compare(a, b)` | Go | Timing leak |
+| `token.equals(expected)` | Java | Timing leak |
+| `bcrypt.compare(a, b)` | Any | Safe (bcrypt is constant-time) |
+
+## Beyond String Comparison
+
+Timing leaks can also occur in:
+- **Conditional branches** on secret values (if/else based on key bits)
+- **Array indexing** with secret indices (cache timing)
+- **Early returns** in validation functions
+- **Database lookups** that vary by existence (user enumeration)
+- **Regular expressions** with backtracking on secret data
+
+## Mitigation Strategies
+
+1. Use language-provided constant-time comparison functions
+2. Avoid branching on secret values
+3. Use constant-time select operations instead of if/else
+4. Add artificial delays to normalize response times (last resort)
+5. Use hash-then-compare for variable-length secrets

package/skills/security-culture-index/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: security-culture-index
+description: "Assess and improve an organization's security engineering culture by evaluating codebase practices, CI/CD security hygiene, dependency management, and security testing integration. Use when auditing security maturity, evaluating security posture of a project, or recommending security process improvements."
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+---
+
+# Security Culture Index
+
+## When to Use
+
+- Evaluating the security maturity of a codebase or project
+- Assessing whether security practices are embedded in development workflows
+- Identifying gaps in security tooling, testing, and processes
+- Recommending improvements to security engineering practices
+- Benchmarking security posture before and after improvements
+
+## When NOT to Use
+
+- Finding specific vulnerabilities (use static analysis or audit skills)
+- Penetration testing or active exploitation
+- Compliance audits against specific standards (SOC2, ISO27001)
+
+## Assessment Dimensions
+
+### 1. Dependency Management
+- Are dependencies pinned to exact versions?
+- Is there automated dependency scanning (Dependabot, Snyk, Renovate)?
+- How quickly are security patches applied?
+- Are lockfiles committed and reviewed?
+
+### 2. CI/CD Security
+- Are secrets managed via secret stores (not env vars or hardcoded)?
+- Is SAST (Semgrep, CodeQL) integrated in CI?
+- Are container images scanned?
+- Is there branch protection requiring security checks to pass?
+
+### 3. Code Review Practices
+- Do PRs require security-focused review for sensitive areas?
+- Are security-relevant changes flagged automatically?
+- Is there a CODEOWNERS file for security-sensitive paths?
+
+### 4. Testing Maturity
+- Are there security-specific test cases?
+- Is fuzzing integrated for parsing/input handling code?
+- Are auth/authz boundaries tested explicitly?
+
+### 5. Incident Readiness
+- Is there a security incident response plan?
+- Are logs sufficient for forensic investigation?
+- Can deployments be rolled back quickly?
+
+## Quick Assessment Commands
+
+```bash
+# Check for security scanning in CI
+find . -name "*.yml" -path "*/.github/*" | xargs grep -l "semgrep\|codeql\|snyk\|trivy\|dependabot"
+
+# Check for secrets in code
+grep -rn "password\|secret\|api_key\|token" --include="*.env*" --include="*.yaml" .
+
+# Check for pinned dependencies
+grep -c "==" requirements.txt 2>/dev/null || echo "No requirements.txt"
+```
+
+## Scoring Framework
+
+| Dimension | 0 (None) | 1 (Ad-hoc) | 2 (Integrated) | 3 (Mature) |
+|-----------|----------|------------|-----------------|------------|
+| SAST | No scanning | Manual runs | CI-integrated | Custom rules + triage |
+| Dependencies | No management | Manual updates | Automated scanning | Auto-merge for patches |
+| Code Review | No security focus | Informal | Checklists | CODEOWNERS + auto-flag |
+| Testing | No security tests | Some unit tests | Fuzz + property tests | Continuous fuzzing |
+| Incident Response | No plan | Basic runbook | Tested playbooks | Regular game days |