mantis-reproduce
Skill2.5k starsChanged 15 days agoApache-2.0View on GitHub
Generates and runs crash reproducers to verify security flaws. Use when viable findings exist and you need to write and execute a script or payload to verify the crash. Don't use for code auditing or patching.
We split this skill into the rules it gives an agent
45 rules. About 0 are common, 9 are distinctive, and 36 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
36
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 53
If run normally: updates findings in-place under state_root/workspace/findings/ (sets "repro_status", "repro_file_path", "run_command", …
- Very specific: line 57
If run with --reattack: updates findings in-place under state_root/workspace/findings/ (sets "reattack_status", "reattack_file_path", …
- Distinctive: line 162
Write a Proof-of-Concept Reproduction Script (Repro) or raw input payload file that reproduces a confirmed security flaw.
- Very specific: line 169
If --finding_id is supplied:
- Very specific: line 172
If --reattack is specified: Enforce the expected patch workflow state for the loaded finding:
- Very specific: line 181
If --reattack is NOT specified (Targeted Normal Run):
- Very specific: line 182
If --force is NOT specified, enforce standard eligibility filters:
- Very specific: line 189
If --force is specified, bypass these eligibility checks.
- Very specific: line 190
If --finding_id is not supplied:
- Very specific: line 193
Read the JSON files in the state_root/workspace/findings/ directory.
- Distinctive: line 199
If no applicable findings exist, notify the user and exit.
- Very specific: line 209
Call graphs miss macros, function pointers, dynamic dispatch, and interface tables.
- Distinctive: line 223
All reproducer executions must run isolated.
- Very specific: line 229
Writing and Launching the Reproducer: Write a self-contained test script (e.g., poc_[uuid].py or a C reproducer file in the same directory) …
- Very specific: line 261
Sanitizer compilation (C/C++ targets): When the bug class is memory-safety or undefined-behavior, compile with -fsanitize=address,undefined …
- Very specific: line 284
When writing run_command or reattack_run_command, use the literal token {TARGET_ROOT} for any path that references the target tree.
- Very specific: line 294
Execute your reproduction using the appropriate environment: If the target is firmware, you may write a script to boot it via qemu, …
- Distinctive: line 302
Parallel Trajectory Search (Breadth-First): When subagents are available, deploy concurrent workers taking diverse logical approaches to …
- Distinctive: line 332
If a crash can ONLY be achieved by compiling a direct-call harness that feeds a private/static function or bypasses the public API (Step …
- Distinctive: line 345
Absolute Attempt Cap Counting: Only Tier-3 full sandboxed service executions (or full end-to-end reproducer runs) increment the absolute …
- Distinctive: line 348
Intra-Conversation Retries: When a tier fails, inspect logs, adjust payload parameters, fix harness setup, and retry up to 2-3 times within …
- Very specific: line 354
When invoked with --reattack, you MUST author and execute N ≥ 3 boundary-mutated variant inputs in addition to re-running the original PoC.
- Distinctive: line 375
Alternate paths to the same sink: If the vulnerable sink is reached via multiple call sites, author a variant reaching it through a …
- Very specific: line 399
Execution: Write each variant as a separate script in state_root/workspace/reproducers/ (e.g., reattack_variant_[uuid]_[N].py).
- Very specific: line 441
If ANY valid variant triggers the bug, set reattack_status = "bypassed_patch" and apply INV-1 (downgrade VERIFIED_SECURE → …
- Very specific: line 462
Do not declare a finding as "reproduced" if the crash can only be achieved by compiling a direct-call harness that feeds a private/static …
- Very specific: line 466
If a crash cannot be triggered through the public API or with standard allocation padding, classify the finding as "failed_to_reproduce" …
- Very specific: line 474
Before classifying ANY negative outcome (failed_to_reproduce, or in --reattack mode failed_to_bypass), apply this gate:
- Very specific: line 515
HALT ceiling (3-state rule): If active_snapshot is present in state but snapshot_pinned is false (HALT mode — the tree raced or could not …
- Very specific: line 530
Memory Safety & Binary Crashes: If the sandbox execution produces a crash signal or sanitizer trace in stdout/stderr, mark the reproduction …
- Very specific: line 587
Use a separate dedicated lock file state_root/workspace/archive/.repro_attempts.lock which is never deleted or replaced.
- Very specific: line 596
Read the current contents of the cache file state_root/workspace/archive/.repro_attempts.json (treating it as {} if missing or empty).
- Very specific: line 607
Write the updated JSON to a temporary file in the same directory (e.g., state_root/workspace/archive/.repro_attempts.json.tmp).
- Very specific: line 638
If reproduction succeeds (repro_status is evaluated as "reproduced" or "statically_confirmed") and the finding's current "status" is …
- Very specific: line 684
Do NOT claim failed_to_bypass.
- Very specific: line 700
Snapshot-mismatch -> governed by C5 below: When reattack_snapshot_id != repro_snapshot_id, do NOT independently record a verdict — follow …
- Very specific: line 706
C5 — Unpatched-baseline re-run (Phase 2): Before running the attack on the patched build, if reattack_snapshot_id != repro_snapshot_id (a …
- Very specific: line 711
Run the reproducer against a FRESH UNPATCHED copy of the current snapshot — a fresh mktemp -d copy of active_snapshot.root, NOT the patched …
- Very specific: line 715
If the unpatched baseline does NOT trigger (evidence absent per Block F): set reattack_status = "inconclusive_baseline_changed", do NOT …
- Very specific: line 721
If the unpatched baseline DOES trigger: proceed with the attack (bypassed_patch or failed_to_bypass).
- Very specific: line 726
MUST use the same sanitizer flags that made the original baseline trigger.
- Very specific: line 747
NOT invent free-form or custom keys (such as input, result, bypassed, label, name):
- Very specific: line 775
ONLY coexist with a non-failed_to_bypass status (e.g., C5 baseline failure that halted before variant hunting, or …
- Very specific: line 799
Variant criticism (re-attack only): When --reattack is specified, the critic subagent MUST also verify that the variant inputs (Step 3a) …
- Distinctive: line 807
When complete, notify the user.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Reproducer (/mantis-reproduce)
System Goal
Integration Test Engineer. Designs crash reproducers or inputs and executes them inside isolated sandbox environments to empirically verify bugs.
Command Definition
- Command:
/mantis-reproduce [--reattack] [--finding_id=<uuid>] [--force] [--target_root=<path>] [--state_root=<path>] [--snapshot_root=<path>] [--snapshot_id=<SNAPSHOT_ID>] [--snapshot_pinned=<true|false>] - Description: Generates and runs crash reproducers to verify security flaws.
- Parameters:
--reattack: When executing as part of patch verification to isolate re-attack outcomes.--finding_id: The specific finding UUID to reproduce. Must be provided and is required when--reattackis specified.--force: Override/bypass eligibility checks for targeted normal runs.--target_root: Path to the root of the target codebase under test (defaults to.). AUTHORITATIVE when supplied — overrides--snapshot_root(Block A step 1a); the sentinel check is skipped for this tree (e.g. a patched shadow during re-attack verification).--state_root: Path to the root of the Mantis state directory containingworkspace/(defaults to.).--snapshot_root: Root of the pinned immutable code snapshot for this pass. Consumed by Block A (Step 0) when--target_rootis not supplied.--snapshot_id: The SNAPSHOT_ID string of the pinned snapshot, consumed by Block A (sentinel) and Block B (snapshot match check) in Step 0.--snapshot_pinned: Whenfalse(set bymantis-patchduring re-attack on a patched shadow), the reproduce sub-agent MUST skip the snapshot sentinel/match check for this invocation — the--target_roottree is authoritative and sentinel-exempt (Block A step 1a).
Input/Output Contract
- Reads:
state_root/workspace/findings/(viable/conditional findings).target_root/(Repository source files to analyze trigger paths).state_root/workspace/archive/.repro_attempts.json.state_root/workspace/.mantis_state.json(to track current loop pass).
- Writes:
- PoC reproduction files (e.g.
poc_[uuid].pyorcrash_[uuid].payloadinsidestate_root/workspace/reproducers/). - If run normally: updates findings in-place under
state_root/workspace/findings/(sets"repro_status","repro_file_path","run_command","repro_output", and appends history). Updates status to"VALID"if provisionally valid. - If run with
--reattack: updates findings in-place understate_root/workspace/findings/(sets"reattack_status","reattack_file_path","reattack_run_command","reattack_output","reattack_variants", and appends history with stage"reattack"). Does not modify"repro_*"fields or"status". Exception: may atomically downgradepatch_statusper INV-1 in Step 6 (never persistVERIFIED_SECUREalongside a non-failed_to_bypassreattack_status). - Updates
state_root/workspace/archive/.repro_attempts.jsonatomically. - Stamps
"repro_snapshot_id"/"reattack_snapshot_id"on updated findings and stores.repro_attempts.jsonvalues as{count,last_snapshot}objects (bare integers still read correctly).
- PoC reproduction files (e.g.
- Preconditions:
- Findings must exist in
state_root/workspace/findings/. - Sandbox/container runtime environment must be available.
- Findings must exist in
- Idempotency Guarantee:
- Updates findings in place. Uses
state_root/workspace/archive/.repro_attempts.lockfile locking and atomic temporary file swaps (os.replaceonstate_root/workspace/archive/.repro_attempts.json.tmp) to guarantee concurrency safety and retry stability. - Snapshot-aware: regenerates the PoC when the finding's snapshot no longer
matches; refuses to emit a negative verdict without reached-sink evidence.
Re-attack verdicts on a snapshot mismatch are governed by the C5
unpatched-baseline re-run (Step 6), which supersedes the legacy blanket
refusal — a
failed_to_bypassverdict is only written after C5 has confirmed the unpatched baseline still triggers on the current snapshot.
- Updates findings in place. Uses
Instructions
Step 0: Locator Resolution + Snapshot Match (run first)
LOCATOR RESOLUTION (before reading ANY target code or artifact):
0. ROLE: If this skill NEVER reads target source (report, calibrate, reflect),
you are a FINDINGS-ONLY stage: skip steps 2-6; still read active_snapshot from
state for provenance/annotation; NEVER stop merely because a code root is unset.
1. Determine CODE_ROOT, in this priority order:
a. If --target_root is passed on THIS invocation, CODE_ROOT = --target_root.
It is AUTHORITATIVE and OVERRIDES SNAPSHOT_ROOT and the state fallback
(used when a caller hands you a prepared tree, e.g. a patched shadow).
b. Else if --snapshot_root (or SNAPSHOT_ROOT) is passed, use it.
c. Else read state_root/workspace/.mantis_state.json (state_root from
--state_root if passed, else ./workspace/... relative to the current dir)
-> active_snapshot.root / .snapshot_id / .snapshot_pinned.
d. Else (no arg AND no readable active_snapshot): CODE_ROOT = current directory,
treat snapshot_pinned = false (MODE-OFF). Do NOT stop.
2. SENTINEL CHECK (only if snapshot_pinned is true AND you did NOT take path 1a):
verify CODE_ROOT/.mantis_snapshot_id exists and equals SNAPSHOT_ID. If missing
or different -> STOP "snapshot sentinel mismatch". (A --target_root tree (1a) is
deliberately mutated and is sentinel-EXEMPT.)
3. PATH FIELDS:
- SNAPSHOT-RELATIVE (read under CODE_ROOT): code_paths entries; plan target_files
that are file paths. Strip ONLY a trailing ":<digits>". A code_paths entry
containing "://" is a URL/endpoint, NOT a file read. A code_paths entry that is
NOT of the form <existing-path>:<integer> is a non-source LOCATOR
(symbol/offset/endpoint): only check that the artifact/symbol exists; skip ALL
line-range and line-existence logic.
- STATE-RELATIVE (read/write under state_root/workspace, NEVER prefix CODE_ROOT):
kb_references, repro_file_path, reattack_file_path, helper scripts, report
files, and all state/findings JSON.
4. Never WRITE under CODE_ROOT when snapshot_pinned is true. Any command that
compiles, generates, or writes artifacts MUST run in a PRIVATE SHADOW copy
(mktemp -d from CODE_ROOT), never with cwd=CODE_ROOT. Read-only inspection may
cd into CODE_ROOT.
5. VCS-METADATA CARVE-OUT: history-log extraction and any VCS diff/blame command
run in the LIVE repository root (which still has .git/.hg/.repo), NOT CODE_ROOT
(the snapshot copy strips VCS metadata). Do NOT stop merely because CODE_ROOT
lacks .git/.hg/.repo.
6. Every shell command uses ABSOLUTE paths and sets its own working directory on
that call. Do NOT assume the working directory persists between calls.[!NOTE] CURRENT-PASS CHECK (defensive; the binding guarantee is on the harness per
mantis-pipeline-adapterScenario 2): ifactive_snapshotis present ANDactive_snapshot.pass != state.pass_number, treat the snapshot as STALE for this pass — STOP "stale active_snapshot: pass mismatch" or degrade as HALT (snapshot_pinnedeffectively false: no authoritative verdicts, Block B NOT_MATCHED, reproducenot_attempted). This catches a custom harness that preservedactive_snapshotacross the Stage 15 pass increment without re-pinning. The reference meta-agent re-pins every pass, so this check never fires there. Block B itself cannot detect this (it issnapshot_id-only, notpass-aware).
SNAPSHOT MATCH CHECK for finding F (decides MATCHED vs NOT_MATCHED):
1. If snapshot_pinned is false -> NOT_MATCHED. Stop.
2. Read F.discovery_commit:
- missing OR empty OR the literal "MIXED" -> NOT_MATCHED.
- not exactly equal to SNAPSHOT_ID -> NOT_MATCHED.
- exactly equal to SNAPSHOT_ID -> MATCHED.
There is no other route to MATCHED; never fuzzy-compare. The global "default the
field and proceed" backward-compat rule does NOT apply to discovery_commit:
absent = NOT_MATCHED. (There is NO separate "dirty" gate: a dirty tree's
SNAPSHOT_ID already embeds the working-tree content hash, so within-pass findings
MATCH and cross-pass bare-commit findings do not.)Notes: When invoked by the patcher with --target_root=<shadow> (a patched
copy), Block A step 1a makes that shadow the authoritative CODE_ROOT and SKIPS
the sentinel check (the shadow is deliberately mutated). Otherwise CODE_ROOT is
the pinned snapshot and the sentinel MUST match. Stamp repro_snapshot_id
(normal run) or reattack_snapshot_id (--reattack) = the current SNAPSHOT_ID
(from --snapshot_id or state active_snapshot.snapshot_id) on every finding
you update.
Write a Proof-of-Concept Reproduction Script (Repro) or raw input payload file that reproduces a confirmed security flaw.
Execute the reproduction stage under these constraints:
Load Viable Findings:
- If
--finding_idis supplied:- Load only that finding's file
(
state_root/workspace/findings/<uuid>.json). Exit if it does not exist. - If
--reattackis specified: Enforce the expected patch workflow state for the loaded finding:- The finding's
"status"must be"VALID"or"PROVISIONALLY_VALID". - The finding's
"repro_status"must be"reproduced". - The finding's
"patch_status"must NOT be"MITIGATION_PROPOSED". (VERIFIED_SECUREIS allowed: C5 below atomically downgrades it when the re-attack outcome is notfailed_to_bypass.) - Exit with an error if these conditions are not met, explaining the invalid state.
- The finding's
- If
--reattackis NOT specified (Targeted Normal Run):- If
--forceis NOT specified, enforce standard eligibility filters:- The finding's
"status"must be"VALID"or"PROVISIONALLY_VALID". - The finding's
"production_viability"must be"VIABLE","SAMPLE_OR_TEST", or"CONDITIONAL_VIABLE". - Exit with an error if these conditions are not met, explaining the invalid state.
- The finding's
- If
--forceis specified, bypass these eligibility checks.
- If
- Load only that finding's file
(
- If
--finding_idis not supplied:- Constraint: Exit if
--reattackis specified (it requires--finding_id). - Read the JSON files in the
state_root/workspace/findings/directory. - Strict Eligibility Filter (Normal Runs): Include only findings where:
"status"is"VALID"or"PROVISIONALLY_VALID"."production_viability"is"VIABLE","SAMPLE_OR_TEST", or"CONDITIONAL_VIABLE"(or skip this viability filter if not checking viability, but always check status).
- If no applicable findings exist, notify the user and exit.
- Constraint: Exit if
Tier 0 — Structural Reachability Pre-Check (Advisory Queue Sorting): If a structural code index (
mantis-structural-index) is available, you MAY queryquery_structural_index.py(find_callers) before authoring code to check whether an AST call path exists from a public entrypoint to the vulnerable sink. Use this query to prioritize candidate execution order (process findings with verified AST reachability first).- CRITICAL HINT-ONLY GUARDRAIL: AST reachability is a ranking HINT ONLY.
Call graphs miss macros, function pointers, dynamic dispatch, and interface
tables. An absent call path MUST NEVER reject a finding, skip reproduction,
or set
failed_to_reproduce.
Snapshot drift check: For each loaded finding, if it already has a
repro_snapshot_idand Block B (Step 0) returns NOT_MATCHED, treat any stored PoC/offsets as STALE: regenerate the reproducer from scratch against the current CODE_ROOT (do not reuse old line numbers/addresses). If Block B is MATCHED you may reuse an existing PoC.- If
Strict Host Isolation Constraint:
- Host command execution is strictly prohibited. Do not run commands directly on your parent host terminal using terminal/shell execution tools.
- All reproducer executions must run isolated. Use the containerization or sandbox execution tools provided by your environment. For memory-safety PoCs, restrict network access and file system writes as much as possible. For logic/auth functional tests, you may enable local network services as needed, but never expose the environment to the external internet.
Writing and Launching the Reproducer: Write a self-contained test script (e.g.,
poc_[uuid].pyor a C reproducer file in the same directory) or write a raw crash input data payload (e.g.,crash_[uuid].payload) that triggers the target bug. All generated PoC/re-attack scripts and payloads MUST be written inside thestate_root/workspace/reproducers/directory (never in thetarget_rootdirectory). You must ensure the parent directorystate_root/workspace/reproducers/exists (e.g. usingmkdir -p) before writing any files. Analyze the code path and constraints carefully. If your initial reproduction attempt fails, evaluate if the finding details (such as input paths, parameters, or assumptions) are slightly incorrect based on your observations, and adjust the finding details dynamically to attempt a fix. If you cannot find a triggerable path after trying multiple approaches and adjustments, abandon the attempt. Do NOT directly mark it asfailed_to_reproduce— route the abandon decision through the Step-5 Block F (Reached-Sink Evidence) gate: if the harness provably reached the vulnerable entrypoint but the bug did not fire, classify asfailed_to_reproduce; if evidence is absent (setup/build failure, exit 127, "No such file", or the sink was never reached), classify asnot_attempted(retry-eligible). A raw negative from a setup/build failure burns the retry cap and silently drops a real bug.To run your script or payload, use the execution or containerization tools available in your environment to execute the code safely. Select the most appropriate runtime image and flags for the target. All compilation and test execution commands MUST be run in a PRIVATE BUILD SHADOW, never with Cwd=CODE_ROOT (the snapshot is read-only — Block A step 4). Before compiling, create
BUILD_ROOT=$(mktemp -d)and copy CODE_ROOT into it (e.g.cp -a CODE_ROOT/. BUILD_ROOT/); run all compilation/test commands with Cwd=BUILD_ROOT; delete BUILD_ROOT on teardown. Keep the generated PoC file itself understate_root/workspace/reproducers/(STATE-RELATIVE) and store its ABSOLUTE path in"run_command"/"reattack_run_command".Sanitizer compilation (C/C++ targets): When the bug class is memory-safety or undefined-behavior, compile with
-fsanitize=address,undefined(ASan + UBSan) at a minimum. For data races, add-fsanitize=thread(TSan) — TSan is also mutually exclusive with ASan, so use a separate build. Use-fno-omit-frame-pointerfor usable stack traces. These flags surface bugs that would otherwise exit 0 silently (UBSan defaults to recover-mode). MSan caveat: MemorySanitizer (-fsanitize=memory) detects uninitialized-memory reads, but it requires the ENTIRE dependency chain (including libc and the C++ runtime) to be MSan-instrumented — on an arbitrary target that is usually not the case, so a naive-fsanitize=memorybuild yields bogusWARNING: MemorySanitizertraces. MSan is also mutually exclusive with ASan in one build (use a separate build, not an additive flag). If a fully instrumented MSan environment cannot be guaranteed, do NOT add-fsanitize=memory; fall back to ASan+UBSan rather than trusting a possibly-bogus MSan trace. Recognizing MSan output as evidence (Step 5) is still correct when a legitimate MSan instrumented build is available. Sanitizer consistency guardrail: the SAME sanitizer flags MUST be used for the baseline, attack, and re-attack runs — a different sanitizer can mask the bug and produce a false negative (INV-2) or falseVERIFIED_SECURE(INV-1). See Block G.{TARGET_ROOT} token substitution (numbered step):
- When writing
run_commandorreattack_run_command, use the literal token{TARGET_ROOT}for any path that references the target tree. - At run time, reproduce substitutes
{TARGET_ROOT}with the actual root:- On first execution:
CODE_ROOT(the snapshot or--target_root). - On re-execution (re-attack or retry): the current
CODE_ROOT/--target_root/active_snapshot.root.
- On first execution:
- This ensures the stored command resolves correctly after snapshot GC —
never bake an absolute
.mantis_snapshots/pass_<N>path into the stored command.
Execute your reproduction using the appropriate environment: If the target is firmware, you may write a script to boot it via
qemu,unicorn, or Firmadyne. If it's a binary, you may use dynamic instrumentation or standard execution. Use your best judgment to construct a working harness for the artifact.Parallel Trajectory Search vs. Tiered Iterative Reproduction:
- Parallel Trajectory Search (Breadth-First): When subagents are available, deploy concurrent workers taking diverse logical approaches to reproduce the bug. If any trajectory succeeds, immediately adopt its payload and discard the others to escape potential "give up" loops and prune compute costs.
- Tiered Iterative Reproduction (Depth-First Payload Refinement): Each trajectory worker (or a single agent) uses a tiered escalation ladder (Tier 1 -> Tier 2 -> Tier 3) to refine its trigger payload incrementally rather than attempting a single-shot end-to-end launch.
Tiered Iterative Execution Ladder:
- Tier 1 (Micro-Harness / Sink Logic Validation): Construct a lightweight test calling the vulnerable function/module directly to verify that the core bug hypothesis is sound in isolation.
- Tier 2 (Subsystem / Interface Validation): Pass the payload through input serialization, parsers, routing, and auth wrappers to verify the input survives intermediate processing without sanitization or truncation.
- Tier 3 (Full Sandboxed Service / E2E Validation): Execute the
self-contained PoC against the target service via public APIs inside the
isolated sandbox (Docker, QEMU, VM). Yields the authoritative
reproducedverdict per Block F.
CRITICAL STEP-4 TIER-1 HARD GATE (Fail-Closed):
- Tiers 1 and 2 are internal stepping stones only. You MUST NEVER
record
repro_status = "reproduced"or"statically_confirmed"based on a Tier-1 or Tier-2 execution. - If a crash can ONLY be achieved by compiling a direct-call harness
that feeds a private/static function or bypasses the public API (Step 4),
and the payload cannot be escalated to trigger through Tier 3 (the public
API / sandboxed service), you MUST TERMINATE AND RECORD
repro_status = "failed_to_reproduce"with details citing"Internal Invariant Protection".
- Tiers 1 and 2 are internal stepping stones only. You MUST NEVER
record
Attempt Cap Accounting & Local Retries:
- Sub-Tier-3 Stepping-Stone Sub-Budget: Internal Tier-1 and Tier-2
trial runs are bounded local execution steps (max 3 trial executions per
conversation) and DO NOT increment the absolute per-finding attempt
counter in
state_root/workspace/archive/.repro_attempts.json. - Absolute Attempt Cap Counting: Only Tier-3 full sandboxed service executions (or full end-to-end reproducer runs) increment the absolute attempt counter toward the hard ceiling of 6 (Section 6).
- Intra-Conversation Retries: When a tier fails, inspect logs, adjust payload parameters, fix harness setup, and retry up to 2-3 times within the active conversation before reporting back to the orchestrator.
- Sub-Tier-3 Stepping-Stone Sub-Budget: Internal Tier-1 and Tier-2
trial runs are bounded local execution steps (max 3 trial executions per
conversation) and DO NOT increment the absolute per-finding attempt
counter in
- When writing
Step 3a: Variant Hunting (re-attack only, MANDATORY)
When invoked with --reattack, you MUST author and execute N ≥ 3
boundary-mutated variant inputs in addition to re-running the original PoC.
The schema (schema.json) literally calls this the "variant-hunting re-attack"
— merely re-running the original PoC is insufficient. Over-narrow patches that
guard the exact PoC bytes are the dominant auto-repair failure mode; variant
hunting is the zero-infra-cost defense against them.
Legacy findings: Findings with absent reattack_variants (created before
this rule existed) are re-verified under the ≥3 variant requirement on their
first --reattack pass. This is intentional — legacy VERIFIED_SECURE verdicts
are upgraded to the stricter gate — but expect one-time churn across archived
findings on the first pass that runs variant hunting.
What to generate (bug-class-aware):
Memory-safety bugs (buffer overflow, OOB read/write, UAF, integer overflow): Author at least 3 of:
- Off-by-one:
len = bound,len = bound + 1,len = bound - 1. - Size mutations:
len ± 1,len = 0,len = SIZE_MAX, sign flips on signed lengths. - Alternate paths to the same sink: If the vulnerable sink is reached via multiple call sites, author a variant reaching it through a different path (e.g., different API endpoint, file format variant, or protocol command).
- Type confusion / width mismatch: Exploit a different type path to the same sink.
- Off-by-one:
Non-memory-safety bugs (logic, auth, injection, SSRF, path traversal): Hunt for actual variants of the same class:
- Alternate endpoints/parameters: Try
/api/v2/echowhen PoC targets/api/v1/echo, or alternate parameter names. - Equivalent payloads:
..%2fetc%2fpasswd,..\\..\\, URL-encoding, double encoding, unicode normalization variants. - Auth boundary variants: Different roles, empty/null tokens, alternate privilege-escalation paths.
- Injection variants:
'; EXEC--,UNION SELECT, blind variants, alternate injection points.
- Alternate endpoints/parameters: Try
- Parallel variant generation (if subagents available): You SHOULD spawn
subagents to author and test variants in parallel. Each subagent gets one
mutation strategy, writes its variant PoC, and reports whether it triggered.
Aggregate all results before setting
reattack_status. If subagents are unavailable, do them sequentially.
Execution: Write each variant as a separate script in
state_root/workspace/reproducers/ (e.g., reattack_variant_[uuid]_[N].py).
Execute each against the patched shadow (--target_root) using the same
isolation constraints as Step 3. Record each variant in the reattack_variants
array using EXACTLY the schema keys
{"description": "...", "triggered": true/false} (Step 6).
Verdict rule: reattack_status = "failed_to_bypass" requires a non-empty
reattack_variants array containing ≥ 3 valid variant inputs that ALL failed to
trigger the bug on the patched shadow. An empty or short set makes "all variants
failed" vacuously true — this is FORBIDDEN: if fewer than 3 meaningful variants
can be constructed after genuine effort, cap at VERIFICATION_INCOMPLETE
(history note insufficient_variants), NEVER failed_to_bypass. The [] case
may ONLY coexist with a non-failed_to_bypass status (e.g., C5 baseline failure
that halted before variant hunting).
Variant validity guardrail: A variant counts as a bypass (triggered = true
causing bypassed_patch) ONLY if it satisfies BOTH:
- Same vulnerability class: The variant reproduces the original bug class —
same sink function / sanitizer signature / crash type. A junk mutant (e.g.,
len=SIZE_MAXcausing an unrelated OOM, an alternate endpoint 404-ing then erroring, or a completely different crash) does NOT count as a bypass. Discard it (settriggered = falsewith a description noting it was invalid) and continue. For non-memory bugs (logic, auth, injection), compare the same sink function or behavior (e.g., same unauthorized action succeeds, same injection executes, reaches the same sink function) — NOT a ±line window against a pre-patch line number (patches shift lines, and non-memory bugs often have no precise sink line). If you cannot positively confirm a triggering variant is a DIFFERENT bug, count it as a bypass (fail-closed: prefer a false VERIFICATION_FAILED over a false VERIFIED_SECURE). - Valid input per Step 4: The variant must be a valid exercise of the public API or internal invariants — it must not rely on artificial harness tricks (e.g., private-function direct calls with custom-allocated buffers) that bypass the library's execution invariants.
Ideally, confirm each triggering variant still triggers on the unpatched shadow (same baseline the original PoC ran against) to prove it exercises the original bug rather than an artifact. If the unpatched shadow is unavailable (e.g., snapshot mismatch), require the same-sink evidence (same sanitizer frame, same crash address, same logic failure) as corroboration.
If ANY valid variant triggers the bug, set reattack_status = "bypassed_patch"
and apply INV-1 (downgrade VERIFIED_SECURE → VERIFICATION_FAILED).
Reproduction Status Classification:
reproduced: The PoC successfully triggered the vulnerability.failed_to_reproduce: The PoC was executed but did not trigger the vulnerability.statically_confirmed: Reproduction was impossible due to environmental constraints (e.g., missing hardware emulators, unavailable external services) but the flaw is statically obvious (e.g., hardcoded credentials). This is strongly discouraged and should only be used as a last resort.not_attempted: The reproduction stage was skipped entirely (e.g., due to infrastructure setup failure, timeouts, or explicit skip configuration).
Strict Public-API & Internal Invariant Constraints:
- Your crash reproducer should interact with the codebase through public-facing APIs wherever possible, or strictly respect the library's global execution invariants (such as allocator padding) to avoid generating artificial, non-viable crashes.
- Do not declare a finding as "reproduced" if the crash can only be achieved
by compiling a direct-call harness that feeds a private/static function a
custom-allocated buffer (e.g.,
malloc(15)) that bypasses the library's guaranteed allocator wrappers (e.g.,png_malloc(rowbytes + 48)). - If a crash cannot be triggered through the public API or with standard
allocation padding, classify the finding as
"failed_to_reproduce"due to "Internal Invariant Protection."
Functional & Crash-Aware Validation: Analyze the output such as stdout, stderr, and exit codes to classify reproduction success depending on the bug class:
Before classifying ANY negative outcome (
failed_to_reproduce, or in--reattackmodefailed_to_bypass), apply this gate:REACHED-SINK EVIDENCE GATE (mechanical): Each reproducer produces REACHED-SINK EVIDENCE via ONE channel, recorded in repro_hints: (a) script/source harness -> write the exact bytes MANTIS_REACHED_ENTRYPOINT to a sidecar file $SENTINEL_FILE and flush+fsync (or unbuffered write) BEFORE invoking the sink. (A file survives a crash that truncates buffered stdout.) (b) binary / firmware / raw-payload -> reached-sink evidence is a captured crash backtrace or sanitizer frame (ASan/UBSan/MSan/TSan) that explicitly names the target sink function (target-produced tracing). A marker written by a wrapper you author BEFORE invoking the target is SETUP EVIDENCE ONLY: it proves "launch attempted," not "sink reached," and does NOT qualify as reached-sink evidence. If no in-path marker (channel a) and no target-produced backtrace/sanitizer trace (channel b) is achievable, the sink is unreached. EVIDENCE PRESENT (reached-sink) = (channel a) sidecar file contains MANTIS_REACHED_ENTRYPOINT written in-path, OR (channel b) target-produced backtrace/sanitizer output names the sink. A wrapper pre-launch marker alone is NOT evidence present. EVIDENCE ABSENT includes: any compiler/build nonzero exit; exit 127 (command not found); exit 2 with a "No such file" message. DECISION GATE (gate the DECISION, not specific verdict strings): - Record repro_status = reproduced OR statically_confirmed ONLY if EVIDENCE is PRESENT. If ABSENT -> repro_status = not_attempted (retry-eligible), STOP. - In patch verification, EVIDENCE is required on the UNPATCHED baseline (Block G), NOT on the post-patch attack run (a correct patch legitimately stops the input before the sink). - If NO evidence channel is achievable for this target, downgrade to not_attempted / VERIFICATION_INCOMPLETE. NEVER synthesize the marker.Concretely: if the run produced NO reached-sink evidence (build/setup error, exit 127, "No such file", or the sink was never reached), record
repro_status = not_attempted(retry-eligible) — NEVERfailed_to_reproduce; and in--reattackmode leavereattack_statusUNSET with a history note "setup_failed" — NEVERfailed_to_bypass. Only classify a negative when the harness provably reached the vulnerable entrypoint and the bug did not fire.HALT ceiling (3-state rule): If
active_snapshotis present in state butsnapshot_pinnedisfalse(HALT mode — the tree raced or could not be pinned), you MUST NOT recordfailed_to_reproduceorfailed_to_bypassat all. In HALT, the code may have drifted and a negative reproduction result cannot be trusted as authoritative. Instead, recordrepro_status = not_attempted(retry-eligible) and, in--reattackmode, leavereattack_statusUNSET with a history note "HALT mode: snapshot unpinned, negative result suppressed". This mirrors the authoritative-verdict prohibition that applies to all stages in HALT. (In MODE-OFF — noactive_snapshot— classify negatives normally as today.)- Logic & Authorization Bugs: A successful reproducer is a functional
unit test or script that explicitly demonstrates the logic failure (e.g.,
an unauthorized request returns
200 OK, or a test script successfully bypasses validation and exits with0). - Memory Safety & Binary Crashes: If the sandbox execution produces a
crash signal or sanitizer trace in stdout/stderr, mark the reproduction as
"reproduced". Scan stdout/stderr for sanitizer signatures regardless of exit code — UBSan defaults to recover-mode (exit 0), so an exit-0 run can still contain a valid UBSan trace proving the bug fired. Check for:- AddressSanitizer (ASan) error outputs (e.g.
ERROR: AddressSanitizer). - UndefinedBehaviorSanitizer (UBSan) runtime reports (e.g.
runtime error:,SUMMARY: UndefinedBehaviorSanitizer). - MemorySanitizer (MSan) error outputs (e.g.
WARNING: MemorySanitizer). MSan evidence is valid ONLY ifrepro_hintsrecords that a fully-instrumented MSan build was available (Step 3 caveat). A naive-fsanitize=memorybuild without full instrumentation produces bogus traces — do NOT classify these as"reproduced". - ThreadSanitizer (TSan) race reports (e.g.
WARNING: ThreadSanitizer). - Segmentation faults (SIGSEGV, exit code
139). - Abort signals (SIGABRT, exit code
134). - Crash or core dumps.
- AddressSanitizer (ASan) error outputs (e.g.
- Logic & Authorization Bugs: A successful reproducer is a functional
unit test or script that explicitly demonstrates the logic failure (e.g.,
an unauthorized request returns
Token-Optimized File Updates: To minimize LLM output tokens, do not re-emit or manually rewrite the entire JSON object in your output. Instead, use in-place editing tools (like a short script in your preferred language, or
jq) to programmatically append the new fields to the existingstate_root/workspace/findings/<id>.jsonfile.Additionally, you must Update the Reproduction Attempt Cache to help the planner track attempts efficiently:
- Maintain a JSON cache file at
state_root/workspace/archive/.repro_attempts.json. Ensure the parent directorystate_root/workspace/archive/exists (e.g.,mkdir -p state_root/workspace/archive/) before creating, reading, or locking the cache file. - Key the cache by a stable identifier that persists across loop runs even if
UUIDs are regenerated. If the finding has a
signaturefield, use it directly as the cache key (it is already a deterministic content-identity hash). Ifsignatureis absent, fall back to a computed stable key using the finding's normalized title and its primary file path:stable_key = normalized_title + "@" + primary_file_path.- Compute
normalized_titleby converting the title to lowercase and removing all non-alphanumeric characters. - Compute
primary_file_pathby taking the first entry incode_pathsand stripping any line number suffixes (e.g., convertingsrc/auth.c:120tosrc/auth.c). - Snapshot-aware cap (value shape
{count, last_snapshot}): store each cache value as an object{count, last_snapshot}. When reading a value V: if V is a bare integer, treat count=V and last_snapshot=UNKNOWN; if V is an object, use V.count / V.last_snapshot (default UNKNOWN). Before incrementing, run Block B comparing the finding's snapshot to the current SNAPSHOT_ID: resetcount=0ONLY when Block B is NOT_MATCHED because the two snapshots are present and actually differ (a genuine code change earns a fresh budget). Do NOT reset on UNKNOWN (absent/pass_/unpinned) — that would make no-VCS targets retry forever. Additionally keep an absolute per-finding-id attempt counter that is NEVER reset, and stop retrying once it reaches a hard ceiling (e.g. 6) regardless of snapshot changes.
- Compute
- To prevent race conditions during concurrent executions (including locking
bypasses caused by atomic file replacement) and protect lockless readers:
- Use a separate dedicated lock file
state_root/workspace/archive/.repro_attempts.lockwhich is never deleted or replaced. - Perform updates atomically using Python's
fcntl.flockon this lock file:
- Open the lock file
state_root/workspace/archive/.repro_attempts.lock(creating it if missing) and acquire an exclusive lock (fcntl.flockwithfcntl.LOCK_EX) inside a context manager (withstatement). - Read the current contents of the cache file
state_root/workspace/archive/.repro_attempts.json(treating it as{}if missing or empty). - Increment the
countfield of this finding's cache-key entry — keyed bysignatureif present, elsestable_key, the SAME key selection defined above (the{count, last_snapshot}object) — by 1 ONLY for Tier-3 (full end-to-end sandboxed service) executions. Internal Tier-1 and Tier-2 stepping-stone trials MUST NOT incrementcount(they are governed by the sub-budget rule in Step 3). - Write the updated JSON to a temporary file in the same directory (e.g.,
state_root/workspace/archive/.repro_attempts.json.tmp). - Atomically replace the target cache file with the temporary file (e.g.,
os.replacein Python) to ensure readers never see a truncated or incomplete file. - Close the lock file descriptor to release the lock (automatically handled
by exiting the
withcontext manager).
- Use a separate dedicated lock file
Depending on whether the
--reattackflag is provided:If run normally (no
--reattackflag): You must append or update the following on the existing object:"repro_status"("reproduced","statically_confirmed","not_attempted", or"failed_to_reproduce")."repro_file_path""run_command""repro_output""repro_snapshot_id": the current SNAPSHOT_ID this run executed against."repro_hints": Record compilation and sandbox execution telemetry (e.g.,sanitizers_used: ASan+UBSan,assertions_disabled: true,build_profile: release) to provide empirical execution evidence for/mantis-critic.- If reproduction succeeds (
repro_statusis evaluated as"reproduced"or"statically_confirmed") and the finding's current"status"is"PROVISIONALLY_VALID": BEFORE upgrading, scan the finding'striage_checklist(if present). If ANY entry hasoutcome == "UNKNOWN"(orpasses == false), do NOT upgrade: leavestatusas"PROVISIONALLY_VALID", still setrepro_statusto the success value (reproduction DID succeed), and append a history noteupgrade-to-VALID-blocked: triage_checklist has UNKNOWN entries (re-review required). This avoids violating the schema'sVALID ⇒ no UNKNOWNallOf gate (schema.json lines 471-507), which forbidsUNKNOWN/passes:falseon anyVALIDnon-chain finding'striage_checklist. Reproduce does NOT touchtriage_checklistentries (the checklist is review's artifact; only review may resolveUNKNOWNentries). Iftriage_checklistis absent (noreviewerhistory entry, e.g. a legacy finding), or NO entry isUNKNOWN/passes:false, you must update"status"to"VALID". - An entry to the
"history"array:
{ "stage": "reproduce", "action": "reproduced", "details": "Reproduction status evaluated as [reproduced/failed_to_reproduce] using command: [run_command]", "pass_number": <current_pass_number>, "timestamp": "<current_iso8601_timestamp>" }If run with
--reattack: You must append or update the following on the existing object (do not touchrepro_*orstatus):"reattack_status"("bypassed_patch","failed_to_bypass","inconclusive_baseline_changed")."bypassed_patch": The PoC bypassed the patch and triggered the bug. Ifpatch_statusisVERIFIED_SECURE, atomically setpatch_status = "VERIFICATION_FAILED"in the same write (a bypass defeats the patch). This is an explicit exception to "do not touch status" and applies to both the C5 step-3 path and same-snapshot runs."failed_to_bypass": The PoC was run but failed to bypass the patch. (No downgrade needed —failed_to_bypassis the value the allOf gate requires forVERIFIED_SECURE.)"inconclusive_baseline_changed": The unpatched baseline was re-run (see C5 below) and the bug NO LONGER TRIGGERS on the current unpatched code. Do NOT claimfailed_to_bypass. Ifpatch_statusisVERIFIED_SECURE, atomically setpatch_status = "VERIFICATION_INCOMPLETE"in the same write.- INV-1 (single source — the schema's
VERIFIED_SECUREallOf gate):VERIFIED_SECURE => reattack_statusmust befailed_to_bypass, andfailed_to_bypassrequires a non-emptyreattack_variantsarray with ≥ 3 valid variant inputs (Step 3a) that ALL failed to trigger the bug on the patched shadow. An empty or short variant set makes "all failed" vacuously true — this is FORBIDDEN: cap atVERIFICATION_INCOMPLETEinstead. Any other outcome MUST atomically downgradepatch_statusin the same write —VERIFICATION_INCOMPLETEforinconclusive_baseline_changedor an insufficient variant set,VERIFICATION_FAILEDforbypassed_patch. Never persistVERIFIED_SECUREalongside a non-failed_to_bypassreattack_status. - Snapshot-mismatch -> governed by C5 below: When
reattack_snapshot_id!=repro_snapshot_id, do NOT independently record a verdict — follow C5, which re-establishes the unpatched baseline on the CURRENT snapshot. If C5 cannot run, fall back to leavingreattack_statusUNSET with aSNAPSHOT_MISMATCHhistory note. C5 — Unpatched-baseline re-run (Phase 2): Before running the attack on the patched build, if
reattack_snapshot_id!=repro_snapshot_id(a genuine snapshot change, NOT a HALT-modelive:tree), FIRST re-establish the unpatched baseline:- Run the reproducer against a FRESH UNPATCHED copy of the current
snapshot — a fresh
mktemp -dcopy ofactive_snapshot.root, NOT the patched shadow. (This is the same unpatched baseline thatmantis-patchBlock G step 1 runs; reproduce has no Block G.) - If the unpatched baseline does NOT trigger (evidence absent per Block
F): set
reattack_status = "inconclusive_baseline_changed", do NOT proceed with the attack, do NOT claimfailed_to_bypass. You MUST still populatereattack_file_path,reattack_run_command, andreattack_outputwith the baseline re-run's details. Apply INV-1 (downgradeVERIFIED_SECURE->VERIFICATION_INCOMPLETE). - If the unpatched baseline DOES trigger: proceed with the attack
(
bypassed_patchorfailed_to_bypass). Apply INV-1 (downgradeVERIFIED_SECURE->VERIFICATION_FAILEDifbypassed_patch).
- Sanitizer consistency: the baseline re-run, attack, and re-attack
MUST use the same sanitizer flags that made the original baseline
trigger. If the baseline triggered via UBSan (exit 0), recompiling the
attack without UBSan would mask the bug and produce a false negative
(INV-2) or false
failed_to_bypass(INV-1). - HALT-mode guardrail: Detect HALT by the PASS's snapshot id in state
(
active_snapshot.snapshot_idstarts withlive:), NOT the--snapshot_pinned=falseargument (that's only the sentinel-exemption for the patched shadow). In HALT, skip C5 and follow the existing HALT ceiling (leavereattack_statusUNSET with the HALT note). - This does NOT change the VERIFIED_SECURE gate — Block G still requires the unpatched baseline to trigger.
- Run the reproducer against a FRESH UNPATCHED copy of the current
snapshot — a fresh
"reattack_file_path""reattack_run_command""reattack_output""reattack_variants": An array of objects, one per variant input attempted during Step 3a. Each object MUST contain EXACTLY the two required keys"description"(string) and"triggered"(boolean). Do NOT invent free-form or custom keys (such asinput,result,bypassed,label,name):"reattack_variants": [ { "description": "off-by-one: len=bound+1", "triggered": false }, { "description": "alternate path via /api/v2/echo", "triggered": false }, { "description": "boundary mutation: max INT_MAX", "triggered": false } ]"description": What the variant does (e.g.,"off-by-one: len=bound+1","alternate path via /api/v2/echo")."triggered": boolean — whether this variant triggered the original vulnerability class on the patched shadow (per the variant validity guardrail in Step 3a). Invalid/junk mutants that produced an unrelated crash or error are recorded astriggered = falsewith a description noting invalidity.reattack_variantsMUST be non-empty (≥ 3 entries) forreattack_status = "failed_to_bypass". An empty array[]may ONLY coexist with a non-failed_to_bypassstatus (e.g., C5 baseline failure that halted before variant hunting, orinconclusive_baseline_changed).
"reattack_snapshot_id": the current SNAPSHOT_ID this run executed against.- An entry to the
"history"array:
{ "stage": "reattack", "action": "reproduced", "details": "Re-attack status evaluated as [bypassed_patch/failed_to_bypass] using command: [reattack_run_command]", "pass_number": <current_pass_number>, "timestamp": "<current_iso8601_timestamp>" }
- Maintain a JSON cache file at
Criticism of Reproduction Validity: To ensure the reproduction is a valid example of reproducing the reported vulnerability, have a subagent with a fresh context window review and criticize the generated PoC. Seek genuine criticism to ensure false reports are never surfaced later.
Variant criticism (re-attack only): When
--reattackis specified, the critic subagent MUST also verify that the variant inputs (Step 3a) are genuinely diverse — not trivially identical mutations (e.g., changing a comment while keeping the same payload). If the critic finds the variants are not meaningfully diverse, record a history notevariant_diversity_insufficientand re-author variants before finalizingreattack_status.
When complete, notify the user.
Trending
Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data
Who's talking about google/mantis
- Matheus Battisti“O Google lançou uma ferramenta que caça falhas de segurança com IA (Google Mantis)”YouTube · Jul 30, 2026 · 9.2k views
- ☕ Claude Code Cafe“🔒 コードの脆弱性を AI に探させて再現まで確かめる Google のリポジトリで公開された mantis #claude #claudecode”YouTube · Sep 8, 2026 · 647 views
- o0o0o0o“Your Tests Pass. Is Your Code Safe? Google’s AI Security Agents”YouTube · Sep 30, 2026 · 180 views
- ☕️ Claude Code Cafe“🔒 Let an Agent Find Your Security Flaws and Reproduce Them — mantis #claude #claudecode”YouTube · Sep 9, 2026 · 40 views
- 智用AI“Mantis:85% Token开销削减,AI漏洞扫描怎么做到的? #Shorts”YouTube · Sep 10, 2026 · 26 views
The biggest 5 of 46 mentions linking to the repository that our crawl found. Each line is their own headline.
See all 46
Talked about on GitHub, YouTube and Bluesky (46 times).
On GitHub · 32
- Oct 30, 2026Design sandboxed agentic bug hunting, RCA, and novel vulnerability discovery — combustrrr/code-analysis-dashboard0 reactions
- Oct 30, 2026Epic: governed scanner and agentic analysis expansion — combustrrr/code-analysis-dashboard0 reactions
- Oct 28, 2026[radar-spike] google/mantis skills — sandbox threat-model (no CI gate) — pablontiv/a4s0 reactions
- Oct 27, 2026google 'mantis' — AI 코딩 에이전트용 취약점 자동 발견·재현·패치 툴킷 (10/26, GitHub) — roomedia/ax-trend0 reactions
- Oct 24, 2026agent-skills.github.google.mantis: 0-unstable-2026-10-22 → 0-unstable-2026-10-24 — sudosubin/agents.nix0 reactions
27 more on GitHub
- Oct 23, 2026agent-skills.github.google.mantis: 0-unstable-2026-10-17 → 0-unstable-2026-10-22 — sudosubin/agents.nix0 reactions
- Oct 17, 2026agent-skills.github.google.mantis: 0-unstable-2026-10-16 → 0-unstable-2026-10-17 — sudosubin/agents.nix0 reactions
- Oct 16, 2026agent-skills.github.google.mantis: 0-unstable-2026-10-15 → 0-unstable-2026-10-16 — sudosubin/agents.nix0 reactions
- Oct 15, 2026agent-skills.github.google.mantis: 0-unstable-2026-10-14 → 0-unstable-2026-10-15 — sudosubin/agents.nix0 reactions
- Oct 14, 2026feat: SAST — LLM alert triage of CodeQL and Semgrep findings with human sign-off (PR/CI, Advanced) — sparkgeo/github-actions0 reactions
- Oct 14, 2026agent-skills.github.google.mantis: 0-unstable-2026-10-13 → 0-unstable-2026-10-14 — sudosubin/agents.nix0 reactions
- Oct 13, 2026agent-skills.github.google.mantis: 52093f7 → 49ab993 — sudosubin/agents.nix0 reactions
- Oct 13, 2026agent-skills.github.google.mantis: 0-unstable-2026-10-05 → 0-unstable-2026-10-13 — sudosubin/agents.nix0 reactions
- Oct 5, 2026agent-skills.github.google.mantis: 76bf653 → f671cd8 — sudosubin/agents.nix0 reactions
- Oct 5, 2026agent-skills.github.google.mantis: 0-unstable-2026-10-04 → 0-unstable-2026-10-05 — sudosubin/agents.nix0 reactions
- Oct 5, 2026agent-skills.github.google.mantis: 30447e1 → f5656dd — sudosubin/agents.nix0 reactions
- Oct 5, 2026agent-skills.github.google.mantis: f48a85e → 30447e1 — sudosubin/agents.nix0 reactions
- Oct 4, 2026Update skill: /google-mantis-patch (high risk) — aiskillstore/marketplace0 reactions
- Oct 4, 2026Update skill: /google-mantis-meta-agent (critical risk) — aiskillstore/marketplace0 reactions
- Oct 4, 2026Update skill: /google-mantis-dedupe (high risk) — aiskillstore/marketplace0 reactions
- Oct 4, 2026Update skill: /google-mantis-threat-model (low risk) — aiskillstore/marketplace0 reactions
- Oct 4, 2026Update skill: /google-mantis-history (medium risk) — aiskillstore/marketplace0 reactions
- Oct 4, 2026Update skill: /google-mantis-structural-index (high risk) — aiskillstore/marketplace0 reactions
- Oct 4, 2026Update skill: /google-mantis-calibrate (high risk) — aiskillstore/marketplace0 reactions
- Oct 4, 2026agent-skills.github.google.mantis: 0-unstable-2026-09-28 → 0-unstable-2026-10-04 — sudosubin/agents.nix0 reactions
- Oct 3, 2026agent-skills.github.google.mantis: 0-unstable-2026-09-18 → 0-unstable-2026-09-28 — sudosubin/agents.nix0 reactions
- Sep 27, 2026agent-skills.github.google.mantis: init at 0-unstable-2026-09-18 — sudosubin/agents.nix0 reactions
- Sep 22, 2026fix(rust): patch parameter bounds validation bugs to avoid panic — morrowc/mrtparser0 reactions
- Sep 22, 2026fix(cpp): add minimal bound checks for packet lengths — morrowc/mrtparser0 reactions
- Sep 11, 2026mode — chogng/ash0 reactions
- Jul 27, 2026Integrate Google Mantis Skills as CRSs — ossf/oss-crs0 reactions · 1 comment
- Jul 3, 2026Add Google Mantis — agentic AI security review pipeline — ottosulin/awesome-ai-security0 reactions
On YouTube · 9
- Jul 30, 2026O Google lançou uma ferramenta que caça falhas de segurança com IA (Google Mantis) — Matheus Battisti - Hora de Codar9.2k views · 29 comments
- Sep 8, 2026🔒 コードの脆弱性を AI に探させて再現まで確かめる Google のリポジトリで公開された mantis #claude #claudecode — ☕ Claude Code Cafe647 views
- Sep 30, 2026Your Tests Pass. Is Your Code Safe? Google’s AI Security Agents — o0o0o0o180 views
- Sep 9, 2026🔒 Let an Agent Find Your Security Flaws and Reproduce Them — mantis #claude #claudecode — ☕️ Claude Code Cafe40 views
- Sep 10, 2026Mantis:85% Token开销削减,AI漏洞扫描怎么做到的? #Shorts — 智用AIsays it tested it26 views
4 more on YouTube
- Sep 3, 2026今日のAI実用ニュース4選:Slack・Skills・動画理解・WebGPU【9月3日】 — 毎日最速AIニュース21 views
- Sep 10, 2026Mantis:85% Token开销削减,AI漏洞扫描怎么做到的? — 智用AIsays it tested it19 views
- Jul 15, 2026Developer tools and hidden risk & Enterprise agents need real infrastructure - AI News (Jul 15, 2... — The Automated Daily9 views
- Sep 3, 2026Googleの新Skills「Mantis」公開、本番PCで試すな #Shorts — 毎日最速AIニュース5 views
On Bluesky · 5
- Sep 15, 2026Mantis : toolkit open source de Google pour agents de coding, conçu pour trouver, reproduire et corriger des vulnérabilités de façon… — @camilleroux.com3 likes and reposts · 1 reply
- Oct 1, 2026GitHub - google/mantis: A modular, stack-agnostic toolkit for AI coding agents to autonomously find, reproduce, and patch vulnerabilities.… — @tech-trending.bsky.social1 likes and repost
- Sep 23, 2026#ばばさん通信ダイジェスト 賛否関わらず話題になった/なりそうなものを共有しています。 GitHub - google/mantis: A modular, stack-agnostic toolkit for AI coding agents to autonomously… — @netmarkjp.bsky.social1 likes and repost
- Jul 3, 2026Three repos that are leading our path forward in scaling AppSec workflows: 1. github.com/google/mantis 2. github.com/anthropics/d... 3.… — @javanrasokat.bsky.social1 likes and repost
- Oct 1, 2026🤖 GitHub - google/mantis: A modular, stack-agnostic toolkit for AI coding agents to autonomously find,... 要約:… — @ai-bs-bot.bsky.social0 likes and reposts · 1 reply
In this repository21 other files it gives its agents.
- AGENTS.mdAGENTS.md
- mantis-configureSkill
- mantis-launchSkill
- mantis-adviseSkill
- mantis-architectureSkill
- mantis-calibrateSkill
- mantis-chainSkill
- mantis-criticSkill
- mantis-dedupeSkill
- mantis-historySkill
- mantis-meta-agentSkill
- mantis-patchSkill
- mantis-pipeline-adapterSkill
- mantis-planSkill
- mantis-reflectSkill
- mantis-reportSkill
- mantis-researcherSkill
- mantis-reviewSkill
- mantis-structural-indexSkill
- mantis-summarizeSkill
- mantis-threat-modelSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

