@bgicli/bgicli 2.2.8 → 2.2.10

package/data/skills/trailofbits-modern-python/SKILL.md

@@ -0,0 +1,333 @@
+---
+name: modern-python
+description: Configures Python projects with modern tooling (uv, ruff, ty). Use when creating projects, writing standalone scripts, or migrating from pip/Poetry/mypy/black.
+---
+
+# Modern Python
+
+Guide for modern Python tooling and best practices, based on [trailofbits/cookiecutter-python](https://github.com/trailofbits/cookiecutter-python).
+
+## When to Use This Skill
+
+- Creating a new Python project or package
+- Setting up `pyproject.toml` configuration
+- Configuring development tools (linting, formatting, testing)
+- Writing Python scripts with external dependencies
+- Migrating from legacy tools (when user requests it)
+
+## When NOT to Use This Skill
+
+- **User wants to keep legacy tooling**: Respect existing workflows if explicitly requested
+- **Python < 3.11 required**: These tools target modern Python
+- **Non-Python projects**: Mixed codebases where Python isn't primary
+
+## Anti-Patterns to Avoid
+
+| Avoid | Use Instead |
+|-------|-------------|
+| `[tool.ty]` python-version | `[tool.ty.environment]` python-version |
+| `uv pip install` | `uv add` and `uv sync` |
+| Editing pyproject.toml manually to add deps | `uv add <pkg>` / `uv remove <pkg>` |
+| `hatchling` build backend | `uv_build` (simpler, sufficient for most cases) |
+| Poetry | uv (faster, simpler, better ecosystem integration) |
+| requirements.txt | PEP 723 for scripts, pyproject.toml for projects |
+| mypy / pyright | ty (faster, from Astral team) |
+| `[project.optional-dependencies]` for dev tools | `[dependency-groups]` (PEP 735) |
+| Manual virtualenv activation (`source .venv/bin/activate`) | `uv run <cmd>` |
+| pre-commit | prek (faster, no Python runtime needed) |
+
+**Key principles:**
+- Always use `uv add` and `uv remove` to manage dependencies
+- Never manually activate or manage virtual environments—use `uv run` for all commands
+- Use `[dependency-groups]` for dev/test/docs dependencies, not `[project.optional-dependencies]`
+
+## Decision Tree
+
+```
+What are you doing?
+│
+├─ Single-file script with dependencies?
+│   └─ Use PEP 723 inline metadata (./references/pep723-scripts.md)
+│
+├─ New multi-file project (not distributed)?
+│   └─ Minimal uv setup (see Quick Start below)
+│
+├─ New reusable package/library?
+│   └─ Full project setup (see Full Setup below)
+│
+└─ Migrating existing project?
+    └─ See Migration Guide below
+```
+
+## Tool Overview
+
+| Tool | Purpose | Replaces |
+|------|---------|----------|
+| **uv** | Package/dependency management | pip, virtualenv, pip-tools, pipx, pyenv |
+| **ruff** | Linting AND formatting | flake8, black, isort, pyupgrade, pydocstyle |
+| **ty** | Type checking | mypy, pyright (faster alternative) |
+| **pytest** | Testing with coverage | unittest |
+| **prek** | Pre-commit hooks ([setup](./references/prek.md)) | pre-commit (faster, Rust-native) |
+
+### Security Tools
+
+| Tool | Purpose | When It Runs |
+|------|---------|--------------|
+| **shellcheck** | Shell script linting | pre-commit |
+| **detect-secrets** | Secret detection | pre-commit |
+| **actionlint** | Workflow syntax validation | pre-commit, CI |
+| **zizmor** | Workflow security audit | pre-commit, CI |
+| **pip-audit** | Dependency vulnerability scanning | CI, manual |
+| **Dependabot** | Automated dependency updates | scheduled |
+
+See [security-setup.md](./references/security-setup.md) for configuration and usage.
+
+## Quick Start: Minimal Project
+
+For simple multi-file projects not intended for distribution:
+
+```bash
+# Create project with uv
+uv init myproject
+cd myproject
+
+# Add dependencies
+uv add requests rich
+
+# Add dev dependencies
+uv add --group dev pytest ruff ty
+
+# Run code
+uv run python src/myproject/main.py
+
+# Run tools
+uv run pytest
+uv run ruff check .
+```
+
+## Full Project Setup
+If starting from scratch, ask the user if they prefer to use the Trail of Bits cookiecutter template to bootstrap a complete project with already preconfigured tooling.
+
+```bash
+uvx cookiecutter gh:trailofbits/cookiecutter-python
+```
+
+### 1. Create Project Structure
+
+```bash
+uv init --package myproject
+cd myproject
+```
+
+This creates:
+```
+myproject/
+├── pyproject.toml
+├── README.md
+├── src/
+│   └── myproject/
+│       └── __init__.py
+└── .python-version
+```
+
+### 2. Configure pyproject.toml
+
+See [pyproject.md](./references/pyproject.md) for complete configuration reference.
+
+Key sections:
+```toml
+[project]
+name = "myproject"
+version = "0.1.0"
+requires-python = ">=3.11"
+dependencies = []
+
+[dependency-groups]
+dev = [{include-group = "lint"}, {include-group = "test"}, {include-group = "audit"}]
+lint = ["ruff", "ty"]
+test = ["pytest", "pytest-cov"]
+audit = ["pip-audit"]
+
+[tool.ruff]
+line-length = 100
+target-version = "py311"
+
+[tool.ruff.lint]
+select = ["ALL"]
+ignore = ["D", "COM812", "ISC001"]
+
+[tool.pytest]
+addopts = ["--cov=myproject", "--cov-fail-under=80"]
+
+[tool.ty.terminal]
+error-on-warning = true
+
+[tool.ty.environment]
+python-version = "3.11"
+
+[tool.ty.rules]
+# Strict from day 1 for new projects
+possibly-unresolved-reference = "error"
+unused-ignore-comment = "warn"
+```
+
+### 3. Install Dependencies
+
+```bash
+# Install all dependency groups
+uv sync --all-groups
+
+# Or install specific groups
+uv sync --group dev
+```
+
+### 4. Add Makefile
+
+```makefile
+.PHONY: dev lint format test build
+
+dev:
+	uv sync --all-groups
+
+lint:
+	uv run ruff format --check && uv run ruff check && uv run ty check src/
+
+format:
+	uv run ruff format .
+
+test:
+	uv run pytest
+
+build:
+	uv build
+```
+
+## Migration Guide
+
+When a user requests migration from legacy tooling:
+
+### From requirements.txt + pip
+
+First, determine the nature of the code:
+
+**For standalone scripts**: Convert to PEP 723 inline metadata (see [pep723-scripts.md](./references/pep723-scripts.md))
+
+**For projects**:
+```bash
+# Initialize uv in existing project
+uv init --bare
+
+# Add dependencies using uv (not by editing pyproject.toml)
+uv add requests rich  # add each package
+
+# Or import from requirements.txt (review each package before adding)
+# Note: Complex version specifiers may need manual handling
+grep -v '^#' requirements.txt | grep -v '^-' | grep -v '^\s*$' | while read -r pkg; do
+    uv add "$pkg" || echo "Failed to add: $pkg"
+done
+
+uv sync
+```
+
+Then:
+1. Delete `requirements.txt`, `requirements-dev.txt`
+2. Delete virtual environment (`venv/`, `.venv/`)
+3. Add `uv.lock` to version control
+
+### From setup.py / setup.cfg
+
+1. Run `uv init --bare` to create pyproject.toml
+2. Use `uv add` to add each dependency from `install_requires`
+3. Use `uv add --group dev` for dev dependencies
+4. Copy non-dependency metadata (name, version, description, etc.) to `[project]`
+5. Delete `setup.py`, `setup.cfg`, `MANIFEST.in`
+
+### From flake8 + black + isort
+
+1. Remove flake8, black, isort via `uv remove`
+2. Delete `.flake8`, `pyproject.toml [tool.black]`, `[tool.isort]` configs
+3. Add ruff: `uv add --group dev ruff`
+4. Add ruff configuration (see [ruff-config.md](./references/ruff-config.md))
+5. Run `uv run ruff check --fix .` to apply fixes
+6. Run `uv run ruff format .` to format
+
+### From mypy / pyright
+
+1. Remove mypy/pyright via `uv remove`
+2. Delete `mypy.ini`, `pyrightconfig.json`, or `[tool.mypy]`/`[tool.pyright]` sections
+3. Add ty: `uv add --group dev ty`
+4. Run `uv run ty check src/`
+
+## Quick Reference: uv Commands
+
+| Command | Description |
+|---------|-------------|
+| `uv init` | Create new project |
+| `uv init --package` | Create distributable package |
+| `uv add <pkg>` | Add dependency |
+| `uv add --group dev <pkg>` | Add to dependency group |
+| `uv remove <pkg>` | Remove dependency |
+| `uv sync` | Install dependencies |
+| `uv sync --all-groups` | Install all dependency groups |
+| `uv run <cmd>` | Run command in venv |
+| `uv run --with <pkg> <cmd>` | Run with temporary dependency |
+| `uv build` | Build package |
+| `uv publish` | Publish to PyPI |
+
+### Ad-hoc Dependencies with `--with`
+
+Use `uv run --with` for one-off commands that need packages not in your project:
+
+```bash
+# Run Python with a temporary package
+uv run --with requests python -c "import requests; print(requests.get('https://httpbin.org/ip').json())"
+
+# Run a module with temporary deps
+uv run --with rich python -m rich.progress
+
+# Multiple packages
+uv run --with requests --with rich python script.py
+
+# Combine with project deps (adds to existing venv)
+uv run --with httpx pytest  # project deps + httpx
+```
+
+**When to use `--with` vs `uv add`:**
+- `uv add`: Package is a project dependency (goes in pyproject.toml/uv.lock)
+- `--with`: One-off usage, testing, or scripts outside a project context
+
+See [uv-commands.md](./references/uv-commands.md) for complete reference.
+
+## Quick Reference: Dependency Groups
+
+```toml
+[dependency-groups]
+dev = ["ruff", "ty"]
+test = ["pytest", "pytest-cov", "hypothesis"]
+docs = ["sphinx", "myst-parser"]
+```
+
+Install with: `uv sync --group dev --group test`
+
+## Best Practices Checklist
+
+- [ ] Use `src/` layout for packages
+- [ ] Set `requires-python = ">=3.11"`
+- [ ] Configure ruff with `select = ["ALL"]` and explicit ignores
+- [ ] Use ty for type checking
+- [ ] Enforce test coverage minimum (80%+)
+- [ ] Use dependency groups instead of extras for dev tools
+- [ ] Add `uv.lock` to version control
+- [ ] Use PEP 723 for standalone scripts
+
+## Read Next
+
+- [migration-checklist.md](./references/migration-checklist.md) - Step-by-step migration cleanup
+- [pyproject.md](./references/pyproject.md) - Complete pyproject.toml reference
+- [uv-commands.md](./references/uv-commands.md) - uv command reference
+- [ruff-config.md](./references/ruff-config.md) - Ruff linting/formatting configuration
+- [testing.md](./references/testing.md) - pytest and coverage setup
+- [pep723-scripts.md](./references/pep723-scripts.md) - PEP 723 inline script metadata
+- [prek.md](./references/prek.md) - Fast pre-commit hooks with prek
+- [security-setup.md](./references/security-setup.md) - Security hooks and dependency scanning
+- [dependabot.md](./references/dependabot.md) - Automated dependency updates

package/data/skills/trailofbits-property-based-testing/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: property-based-testing
+description: Provides guidance for property-based testing across multiple languages and smart contracts. Use when writing tests, reviewing code with serialization/validation/parsing patterns, designing features, or when property-based testing would provide stronger coverage than example-based tests.
+---
+
+# Property-Based Testing Guide
+
+Use this skill proactively during development when you encounter patterns where PBT provides stronger coverage than example-based tests.
+
+## When to Invoke (Automatic Detection)
+
+**Invoke this skill when you detect:**
+
+- **Serialization pairs**: `encode`/`decode`, `serialize`/`deserialize`, `toJSON`/`fromJSON`, `pack`/`unpack`
+- **Parsers**: URL parsing, config parsing, protocol parsing, string-to-structured-data
+- **Normalization**: `normalize`, `sanitize`, `clean`, `canonicalize`, `format`
+- **Validators**: `is_valid`, `validate`, `check_*` (especially with normalizers)
+- **Data structures**: Custom collections with `add`/`remove`/`get` operations
+- **Mathematical/algorithmic**: Pure functions, sorting, ordering, comparators
+- **Smart contracts**: Solidity/Vyper contracts, token operations, state invariants, access control
+
+**Priority by pattern:**
+
+| Pattern | Property | Priority |
+|---------|----------|----------|
+| encode/decode pair | Roundtrip | HIGH |
+| Pure function | Multiple | HIGH |
+| Validator | Valid after normalize | MEDIUM |
+| Sorting/ordering | Idempotence + ordering | MEDIUM |
+| Normalization | Idempotence | MEDIUM |
+| Builder/factory | Output invariants | LOW |
+| Smart contract | State invariants | HIGH |
+
+## When NOT to Use
+
+Do NOT use this skill for:
+- Simple CRUD operations without transformation logic
+- One-off scripts or throwaway code
+- Code with side effects that cannot be isolated (network calls, database writes)
+- Tests where specific example cases are sufficient and edge cases are well-understood
+- Integration or end-to-end testing (PBT is best for unit/component testing)
+
+## Property Catalog (Quick Reference)
+
+| Property | Formula | When to Use |
+|----------|---------|-------------|
+| **Roundtrip** | `decode(encode(x)) == x` | Serialization, conversion pairs |
+| **Idempotence** | `f(f(x)) == f(x)` | Normalization, formatting, sorting |
+| **Invariant** | Property holds before/after | Any transformation |
+| **Commutativity** | `f(a, b) == f(b, a)` | Binary/set operations |
+| **Associativity** | `f(f(a,b), c) == f(a, f(b,c))` | Combining operations |
+| **Identity** | `f(x, identity) == x` | Operations with neutral element |
+| **Inverse** | `f(g(x)) == x` | encrypt/decrypt, compress/decompress |
+| **Oracle** | `new_impl(x) == reference(x)` | Optimization, refactoring |
+| **Easy to Verify** | `is_sorted(sort(x))` | Complex algorithms |
+| **No Exception** | No crash on valid input | Baseline property |
+
+**Strength hierarchy** (weakest to strongest):
+No Exception → Type Preservation → Invariant → Idempotence → Roundtrip
+
+## Decision Tree
+
+Based on the current task, read the appropriate section:
+
+```
+TASK: Writing new tests
+  → Read [{baseDir}/references/generating.md]({baseDir}/references/generating.md) (test generation patterns and examples)
+  → Then [{baseDir}/references/strategies.md]({baseDir}/references/strategies.md) if input generation is complex
+
+TASK: Designing a new feature
+  → Read [{baseDir}/references/design.md]({baseDir}/references/design.md) (Property-Driven Development approach)
+
+TASK: Code is difficult to test (mixed I/O, missing inverses)
+  → Read [{baseDir}/references/refactoring.md]({baseDir}/references/refactoring.md) (refactoring patterns for testability)
+
+TASK: Reviewing existing PBT tests
+  → Read [{baseDir}/references/reviewing.md]({baseDir}/references/reviewing.md) (quality checklist and anti-patterns)
+
+TASK: Test failed, need to interpret
+  → Read [{baseDir}/references/interpreting-failures.md]({baseDir}/references/interpreting-failures.md) (failure analysis and bug classification)
+
+TASK: Need library reference
+  → Read [{baseDir}/references/libraries.md]({baseDir}/references/libraries.md) (PBT libraries by language, includes smart contract tools)
+```
+
+## How to Suggest PBT
+
+When you detect a high-value pattern while writing tests, **offer PBT as an option**:
+
+> "I notice `encode_message`/`decode_message` is a serialization pair. Property-based testing with a roundtrip property would provide stronger coverage than example tests. Want me to use that approach?"
+
+**If codebase already uses a PBT library** (Hypothesis, fast-check, proptest, Echidna), be more direct:
+
+> "This codebase uses Hypothesis. I'll write property-based tests for this serialization pair using a roundtrip property."
+
+**If user declines**, write good example-based tests without further prompting.
+
+## When NOT to Use PBT
+
+- Simple CRUD without complex validation
+- UI/presentation logic
+- Integration tests requiring complex external setup
+- Prototyping where requirements are fluid
+- User explicitly requests example-based tests only
+
+## Red Flags
+
+- Recommending trivial getters/setters
+- Missing paired operations (encode without decode)
+- Ignoring type hints (well-typed = easier to test)
+- Overwhelming user with candidates (limit to top 5-10)
+- Being pushy after user declines
+
+## Rationalizations to Reject
+
+Do not accept these shortcuts:
+
+- **"Example tests are good enough"** - If serialization/parsing/normalization is involved, PBT finds edge cases examples miss
+- **"The function is simple"** - Simple functions with complex input domains (strings, floats, nested structures) benefit most from PBT
+- **"We don't have time"** - PBT tests are often shorter than comprehensive example suites
+- **"It's too hard to write generators"** - Most PBT libraries have excellent built-in strategies; custom generators are rarely needed
+- **"The test failed, so it's a bug"** - Failures require validation; see [interpreting-failures.md]({baseDir}/references/interpreting-failures.md)
+- **"No crash means it works"** - "No exception" is the weakest property; always push for stronger guarantees

package/data/skills/trailofbits-semgrep-rule-creator/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: semgrep-rule-creator
+description: Creates custom Semgrep rules for detecting security vulnerabilities, bug patterns, and code patterns. Use when writing Semgrep rules or building custom static analysis detections.
+allowed-tools:
+  - Bash
+  - Read
+  - Write
+  - Edit
+  - Glob
+  - Grep
+  - WebFetch
+---
+
+# Semgrep Rule Creator
+
+Create production-quality Semgrep rules with proper testing and validation.
+
+## When to Use
+
+**Ideal scenarios:**
+- Writing Semgrep rules for specific bug patterns
+- Writing rules to detect security vulnerabilities in your codebase
+- Writing taint mode rules for data flow vulnerabilities
+- Writing rules to enforce coding standards
+
+## When NOT to Use
+
+Do NOT use this skill for:
+- Running existing Semgrep rulesets
+- General static analysis without custom rules (use `static-analysis` skill)
+
+## Rationalizations to Reject
+
+When writing Semgrep rules, reject these common shortcuts:
+
+- **"The pattern looks complete"** → Still run `semgrep --test --config <rule-id>.yaml <rule-id>.<ext>` to verify. Untested rules have hidden false positives/negatives.
+- **"It matches the vulnerable case"** → Matching vulnerabilities is half the job. Verify safe cases don't match (false positives break trust).
+- **"Taint mode is overkill for this"** → If data flows from user input to a dangerous sink, taint mode gives better precision than pattern matching.
+- **"One test is enough"** → Include edge cases: different coding styles, sanitized inputs, safe alternatives, and boundary conditions.
+- **"I'll optimize the patterns first"** → Write correct patterns first, optimize after all tests pass. Premature optimization causes regressions.
+- **"The AST dump is too complex"** → The AST reveals exactly how Semgrep sees code. Skipping it leads to patterns that miss syntactic variations.
+
+## Anti-Patterns
+
+**Too broad** - matches everything, useless for detection:
+```yaml
+# BAD: Matches any function call
+pattern: $FUNC(...)
+
+# GOOD: Specific dangerous function
+pattern: eval(...)
+```
+
+**Missing safe cases in tests** - leads to undetected false positives:
+```python
+# BAD: Only tests vulnerable case
+# ruleid: my-rule
+dangerous(user_input)
+
+# GOOD: Include safe cases to verify no false positives
+# ruleid: my-rule
+dangerous(user_input)
+
+# ok: my-rule
+dangerous(sanitize(user_input))
+
+# ok: my-rule
+dangerous("hardcoded_safe_value")
+```
+
+**Overly specific patterns** - misses variations:
+```yaml
+# BAD: Only matches exact format
+pattern: os.system("rm " + $VAR)
+
+# GOOD: Matches all os.system calls with taint tracking
+mode: taint
+pattern-sources:
+  - pattern: input(...)
+pattern-sinks:
+  - pattern: os.system(...)
+```
+
+## Strictness Level
+
+This workflow is **strict** - do not skip steps:
+- **Read documentation first**: See [Documentation](#documentation) before writing Semgrep rules
+- **Test-first is mandatory**: Never write a rule without tests
+- **100% test pass is required**: "Most tests pass" is not acceptable
+- **Optimization comes last**: Only simplify patterns after all tests pass
+- **Avoid generic patterns**: Rules must be specific, not match broad patterns
+- **Prioritize taint mode**: For data flow vulnerabilities
+- **One YAML file - one Semgrep rule**: Each YAML file must contain only one Semgrep rule; don't combine multiple rules in a single file
+- **No generic rules**: When targeting a specific language for Semgrep rules - avoid generic pattern matching (`languages: generic`)
+- **Forbidden `todook` and `todoruleid` test annotations**: `todoruleid: <rule-id>` and `todook: <rule-id>` annotations in tests files for future rule improvements are forbidden
+
+## Overview
+
+This skill guides creation of Semgrep rules that detect security vulnerabilities and code patterns. Rules are created iteratively: analyze the problem, write tests first, analyze AST structure, write the rule, iterate until all tests pass, optimize the rule.
+
+**Approach selection:**
+- **Taint mode** (prioritize): Data flow issues where untrusted input reaches dangerous sinks
+- **Pattern matching**: Simple syntactic patterns without data flow requirements
+
+**Why prioritize taint mode?** Pattern matching finds syntax but misses context. A pattern `eval($X)` matches both `eval(user_input)` (vulnerable) and `eval("safe_literal")` (safe). Taint mode tracks data flow, so it only alerts when untrusted data actually reaches the sink—dramatically reducing false positives for injection vulnerabilities.
+
+**Iterating between approaches:** It's okay to experiment. If you start with taint mode and it's not working well (e.g., taint doesn't propagate as expected, too many false positives/negatives), switch to pattern matching. Conversely, if pattern matching produces too many false positives on safe cases, try taint mode instead. The goal is a working rule—not rigid adherence to one approach.
+
+**Output structure** - exactly 2 files in a directory named after the rule-id:
+```
+<rule-id>/
+├── <rule-id>.yaml     # Semgrep rule
+└── <rule-id>.<ext>    # Test file with ruleid/ok annotations
+```
+
+## Quick Start
+
+```yaml
+rules:
+  - id: insecure-eval
+    languages: [python]
+    severity: HIGH
+    message: User input passed to eval() allows code execution
+    mode: taint
+    pattern-sources:
+      - pattern: request.args.get(...)
+    pattern-sinks:
+      - pattern: eval(...)
+```
+
+Test file (`insecure-eval.py`):
+```python
+# ruleid: insecure-eval
+eval(request.args.get('code'))
+
+# ok: insecure-eval
+eval("print('safe')")
+```
+
+Run tests (from rule directory): `semgrep --test --config <rule-id>.yaml <rule-id>.<ext>`
+
+## Quick Reference
+
+- For commands, pattern operators, and taint mode syntax, see [quick-reference.md]({baseDir}/references/quick-reference.md).
+- For detailed workflow and examples, you MUST see [workflow.md]({baseDir}/references/workflow.md)
+
+## Workflow
+
+Copy this checklist and track progress:
+
+```
+Semgrep Rule Progress:
+- [ ] Step 1: Analyze the Problem
+- [ ] Step 2: Write Tests First
+- [ ] Step 3: Analyze AST structure
+- [ ] Step 4: Write the rule
+- [ ] Step 5: Iterate until all tests pass (semgrep --test)
+- [ ] Step 6: Optimize the rule (remove redundancies, re-test)
+- [ ] Step 7: Final Run
+```
+
+## Documentation
+
+**REQUIRED**: Before writing any rule, use WebFetch to read **all** of these 7 links with Semgrep documentation:
+
+1. [Rule Syntax](https://raw.githubusercontent.com/semgrep/semgrep-docs/refs/heads/main/docs/writing-rules/rule-syntax.md)
+2. [Pattern Syntax](https://raw.githubusercontent.com/semgrep/semgrep-docs/refs/heads/main/docs/writing-rules/pattern-syntax.mdx)
+3. [Testing Rules](https://raw.githubusercontent.com/semgrep/semgrep-docs/refs/heads/main/docs/writing-rules/testing-rules.md)
+4. [Taint analysis](https://raw.githubusercontent.com/semgrep/semgrep-docs/refs/heads/main/docs/writing-rules/data-flow/taint-mode/overview.md)
+5. [Advanced techniques for taint analysis](https://raw.githubusercontent.com/semgrep/semgrep-docs/refs/heads/main/docs/writing-rules/data-flow/taint-mode/advanced.md)
+6. [Constant propagation](https://raw.githubusercontent.com/semgrep/semgrep-docs/refs/heads/main/docs/writing-rules/data-flow/constant-propagation.md)
+7. [Trail of Bits Testing Handbook - Semgrep chapter](https://raw.githubusercontent.com/trailofbits/testing-handbook/refs/heads/main/content/docs/static-analysis/semgrep/10-advanced.md)