mirror of
https://github.com/trailofbits/skills
synced 2026-06-21 14:12:00 +00:00
Lixin2026
d5fe2e6a78
* feat(codex): add skill UI metadata * Use official Trail of Bits logo * fix: resolve code review findings for PR #175 Codex silently drops the icons as authored: its loader (codex-rs/core-skills resolve_asset_path) requires icon paths containing '..' to resolve under <plugin_root>/assets/, and the repo-root .codex/assets location fails that containment check. Verified empirically via codex app-server plugin/read: every iconSmall/iconLarge came back null; only brand_color applied. P1 fixed: - Vendor trail-of-bits-mark.svg into plugins/<name>/assets/ for all 38 plugins with skills and point every openai.yaml at ../../assets/trail-of-bits-mark.svg (the supported plugin-level shared asset pattern). Icons now resolve for marketplace installs too, since nothing escapes the plugin root. - Drop the .codex/ additions: .codex/skills/gh-cli/agents/ openai.yaml resolved nowhere (.codex/skills is not a Codex discovery root) and PR #173 removes the whole .codex/ tree P2 fixed: - Patch-bump all 38 touched plugins in plugin.json and marketplace.json so installed clients pick up the metadata Verified: - Static check replicating Codex's resolution algorithm: all 73 yaml files resolve under their plugin assets/ and exist - Live codex app-server probe: 71/72 loadable skills report resolved iconSmall/iconLarge and brand_color #D83A34 (claude-in-chrome-troubleshooting fails to load on main due to a pre-existing 64-char qualified-name limit, fixed by #173's rename; zeroize-audit's manifest mcpServers object is likewise a pre-existing Codex incompatibility fixed by #173) - validate_codex_skills.py, validate_plugin_metadata.py, prek all pass Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(codex): use skill-local icon assets --------- Co-authored-by: Dan Guido <dan@trailofbits.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Mutation Testing — Campaign Configuration (mewt/muton)
Helps configure mewt or muton mutation testing campaigns — scoping targets, tuning timeouts, and optimizing long-running runs so you can execute mewt run or muton run with confidence.
Note
: muton and mewt share identical interfaces but target different languages — mewt for general-purpose languages, muton for TON smart contracts (Tact, Tolk, FunC). All commands and configuration patterns in this plugin apply to both tools. File names change accordingly:
mewt.toml→muton.toml,mewt.sqlite→muton.sqlite.
What It Does
Walks through a 5-phase configuration workflow:
- Initialize and validate targets — run
mewt init, review auto-generated config, fix include/ignore patterns - Generate mutants and assess scope — count mutants, time the test command, estimate campaign duration
- Decide on optimization — choose between full run, targeted components, high/medium severity only, or two-phase campaign
- Validate test command and timeout — verify the command works; set manual timeout for recompilation-heavy languages (Solidity/Foundry, heavy C++)
- Final validation checklist — confirm config, mutant count, target selection, and timeout before running
When to Use
- Setting up a new mutation testing campaign
- Optimizing a campaign that would take too long to run
- Diagnosing why no mutants are generated or why the test command fails
Prerequisites
- mewt v3.0.0+ or muton v3.0.0+ installed
- A test suite runnable from the command line
- Source code in a supported language:
- mewt: Rust, Solidity, Go, TypeScript, JavaScript
- muton: Tact, Tolk, FunC (TON smart contract languages)
Example Usage
User: "Help me set up mewt for this Solidity project"
User: "Configure muton for this FunC codebase"
User: "My mewt campaign would take 30 hours — how do I optimize it?"
→ Guides through configuration, scope assessment, and optimization
References
- mewt GitHub Repository
- Use mutation testing to find the bugs your tests don't catch — Trail of Bits blog post