@elizaos/skills 2.0.0-alpha.10

package/skills/semgrep-rule-creator/skills/semgrep-rule-creator/references/workflow.md

@@ -0,0 +1,240 @@
+# Semgrep Rule Creation Workflow
+
+Detailed workflow for creating production-quality Semgrep rules.
+
+## Step 1: Analyze the Problem
+
+Before writing any code:
+
+1. **Fetch external documentation**: See [Documentation](../SKILL.md#documentation) for required reading
+2. **Understand the exact bug pattern and explain the bug for a junior developer**: What vulnerability, issue or pattern should be detected?
+3. **Identify the target language**: What is specific about the bug and that language?
+4. **Determine the approach**:
+   - **Pattern matching**: Syntactic patterns without data flow
+   - **Taint mode**: Data flows from untrusted source to dangerous sink
+
+### When to Use Taint Mode
+
+Taint mode is a powerful feature in Semgrep that can track the flow of data from one location to another. By using taint mode, you can:
+
+- **Track data flow across multiple variables**: Trace how data moves across different variables, functions, components, and identify insecure flow paths (e.g., situations where a specific sanitizer is not used).
+- **Find injection vulnerabilities**: Identify injection vulnerabilities such as SQL injection, command injection, and XSS attacks.
+- **Write simple and resilient Semgrep rules**: Simplify rules that are resilient to code patterns nested in if statements, loops, and other structures.
+
+## Step 2: Write Tests First
+
+**Why test-first?** Writing tests before the rule forces you to think about both vulnerable AND safe cases. Rules written without tests often have hidden false positives (matching safe cases) or false negatives (missing vulnerable variants). Tests make these visible immediately.
+
+Create directory and test file with annotations (`# ruleid:`, `# ok:` only). See [quick-reference.md]({baseDir}/references/quick-reference.md#test-file-annotations) for full syntax.
+
+### Directory Structure
+
+```
+<rule-id>/
+├── <rule-id>.yaml     # Semgrep rule
+└── <rule-id>.<ext>    # Test file with ruleid/ok annotations
+```
+
+**CRITICAL**:
+1. The comment (`# ruleid:` or `# ok:` ) must be on the line IMMEDIATELY BEFORE the code. Semgrep reports findings on the line after the annotation.
+2. The comment must contain ONLY the comment marker and annotation (e.g., `# ruleid: my-rule`). No other text, comments, or code on the same line.
+
+### Test Case Design
+
+You must include test cases for:
+- Clear vulnerable cases (must match)
+- Clear safe cases (must not match)
+- Edge cases and variations
+- Different coding styles
+- Sanitized/validated input (must not match)
+- Unrelated code (must not match) - normal code with no relation to the rule's target pattern
+- Nested structures (e.g., inside if statements, loops, try/catch blocks, callbacks)
+
+## Step 3: Analyze AST Structure
+
+**Why analyze AST?** Semgrep matches against the AST, not raw text. Code that looks similar may parse differently (e.g., `foo.bar()` vs `foo().bar`). The AST dump shows exactly what Semgrep sees, preventing patterns that fail due to unexpected tree structure. Understanding how exactly Semgrep parses code is crucial for writing precise patterns.
+
+```bash
+semgrep --dump-ast -l <language> <rule-id>.<ext>
+```
+
+Example output helps understand:
+- How function calls are represented
+- How variables are bound
+- How control flow is structured
+
+## Step 4: Write the Rule
+
+Choose the appropriate pattern operators and write the rule.
+
+For pattern operator syntax (basic matching, scope operators, metavariable filters, focus), see [quick-reference.md](quick-reference.md).
+
+### Validate and Test
+
+#### Validate YAML Syntax
+
+```bash
+semgrep --validate --config <rule-id>.yaml
+```
+
+#### Run Tests
+
+```bash
+cd <rule-directory>
+semgrep --test --config <rule-id>.yaml <rule-id>.<ext>
+```
+
+#### Expected Output
+
+```
+1/1: ✓ All tests passed
+```
+
+#### Debug Failures
+
+If tests fail, check:
+1. **Missed lines**: Rule didn't match when it should
+   - Pattern too specific
+   - Missing pattern variant
+2. **Incorrect lines**: Rule matched when it shouldn't
+   - Pattern too broad
+   - Need `pattern-not` exclusion
+
+#### Debug Taint Mode Rules
+
+```bash
+semgrep --dataflow-traces -f <rule-id>.yaml <rule-id>.<ext>
+```
+
+Shows:
+- Source locations
+- Sink locations
+- Data flow path
+- Why taint didn't propagate (if applicable)
+
+## Step 5: Iterate Until Tests Pass
+Work on writing Semgrep rule (patterns) iteratively to ensure the Semgrep rule works correctly.
+
+Each time when you introduce any changes, test Semgrep rule:
+
+```bash
+semgrep --test --config <rule-id>.yaml <rule-id>.<ext>
+```
+
+For debugging taint mode rules:
+```bash
+semgrep --dataflow-traces -f <rule-id>.yaml <rule-id>.<ext>
+```
+
+**Verification checkpoint**: Output MUST show "All tests passed". **Only proceed when validation passes**.
+
+
+**Verification checkpoint**: Proceed to Step 6: Optimize the Rule when:
+- "All tests passed"
+- No "missed lines" (false negatives)
+- No "incorrect lines" (false positives)
+
+### Common Fixes
+
+| Problem | Solution |
+|---------|----------|
+| Too many matches | Add `pattern-not` exclusions |
+| Missing matches | Add `pattern-either` variants |
+| Wrong line matched | Adjust `focus-metavariable` |
+| Taint not flowing | Check sanitizers aren't too broad |
+| Taint false positive | Add sanitizer pattern |
+
+## Step 6: Optimize the Rule
+
+After all tests pass, remove redundant patterns (quote variants, ellipsis subsets, redundant patterns).
+
+### Semgrep Pattern Equivalences
+
+Semgrep treats certain patterns as equivalent:
+
+| Written | Also Matches | Reason |
+|---------|--------------|--------|
+| `"string"` | `'string'` | Quote style normalized (in languages where both are equivalent) |
+| `func(...)` | `func()`, `func(a)`, `func(a,b)` | Ellipsis matches zero or more |
+| `func($X, ...)` | `func($X)`, `func($X, a, b)` | Trailing ellipsis is optional |
+
+### Common Redundancies to Remove
+
+**1. Quote Variants** (depends on the language)
+
+Before:
+```yaml
+pattern-either:
+  - pattern: hashlib.new("md5", ...)
+  - pattern: hashlib.new('md5', ...)
+```
+
+After:
+```yaml
+pattern-either:
+  - pattern: hashlib.new("md5", ...)
+```
+
+**2. Ellipsis Subsets**
+
+Before:
+```yaml
+pattern-either:
+  - pattern: dangerous($X, ...)
+  - pattern: dangerous($X)
+  - pattern: dangerous($X, $Y)
+```
+
+After:
+```yaml
+pattern: dangerous($X, ...)
+```
+
+**3. Consolidate with Metavariables**
+
+Before:
+```yaml
+pattern-either:
+  - pattern: md5($X)
+  - pattern: sha1($X)
+  - pattern: sha256($X)
+```
+
+After:
+```yaml
+patterns:
+  - pattern: $FUNC($X)
+  - metavariable-regex:
+      metavariable: $FUNC
+      regex: ^(md5|sha1|sha256)$
+```
+
+### Optimization Checklist
+
+1. Remove patterns differing only in quote style
+2. Remove patterns that are subsets of `...` patterns
+3. Consolidate similar patterns using metavariable-regex
+4. Remove duplicate patterns in pattern-either
+5. Simplify nested pattern-either when possible
+6. Replace complex regex patterns with metavariable-comparison
+7. **Re-run tests after each optimization**
+
+### Verify After Optimization
+
+```bash
+semgrep --test --config <rule-id>.yaml <rule-id>.<ext>
+```
+
+**CRITICAL**: Always re-run tests after optimization. Some "redundant" patterns may actually be necessary due to AST structure differences. If any test fails, revert the optimization that caused it.
+
+**Task complete ONLY when**: All tests pass after optimization.
+
+
+## Step 7: Final Run
+Run the Semgrep rule you created using: `semgrep --config <rule-id>.yaml <rule-id>.<ext>`.
+
+Ensure that message:
+ 1. Contains a short and concise explanation of the matched pattern
+ 2. Has no uninterpolated metavariables (e.g., $OP, $VAR). All metavariables referenced in the message must be captured by the pattern so they interpolate to actual code. 
+
+Fix any message issues and re-run that Semgrep rule after each fix.

package/skills/session-logs/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: session-logs
+description: Search and analyze your own session logs (older/parent conversations) using jq.
+metadata: { "otto": { "emoji": "📜", "requires": { "bins": ["jq", "rg"] } } }
+---
+
+# session-logs
+
+Search your complete conversation history stored in session JSONL files. Use this when a user references older/parent conversations or asks what was said before.
+
+## Trigger
+
+Use this skill when the user asks about prior chats, parent conversations, or historical context that isn't in memory files.
+
+## Location
+
+Session logs live at: `~/.otto/agents/<agentId>/sessions/` (use the `agent=<id>` value from the system prompt Runtime line).
+
+- **`sessions.json`** - Index mapping session keys to session IDs
+- **`<session-id>.jsonl`** - Full conversation transcript per session
+
+## Structure
+
+Each `.jsonl` file contains messages with:
+
+- `type`: "session" (metadata) or "message"
+- `timestamp`: ISO timestamp
+- `message.role`: "user", "assistant", or "toolResult"
+- `message.content[]`: Text, thinking, or tool calls (filter `type=="text"` for human-readable content)
+- `message.usage.cost.total`: Cost per response
+
+## Common Queries
+
+### List all sessions by date and size
+
+```bash
+for f in ~/.otto/agents/<agentId>/sessions/*.jsonl; do
+  date=$(head -1 "$f" | jq -r '.timestamp' | cut -dT -f1)
+  size=$(ls -lh "$f" | awk '{print $5}')
+  echo "$date $size $(basename $f)"
+done | sort -r
+```
+
+### Find sessions from a specific day
+
+```bash
+for f in ~/.otto/agents/<agentId>/sessions/*.jsonl; do
+  head -1 "$f" | jq -r '.timestamp' | grep -q "2026-01-06" && echo "$f"
+done
+```
+
+### Extract user messages from a session
+
+```bash
+jq -r 'select(.message.role == "user") | .message.content[]? | select(.type == "text") | .text' <session>.jsonl
+```
+
+### Search for keyword in assistant responses
+
+```bash
+jq -r 'select(.message.role == "assistant") | .message.content[]? | select(.type == "text") | .text' <session>.jsonl | rg -i "keyword"
+```
+
+### Get total cost for a session
+
+```bash
+jq -s '[.[] | .message.usage.cost.total // 0] | add' <session>.jsonl
+```
+
+### Daily cost summary
+
+```bash
+for f in ~/.otto/agents/<agentId>/sessions/*.jsonl; do
+  date=$(head -1 "$f" | jq -r '.timestamp' | cut -dT -f1)
+  cost=$(jq -s '[.[] | .message.usage.cost.total // 0] | add' "$f")
+  echo "$date $cost"
+done | awk '{a[$1]+=$2} END {for(d in a) print d, "$"a[d]}' | sort -r
+```
+
+### Count messages and tokens in a session
+
+```bash
+jq -s '{
+  messages: length,
+  user: [.[] | select(.message.role == "user")] | length,
+  assistant: [.[] | select(.message.role == "assistant")] | length,
+  first: .[0].timestamp,
+  last: .[-1].timestamp
+}' <session>.jsonl
+```
+
+### Tool usage breakdown
+
+```bash
+jq -r '.message.content[]? | select(.type == "toolCall") | .name' <session>.jsonl | sort | uniq -c | sort -rn
+```
+
+### Search across ALL sessions for a phrase
+
+```bash
+rg -l "phrase" ~/.otto/agents/<agentId>/sessions/*.jsonl
+```
+
+## Tips
+
+- Sessions are append-only JSONL (one JSON object per line)
+- Large sessions can be several MB - use `head`/`tail` for sampling
+- The `sessions.json` index maps chat providers (discord, whatsapp, etc.) to session IDs
+- Deleted sessions have `.deleted.<timestamp>` suffix
+
+## Fast text-only hint (low noise)
+
+```bash
+jq -r 'select(.type=="message") | .message.content[]? | select(.type=="text") | .text' ~/.otto/agents/<agentId>/sessions/<id>.jsonl | rg 'keyword'
+```

package/skills/sharp-edges/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "sharp-edges",
+  "version": "1.0.0",
+  "description": "Identify error-prone APIs, dangerous configurations, and footgun designs that enable security mistakes",
+  "author": {
+    "name": "Trail of Bits",
+    "email": "opensource@trailofbits.com",
+    "url": "https://github.com/trailofbits"
+  }
+}

package/skills/sharp-edges/README.md

@@ -0,0 +1,48 @@
+# Sharp Edges
+
+Identifies error-prone APIs, dangerous configurations, and footgun designs that enable security mistakes through developer confusion, laziness, or malice.
+
+## When to Use
+
+- Reviewing API designs for security-relevant interfaces
+- Auditing configuration schemas that expose security choices
+- Evaluating cryptographic library ergonomics
+- Assessing authentication/authorization APIs
+- Any code review where developers make security-critical decisions
+
+## What It Does
+
+Analyzes code and designs through the lens of three adversaries:
+
+1. **The Scoundrel**: Can a malicious developer or attacker disable security via configuration?
+2. **The Lazy Developer**: Will copy-pasting the first example lead to insecure code?
+3. **The Confused Developer**: Can parameters be swapped without type errors?
+
+## Core Principle
+
+**The pit of success**: Secure usage should be the path of least resistance. If developers must read documentation carefully or remember special rules to avoid vulnerabilities, the API has failed.
+
+## Installation
+
+```
+/plugin install trailofbits/skills/plugins/sharp-edges
+```
+
+## Sharp Edge Categories
+
+The skill identifies six categories of misuse-prone designs:
+
+| Category | Example |
+|----------|---------|
+| Algorithm Selection | JWT `alg: none` attack; PHP `hash("crc32", $password)` |
+| Dangerous Defaults | `session_timeout: 0` meaning infinite; empty password accepted |
+| Primitive vs. Semantic APIs | `encrypt(msg, bytes, bytes)` where key/nonce can be swapped |
+| Configuration Cliffs | `verify_ssl: false` disables all certificate validation |
+| Silent Failures | Verification returns `False` instead of throwing; ignored return values |
+| Stringly-Typed Security | Permissions as comma-separated strings; SQL from concatenation |
+
+## Related Skills
+
+- [constant-time-analysis](../constant-time-analysis) - Detect timing side-channels in cryptographic code
+- [differential-review](../differential-review) - Security-focused code change review
+- [audit-context-building](../audit-context-building) - Deep architectural analysis before auditing