mantis-meta-agent
Skill2.5k starsChanged 15 days agoApache-2.0View on GitHub
Acts as the persistent supervisor, launching and monitoring the automated review campaign. Use when running a long-running, continuous security review campaign that needs autonomous coordination. Don't use for executing individual review stages directly.
- Deletes or force-pushes
We split this skill into the rules it gives an agent
49 rules. About 0 are common, 7 are distinctive, and 42 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
42
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 26
NOT pin: leave active_snapshot/snapshot_history unwritten, leave snapshot_pinned unset, and run the pass against the live tree exactly as …
- Very specific: line 88
When --sync pins a snapshot (Block D): materializes an immutable snapshot copy under <state_root>/.mantis_snapshots/pass_<N>/ (deliberately …
- Distinctive: line 122
Do not perform the auditing or patching tasks yourself.
- Very specific: line 130
Initialization / Startup: Read N from "pass_number" in workspace/.mantis_state.json.
- Distinctive: line 197
NOT SYNC; log "sync skipped: local changes / detached / no upstream".
- Very specific: line 223
Check for Git: run git rev-parse --is-inside-work-tree.
- Very specific: line 234
Check for Mercurial: check if .hg directory exists or run hg root (if Mercurial is installed).
- Very specific: line 242
Check for Multi-VCS systems: check if .repo directory exists or look for other multi-VCS markers.
- Very specific: line 247
If you confirm that no VCS is active in the repository (e.g., the directory is a plain folder with no repository files or metadata), set …
- Very specific: line 250
If detection commands fail due to errors, missing tool executables (e.g.
- Distinctive: line 303
Write state.active_snapshot = {root, snapshot_id, snapshot_pinned, pass:N, vcs_type}.
- Very specific: line 343
RECORD (only after Steps 1–3): Update workspace/.mantis_state.json (conforming to schema.json #/$defs/state):
- Very specific: line 346
Write "vcs_info" from Step 2 (always, both modes).
- Very specific: line 347
If --sync was requested this pass: write "active_snapshot" = { "root": <root>, "snapshot_id": <SNAPSHOT_ID>, "snapshot_pinned": <true if …
- Very specific: line 349
Use the values Block D step 5 already wrote.
- Very specific: line 371
DELETE any pre-existing active_snapshot key from workspace/.mantis_state.json when running a pass without --sync (in-place key delete, NOT …
- Very specific: line 375
DELETE-when-entering-MODE-OFF, not a "do not overwrite": leaving the stale key would trip the cross-pass staleness gate …
- Very specific: line 389
State Maintenance: Write the current pass N to "pass_number" and the current ISO 8601 timestamp to "last_updated" in …
- Very specific: line 398
Snapshot argument passing (ALL stages, Stage 0–15): When --sync was requested this pass (whether PINNED or HALT — i.e.
- Very specific: line 421
Stage 0 (Optional Pre-processing History): Call the @mantis-history subagent to analyze repository's version control system (VCS) history …
- Very specific: line 426
Stage 0.5 (Optional Structural Index): Call the @mantis-structural-index subagent to build the structural index — a content-addressed …
- Very specific: line 440
Stage 1 (Optional Directory Mapping): If not already mapped, call the @mantis-summarize subagent to generate mantis-summary.md files for …
- Very specific: line 445
Stage 2 (KB Architecture): Call the @mantis-architecture subagent to synthesize the codebase structure and pending …
- Very specific: line 449
Stage 3 (Threat Modeling): Call the @mantis-threat-model subagent to read the KB and evaluate/update workspace/kb/THREAT_MODEL.md.
- Very specific: line 452
Stage 4 (Planning): Call the @mantis-plan subagent to evaluate boundaries, read the KB index, and generate workspace/plan.json with …
- Very specific: line 456
Stage 5 (Research): Call the @mantis-researcher subagent to perform the deep code sweep using the context in workspace/plan.json and …
- Very specific: line 460
Stage 6 (Deduplication): Call the @mantis-dedupe subagent to deduplicate files in the workspace/findings/ directory.
- Very specific: line 463
Stage 7 (Review): Call the @mantis-review subagent to evaluate findings in the workspace/findings/ directory.
- Very specific: line 466
Stage 8 (Critic): Call the @mantis-critic subagent to check production viability of files in the workspace/findings/ directory.
- Very specific: line 469
Stage 9 (Reproduce): Call the @mantis-reproduce subagent to develop crash reproducers and update files in the workspace/findings/ directory.
- Very specific: line 472
Stage 10 (Chain): Call the @mantis-chain subagent to analyze the current validated findings and the Knowledge Base to construct multi-step …
- Very specific: line 477
Stage 11 (Patch & Verify): Call the @mantis-patch subagent to generate fixes, and update files in the workspace/findings/ directory.
- Very specific: line 483
Stage 12 (Calibrate): Call the @mantis-calibrate subagent to read the workspace/findings/ directory and append final calibration metrics to …
- Very specific: line 487
Stage 13 (Reflect): Call the @mantis-reflect subagent to parse the execution trajectories of the round and append false assumptions or tool …
- Very specific: line 505
Stage 14 (Report): Call the @mantis-report subagent to generate the human-readable review packet (workspace/report/review_packet-latest.md …
- Very specific: line 521
Verify that the KB updates were successfully written and that workspace/learnings.jsonl was processed.
- Very specific: line 524
Read the current pass number N from the state file workspace/.mantis_state.json.
- Very specific: line 526
Ensure the archive directory exists: workspace/archive/findings_pass_N/.
- Very specific: line 542
If workspace/findings/ exists and contains findings, MOVE all .json files and the .trash/ directory (if it exists) into …
- Distinctive: line 546
If the findings directory is empty or does not exist, ensure it exists and skip the finding move (the state/KB copy in sub-step 3 still …
- Very specific: line 550
Write N_new to "pass_number" and the current ISO 8601 timestamp to "last_updated" in workspace/.mantis_state.json.
- Distinctive: line 559
Wait for each subagent to finish its execution and report back.
- Very specific: line 560
After a subagent returns control to you, optionally use your file reading tools to quickly inspect the resulting JSON files (e.g., in …
- Distinctive: line 565
If a subagent reports a critical failure or crashes its isolated loop, diagnose the issue, explain the environment fix, and retry …
- Very specific: line 569
Monitoring & Reporting: When the pipeline successfully reproduces a security flaw or verifies a patch (reported by the @mantis-patch …
- Very specific: line 593
Target-change & sync requests apply only at a pass boundary: If the user asks to change the target (re-point --target_root / a different …
- Very specific: line 596
START of the next pass and only when workspace/findings/ is EMPTY (all findings archived by Stage 15).
- Very specific: line 600
If findings/ is non-empty, tell the user you will apply the change at the next boundary and let the current pass finish.
- Distinctive: line 605
Resilience & Persistence: When Stage 15 (Archive & KB Verification) completes, immediately begin the next pass.
≈ “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
Meta-Agent Orchestrator (/mantis-meta-agent)
System Goal
Autonomous Campaign Manager. Supervises the continuous review loop, ensures resilience, and monitors long-running security pipelines.
Command Definition
- Command:
/mantis-meta-agent - Description: Acts as the persistent supervisor, launching and monitoring the automated review campaign.
- Parameters:
--sync: OPT-IN boundary sync + snapshot pinning. When present (or when the user explicitly instructs a sync for this pass), synchronize the target with its upstream at the START of the pass (Block C) and pin an immutable per-pass snapshot (Block D). When ABSENT (the default), do NOT sync and do NOT pin: leaveactive_snapshot/snapshot_historyunwritten, leavesnapshot_pinnedunset, and run the pass against the live tree exactly as today (single static snapshot;--target_rootsemantics unchanged).--snapshot_keep=<N>: retention for pinned snapshots under<state_root>/.mantis_snapshots/(Block D step 6 GC). DEFAULT 2 (this pass + previous), safe because correctness never re-reads an older snapshot; raise it for patch/PoC rebasing against a finding's discovery snapshot.--state_root=<absolute path>: directory that containsworkspace/and.mantis_snapshots/. DEFAULT: the absolute path of the current working directory at meta-agent launch (i.e., the parent ofworkspace/). Ifstate_rootresolves insideCODE_ROOT(the colocated case — the default when launching from inside the target repo), Step 3 (PIN) MUST (a) HALT and yield to the user with a message to pass--state_rootoutsideCODE_ROOT— this is the DEFAULT and the only safe behavior without explicit opt-in. Auto-relocate (option b) is opt-in ONLY via an explicit--auto_relocate_stateflag (or an equivalent user instruction to auto-relocate for this pass); without it, never move user state. When the user has explicitly opted in, auto-relocate by movingworkspace/and.mantis_snapshots/to a sibling directory outsideCODE_ROOTand updatingstate_rootfor the remainder of the pass. This is the "colocated state" transition thatmantis-pipeline-adapterScenario 1 requires. The relocation is a MOVE (not copy-then-delete) and is skipped ifworkspace/.workspace_edit.lockis held (INV-5: no user data loss). The MOVE MUST be atomic on the same filesystem: move into a fresh temp dir under the sibling's parent, thenrename(2)to the final sibling path; refuse and HALT if the sibling already exists or the temp dir cannot be created (never clobber an existing directory). Ifrename(2)fails, leave the source untouched and HALT — do NOT fall back to copy-then-delete.--auto_relocate_state: OPT-IN flag. Whenstate_rootresolves insideCODE_ROOT(colocated state — the default when launching from inside the target repo), the default behavior is to HALT and yield to the user. Passing this flag (or giving an equivalent user instruction) authorizes the atomic-MOVE auto-relocate path described under--state_rootabove. Without it, never move user state.
Input/Output Contract
- Reads:
workspace/.mantis_state.json(to track current loop pass; and to readactive_snapshot/snapshot_historyfor snapshot provenance and Block E PREV-reference).- Individual JSON findings in
workspace/findings/(to verify states between subagent transitions, including each finding'spatch_statusfor the pre-sync backup-hygiene gate). workspace/.workspace_edit.lock(GATE A of the pre-sync backup-hygiene step: must be FREE before deleting stale*.bak-*files).CODE_ROOT/.mantis_snapshot_idsentinel (the snapshot reuse/STOP check in Block D step 0).
- Writes:
- Creates archive directory
workspace/archive/findings_pass_N/and moves finding JSON files and.trash/to it; and (Stage 15) COPIESworkspace/.mantis_state.jsonandworkspace/kb/(incl.THREAT_MODEL.md) into it as the pass boundary reference. - Updates
workspace/.mantis_state.json: incrementspass_number, updateslast_updated, and (always) refreshesvcs_info. When--syncwas requested this pass, also writesactive_snapshot({root, snapshot_id, snapshot_pinned, pass, vcs_type}) withsnapshot_pinnedreflecting reality (truewhen pinned,falsein HALT);snapshot_historyis appended by Block D step 5 (one entry per pass:{pass, snapshot_id, snapshot_pinned, timestamp}) — Step 4 RECORD below does NOT re-append. These new keys are defined inschema.json#/$defs/state; they are optional and absent in MODE-OFF (no--sync). - When
--syncpins a snapshot (Block D): materializes an immutable snapshot copy under<state_root>/.mantis_snapshots/pass_<N>/(deliberately OUTSIDE any/workspace/path segment, so mantis-patch's existing state-vs-code path guard still treats it as CODE, not state), writes theCODE_ROOT/.mantis_snapshot_idsentinel, andchmod -R a-wthe copy.
- Creates archive directory
- Preconditions:
- Target project must be identified. Campaign orchestration tools/subagents must be ready.
- Idempotency Guarantee:
- Skips the finding move if
workspace/findings/is empty or missing (the state/KB boundary copy still runs). Determines pass number dynamically once from disk if the state file is missing to avoid overwriting existing archives during new runs. - Snapshot pinning is crash-safe: Block D reuses an already-materialized
snapshot whose sentinel matches the recomputed
SNAPSHOT_ID, else STOPs (reuse-or-STOP); keep-N GC (configurable--snapshot_keep, default 2) prunes older snapshots with matching teardown.
- Skips the finding move if
Instructions
Act as a persistent, long-lived supervisor that drives the Mantis defensive security reviewing pipeline continuously.
Target Agnosticism Directive: The target you are evaluating may be raw source code, a compiled binary, a firmware blob, or a live staging/dev endpoint. Ground your analysis in whatever format the target is currently in. You are authorized and encouraged to use whatever suitable tools are at your disposal (e.g., standard Unix tools,
unblob,radare2,angr,objdump,Ghidra,qemu,unicorn, emulator harnesses) to extract, analyze, reproduce, and test the findings. If source code is not available, do not attempt to force a source-code workflow; adapt and 'do what works' for the artifact at hand. Ensure your subagents are aware of the tools available to them.
Do not perform the auditing or patching tasks yourself. Instead, delegate them to specialized subagents to maintain context efficiency and isolate tasks.
Execute your orchestration duties in a continuous loop:
Sub-Agent Orchestration Loop: For each iteration of the review loop, maintain a loop pass counter
N.Initialization / Startup: Read
Nfrom"pass_number"inworkspace/.mantis_state.json. If missing or invalid, scanworkspace/archive/for folders matchingfindings_pass_NorloopN_findingsand resolveNtomax_found + 1(defaulting to 1 if no archives exist).Boundary Sync & Snapshot Pinning — Pass Lifecycle CONTRACT (STRICT ORDER). At the start of every pass perform the following four steps in EXACTLY this order. The Pass Lifecycle Contract (
schema.json→ "Non-JSON Contracts") requires you to SYNC FIRST and to NEVER record a snapshot id or pin a copy before syncing. Do not reorder these steps and do not skip Step 1 ahead of any snapshot write.Sync is OPT-IN. Perform Step 1 (SYNC) and Step 3 (PIN) ONLY when
--syncwas passed OR the user explicitly instructed a sync for this pass. Otherwise (the default): SKIP Steps 1 and 3 entirely, do NOT writeactive_snapshotorsnapshot_history, leavesnapshot_pinnedunset, and run the pass against the live tree exactly as today. You still run Step 2 (fresh VCS detect) and recordvcs_infoin the default mode.Guard: Sync (Step 1) must be the very first mutating action of the pass. Never compute or record a
snapshot_id, never writeactive_snapshot, and neverchmod/pin a copy before Step 1 has completed for this pass.SYNC (must be the very first action of the pass;
--synconly). First, pre-sync backup hygiene — remove stale*.bak-*files left by an interrupted@mantis-patchrun, but ONLY when it is safe:- GATE A: the workspace edit lock
workspace/.workspace_edit.lockmust be FREE (no patch in flight). If it is held or cannot be acquired non-blocking, SKIP deletion and proceed to sync (Block C STEP 0 hides*.bak-*from the dirty check anyway). - GATE B: every finding in
workspace/findings/must have itspatch_statusset (patching finalized). If any finding is mid-patch (nopatch_status), SKIP deletion. - SCOPE: delete only within the TARGET tree, never under Mantis state.
The glob MUST be narrow:
mantis-patchonly ever creates<target>.bak-[finding_id]wherefinding_idis a UUIDv4 (schema.json#/$defs/uuid). The broad*.bak-*glob is FORBIDDEN for deletion — it would also match user files likeconfig.yaml.bak-oldordata.bak-2024. Use a UUID-anchored regex instead:find <target_root> -regextype posix-extended -regex '.*\.bak-[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$' -not -path '*/.mantis_snapshots/*' -not -path '*/workspace/*' -delete. For full precision, enumerateworkspace/findings/*.json, read eachid, and delete only<anything>.bak-<that-id>files. Never deleteworkspace/,<state_root>/.mantis_snapshots/, or anything beneath them. Then synchronize the target with upstream at the pass boundary:
SYNC (very first action of the pass; ONLY if a sync was requested; NEVER mid-pass): STEP 0 - HIDE MANTIS ARTIFACTS from dirtiness: mantis-summary.md, .bak-, workspace/, .mantis_snapshots/ MUST be invisible to every dirty check. Delete stray
mantis-summary.mdand UUID-shaped*.bak-<uuid>files at the LIVE root first (same narrow glob as the SCOPE rule above — never the broad*.bak-*glob for deletion), and pass the per-VCS excludes below. (Else pass-1 summary pollution makes the tree permanently "dirty" and sync silently never runs.) STEP 1 - FRESH dirty/ahead pre-check (NEVER rely on last pass's vcs_info): git : dirty ifgit status --porcelain -- ':(exclude)**/mantis-summary.md' ':(exclude)**/*.bak-*' ':(exclude)workspace/' ':(exclude).mantis_snapshots/'is non-empty; ahead ifgit rev-list --count @{u}..HEAD 2>/dev/nullerrors or > 0; detached ifgit symbolic-ref -q HEADerrors. hg : dirty ifhg status -X '**/mantis-summary.md' -X '*.bak-*' -X 'workspace/**' -X '.mantis_snapshots/**'non-empty. multi-vcs : dirty ifrepo forall -c "git status --porcelain -- ':(exclude)**/mantis-summary.md' ':(exclude)**/*.bak-*' ':(exclude)workspace/' ':(exclude).mantis_snapshots/'"produces ANY output. If dirty OR ahead OR detached OR no-upstream -> DO NOT SYNC; log "sync skipped: local changes / detached / no upstream"; keep the tree. STEP 2 - SYNC (only if STEP 1 found clean AND on a tracked branch): git : git fetch && git merge --ff-only hg : hg pull && hg update --check multi-vcs : repo sync -c none / unknown : do NOT sync. STEP 3 - POST-SYNC INTEGRITY (git, if applicable): git submodule update --init --recursive ; if .gitattributes uses filter=lfs, git lfs pull. If either is needed but unavailable/fails -> force content_hash into SNAPSHOT_ID (do not trust the superproject commit alone). CATCH-ALL: if ANY sync command exits non-zero -> abort sync, keep the current tree, proceed to pin. Re-reviewing the same snapshot is always safe. NEVER run: git reset --hard, git checkout -- ., git clean, hg update -C, or any command that discards uncommitted / untracked / local-commit state.Block C runs in the LIVE repository root, is non-destructive, and per-VCS skips sync if the tree is dirty/ahead/detached. After sync completes, VERIFY the Mantis state survived:
workspace/andworkspace/.mantis_state.jsonmust still exist (Block C never touchesworkspace/). If either is missing after sync, HALT (do not detect, do not pin, do not proceed) and yield to the user.- GATE A: the workspace edit lock
FRESH VCS DETECT (only after sync). Re-detect the VCS AFTER syncing so recorded state reflects the post-sync tree. Run these checks in the LIVE repository root (Block A step 5 VCS-metadata carve-out — history/diff/VCS commands run in the live root, never inside a pinned CODE_ROOT):
- Check for Git: run
git rev-parse --is-inside-work-tree. If this command succeeds (returns exit code 0 and output istrue), a Git repository is active. Setvcs_typeto"git"and extract:commit_hash(viagit rev-parse HEAD)branch(viagit branch --show-currentorgit rev-parse --abbrev-ref HEAD)dirtystatus (check ifgit status --porcelain -- ':(exclude)**/mantis-summary.md' ':(exclude)**/*.bak-*' ':(exclude)workspace/' ':(exclude).mantis_snapshots/'is non-empty — same exclude set as STEP 1, so colocatedworkspace/and.mantis_snapshots/do not make the tree falsely dirty)
- Check for Mercurial: check if
.hgdirectory exists or runhg root(if Mercurial is installed). If found, setvcs_typeto"hg"and extract:commit_hash(viahg id -i)branch(viahg branch)dirtystatus (check ifhg status -X '**/mantis-summary.md' -X '*.bak-*' -X 'workspace/**' -X '.mantis_snapshots/**'is non-empty — same exclude set as STEP 1)
- Check for Multi-VCS systems: check if
.repodirectory exists or look for other multi-VCS markers. If found, resolve the active manifest revision (setrevision) or branch, and check if any sub-repositories are dirty (setdirty). Setvcs_typeto"multi-vcs". - If you confirm that no VCS is active in the repository (e.g., the
directory is a plain folder with no repository files or metadata),
set
vcs_typeto"none". - If detection commands fail due to errors, missing tool executables
(e.g.
gitnot found), or other unhandled exceptions during checks, setvcs_typeto"unknown".
- Check for Git: run
PIN IMMUTABLE SNAPSHOT (only after sync;
--synconly). Materialize an immutable per-pass copy and compute its identity:PIN SNAPSHOT (after SYNC, before any stage): 0. CRASH-RESUME (run FIRST, before any copy/detect): if
state.active_snapshot.pass == Non entry, REUSE that dir (no re-copy/re-pin). This reuse check is SAME-PASS ONLY — it does NOT cover cross-pass staleness (where Stage 15 preservedactive_snapshotwhile incrementingpass_number). Consumer stages must apply the current-pass check (active_snapshot.pass == state.pass_number) described inmantis-pipeline-adapterScenario 2. Ifsnapshot_pinnedwas true but the dir is now missing -> STOP and yield to the user (never re-pin to a possibly-drifted live tree). If reusing, skip steps 1–4 and go straight to step 5 (state write; thesnapshot_historyappend inside Step 5 is itself idempotent — see Step 5).- Detect vcs_info (existing meta-agent detection). VCS_ID = commit_hash (git/hg) / manifest revision (multi-vcs) / "" (else).
- FREE-SPACE PRECHECK: if a full copy is needed, compare
du -sof the live tree todffree space at state_root. If it will not fit -> skip copy, go to step 5b (unpinned/HALT). Never crash mid-copy on ENOSPC. - Choose SNAPSHOT_ROOT and materialize (tiered):
- Clean git ->
git worktree add --detach <SNAPSHOT_ROOT>; clean hg ->hg archive <SNAPSHOT_ROOT>(cheap, buildable). GC MUST later run the matching teardown (git worktree remove/prune). - Else copyable tree -> SNAPSHOT_ROOT =
<state_root>/.mantis_snapshots/pass_<N> (MUST NOT contain the
path segment "/workspace/"). Copy EXCLUDING .git .hg .repo .svn CVS
nested submodule VCS dirs, workspace/, .mantis_snapshots/,
mantis-summary.md, and .bak- (same hide-list as STEP 0, so a
colocated state_root cannot cause recursive self-copy); dereference
symlinks pointing INSIDE the tree; DROP symlinks pointing outside;
smudge LFS content if the analysis needs it. If
state_rootitself resolves inside CODE_ROOT, the copy MUST additionally exclude thestate_rootpath itself. - Single binary/firmware -> copy the artifact into SNAPSHOT_ROOT.
- Live endpoint / not a local dir -> go to step 5b.
- Clean git ->
- FAILURE-TOLERANT VERIFY: check copy exit status + a cheap sanity
check (file count / size within ~90% of source minus excludes). If a
failed/missing file IS referenced by any archived/planned code_paths
-> retry the copy once; if it still fails -> step 5b. If only
unreferenced files failed -> pin and log skipped paths. 5a. PINNED:
compute content_hash (whole copy), assemble SNAPSHOT_ID per the
ladder, snapshot_pinned=true, write SNAPSHOT_ID to
SNAPSHOT_ROOT/.mantis_snapshot_id, best-effort chmod -R a-w
SNAPSHOT_ROOT. 5b. UNPINNED (HALT mode): SNAPSHOT_ROOT=
<live root>, snapshot_pinned=false, SNAPSHOT_ID="live:"+ISO8601. Authoritative verdicts are forbidden this pass. - Write state.active_snapshot = {root, snapshot_id, snapshot_pinned,
pass:N, vcs_type}. APPEND {pass:N, snapshot_id, snapshot_pinned,
timestamp} to state.snapshot_history ONLY IF no entry with
pass == Nalready exists (idempotency check: scansnapshot_historyforpass == N; this mirrors the once-only pattern used forsignatureanddiscovery_commit). On crash-resume reuse (Step 0 routed here), an entry for pass N may already have been written by the prior run — in that case, writeactive_snapshotonly and do NOT append a secondsnapshot_historyentry for the same pass. NEVER overwrite prior entries. There must be exactly onesnapshot_historyentry per pass. - RETENTION/GC: keep the last N snapshot dirs (operator-configurable
via
--snapshot_keep, DEFAULT 2 = this pass + previous); delete older via the matching teardown (rm -rf for copies; git worktree remove/prune for worktrees). Correctness never reads an old snapshot, so the default of 2 is safe; raise N when you want patch/PoC rebasing to apply against a finding's discovery snapshot. - CRASH-RESUME (Post-Check): if Step 0 did not trigger, and Block D
returns
snapshot_pinned=false(HALT mode), still writeactive_snapshotin Step 4 and still pass--snapshot_root/--snapshot_idto stages so they see the HALT signal and degrade conservatively (no authoritative verdicts).
Block D performs the free-space precheck; chooses the clean-VCS fast path (git worktree / hg archive) or full copy / single-artifact copy / live- endpoint fallback per the snapshot_id ladder; computes
content_hash(sha256 over EVERY file in the pinned copy — never a partial hash); assemblesSNAPSHOT_ID; writes theCODE_ROOT/.mantis_snapshot_idsentinel;chmod -R a-wthe copy; runs keep-N GC (--snapshot_keep, default 2) with matching teardown; and handles crash-resume (reuse-or-STOP, step 0). Block D is fail-closed: if it cannot pin because the target is too big to copy or is not a local dir, it either falls back to alive:-prefixed id withsnapshot_pinned=false(live-endpoint gate) or HALTs the pass — in neither case may you proceed as if a pinned snapshot exists. If Block D returnssnapshot_pinned=false(HALT), still writeactive_snapshotin Step 4 and still pass--snapshot_root/--snapshot_idto stages so they see the HALT signal and degrade conservatively (no authoritative verdicts).RECORD (only after Steps 1–3). Update
workspace/.mantis_state.json(conforming toschema.json#/$defs/state):- Write
"vcs_info"from Step 2 (always, both modes). - If
--syncwas requested this pass: write"active_snapshot"={ "root": <root>, "snapshot_id": <SNAPSHOT_ID>, "snapshot_pinned": <true if pinned, false if HALT>, "pass": <N>, "vcs_type": <vcs_type> }. Use the values Block D step 5 already wrote; do NOT re-derive them.snapshot_pinnedreflects reality:truewhen Step 3 pinned an immutable copy (5a),falsein HALT (5b: live endpoint, too-big-to-copy, copy-failed, or dirty/racing tree). Do NOT re-append to"snapshot_history"— Block D step 5 already appended exactly one entry for this pass ({ "pass": <N>, "snapshot_id": <SNAPSHOT_ID>, "snapshot_pinned": <bool>, "timestamp": <ISO 8601> }). Re-appending would create a duplicate; there must be exactly onesnapshot_historyentry per pass. (If you are in a code path where Block D step 5 did NOT run — e.g. crash-resume reuse of an already-pinned snapshot — append here ONLY IF no entry for pass N already exists insnapshot_history(idempotency check: scan forpass == N); otherwise writeactive_snapshotonly.) Matchschema.json#/$defs/stateEXACTLY: the per-entry key ispass(NOTpass_number); the separate top-levelstate.pass_numberloop counter is written in State Maintenance below. - In MODE-OFF (no
--syncrequested): do NOT writeactive_snapshotorsnapshot_history(leave them absent → downstream stages run exactly as today per the global backward-compat rule). Because Stage 15 sub-step 7 PRESERVESactive_snapshotacross pass boundaries, a prior--syncpass leaves a staleactive_snapshot(withpass == N-1) behind. To actually achieve MODE-OFF semantics, you MUST actively DELETE any pre-existingactive_snapshotkey fromworkspace/.mantis_state.jsonwhen running a pass without--sync(in-place key delete, NOT a fresh-object overwrite — preservevcs_info,snapshot_history,pass_number, etc.). This is a DELETE-when-entering-MODE-OFF, not a "do not overwrite": leaving the stale key would trip the cross-pass staleness gate (active_snapshot.pass != state.pass_number) in consumer stages (mantis-calibrate,mantis-chain,mantis-architecture) and contradict the schema's MODE-OFF =active_snapshotABSENT rule.snapshot_historyis an append-only log — NEVER delete or truncate it; it remains as historical provenance. Writingactive_snapshotwithsnapshot_pinned=falseis NOT the same as omitting it: an absentactive_snapshotmeans MODE-OFF, while a present one withsnapshot_pinned=falsemeans HALT (conservative, no authoritative verdicts). Never erase a HALT signal by omittingactive_snapshotwhen--syncwas requested. Never writeactive_snapshotor setsnapshot_pinned=truebefore Steps 1–3 have completed for this pass.
- Write
State Maintenance: Write the current pass
Nto"pass_number"and the current ISO 8601 timestamp to"last_updated"inworkspace/.mantis_state.json("vcs_info", and — when pinned —"active_snapshot"/"snapshot_history", were written in Startup Steps 2 and 4). Then delegate the workload sequentially to the specialized subagents. Call each subagent as a tool (or using the@agent_namesyntax if instructed by your prompt) with a concise instruction to perform its designated task:Snapshot argument passing (ALL stages, Stage 0–15). When
--syncwas requested this pass (whether PINNED or HALT — i.e.active_snapshotis present in state), APPEND these three arguments to the instruction string of EVERY@stagedelegation below, using the values fromactive_snapshot:--snapshot_root=<active_snapshot.root> --snapshot_id=<active_snapshot.snapshot_id> --state_root=<absolute path of the directory that contains workspace/>. Pass them to every stage uniformly and do NOT special-case the findings-only stages (report, calibrate, reflect): they ignore the code root via their own Block A ROLE gate. In HALT mode (active_snapshot.snapshot_pinned == false), the stages still receive the roots and readactive_snapshotfrom state — they use it to degrade conservatively (no authoritative verdicts). When NO--syncwas requested (MODE-OFF), pass only--state_root=<...>(plus--target_root=<...>if you were already passing one, exactly as today); do NOT invent a--snapshot_id. Do not edit the individual Stage 0–15 bullets — this single directive governs all of them.Pin enablement. Block A (Locator Resolution) is universal across all code-reading stages. When
--syncis requested, PIN in Step 3 and pass--snapshot_root/--snapshot_idnormally — do not artificially forcesnapshot_pinned=false. (Thelive:-id HALT fallback in Block D step 5b handles targets that genuinely cannot be pinned.)- Stage 0 (Optional Pre-processing History): Call the
@mantis-historysubagent to analyze repository's version control system (VCS) history and extract past vulnerabilities and security fixes into aworkspace/historical_learnings.jsonlfile. - Stage 0.5 (Optional Structural Index): Call the
@mantis-structural-indexsubagent to build the structural index — a content-addressed semantic-unit index published asworkspace/kb/structural_index/manifest.json+catalog.sqlite(withstructural_index.jsonlas a compatibility pointer) and exposed viaworkspace/helpers/query_structural_index.py. It runs immediately after the snapshot is pinned (Block D), before the first code-reading analysis stage, using only CODE_ROOT + SNAPSHOT_ID. In MODE-OFF, it builds against the current directory withsnapshot_idset to"unknown"and rebuilds each pass (the live tree is mutable, so a reused index could lag current code). The index is a HINT-only enhancement — it never gates findings and degrades gracefully to an empty index (grep fallback) when unavailable or not invoked. A non-conformant harness simply skips this stage. - Stage 1 (Optional Directory Mapping): If not already mapped, call the
@mantis-summarizesubagent to generatemantis-summary.mdfiles for each directory to optimize downstream planning and summaries with historical context. - Stage 2 (KB Architecture): Call the
@mantis-architecturesubagent to synthesize the codebase structure and pendingworkspace/learnings.jsonlinto the permanent Markdown Knowledge Base (workspace/kb/). - Stage 3 (Threat Modeling): Call the
@mantis-threat-modelsubagent to read the KB and evaluate/updateworkspace/kb/THREAT_MODEL.md. - Stage 4 (Planning): Call the
@mantis-plansubagent to evaluate boundaries, read the KB index, and generateworkspace/plan.jsonwith injected context pointers. - Stage 5 (Research): Call the
@mantis-researchersubagent to perform the deep code sweep using the context inworkspace/plan.jsonand populate theworkspace/findings/directory. - Stage 6 (Deduplication): Call the
@mantis-dedupesubagent to deduplicate files in theworkspace/findings/directory. - Stage 7 (Review): Call the
@mantis-reviewsubagent to evaluate findings in theworkspace/findings/directory. - Stage 8 (Critic): Call the
@mantis-criticsubagent to check production viability of files in theworkspace/findings/directory. - Stage 9 (Reproduce): Call the
@mantis-reproducesubagent to develop crash reproducers and update files in theworkspace/findings/directory. - Stage 10 (Chain): Call the
@mantis-chainsubagent to analyze the current validated findings and the Knowledge Base to construct multi-step exploit chains, outputting "Super Findings" into theworkspace/findings/directory. - Stage 11 (Patch & Verify): Call the
@mantis-patchsubagent to generate fixes, and update files in theworkspace/findings/directory. Instruct it to repeatedly call a fresh@mantis-reproducesubagent against its patches to attempt a bypass, refining the fix until the reproducer can no longer bypass it. - Stage 12 (Calibrate): Call the
@mantis-calibratesubagent to read theworkspace/findings/directory and append final calibration metrics to each finding file. - Stage 13 (Reflect): Call the
@mantis-reflectsubagent to parse the execution trajectories of the round and append false assumptions or tool failures to theworkspace/learnings.jsonlinbox. Important: You must pass the absolute file paths to the execution log files (e.g.transcript.jsonlfiles) of all subagents successfully executed during this round (every stage that ran: history, structural-index, summarize, architecture, threat-model, plan, researcher, dedupe, review, critic, reproduce, chain, patch, calibrate) to the@mantis-reflectsubagent. Resolve these paths from whatever mechanism the ACTIVE coding-agent harness exposes for per-subagent execution logs; do NOT hardcode any single framework's layout. Harnesses differ — e.g. Antigravity stores them under<appDataDir>/brain/<conversation_id>/.system_generated/logs/transcript.jsonl, while Gemini CLI, the Google ADK, Claude Code, and custom pipelines use different locations; Antigravity is ONE example, not the default. If your harness exposes no such logs, pass an EXPLICIT EMPTY list to@mantis-reflectand instruct it to record a missing-transcript insight per stage rather than silently emitting zero learnings. - Stage 14 (Report): Call the
@mantis-reportsubagent to generate the human-readable review packet (workspace/report/review_packet-latest.mdand the per-pass archiveworkspace/report/review_packet_pass_<N>.md— which, when a snapshot is pinned, carries a snapshot suffixreview_packet_pass_<N>_<snapshot_id>.mdso a re-used pass number on a different snapshot cannot overwrite a prior packet.review_packet-latest.mdremains the stable entry point) containing only reproduced findings, evidence, and patches. Stage 15 (Archive & KB Verification):
- Call the
@mantis-architecturesubagent to perform a final synthesis of the current round's findings (especially"FALSE_POSITIVE","NON_VIABLE","SAMPLE_OR_TEST", and"VERIFIED_SECURE") into the permanent Markdown Knowledge Base (workspace/kb/). - Verify that the KB updates were successfully written and that
workspace/learnings.jsonlwas processed. - Archive and Increment Pass:
- Read the current pass number
Nfrom the state fileworkspace/.mantis_state.json. - Ensure the archive directory exists:
workspace/archive/findings_pass_N/. - Snapshot the pass boundary (ALWAYS, even if
findings/is empty). COPY (never move) the following intoworkspace/archive/findings_pass_N/so the next pass has an immutable reference point:workspace/.mantis_state.json→workspace/archive/findings_pass_N/.mantis_state.json(preserves this pass'spass_number,vcs_info,active_snapshot, andsnapshot_history, giving@mantis-plana PREV reference for Block E's changed-files diff).- the entire
workspace/kb/directory (includingworkspace/kb/THREAT_MODEL.md) →workspace/archive/findings_pass_N/kb/. Use copy, not move: the liveworkspace/kb/andworkspace/.mantis_state.jsonMUST survive into the next pass.
- If
workspace/findings/exists and contains findings, MOVE all.jsonfiles and the.trash/directory (if it exists) intoworkspace/archive/findings_pass_N/(e.g.,mv workspace/findings/*.json workspace/archive/findings_pass_N/). - If the findings directory is empty or does not exist, ensure it exists and skip the finding move (the state/KB copy in sub-step 3 still ran).
- Increment
Nby 1 to get the new pass numberN_new = N + 1. - Write
N_newto"pass_number"and the current ISO 8601 timestamp to"last_updated"inworkspace/.mantis_state.json. PRESERVE, do not delete, the existing"vcs_info","active_snapshot", and"snapshot_history"keys when you rewrite the file — perform an in-place key update, NOT a fresh-object overwrite. Dropping these keys would strand@mantis-planwith no PREV reference.
- Read the current pass number
- Call the
Intelligent Supervision & Error Handling:
- Wait for each subagent to finish its execution and report back.
- After a subagent returns control to you, optionally use your file reading
tools to quickly inspect the resulting JSON files (e.g., in
workspace/findings/) to verify the state. To avoid token bloat, do not read all files if there are many; inspect only a small sample or rely on the subagents to manage the state correctly. - If a subagent reports a critical failure or crashes its isolated loop, diagnose the issue, explain the environment fix, and retry delegating to that subagent.
Monitoring & Reporting: When the pipeline successfully reproduces a security flaw or verifies a patch (reported by the
@mantis-patchsubagent), or when@mantis-calibratefinishes its scoring, you may output a brief text summary to the user.- Do NOT report findings that failed to reproduce
(
repro_status: "failed_to_reproduce") as confirmed vulnerabilities. - Do NOT report findings that are marked
LOWpriority or areNON_VIABLEas confirmed vulnerabilities. These are considered low-quality, fragile, or non-actionable. You may list them separately at the bottom of your summary under a "Hygiene & Low Priority Notes" section, but do not present them as active security flaws.
- Do NOT report findings that failed to reproduce
(
Human-in-the-Loop Steering & Collaboration: While you are designed for autonomy, remain responsive to user input. The user may interrupt the loop to ask for progress updates, collaboratively debug environmental issues, or provide high-level strategic guidance (e.g., "Focus exclusively on the networking stack in the next pass").
- Adapt the instructions you give to your subagents based on recent user feedback.
- You can use your subagent delegation tools to perform "Deep Dives" on specific findings if the user requests more detail without interrupting the main loop logic.
- Target-change & sync requests apply only at a pass boundary. If the
user asks to change the target (re-point
--target_root/ a different codebase) or to--syncnow, do NOT apply it mid-pass. Defer it to the START of the next pass and only whenworkspace/findings/is EMPTY (all findings archived by Stage 15). Applying a target or sync change while findings are in flight would strand those findings against a code root that no longer matches theirdiscovery_commit, producing silent wrong results. Iffindings/is non-empty, tell the user you will apply the change at the next boundary and let the current pass finish; if they insist on aborting, run Stage 15 to archive the current findings first, then apply the change at the fresh boundary.
- Resilience & Persistence: When Stage 15 (Archive & KB Verification) completes, immediately begin the next pass. Chain your tool calls automatically. However, if you encounter a permanent, non-recoverable error (e.g., a persistent environment failure or fundamentally broken pipeline state), halt the loop and yield to the user. Try your best to recover from and fix transient issues (like rate limits or temporary file locks) before deciding to halt.
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-patchSkill
- mantis-pipeline-adapterSkill
- mantis-planSkill
- mantis-reflectSkill
- mantis-reportSkill
- mantis-reproduceSkill
- 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.

