* Commit plugin lockfiles so Dependabot can do something useful The uv ecosystem config added in #206 pointed at four directories that declare PEP 621 ranges and carry no lockfile. With nothing to pin, Dependabot's only available action is raising the lower bound of an already-open range — which changes nothing about what installs and only drops support for older versions. It opened five such PRs within a minute of #206 merging (#208-#212), all no-ops: the existing ranges already resolved to exactly the versions being proposed as new floors. The one directory that did have a lockfile, constant-time-analysis, produced no PR at all, because there was genuinely nothing to update. That is the whole diagnosis. Lockfiles committed for the other four. .gitignore ignored uv.lock globally, which is why they were missing; constant-time-analysis's was tracked only because it predates the rule. Now scoped to the root file (ephemeral — there is no root pyproject.toml) with plugin lockfiles explicitly allowed, matching the pattern already used for .mcp.json. Also fixes two bugs #206 introduced: - The version-increment check failed all five Dependabot PRs, and Dependabot can neither bump a plugin version nor label its own PR, so every future dependency PR would have been permanently red. Exempted by actor. - The 'no-version-bump' label was documented in AGENTS.md and wired into validate.yml but never created, so the escape hatch did not exist. Created. * Re-run CI with the no-version-bump label applied The version-increment check fired on this PR: adding uv.lock under plugins/<name>/ counts as touching those plugins. Correct behaviour — the lockfiles pin exactly what the existing ranges already resolve to, so nothing changes for anyone installing these plugins, which is what the label is for. First real use of the escape hatch created in this same PR. * Fix the three findings from this PR's review A local uv setting leaked into all four new lockfiles. /etc/uv/uv.toml on ToB machine images sets exclude-newer = "1 week", so every lock carried an [options] block with exclude-newer-span = "P1W" and pinned versions resolved a week stale — diverging from constant-time-analysis/uv.lock, which predates this PR and has no such block. Regenerated with UV_NO_CONFIG=1. That cooldown is the org's supply-chain posture and it belongs in dependabot.yml's 'cooldown: default-days: 7', where it already is; baking it into committed lockfiles was my environment leaking, not a decision. "EVERY directory here must carry a committed uv.lock" was enforced by a comment, which is precisely the anti-pattern AGENTS.md tells people to avoid. Now a validator check: it parses the uv ecosystem block out of dependabot.yml and asserts a uv.lock beside each listed directory. Scoped to that block rather than grepping for '- /plugins/...' so a future ecosystem's paths are not swept in, and it errors if the block exists but no directories parse out — otherwise the checker could inspect zero items and report clean, which is the exact failure it exists to prevent. Three self-test fixtures, and verified by deleting a real lockfile and confirming CI would go red. The Dependabot exemption keyed on github.actor, which on a synchronize event is whoever pushed. A human adding one commit to a Dependabot branch would re-arm the version check and turn the PR red — making the follow-up bump mandatory exactly where the comment says it is discretionary. Keyed on PR authorship now.
YARA-X Authoring Plugin
A behavior-driven skill for authoring high-quality YARA-X detection rules, teaching you to think and act like an expert YARA author.
YARA-X Focus: This skill targets YARA-X, the Rust-based successor to legacy YARA. YARA-X powers VirusTotal's Livehunt/Retrohunt production systems and is 5-10x faster for regex-heavy rules. Legacy YARA (C implementation) is in maintenance mode.
Philosophy
This skill doesn't dump YARA syntax at you. Instead, it teaches:
- Decision trees for common judgment calls (Is this string good enough? When to abandon an approach?)
- Expert heuristics (mutex names are gold, API names are garbage)
- Rationalizations to reject (the shortcuts that cause production failures)
An expert uses 5 tools: yarGen, FLOSS, yr CLI, signature-base, YARA-CI. Everything else is noise.
Installation
YARA-X CLI
# macOS
brew install yara-x
# Or from source
cargo install yara-x
# Verify installation
yr --version
Python Package (for scripts)
pip install yara-x
# or with uv
uv pip install yara-x
Plugin
Add this plugin to your Claude Code configuration:
claude mcp add-plugin /path/to/yara-authoring
Skills
yara-rule-authoring
Guides authoring of YARA-X rules for malware detection with expert judgment.
Covers:
- Decision trees for string quality, when to abandon approaches, debugging FPs
- Expert heuristics from experienced YARA authors
- Rationalizations to reject (common shortcuts that fail)
- Naming conventions (CATEGORY_PLATFORM_FAMILY_DATE format)
- Performance optimization (atom quality, short-circuit conditions)
- Testing workflow (goodware corpus validation)
- YARA-X migration guide for converting legacy rules
- Chrome extension analysis with
crxmodule - Android DEX analysis with
dexmodule
Triggers: YARA, YARA-X, malware detection, threat hunting, IOC, signature
Scripts
The skill includes two Python scripts that require uv to run:
yara_lint.py
Validates YARA-X rules for style, metadata, compatibility issues, and anti-patterns:
uv run yara_lint.py rule.yar
uv run yara_lint.py --json rules/
uv run yara_lint.py --strict rule.yar
atom_analyzer.py
Evaluates string quality for efficient atom extraction:
uv run atom_analyzer.py rule.yar
uv run atom_analyzer.py --verbose rule.yar
Reference Documentation
| Document | Purpose |
|---|---|
| style-guide.md | Naming conventions, metadata requirements |
| performance.md | Atom theory, optimization techniques |
| strings.md | String selection judgment, good/bad patterns |
| testing.md | Validation workflow, FP investigation |
Key Resources
- YARA-X Documentation (official)
- YARA-X GitHub
- Neo23x0 YARA Style Guide
- Neo23x0 Performance Guidelines
- signature-base Rule Collection
- YARA-CI
Requirements
The scripts use PEP 723 inline metadata, so dependencies are resolved automatically by uv run.
Migrating from Legacy YARA
If you have existing rules written for legacy YARA:
- Run validation:
yr check --relaxed-re-syntax rules/ - Fix issues identified (see SKILL.md migration section)
- Validate without relaxed mode:
yr check rules/
Note: Use
--relaxed-re-syntaxonly as a temporary diagnostic tool. Fix all identified issues rather than relying on relaxed mode permanently.
Common migration issues:
- Unescaped
{in regex patterns - Invalid escape sequences (
\R→\\R) - Base64 patterns on strings < 3 characters
- Negative array indexing