[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69923BSPMRW5P06D2G284VJ":3,"skill-same:01M69923BSPMRW5P06D2G284VJ":68},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M69923BSPMRW5P06D2G284VJ","mantis-plan",null,"Formulates a targeted defensive security reviewing plan based on the active threat model and historical learnings. Use when starting a security review campaign to map the codebase boundaries and generate a roadmap (workspace\u002Fplan.json). Don't use for executing code reviews, writing test scripts, or patching code.","google\u002Fmantis","google","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1342004?v=4","01M698VYEFDM0VJBZDYYJ2T83S","Google","01M6990SDGGFEAP21TJNS7HEG9",2778,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fmantis\u002Fblob\u002Fmain\u002Fskills\u002Fmantis-plan\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"mantis plan","plan","model","when","reviews","scripts","active","map","learnings","campaign","roadmap","threat","writing","patching","threat model","code","generate","security review","security","review","2026-11-10 10:12:30",false,"---\nname: mantis-plan\ndescription: >-\n  Formulates a targeted defensive security reviewing plan based on the active threat model and historical learnings.\n  Use when starting a security review campaign to map the codebase boundaries and generate a roadmap (workspace\u002Fplan.json).\n  Don't use for executing code reviews, writing test scripts, or patching code.\n---\n\n# Strategist (\u002Fmantis-plan)\n\n## System Goal\n\nSecurity Architect. Analyzes code structure, directory metadata, and historical\nrecords to map the external boundary and formulate an adaptive review roadmap.\n\n## Command Definition\n\n- **Command:** `\u002Fmantis-plan`\n- **Description:** Formulates a targeted defensive security reviewing plan based\n  on the active threat model and historical learnings.\n- **Arguments (optional; supplied by the orchestrator, consumed by Block A):**\n  - `--snapshot_root` \u002F `SNAPSHOT_ROOT`: absolute path to the pinned read-only\n    code snapshot (CODE_ROOT for all snapshot-relative paths).\n  - `--snapshot_id` \u002F `SNAPSHOT_ID`: the pass snapshot identifier (sentinel +\n    Block B comparisons).\n  - `--state_root`: absolute path to the `workspace\u002F` state dir (plan.json,\n    .mantis_state.json, findings\u002F, kb\u002F, archive\u002F). STATE-RELATIVE — never\n    prefixed with CODE_ROOT.\n  - All flags absent -> MODE-OFF\u002Flegacy mode (Block A step 1d): behaves exactly\n    as today.\n\n## Input\u002FOutput Contract\n\n- **Reads**:\n  - `workspace\u002F.mantis_state.json` (to track current loop pass).\n  - `workspace\u002Fkb\u002FTHREAT_MODEL.md` (if exists).\n  - `workspace\u002Fkb\u002Findex.md` (checks existence to determine Mode A vs B).\n  - Mode A: traverses production directories and source files, reads\n    `mantis-summary.md` (if available).\n  - Mode B: reads `workspace\u002Fkb\u002Findex.md`, `workspace\u002Fkb\u002FTHREAT_MODEL.md`,\n    `workspace\u002Farchive\u002F.repro_attempts.json` (if exists), VCS diffs or file\n    timestamps\u002Fhashes.\n  - `workspace\u002Fkb\u002Fstructural_index\u002Fmanifest.json` (to check structural index\n    availability\u002Fstatus).\n  - `workspace\u002Fhelpers\u002Fquery_structural_index.py` (to invoke bounded\n    structural-index queries).\n  - `workspace\u002F.mantis_state.json` NEW fields:\n    `active_snapshot.{snapshot_id, snapshot_pinned, vcs_type}`,\n    `snapshot_history` (read, written by the meta-agent). `vcs_type` is read\n    because Block E branches on it. Plan runs Block E in the LIVE repo root to\n    compute `changed_files` \u002F `changed_files_status` (COMPUTED or UNKNOWN) and\n    writes them back to state.\n- **Writes**:\n  - `workspace\u002Fplan.json`.\n  - Copies retry-eligible finding JSON files from\n    `workspace\u002Farchive\u002Ffindings_pass_K\u002F` or `workspace\u002Farchive\u002FloopK_findings\u002F`\n    (where K is the pass it was archived in) to `workspace\u002Ffindings\u002F`\n    (preserving their original UUID filenames).\n- **Preconditions**:\n  - Codebase must be accessible.\n- **Idempotency Guarantee**:\n  - Overwrites `workspace\u002Fplan.json` directly. In Mode B, copies a finding back\n    verbatim only when Block B is MATCHED and its file is unchanged and present;\n    otherwise it schedules a fresh re-discovery investigation. Consults\n    `.repro_attempts.json` under the cache read rule.\n\n## Instructions\n\n### Step 0: Locator Resolution (run before everything else)\n\n```\nLOCATOR RESOLUTION (before reading ANY target code or artifact):\n0. ROLE: If this skill NEVER reads target source (report, calibrate, reflect),\n   you are a FINDINGS-ONLY stage: skip steps 2-6; still read active_snapshot from\n   state for provenance\u002Fannotation; NEVER stop merely because a code root is unset.\n1. Determine CODE_ROOT, in this priority order:\n   a. If --target_root is passed on THIS invocation, CODE_ROOT = --target_root.\n      It is AUTHORITATIVE and OVERRIDES SNAPSHOT_ROOT and the state fallback\n      (used when a caller hands you a prepared tree, e.g. a patched shadow).\n   b. Else if --snapshot_root (or SNAPSHOT_ROOT) is passed, use it.\n   c. Else read state_root\u002Fworkspace\u002F.mantis_state.json (state_root from\n      --state_root if passed, else .\u002Fworkspace\u002F... relative to the current dir)\n      -> active_snapshot.root \u002F .snapshot_id \u002F .snapshot_pinned.\n   d. Else (no arg AND no readable active_snapshot): CODE_ROOT = current directory,\n      treat snapshot_pinned = false (MODE-OFF). Do NOT stop.\n2. SENTINEL CHECK (only if snapshot_pinned is true AND you did NOT take path 1a):\n   verify CODE_ROOT\u002F.mantis_snapshot_id exists and equals SNAPSHOT_ID. If missing\n   or different -> STOP \"snapshot sentinel mismatch\". (A --target_root tree (1a) is\n   deliberately mutated and is sentinel-EXEMPT.)\n3. PATH FIELDS:\n   - SNAPSHOT-RELATIVE (read under CODE_ROOT): code_paths entries; plan target_files\n     that are file paths. Strip ONLY a trailing \":\u003Cdigits>\". A code_paths entry\n     containing \":\u002F\u002F\" is a URL\u002Fendpoint, NOT a file read. A code_paths entry that is\n     NOT of the form \u003Cexisting-path>:\u003Cinteger> is a non-source LOCATOR\n     (symbol\u002Foffset\u002Fendpoint): only check that the artifact\u002Fsymbol exists; skip ALL\n     line-range and line-existence logic.\n   - STATE-RELATIVE (read\u002Fwrite under state_root\u002Fworkspace, NEVER prefix CODE_ROOT):\n     kb_references, repro_file_path, reattack_file_path, helper scripts, report\n     files, and all state\u002Ffindings JSON.\n4. Never WRITE under CODE_ROOT when snapshot_pinned is true. Any command that\n   compiles, generates, or writes artifacts MUST run in a PRIVATE SHADOW copy\n   (mktemp -d from CODE_ROOT), never with cwd=CODE_ROOT. Read-only inspection may\n   cd into CODE_ROOT.\n5. VCS-METADATA CARVE-OUT: history-log extraction and any VCS diff\u002Fblame command\n   run in the LIVE repository root (which still has .git\u002F.hg\u002F.repo), NOT CODE_ROOT\n   (the snapshot copy strips VCS metadata). Do NOT stop merely because CODE_ROOT\n   lacks .git\u002F.hg\u002F.repo.\n6. Every shell command uses ABSOLUTE paths and sets its own working directory on\n   that call. Do NOT assume the working directory persists between calls.\n```\n\n> [!NOTE] **CURRENT-PASS CHECK (defensive; the binding guarantee is on the\n> harness per `mantis-pipeline-adapter` Scenario 2):** if `active_snapshot` is\n> present AND `active_snapshot.pass != state.pass_number`, treat the snapshot as\n> STALE for this pass — STOP \"stale active_snapshot: pass mismatch\" or degrade\n> as HALT (`snapshot_pinned` effectively false: no authoritative verdicts, Block\n> B NOT_MATCHED, reproduce `not_attempted`). This catches a custom harness that\n> preserved `active_snapshot` across the Stage 15 pass increment without\n> re-pinning. The reference meta-agent re-pins every pass, so this check never\n> fires there. Block B itself cannot detect this (it is `snapshot_id`-only, not\n> `pass`-aware).\n\nSkill-specific notes for the strategist:\n\n- Plan is a CODE-READING stage in Mode A (it crawls production directories); the\n  findings-only skip does NOT apply.\n- Mode A crawling and every `target_files` path are SNAPSHOT-RELATIVE: crawl and\n  resolve them under CODE_ROOT.\n- `workspace\u002Fkb\u002F`, `workspace\u002Fplan.json`, `workspace\u002F.mantis_state.json`,\n  `workspace\u002Farchive\u002F`, and `workspace\u002Ffindings\u002F` are STATE-RELATIVE: read\u002Fwrite\n  them under --state_root, NEVER under CODE_ROOT.\n- Never write, compile, or generate under CODE_ROOT (Block A step 4). The plan\n  script writes ONLY workspace\u002Fplan.json (state-relative). The VCS diff in Block\n  E runs in the LIVE repo root per Block A step 5, NOT CODE_ROOT.\n\nAnalyze the repository structure and create a detailed defensive security review\nplan that avoids duplication of prior efforts while digging deep into complex\ninter-procedural paths and un-scanned code boundaries.\n\n> **Target Agnosticism Directive:** The target you are evaluating may be raw\n> source code, a compiled binary, a firmware blob, or a live staging\u002Fdev\n> endpoint. Ground your planning in whatever format the target is currently in.\n> You are authorized and encouraged to use whatever suitable tools are at your\n> disposal (e.g., standard Unix tools, `unblob`, `radare2`, `angr`, `objdump`,\n> `Ghidra`, `qemu`, `unicorn`) to explore the artifact structure. If source code\n> is not available, do not attempt to force a source-code workflow (e.g.\n> searching for `.c` or `.py` files); adapt and 'do what works' for the artifact\n> at hand.\n\nExecute the planning stage as follows:\n\n1. **Check for Threat Model Context:** Check the knowledge base directory for a\n   `workspace\u002Fkb\u002FTHREAT_MODEL.md` file. If it exists, read the file it\n   completely to understand the program's official security boundaries, threat\n   actors, assets, high-risk interfaces, and trusted inputs.\n\n2. **Determine Mode & Retrieve Learnings:** Check if the knowledge base index\n   `workspace\u002Fkb\u002Findex.md` exists.\n\n   - **MODE A: First-Pass Exhaustive Mode (No `workspace\u002Fkb\u002Findex.md` found):**\n     If this is the first run, guarantee complete coverage of the codebase. To\n     avoid hitting output token limits on large repositories, do not generate\n     the `workspace\u002Fplan.json` manually in your text response. Instead, execute\n     a shell command to run a short script in your preferred language that:\n\n     1. Uses `find` or `os.walk` to crawl all production directories. If a\n        `mantis-summary.md` file exists in a directory, use its contents to\n        understand the directory structure instead of reading every individual\n        source file. Otherwise, crawl all production source code files (e.g.,\n        `.c`, `.cpp`, `.py`, `.js`, `.go`, `.rs`, `.java`).\n     2. Ignores test folders, build artifacts, and vendor dependencies (e.g.,\n        `node_modules`, `.git`, `tests\u002F`).\n     3. Programmatically formats the list into the `workspace\u002Fplan.json` schema\n        and writes it directly to disk. Because this is an automated script,\n        instruct it to use a generic, overarching baseline question for the\n        `\"question\"` field (e.g., \"Conduct a baseline audit for memory safety\n        and logic flaws\"), reserving highly contextual custom questions for Mode\n        B.\n\n   - **MODE B: Strategic Learning Mode (`workspace\u002Fkb\u002Findex.md` exists):** Read\n     `workspace\u002Fkb\u002Findex.md` and `workspace\u002Fkb\u002FTHREAT_MODEL.md` to review the\n     compounded historical knowledge of the codebase, including trust\n     boundaries, vulnerability classes, and architectural components. Adapt your\n     focus to design new, targeted deep dives and regression reviews for\n     components and files that have histories of vulnerabilities. You may\n     generate the `workspace\u002Fplan.json` manually using your file-writing tools\n     for this mode, as the scope will be much narrower.\n\n     - **Targeted Re-Evaluation & Retries**: Review the KB index, entity files,\n       and the reproduction attempt cache file\n       (`workspace\u002Farchive\u002F.repro_attempts.json` if it exists). You must\n       identify findings that need re-evaluation or retries:\n\n       Also read the snapshot context from `workspace\u002F.mantis_state.json`:\n       `active_snapshot.{snapshot_id, snapshot_pinned}` and `snapshot_history`\n       (both written by the meta-agent). Then COMPUTE `changed_files` \u002F\n       `changed_files_status` for THIS pass by running Block E below in the LIVE\n       repository root (per Block A step 5 — VCS-metadata carve-out; the pinned\n       --snapshot_root strips .git\u002F.hg\u002F.repo, so the diff MUST run against the\n       live tree). Write the computed `changed_files` (array of repo-relative\n       paths) and `changed_files_status` (`COMPUTED` or `UNKNOWN`) back to\n       `workspace\u002F.mantis_state.json`, then use them for the rest of the stage.\n       Also write `changed_files_pass` = the current `pass_number` from state,\n       so consumers can detect a stale (prior-pass) diff. Use the following to\n       know which files changed since the previous pass:\n\n       CHANGED-SINCE-PREVIOUS: run in the LIVE repository root (NOT\n       SNAPSHOT_ROOT). CUR = current commit\u002Frevision; PREV = snapshot_history\n       entry BEFORE this pass. If PREV missing OR vcs_type in {none,unknown} OR\n       the SNAPSHOT_ID for prev or cur is a content:\u002Flive:\u002F+content_hash\n       fallback OR the diff command errors -> changed_files_status = UNKNOWN.\n       Treat EVERY file as CHANGED. NEVER treat as unchanged. NEVER drop. (Note:\n       `snapshot_pinned false` alone is NOT a trigger for UNKNOWN — in HALT\n       mode, `active_snapshot` is present and `snapshot_history` has a PREV\n       entry, so the diff can still run. In MODE-OFF — no `active_snapshot` —\n       there is no PREV entry, so PREV is missing and the diff degrades to\n       UNKNOWN, but this does NOT force a full Mode-A crawl; see the Mode-A\n       trigger below.) Else: git :\n       `git diff --name-status -M -C --diff-filter=RAMDCT PREV CUR` (the `-M`\n       flag detects renames; `-C` detects copies; `--name-status` outputs\n       `R\u003Cscore>\\told_path\\tnew_path` for renames so both old and new paths are\n       visible; `--diff-filter=RAMDCT` includes Renamed, Added, Modified,\n       Deleted, Copied, and Type-changed files) hg :\n       `hg status -C --rev PREV:CUR` (`-C`\u002F`--copies` shows the source path on a\n       following line for renames\u002Fcopies; hg codes: A=added, R=removed,\n       M=modified) multi-vcs :\n       `repo forall -c 'git diff --name-status -M -C --diff-filter=RAMDCT PREV CUR'`\n       (any error -> UNKNOWN) A finding's file is CHANGED if any of its\n       `code_paths` (path part) is in the set, OR if its path was renamed-to or\n       renamed-from (parse `R\u003Cscore>\\told\\tnew` lines: both old and new paths\n       are in the changed set). If a finding's primary file appears as a rename\n       source (old path), treat the NEW path as changed too — the bug likely\n       moved with the file.\n\n       Also apply this cache read rule wherever you inspect\n       `workspace\u002Farchive\u002F.repro_attempts.json`. FIRST pick the cache KEY\n       exactly the way `mantis-reproduce` writes it: if the finding has a\n       `signature` field, the key is that `signature`; otherwise the key is\n       `stable_key = normalized_title + \"@\" + primary_file_path` (title\n       lowercased with all non-alphanumerics removed; `primary_file_path` =\n       first `code_paths` entry with any trailing `:line` stripped). THEN read\n       the value V under that key: if V is an integer then count=V and\n       last_snapshot=UNKNOWN; if V is an object then count=V.count and\n       last_snapshot=V.last_snapshot (default UNKNOWN). If no entry is found\n       under the chosen key, also try the OTHER key form before concluding\n       count=0, so a signature-keyed writer and a stable_key reader never miss\n       each other and wrongly reset the attempt budget. (The cache mixes both\n       value forms AND both key styles during migration.)\n\n       1. **Schedule for Research:** For findings in the archive marked\n          `\"NEEDS_RESEARCH\"`, schedule a targeted investigation in\n          `workspace\u002Fplan.json` (to gather missing context and resolve them to\n          `\"VALID\"` or `\"FALSE_POSITIVE\"`).\n\n       2. **Copy for Retry (snapshot-gated) or Re-discover:** For each archived\n          finding that would otherwise be retry-eligible (repro not attempted,\n          or `failed_to_reproduce` with fewer than 2 attempts per the cache read\n          rule above, or `patch_status` in\n          {`VERIFICATION_FAILED`,`ERROR`,`VERIFICATION_INCOMPLETE`}), run:\n\n          ```\n          SNAPSHOT MATCH CHECK for finding F (decides MATCHED vs NOT_MATCHED):\n          1. If snapshot_pinned is false -> NOT_MATCHED. Stop.\n          2. Read F.discovery_commit:\n             - missing OR empty OR the literal \"MIXED\" -> NOT_MATCHED.\n             - not exactly equal to SNAPSHOT_ID          -> NOT_MATCHED.\n             - exactly equal to SNAPSHOT_ID              -> MATCHED.\n          There is no other route to MATCHED; never fuzzy-compare. The global \"default the\n          field and proceed\" backward-compat rule does NOT apply to discovery_commit:\n          absent = NOT_MATCHED. (There is NO separate \"dirty\" gate: a dirty tree's\n          SNAPSHOT_ID already embeds the working-tree content hash, so within-pass findings\n          MATCH and cross-pass bare-commit findings do not.)\n          ```\n\n          Then decide mechanically:\n\n          - **COPY VERBATIM** (fast retry) ONLY if ALL hold: Block B is MATCHED\n            for the finding, AND its primary file (first `code_paths`, line\n            stripped) is NOT in `changed_files`, AND that file EXISTS under\n            CODE_ROOT. Copy the archived `\u003Cuuid>.json` back to\n            `workspace\u002Ffindings\u002F\u003Cuuid>.json` preserving the UUID **and its\n            ORIGINAL `discovery_commit`** (do not re-stamp it — drift must stay\n            detectable).\n\n          - **MODE-OFF bypass (3-state rule):** if `active_snapshot` is ABSENT\n            in state (MODE-OFF — no `--sync` was requested), Block B always\n            returns NOT_MATCHED (`snapshot_pinned is false -> NOT_MATCHED`), so\n            the COPY-VERBATIM gate above never fires and every retry- eligible\n            finding is RE-DISCOVERed — a regression from today's behavior\n            (today, pass ≥2 carries forward unchanged findings when the file\n            still exists). In MODE-OFF, COPY-VERBATIM when the finding's primary\n            file (first `code_paths`, line stripped) EXISTS under CODE_ROOT\n            (drop the `Block B MATCHED` and `file NOT in changed_files`\n            conjuncts — there is no `changed_files` diff in MODE-OFF anyway).\n            This mirrors `mantis-patch`'s LEGACY-mode carve- out\n            (`patch:133-138`, `patch:172-174`). Do NOT gate the bypass on\n            `snapshot_pinned==false` — that would also catch HALT mode, where\n            the STALE banner legitimately marks the finding as needing\n            re-verification. Gate ONLY on `active_snapshot` absent. (Do NOT\n            change Block B itself — it is character-identical across skills per\n            `README_AGENTS.md:711-718` block-fidelity warning; the fix goes in\n            plan's CONSUMERS of Block B, not Block B.)\n\n          - **RE-DISCOVER** in every other case (Block B NOT_MATCHED, or file in\n            `changed_files`, or file missing, or\n            `changed_files_status`==UNKNOWN): do NOT copy back. Instead append a\n            fresh investigation to `workspace\u002Fplan.json` that embeds the\n            finding's `title`, `description`, and `repro_hints`, sets\n            `target_files` to the old code_paths' directory subtree(s) PLUS a\n            repository-wide symbol\u002Fkeyword search for the finding's\n            function\u002Fstruct\u002Ftitle terms (so a moved\u002Frenamed bug is re-found),\n            and asks the researcher to re-derive the exact lines on the CURRENT\n            snapshot. Additionally, record a history note\n            `unconfirmed-regression-pending` on the archived finding so it is\n            never silently dropped until a pass re-discovers it or a human\n            dismisses it.\n\n          - **Line\u002FAST Re-anchoring (Phase 2 incremental efficiency):** Before\n            falling back to full RE-DISCOVER, attempt to re-anchor the finding's\n            line numbers to the CURRENT snapshot using forward line-tracking\n            (reverse blame or diff-hunk offset). This is an optimization: if the\n            finding's primary function\u002Fsymbol still exists nearby, re-anchoring\n            produces a line-number HINT that focuses the RE-DISCOVER\n            investigation — it does NOT replace re-verification (the snapshot\n            changed, so the finding is still re-researched downstream).\n\n            - **How:** Translate the finding's old line FORWARD from PREV to CUR\n              (do NOT blame PREV in isolation — that returns the line as of PREV\n              and does not map it forward). Run in the LIVE repo root (Block A\n              step 5 carve-out): git :\n              `git blame --reverse \u003CPREV>..\u003CCUR> -L \u003Cold_line>,\u003Cold_line> -- \u003Cfile>`\n              (reverse blame follows the line forward to CUR), or add the hunk\n              offset from `git diff \u003CPREV> \u003CCUR> -- \u003Cfile>` to `\u003Cold_line>`.\n              Then read the mapped line in CODE_ROOT (the current pinned\n              snapshot) and confirm the finding's primary function\u002Fsymbol is\n              present within ±50 lines. This yields a CANDIDATE new line number\n              only — a search hint for RE-DISCOVER, never a trusted\n              re-validation.\n            - **When re-anchoring SUCCEEDS** (symbol found at the mapped line):\n              use the new line number to FOCUS this finding's RE-DISCOVER\n              investigation (point the researcher at the mapped `code_paths`\n              location first). Do NOT convert the finding to COPY-VERBATIM and\n              do NOT skip re-verification: Block B is NOT_MATCHED, so the\n              finding is still re-researched\u002Fre-reproduced downstream (a symbol\n              can exist at the mapped line yet already be FIXED). Keep\n              `discovery_commit`, `signature`, and `lineage_id` unchanged; add a\n              history note\n              `re-anchored: \u003Cold_line> -> \u003Cnew_line> (search hint)`.\n            - **When re-anchoring FAILS** (function deleted, symbol not found,\n              diff too large, blame errors, or the code at the old line is\n              completely different): fall back to full RE-DISCOVER as above.\n              This is the conservative guardrail: on ANY uncertainty,\n              re-discover.\n            - **Never use re-anchoring to suppress or drop a finding.** It is\n              purely a fast-path for line-number updates; if it fails, the\n              finding is still re-discovered via the normal path.\n            - **VCS-agnostic:** For hg, diff `PREV:CUR`\n              (`hg diff --rev PREV:CUR -- \u003Cfile>`) and apply the hunk offset to\n              `\u003Cold_line>` to get the forward-mapped line. For no-VCS\u002Fbinary\n              targets, re-anchoring is not applicable; always fall back to\n              RE-DISCOVER.\n\n          - **NEVER copy back** a finding whose `\"status\"` is\n            `\"FALSE_POSITIVE\"`, or `\"patch_status\"` is `\"VERIFIED_SECURE\"`, or\n            `\"repro_status\"` is `\"reproduced\"` (unless patch failed as above),\n            or that has reached the 2-attempt cap for the CURRENT snapshot. But\n            if such a finding's file IS in `changed_files` or Block B is\n            NOT_MATCHED, treat it as a possible regression: RE-DISCOVER it (do\n            not trust the old terminal verdict against changed code). **MODE-OFF\n            carve-out:** if `active_snapshot` is ABSENT (MODE-OFF), drop the\n            `or Block B is NOT_MATCHED` disjunct above — in MODE-OFF, Block B is\n            NOT_MATCHED for every finding (artifact of no snapshot, not a signal\n            of drift), so leaving the disjunct in would re-open every terminal\n            verdict (FALSE_POSITIVE\u002FVERIFIED_SECURE\u002Freproduced) every pass. In\n            MODE-OFF, rely ONLY on `file IS in changed_files` (which is\n            vacuously false in MODE-OFF — there is no `changed_files` diff), so\n            terminal findings are carried forward unchanged. This is today's\n            behavior.\n\n     - **Changed \u002F new attack-surface coverage (MANDATORY):** Add an\n       investigation titled `Exhaustive Review: \u003Cpath>` for EVERY path in\n       `changed_files` (whether or not it maps to an archived finding). If\n       `changed_files_status`==UNKNOWN AND `active_snapshot` is present (HALT or\n       PINNED mode — a sync was requested this pass), OR a sync occurred this\n       pass (`snapshot_id` != the previous `snapshot_history` entry's id), you\n       CANNOT trust a narrow set: fall back to a full **Mode A** exhaustive\n       crawl for this pass EVEN IF `kb\u002Findex.md` exists (this is the only way to\n       catch newly added files). However, in MODE-OFF (no `active_snapshot` — no\n       `--sync`), do NOT force a full Mode-A crawl in pass ≥2 even if\n       `changed_files_status`==UNKNOWN: this is today's default behavior, and\n       forcing Mode-A on every MODE-OFF pass ≥2 would be a regression. In\n       MODE-OFF, rely on the existing `kb\u002Findex.md` (Mode B) for narrowing, as\n       today.\n\n     - **Dependency-aware fan-out (Phase 2 incremental efficiency):** When\n       `changed_files_status` is known (not UNKNOWN) and a dependency graph is\n       available, EXPAND the investigation scope beyond just the changed files\n       themselves. The goal: identify files that IMPORT or DEPEND ON the changed\n       files, so the planner can schedule targeted investigations for consumers\n       of the changed code (not just the changed code itself).\n\n       - **How:** Start with the file-level dependency graph\n         (`workspace\u002Fkb\u002Fdependencies.json` or entity-relationship markdown) as\n         the mandatory floor: for each changed file F, find all files that\n         import F (directly or transitively up to 2 hops). Add these dependent\n         files to the investigation scope as\n         `Exhaustive Review: \u003Cdependent_file>` entries. Then ADD structural\n         index callers on top: use the query helper\n         (`workspace\u002Fhelpers\u002Fquery_structural_index.py`) for function-level\n         precision when available — call `resolve_symbol()` for a changed file's\n         exported functions, then `find_callers()` to enumerate dependents at\n         the symbol level. Schedule investigations for the UNION of\n         dependency-graph-found dependents and structural-index-found callers —\n         they are complementary, not alternatives. If the structural index is\n         absent (no `manifest.json`), empty, or the query helper is missing, the\n         dependency graph alone remains the floor.\n       - **When to use:** ONLY when `changed_files_status` is known AND the KB\n         contains dependency information. If the KB lacks an import\u002Fbuild graph,\n         or the KB is stale (check `kb_snapshot_id` in\n         `workspace\u002F.mantis_state.json` against `SNAPSHOT_ID` — if they differ,\n         the KB was built against a different snapshot and may be stale), fall\n         back to the Phase-1 behavior (full Mode-A crawl or Mode-B narrowing).\n       - **Guardrail:** If the dependency graph is incomplete, stale, or any\n         uncertainty arises, fall back to Phase-1 re-discovery (treat ALL files\n         as potentially affected). Never use dependency narrowing to DROP an\n         investigation — it can only ADD targeted investigations for dependent\n         files. The changed files themselves are ALWAYS investigated regardless.\n       - **VCS-agnostic:** The dependency graph is derived from the KB's\n         architecture analysis, not from VCS metadata. It works for any language\n         with import\u002Finclude\u002Fuse statements that the KB has indexed.\n\n     - **Structural Index Queries (HINT-only enhancement):** When a structural\n       index is available (`workspace\u002Fkb\u002Fstructural_index\u002Fmanifest.json`\n       exists), use it to SUPPLEMENT the dependency-aware fan-out above with\n       precise, symbol-level caller discovery. The structural index decides\n       ORDER of investigation priority, NEVER MEMBERSHIP of the audit set.\n\n       - **Resolution-first protocol (MANDATORY):** Before querying callers,\n         resolve the symbol:\n\n         `python3 workspace\u002Fhelpers\u002Fquery_structural_index.py resolve_symbol --name \"\u003Cfunction_name>\" [--language \"\u003Clang>\"] [--file \"\u003Cpath>\"] --state_root \u003Cstate_root>`\n\n         If the response has `ambiguous: true`, do NOT silently pick one match.\n         Narrow with `--file`\u002F`--language`, or schedule investigations for ALL\n         matched symbols.\n\n       - **Bounded caller queries:** Once resolved, query callers with explicit\n         bounds:\n\n         `python3 workspace\u002Fhelpers\u002Fquery_structural_index.py find_callers --symbol_id \"\u003Cresolved_id>\" --limit 100 --offset 0 --state_root \u003Cstate_root>`\n\n         Paginate with `--offset` if `has_more` is true.\n\n       - **Coverage-aware interpretation:** Check `coverage.partition_status` in\n         every structural index response:\n\n         - `complete` + `precision == semantic` + no callers = \"no indexed\n           callers\" — the partition is fully indexed with a semantic backend, so\n           the empty result is authoritative for indexed code. Still run grep\n           per the HINT-only rule (grep catches macro-based calls, function\n           pointers, and dynamic dispatch).\n         - `complete` + `precision != semantic` + no callers = \"no indexed\n           callers\" — the partition is complete but precision is below semantic,\n           so the empty result is NOT authoritative. MUST run exhaustive grep\n           fallback.\n         - `partial` \u002F `empty` \u002F `failed` + no callers = \"not fully indexed\" —\n           the partition is not complete, so expand the investigation scope and\n           MUST run exhaustive grep fallback.\n\n       - **Guardrails:**\n\n         - HINT-only: structural index results decide ORDER, never MEMBERSHIP.\n           They prioritize which dependent files to investigate first; they MUST\n           NEVER cause a file to be dropped from the audit scope.\n         - Every result carries `precision` and `backend` fields — use\n           `precision` (`semantic` > `typecheck` > `ast` > `symbol-only` >\n           `heuristic` > `deferred` > `coverage-only`) to weight trust in the\n           result.\n         - If the structural index is absent (no `manifest.json`), empty, or the\n           query helper is missing: fall back to grep-based discovery (today's\n           behavior). The structural index is a coverage HINT only.\n\n     - **Context Injection (`kb_references`):** For each investigation you plan,\n       you must determine which files in the `workspace\u002Fkb\u002F` directory (e.g.,\n       `workspace\u002Fkb\u002Fentities\u002Fauth_module.md` or\n       `workspace\u002Fkb\u002Fvulnerabilities\u002FCWE-79.md`) provide necessary context for\n       the researcher. Include the exact file paths to these markdown files in\n       the `\"kb_references\"` array for that investigation. This shifts the\n       burden of context-gathering off the researcher.\n\n     - **Exploratory\u002FUnconstrained Investigations (Moderate Probability):** With\n       a moderate probability (e.g., a 25-50% chance per planning pass), include\n       either an unconstrained adversarial sweep or a random exploration in the\n       plan:\n\n       1. **Adversarial Sweep:** Select a component or directory that the threat\n          model currently marks as safe, low-risk, or out of scope. Instruct the\n          researcher to perform an unconstrained sweep, ignoring safety\n          assumptions in `workspace\u002Fkb\u002FTHREAT_MODEL.md`.\n\n       2. **Random Digging:** Select a random starting position (file or\n          directory) in the codebase. The question for this investigation should\n          be minimal and open-ended, simply instructing the researcher to \"dig\n          into\" or \"explore\" the selected area without specific threat-model\n          context or pre-defined vulnerability classes. Set `kb_references` to\n          an empty list for this investigation to ensure a fresh look.\n\n       **Token Optimization:** Whether using a script (Mode A) or your\n       file-writing tools (Mode B), write the plan directly to disk and do not\n       print the JSON contents in your chat response.\n\n3. **Schema Enforcement:** Regardless of the mode, the final\n   `workspace\u002Fplan.json` file written to disk should match the following schema\n   to ensure downstream auditing agents can parse it correctly:\n\n### Plan Schema Format\n\n```json\n{\n  \"investigations\": [\n    {\n      \"title\": \"Exhaustive Review: [relative_file_path]\",\n      \"target_files\": [\"[relative_file_path_1]\", \"[relative_file_path_2]\"],\n      \"kb_references\": [\"workspace\u002Fkb\u002Fentities\u002Fauth_module.md\", \"workspace\u002Fkb\u002Fvulnerabilities\u002FCWE-79.md\"],\n      \"question\": \"Detailed reviewing prompt instructions asking the researcher to trace specific input pathways, variables, memory allocations, or function constraints.\"\n    }\n  ]\n}\n```\n\nEnsure `workspace\u002Fplan.json` is successfully written. When you have finished,\nnotify the user.\n","# Strategist (\u002Fmantis-plan)\n\n## System Goal\n\nSecurity Architect. Analyzes code structure, directory metadata, and historical\nrecords to map the external boundary and formulate an adaptive review roadmap.\n\n## Command Definition\n\n- **Command:** `\u002Fmantis-plan`\n- **Description:** Formulates a targeted defensive security reviewing plan based\n  on the active threat model and historical learnings.\n- **Arguments (optional; supplied by the orchestrator, consumed by Block A):**\n  - `--snapshot_root` \u002F `SNAPSHOT_ROOT`: absolute path to the pinned read-only\n    code snapshot (CODE_ROOT for all snapshot-relative paths).\n  - `--snapshot_id` \u002F `SNAPSHOT_ID`: the pass snapshot identifier (sentinel +\n    Block B comparisons).\n  - `--state_root`: absolute path to the `workspace\u002F` state dir (plan.json,\n    .mantis_state.json, findings\u002F, kb\u002F, archive\u002F). STATE-RELATIVE — never\n    prefixed with CODE_ROOT.\n  - All flags absent -> MODE-OFF\u002Flegacy mode (Block A step 1d): behaves exactly\n    as today.\n\n## Input\u002FOutput Contract\n\n- **Reads**:\n  - `workspace\u002F.mantis_state.json` (to track current loop pass).\n  - `workspace\u002Fkb\u002FTHREAT_MODEL.md` (if exists).\n  - `workspace\u002Fkb\u002Findex.md` (checks existence to determine Mode A vs B).\n  - Mode A: traverses production directories and source files, reads\n    `mantis-summary.md` (if available).\n  - Mode B: reads `workspace\u002Fkb\u002Findex.md`, `workspace\u002Fkb\u002FTHREAT_MODEL.md`,\n    `workspace\u002Farchive\u002F.repro_attempts.json` (if exists), VCS diffs or file\n    timestamps\u002Fhashes.\n  - `workspace\u002Fkb\u002Fstructural_index\u002Fmanifest.json` (to check structural index\n    availability\u002Fstatus).\n  - `workspace\u002Fhelpers\u002Fquery_structural_index.py` (to invoke bounded\n    structural-index queries).\n  - `workspace\u002F.mantis_state.json` NEW fields:\n    `active_snapshot.{snapshot_id, snapshot_pinned, vcs_type}`,\n    `snapshot_history` (read, written by the meta-agent). `vcs_type` is read\n    because Block E branches on it. Plan runs Block E in the LIVE repo root to\n    compute `changed_files` \u002F `changed_files_status` (COMPUTED or UNKNOWN) and\n    writes them back to state.\n- **Writes**:\n  - `workspace\u002Fplan.json`.\n  - Copies retry-eligible finding JSON files from\n    `workspace\u002Farchive\u002Ffindings_pass_K\u002F` or `workspace\u002Farchive\u002FloopK_findings\u002F`\n    (where K is the pass it was archived in) to `workspace\u002Ffindings\u002F`\n    (preserving their original UUID filenames).\n- **Preconditions**:\n  - Codebase must be accessible.\n- **Idempotency Guarantee**:\n  - Overwrites `workspace\u002Fplan.json` directly. In Mode B, copies a finding back\n    verbatim only when Block B is MATCHED and its file is unchanged and present;\n    otherwise it schedules a fresh re-discovery investigation. Consults\n    `.repro_attempts.json` under the cache read rule.\n\n## Instructions\n\n### Step 0: Locator Resolution (run before everything else)\n\n```\nLOCATOR RESOLUTION (before reading ANY target code or artifact):\n0. ROLE: If this skill NEVER reads target source (report, calibrate, reflect),\n   you are a FINDINGS-ONLY stage: skip steps 2-6; still read active_snapshot from\n   state for provenance\u002Fannotation; NEVER stop merely because a code root is unset.\n1. Determine CODE_ROOT, in this priority order:\n   a. If --target_root is passed on THIS invocation, CODE_ROOT = --target_root.\n      It is AUTHORITATIVE and OVERRIDES SNAPSHOT_ROOT and the state fallback\n      (used when a caller hands you a prepared tree, e.g. a patched shadow).\n   b. Else if --snapshot_root (or SNAPSHOT_ROOT) is passed, use it.\n   c. Else read state_root\u002Fworkspace\u002F.mantis_state.json (state_root from\n      --state_root if passed, else .\u002Fworkspace\u002F... relative to the current dir)\n      -> active_snapshot.root \u002F .snapshot_id \u002F .snapshot_pinned.\n   d. Else (no arg AND no readable active_snapshot): CODE_ROOT = current directory,\n      treat snapshot_pinned = false (MODE-OFF). Do NOT stop.\n2. SENTINEL CHECK (only if snapshot_pinned is true AND you did NOT take path 1a):\n   verify CODE_ROOT\u002F.mantis_snapshot_id exists and equals SNAPSHOT_ID. If missing\n   or different -> STOP \"snapshot sentinel mismatch\". (A --target_root tree (1a) is\n   deliberately mutated and is sentinel-EXEMPT.)\n3. PATH FIELDS:\n   - SNAPSHOT-RELATIVE (read under CODE_ROOT): code_paths entries; plan target_files\n     that are file paths. Strip ONLY a trailing \":\u003Cdigits>\". A code_paths entry\n     containing \":\u002F\u002F\" is a URL\u002Fendpoint, NOT a file read. A code_paths entry that is\n     NOT of the form \u003Cexisting-path>:\u003Cinteger> is a non-source LOCATOR\n     (symbol\u002Foffset\u002Fendpoint): only check that the artifact\u002Fsymbol exists; skip ALL\n     line-range and line-existence logic.\n   - STATE-RELATIVE (read\u002Fwrite under state_root\u002Fworkspace, NEVER prefix CODE_ROOT):\n     kb_references, repro_file_path, reattack_file_path, helper scripts, report\n     files, and all state\u002Ffindings JSON.\n4. Never WRITE under CODE_ROOT when snapshot_pinned is true. Any command that\n   compiles, generates, or writes artifacts MUST run in a PRIVATE SHADOW copy\n   (mktemp -d from CODE_ROOT), never with cwd=CODE_ROOT. Read-only inspection may\n   cd into CODE_ROOT.\n5. VCS-METADATA CARVE-OUT: history-log extraction and any VCS diff\u002Fblame command\n   run in the LIVE repository root (which still has .git\u002F.hg\u002F.repo), NOT CODE_ROOT\n   (the snapshot copy strips VCS metadata). Do NOT stop merely because CODE_ROOT\n   lacks .git\u002F.hg\u002F.repo.\n6. Every shell command uses ABSOLUTE paths and sets its own working directory on\n   that call. Do NOT assume the working directory persists between calls.\n```\n\n> [!NOTE] **CURRENT-PASS CHECK (defensive; the binding guarantee is on the\n> harness per `mantis-pipeline-adapter` Scenario 2):** if `active_snapshot` is\n> present AND `active_snapshot.pass != state.pass_number`, treat the snapshot as\n> STALE for this pass — STOP \"stale active_snapshot: pass mismatch\" or degrade\n> as HALT (`snapshot_pinned` effectively false: no authoritative verdicts, Block\n> B NOT_MATCHED, reproduce `not_attempted`). This catches a custom harness that\n> preserved `active_snapshot` across the Stage 15 pass increment without\n> re-pinning. The reference meta-agent re-pins every pass, so this check never\n> fires there. Block B itself cannot detect this (it is `snapshot_id`-only, not\n> `pass`-aware).\n\nSkill-specific notes for the strategist:\n\n- Plan is a CODE-READING stage in Mode A (it crawls production directories); the\n  findings-only skip does NOT apply.\n- Mode A crawling and every `target_files` path are SNAPSHOT-RELATIVE: crawl and\n  resolve them under CODE_ROOT.\n- `workspace\u002Fkb\u002F`, `workspace\u002Fplan.json`, `workspace\u002F.mantis_state.json`,\n  `workspace\u002Farchive\u002F`, and `workspace\u002Ffindings\u002F` are STATE-RELATIVE: read\u002Fwrite\n  them under --state_root, NEVER under CODE_ROOT.\n- Never write, compile, or generate under CODE_ROOT (Block A step 4). The plan\n  script writes ONLY workspace\u002Fplan.json (state-relative). The VCS diff in Block\n  E runs in the LIVE repo root per Block A step 5, NOT CODE_ROOT.\n\nAnalyze the repository structure and create a detailed defensive security review\nplan that avoids duplication of prior efforts while digging deep into complex\ninter-procedural paths and un-scanned code boundaries.\n\n> **Target Agnosticism Directive:** The target you are evaluating may be raw\n> source code, a compiled binary, a firmware blob, or a live staging\u002Fdev\n> endpoint. Ground your planning in whatever format the target is currently in.\n> You are authorized and encouraged to use whatever suitable tools are at your\n> disposal (e.g., standard Unix tools, `unblob`, `radare2`, `angr`, `objdump`,\n> `Ghidra`, `qemu`, `unicorn`) to explore the artifact structure. If source code\n> is not available, do not attempt to force a source-code workflow (e.g.\n> searching for `.c` or `.py` files); adapt and 'do what works' for the artifact\n> at hand.\n\nExecute the planning stage as follows:\n\n1. **Check for Threat Model Context:** Check the knowledge base directory for a\n   `workspace\u002Fkb\u002FTHREAT_MODEL.md` file. If it exists, read the file it\n   completely to understand the program's official security boundaries, threat\n   actors, assets, high-risk interfaces, and trusted inputs.\n\n2. **Determine Mode & Retrieve Learnings:** Check if the knowledge base index\n   `workspace\u002Fkb\u002Findex.md` exists.\n\n   - **MODE A: First-Pass Exhaustive Mode (No `workspace\u002Fkb\u002Findex.md` found):**\n     If this is the first run, guarantee complete coverage of the codebase. To\n     avoid hitting output token limits on large repositories, do not generate\n     the `workspace\u002Fplan.json` manually in your text response. Instead, execute\n     a shell command to run a short script in your preferred language that:\n\n     1. Uses `find` or `os.walk` to crawl all production directories. If a\n        `mantis-summary.md` file exists in a directory, use its contents to\n        understand the directory structure instead of reading every individual\n        source file. Otherwise, crawl all production source code files (e.g.,\n        `.c`, `.cpp`, `.py`, `.js`, `.go`, `.rs`, `.java`).\n     2. Ignores test folders, build artifacts, and vendor dependencies (e.g.,\n        `node_modules`, `.git`, `tests\u002F`).\n     3. Programmatically formats the list into the `workspace\u002Fplan.json` schema\n        and writes it directly to disk. Because this is an automated script,\n        instruct it to use a generic, overarching baseline question for the\n        `\"question\"` field (e.g., \"Conduct a baseline audit for memory safety\n        and logic flaws\"), reserving highly contextual custom questions for Mode\n        B.\n\n   - **MODE B: Strategic Learning Mode (`workspace\u002Fkb\u002Findex.md` exists):** Read\n     `workspace\u002Fkb\u002Findex.md` and `workspace\u002Fkb\u002FTHREAT_MODEL.md` to review the\n     compounded historical knowledge of the codebase, including trust\n     boundaries, vulnerability classes, and architectural components. Adapt your\n     focus to design new, targeted deep dives and regression reviews for\n     components and files that have histories of vulnerabilities. You may\n     generate the `workspace\u002Fplan.json` manually using your file-writing tools\n     for this mode, as the scope will be much narrower.\n\n     - **Targeted Re-Evaluation & Retries**: Review the KB index, entity files,\n       and the reproduction attempt cache file\n       (`workspace\u002Farchive\u002F.repro_attempts.json` if it exists). You must\n       identify findings that need re-evaluation or retries:\n\n       Also read the snapshot context from `workspace\u002F.mantis_state.json`:\n       `active_snapshot.{snapshot_id, snapshot_pinned}` and `snapshot_history`\n       (both written by the meta-agent). Then COMPUTE `changed_files` \u002F\n       `changed_files_status` for THIS pass by running Block E below in the LIVE\n       repository root (per Block A step 5 — VCS-metadata carve-out; the pinned\n       --snapshot_root strips .git\u002F.hg\u002F.repo, so the diff MUST run against the\n       live tree). Write the computed `changed_files` (array of repo-relative\n       paths) and `changed_files_status` (`COMPUTED` or `UNKNOWN`) back to\n       `workspace\u002F.mantis_state.json`, then use them for the rest of the stage.\n       Also write `changed_files_pass` = the current `pass_number` from state,\n       so consumers can detect a stale (prior-pass) diff. Use the following to\n       know which files changed since the previous pass:\n\n       CHANGED-SINCE-PREVIOUS: run in the LIVE repository root (NOT\n       SNAPSHOT_ROOT). CUR = current commit\u002Frevision; PREV = snapshot_history\n       entry BEFORE this pass. If PREV missing OR vcs_type in {none,unknown} OR\n       the SNAPSHOT_ID for prev or cur is a content:\u002Flive:\u002F+content_hash\n       fallback OR the diff command errors -> changed_files_status = UNKNOWN.\n       Treat EVERY file as CHANGED. NEVER treat as unchanged. NEVER drop. (Note:\n       `snapshot_pinned false` alone is NOT a trigger for UNKNOWN — in HALT\n       mode, `active_snapshot` is present and `snapshot_history` has a PREV\n       entry, so the diff can still run. In MODE-OFF — no `active_snapshot` —\n       there is no PREV entry, so PREV is missing and the diff degrades to\n       UNKNOWN, but this does NOT force a full Mode-A crawl; see the Mode-A\n       trigger below.) Else: git :\n       `git diff --name-status -M -C --diff-filter=RAMDCT PREV CUR` (the `-M`\n       flag detects renames; `-C` detects copies; `--name-status` outputs\n       `R\u003Cscore>\\told_path\\tnew_path` for renames so both old and new paths are\n       visible; `--diff-filter=RAMDCT` includes Renamed, Added, Modified,\n       Deleted, Copied, and Type-changed files) hg :\n       `hg status -C --rev PREV:CUR` (`-C`\u002F`--copies` shows the source path on a\n       following line for renames\u002Fcopies; hg codes: A=added, R=removed,\n       M=modified) multi-vcs :\n       `repo forall -c 'git diff --name-status -M -C --diff-filter=RAMDCT PREV CUR'`\n       (any error -> UNKNOWN) A finding's file is CHANGED if any of its\n       `code_paths` (path part) is in the set, OR if its path was renamed-to or\n       renamed-from (parse `R\u003Cscore>\\told\\tnew` lines: both old and new paths\n       are in the changed set). If a finding's primary file appears as a rename\n       source (old path), treat the NEW path as changed too — the bug likely\n       moved with the file.\n\n       Also apply this cache read rule wherever you inspect\n       `workspace\u002Farchive\u002F.repro_attempts.json`. FIRST pick the cache KEY\n       exactly the way `mantis-reproduce` writes it: if the finding has a\n       `signature` field, the key is that `signature`; otherwise the key is\n       `stable_key = normalized_title + \"@\" + primary_file_path` (title\n       lowercased with all non-alphanumerics removed; `primary_file_path` =\n       first `code_paths` entry with any trailing `:line` stripped). THEN read\n       the value V under that key: if V is an integer then count=V and\n       last_snapshot=UNKNOWN; if V is an object then count=V.count and\n       last_snapshot=V.last_snapshot (default UNKNOWN). If no entry is found\n       under the chosen key, also try the OTHER key form before concluding\n       count=0, so a signature-keyed writer and a stable_key reader never miss\n       each other and wrongly reset the attempt budget. (The cache mixes both\n       value forms AND both key styles during migration.)\n\n       1. **Schedule for Research:** For findings in the archive marked\n          `\"NEEDS_RESEARCH\"`, schedule a targeted investigation in\n          `workspace\u002Fplan.json` (to gather missing context and resolve them to\n          `\"VALID\"` or `\"FALSE_POSITIVE\"`).\n\n       2. **Copy for Retry (snapshot-gated) or Re-discover:** For each archived\n          finding that would otherwise be retry-eligible (repro not attempted,\n          or `failed_to_reproduce` with fewer than 2 attempts per the cache read\n          rule above, or `patch_status` in\n          {`VERIFICATION_FAILED`,`ERROR`,`VERIFICATION_INCOMPLETE`}), run:\n\n          ```\n          SNAPSHOT MATCH CHECK for finding F (decides MATCHED vs NOT_MATCHED):\n          1. If snapshot_pinned is false -> NOT_MATCHED. Stop.\n          2. Read F.discovery_commit:\n             - missing OR empty OR the literal \"MIXED\" -> NOT_MATCHED.\n             - not exactly equal to SNAPSHOT_ID          -> NOT_MATCHED.\n             - exactly equal to SNAPSHOT_ID              -> MATCHED.\n          There is no other route to MATCHED; never fuzzy-compare. The global \"default the\n          field and proceed\" backward-compat rule does NOT apply to discovery_commit:\n          absent = NOT_MATCHED. (There is NO separate \"dirty\" gate: a dirty tree's\n          SNAPSHOT_ID already embeds the working-tree content hash, so within-pass findings\n          MATCH and cross-pass bare-commit findings do not.)\n          ```\n\n          Then decide mechanically:\n\n          - **COPY VERBATIM** (fast retry) ONLY if ALL hold: Block B is MATCHED\n            for the finding, AND its primary file (first `code_paths`, line\n            stripped) is NOT in `changed_files`, AND that file EXISTS under\n            CODE_ROOT. Copy the archived `\u003Cuuid>.json` back to\n            `workspace\u002Ffindings\u002F\u003Cuuid>.json` preserving the UUID **and its\n            ORIGINAL `discovery_commit`** (do not re-stamp it — drift must stay\n            detectable).\n\n          - **MODE-OFF bypass (3-state rule):** if `active_snapshot` is ABSENT\n            in state (MODE-OFF — no `--sync` was requested), Block B always\n            returns NOT_MATCHED (`snapshot_pinned is false -> NOT_MATCHED`), so\n            the COPY-VERBATIM gate above never fires and every retry- eligible\n            finding is RE-DISCOVERed — a regression from today's behavior\n            (today, pass ≥2 carries forward unchanged findings when the file\n            still exists). In MODE-OFF, COPY-VERBATIM when the finding's primary\n            file (first `code_paths`, line stripped) EXISTS under CODE_ROOT\n            (drop the `Block B MATCHED` and `file NOT in changed_files`\n            conjuncts — there is no `changed_files` diff in MODE-OFF anyway).\n            This mirrors `mantis-patch`'s LEGACY-mode carve- out\n            (`patch:133-138`, `patch:172-174`). Do NOT gate the bypass on\n            `snapshot_pinned==false` — that would also catch HALT mode, where\n            the STALE banner legitimately marks the finding as needing\n            re-verification. Gate ONLY on `active_snapshot` absent. (Do NOT\n            change Block B itself — it is character-identical across skills per\n            `README_AGENTS.md:711-718` block-fidelity warning; the fix goes in\n            plan's CONSUMERS of Block B, not Block B.)\n\n          - **RE-DISCOVER** in every other case (Block B NOT_MATCHED, or file in\n            `changed_files`, or file missing, or\n            `changed_files_status`==UNKNOWN): do NOT copy back. Instead append a\n            fresh investigation to `workspace\u002Fplan.json` that embeds the\n            finding's `title`, `description`, and `repro_hints`, sets\n            `target_files` to the old code_paths' directory subtree(s) PLUS a\n            repository-wide symbol\u002Fkeyword search for the finding's\n            function\u002Fstruct\u002Ftitle terms (so a moved\u002Frenamed bug is re-found),\n            and asks the researcher to re-derive the exact lines on the CURRENT\n            snapshot. Additionally, record a history note\n            `unconfirmed-regression-pending` on the archived finding so it is\n            never silently dropped until a pass re-discovers it or a human\n            dismisses it.\n\n          - **Line\u002FAST Re-anchoring (Phase 2 incremental efficiency):** Before\n            falling back to full RE-DISCOVER, attempt to re-anchor the finding's\n            line numbers to the CURRENT snapshot using forward line-tracking\n            (reverse blame or diff-hunk offset). This is an optimization: if the\n            finding's primary function\u002Fsymbol still exists nearby, re-anchoring\n            produces a line-number HINT that focuses the RE-DISCOVER\n            investigation — it does NOT replace re-verification (the snapshot\n            changed, so the finding is still re-researched downstream).\n\n            - **How:** Translate the finding's old line FORWARD from PREV to CUR\n              (do NOT blame PREV in isolation — that returns the line as of PREV\n              and does not map it forward). Run in the LIVE repo root (Block A\n              step 5 carve-out): git :\n              `git blame --reverse \u003CPREV>..\u003CCUR> -L \u003Cold_line>,\u003Cold_line> -- \u003Cfile>`\n              (reverse blame follows the line forward to CUR), or add the hunk\n              offset from `git diff \u003CPREV> \u003CCUR> -- \u003Cfile>` to `\u003Cold_line>`.\n              Then read the mapped line in CODE_ROOT (the current pinned\n              snapshot) and confirm the finding's primary function\u002Fsymbol is\n              present within ±50 lines. This yields a CANDIDATE new line number\n              only — a search hint for RE-DISCOVER, never a trusted\n              re-validation.\n            - **When re-anchoring SUCCEEDS** (symbol found at the mapped line):\n              use the new line number to FOCUS this finding's RE-DISCOVER\n              investigation (point the researcher at the mapped `code_paths`\n              location first). Do NOT convert the finding to COPY-VERBATIM and\n              do NOT skip re-verification: Block B is NOT_MATCHED, so the\n              finding is still re-researched\u002Fre-reproduced downstream (a symbol\n              can exist at the mapped line yet already be FIXED). Keep\n              `discovery_commit`, `signature`, and `lineage_id` unchanged; add a\n              history note\n              `re-anchored: \u003Cold_line> -> \u003Cnew_line> (search hint)`.\n            - **When re-anchoring FAILS** (function deleted, symbol not found,\n              diff too large, blame errors, or the code at the old line is\n              completely different): fall back to full RE-DISCOVER as above.\n              This is the conservative guardrail: on ANY uncertainty,\n              re-discover.\n            - **Never use re-anchoring to suppress or drop a finding.** It is\n              purely a fast-path for line-number updates; if it fails, the\n              finding is still re-discovered via the normal path.\n            - **VCS-agnostic:** For hg, diff `PREV:CUR`\n              (`hg diff --rev PREV:CUR -- \u003Cfile>`) and apply the hunk offset to\n              `\u003Cold_line>` to get the forward-mapped line. For no-VCS\u002Fbinary\n              targets, re-anchoring is not applicable; always fall back to\n              RE-DISCOVER.\n\n          - **NEVER copy back** a finding whose `\"status\"` is\n            `\"FALSE_POSITIVE\"`, or `\"patch_status\"` is `\"VERIFIED_SECURE\"`, or\n            `\"repro_status\"` is `\"reproduced\"` (unless patch failed as above),\n            or that has reached the 2-attempt cap for the CURRENT snapshot. But\n            if such a finding's file IS in `changed_files` or Block B is\n            NOT_MATCHED, treat it as a possible regression: RE-DISCOVER it (do\n            not trust the old terminal verdict against changed code). **MODE-OFF\n            carve-out:** if `active_snapshot` is ABSENT (MODE-OFF), drop the\n            `or Block B is NOT_MATCHED` disjunct above — in MODE-OFF, Block B is\n            NOT_MATCHED for every finding (artifact of no snapshot, not a signal\n            of drift), so leaving the disjunct in would re-open every terminal\n            verdict (FALSE_POSITIVE\u002FVERIFIED_SECURE\u002Freproduced) every pass. In\n            MODE-OFF, rely ONLY on `file IS in changed_files` (which is\n            vacuously false in MODE-OFF — there is no `changed_files` diff), so\n            terminal findings are carried forward unchanged. This is today's\n            behavior.\n\n     - **Changed \u002F new attack-surface coverage (MANDATORY):** Add an\n       investigation titled `Exhaustive Review: \u003Cpath>` for EVERY path in\n       `changed_files` (whether or not it maps to an archived finding). If\n       `changed_files_status`==UNKNOWN AND `active_snapshot` is present (HALT or\n       PINNED mode — a sync was requested this pass), OR a sync occurred this\n       pass (`snapshot_id` != the previous `snapshot_history` entry's id), you\n       CANNOT trust a narrow set: fall back to a full **Mode A** exhaustive\n       crawl for this pass EVEN IF `kb\u002Findex.md` exists (this is the only way to\n       catch newly added files). However, in MODE-OFF (no `active_snapshot` — no\n       `--sync`), do NOT force a full Mode-A crawl in pass ≥2 even if\n       `changed_files_status`==UNKNOWN: this is today's default behavior, and\n       forcing Mode-A on every MODE-OFF pass ≥2 would be a regression. In\n       MODE-OFF, rely on the existing `kb\u002Findex.md` (Mode B) for narrowing, as\n       today.\n\n     - **Dependency-aware fan-out (Phase 2 incremental efficiency):** When\n       `changed_files_status` is known (not UNKNOWN) and a dependency graph is\n       available, EXPAND the investigation scope beyond just the changed files\n       themselves. The goal: identify files that IMPORT or DEPEND ON the changed\n       files, so the planner can schedule targeted investigations for consumers\n       of the changed code (not just the changed code itself).\n\n       - **How:** Start with the file-level dependency graph\n         (`workspace\u002Fkb\u002Fdependencies.json` or entity-relationship markdown) as\n         the mandatory floor: for each changed file F, find all files that\n         import F (directly or transitively up to 2 hops). Add these dependent\n         files to the investigation scope as\n         `Exhaustive Review: \u003Cdependent_file>` entries. Then ADD structural\n         index callers on top: use the query helper\n         (`workspace\u002Fhelpers\u002Fquery_structural_index.py`) for function-level\n         precision when available — call `resolve_symbol()` for a changed file's\n         exported functions, then `find_callers()` to enumerate dependents at\n         the symbol level. Schedule investigations for the UNION of\n         dependency-graph-found dependents and structural-index-found callers —\n         they are complementary, not alternatives. If the structural index is\n         absent (no `manifest.json`), empty, or the query helper is missing, the\n         dependency graph alone remains the floor.\n       - **When to use:** ONLY when `changed_files_status` is known AND the KB\n         contains dependency information. If the KB lacks an import\u002Fbuild graph,\n         or the KB is stale (check `kb_snapshot_id` in\n         `workspace\u002F.mantis_state.json` against `SNAPSHOT_ID` — if they differ,\n         the KB was built against a different snapshot and may be stale), fall\n         back to the Phase-1 behavior (full Mode-A crawl or Mode-B narrowing).\n       - **Guardrail:** If the dependency graph is incomplete, stale, or any\n         uncertainty arises, fall back to Phase-1 re-discovery (treat ALL files\n         as potentially affected). Never use dependency narrowing to DROP an\n         investigation — it can only ADD targeted investigations for dependent\n         files. The changed files themselves are ALWAYS investigated regardless.\n       - **VCS-agnostic:** The dependency graph is derived from the KB's\n         architecture analysis, not from VCS metadata. It works for any language\n         with import\u002Finclude\u002Fuse statements that the KB has indexed.\n\n     - **Structural Index Queries (HINT-only enhancement):** When a structural\n       index is available (`workspace\u002Fkb\u002Fstructural_index\u002Fmanifest.json`\n       exists), use it to SUPPLEMENT the dependency-aware fan-out above with\n       precise, symbol-level caller discovery. The structural index decides\n       ORDER of investigation priority, NEVER MEMBERSHIP of the audit set.\n\n       - **Resolution-first protocol (MANDATORY):** Before querying callers,\n         resolve the symbol:\n\n         `python3 workspace\u002Fhelpers\u002Fquery_structural_index.py resolve_symbol --name \"\u003Cfunction_name>\" [--language \"\u003Clang>\"] [--file \"\u003Cpath>\"] --state_root \u003Cstate_root>`\n\n         If the response has `ambiguous: true`, do NOT silently pick one match.\n         Narrow with `--file`\u002F`--language`, or schedule investigations for ALL\n         matched symbols.\n\n       - **Bounded caller queries:** Once resolved, query callers with explicit\n         bounds:\n\n         `python3 workspace\u002Fhelpers\u002Fquery_structural_index.py find_callers --symbol_id \"\u003Cresolved_id>\" --limit 100 --offset 0 --state_root \u003Cstate_root>`\n\n         Paginate with `--offset` if `has_more` is true.\n\n       - **Coverage-aware interpretation:** Check `coverage.partition_status` in\n         every structural index response:\n\n         - `complete` + `precision == semantic` + no callers = \"no indexed\n           callers\" — the partition is fully indexed with a semantic backend, so\n           the empty result is authoritative for indexed code. Still run grep\n           per the HINT-only rule (grep catches macro-based calls, function\n           pointers, and dynamic dispatch).\n         - `complete` + `precision != semantic` + no callers = \"no indexed\n           callers\" — the partition is complete but precision is below semantic,\n           so the empty result is NOT authoritative. MUST run exhaustive grep\n           fallback.\n         - `partial` \u002F `empty` \u002F `failed` + no callers = \"not fully indexed\" —\n           the partition is not complete, so expand the investigation scope and\n           MUST run exhaustive grep fallback.\n\n       - **Guardrails:**\n\n         - HINT-only: structural index results decide ORDER, never MEMBERSHIP.\n           They prioritize which dependent files to investigate first; they MUST\n           NEVER cause a file to be dropped from the audit scope.\n         - Every result carries `precision` and `backend` fields — use\n           `precision` (`semantic` > `typecheck` > `ast` > `symbol-only` >\n           `heuristic` > `deferred` > `coverage-only`) to weight trust in the\n           result.\n         - If the structural index is absent (no `manifest.json`), empty, or the\n           query helper is missing: fall back to grep-based discovery (today's\n           behavior). The structural index is a coverage HINT only.\n\n     - **Context Injection (`kb_references`):** For each investigation you plan,\n       you must determine which files in the `workspace\u002Fkb\u002F` directory (e.g.,\n       `workspace\u002Fkb\u002Fentities\u002Fauth_module.md` or\n       `workspace\u002Fkb\u002Fvulnerabilities\u002FCWE-79.md`) provide necessary context for\n       the researcher. Include the exact file paths to these markdown files in\n       the `\"kb_references\"` array for that investigation. This shifts the\n       burden of context-gathering off the researcher.\n\n     - **Exploratory\u002FUnconstrained Investigations (Moderate Probability):** With\n       a moderate probability (e.g., a 25-50% chance per planning pass), include\n       either an unconstrained adversarial sweep or a random exploration in the\n       plan:\n\n       1. **Adversarial Sweep:** Select a component or directory that the threat\n          model currently marks as safe, low-risk, or out of scope. Instruct the\n          researcher to perform an unconstrained sweep, ignoring safety\n          assumptions in `workspace\u002Fkb\u002FTHREAT_MODEL.md`.\n\n       2. **Random Digging:** Select a random starting position (file or\n          directory) in the codebase. The question for this investigation should\n          be minimal and open-ended, simply instructing the researcher to \"dig\n          into\" or \"explore\" the selected area without specific threat-model\n          context or pre-defined vulnerability classes. Set `kb_references` to\n          an empty list for this investigation to ensure a fresh look.\n\n       **Token Optimization:** Whether using a script (Mode A) or your\n       file-writing tools (Mode B), write the plan directly to disk and do not\n       print the JSON contents in your chat response.\n\n3. **Schema Enforcement:** Regardless of the mode, the final\n   `workspace\u002Fplan.json` file written to disk should match the following schema\n   to ensure downstream auditing agents can parse it correctly:\n\n### Plan Schema Format\n\n```json\n{\n  \"investigations\": [\n    {\n      \"title\": \"Exhaustive Review: [relative_file_path]\",\n      \"target_files\": [\"[relative_file_path_1]\", \"[relative_file_path_2]\"],\n      \"kb_references\": [\"workspace\u002Fkb\u002Fentities\u002Fauth_module.md\", \"workspace\u002Fkb\u002Fvulnerabilities\u002FCWE-79.md\"],\n      \"question\": \"Detailed reviewing prompt instructions asking the researcher to trace specific input pathways, variables, memory allocations, or function constraints.\"\n    }\n  ]\n}\n```\n\nEnsure `workspace\u002Fplan.json` is successfully written. When you have finished,\nnotify the user.\n",{"name":5,"description":7},"main","f3162c039ecd9c9d5d8bc404dd1373c7ca3152f7","skills\u002Fmantis-plan",237,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fmantis","https:\u002F\u002Fcloud.google.com\u002F","https:\u002F\u002Fgithub.com\u002Fgoogle","https:\u002F\u002Fopensource.google\u002F","Google ❤️ Open Source","2026-11-15 00:33:31",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add google\u002Fmantis --skill mantis-plan",{"tool":60,"command":61},"bunx","bunx skills add google\u002Fmantis --skill mantis-plan",{"tool":63,"command":64},"pnpm","pnpm dlx skills add google\u002Fmantis --skill mantis-plan","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fmantis\u002Fblob\u002Fmain\u002Fskills\u002Fmantis-plan\u002FSKILL.md",true,[],[69,91,112,140,151,165],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":39},"01M6992XJHHV0R5N8E392EHRW3","mantis-threat-model","Synthesizes trust boundaries, attack surfaces, and attacker profiles into a living threat model. Use as Stage B of the Knowledge Base generation process, reading architecture and entity definitions from the KB. Don't use for analyzing source code or extracting raw learnings from JSONL files.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fmantis\u002Fblob\u002Fmain\u002Fskills\u002Fmantis-threat-model\u002FSKILL.md",[],[76,33,21,30,77,34,78,79,80,81,82,83,27,84,85,86,87,88,89,90],"mantis threat model","architecture","analyzing","knowledge","kb","files","surfaces","trust","knowledge base","as","extracting","reading","jsonl","source","source code",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":102,"publishedAt":39},"01M6992TR1BPA5HVF13QRM7EP0","mantis-summarize","Pre-processes the repository by generating security-focused summaries (mantis-summary.md) for each directory to make planning and research more efficient. Use when starting a review campaign to map the codebase before threat modeling and planning. Don't use for executing code reviews, writing test scripts, or patching code.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fmantis\u002Fblob\u002Fmain\u002Fskills\u002Fmantis-summarize\u002FSKILL.md",[97],{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[103,104,31,105,38,37,106,34,107,108,32,30,28,26,109,24,110,23,111,22],"summarize","mantis summarize","directory","threat modeling","planning","repository","modeling","make","for",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":123,"publishedAt":39},"01M6992QB4DVMDR2AGT6BPSE3N","mantis-structural-index","Builds a content-addressed semantic-unit index from source code for structural context. Use when a pinned or live codebase is available and structural cross-reference data would improve research quality. Don't use for findings analysis, patching, or reporting.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fmantis\u002Fblob\u002Fmain\u002Fskills\u002Fmantis-structural-index\u002FSKILL.md",[118],{"categoryNo":119,"categoryName":120,"taxonomyType":121,"taxonomyTypeDesc":122},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[124,125,126,127,34,128,129,130,131,32,132,133,134,135,136,137,138,139,111,22],"mantis structural index","index","structural","research","content","reporting","data","analysis","improve","quality","context","use","research quality","reference","live","unit",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":39},"01M6992KRP2XYWEMV12P5M4GPE","mantis-review","Independently reviews findings and filters out false positives. Use when consolidated findings need validation against the actual source code. Don't use for reproducing crashes or patching code.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fmantis\u002Fblob\u002Fmain\u002Fskills\u002Fmantis-review\u002FSKILL.md",[],[38,147,34,148,32,135,149,150,23,111,89,90,22],"mantis review","validation","filters","false",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":39},"01M6992GKVGJ2NXEJWYFVCN01Q","mantis-researcher","Audits production source code files based on the strategy in workspace\u002Fplan.json. Use when a review plan exists and you need to perform static analysis and deep-dive reviews of targeted files. Don't use for planning, deduplicating, or writing patches.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fmantis\u002Fblob\u002Fmain\u002Fskills\u002Fmantis-researcher\u002FSKILL.md",[],[158,159,31,38,160,34,107,131,20,161,135,81,162,163,23,111,89,164,90,22],"mantis researcher","researcher","static analysis","strategy","deep","you","static",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":39},"01M6992D5WXENF3TW68GM5WPHC","mantis-reproduce","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.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fmantis\u002Fblob\u002Fmain\u002Fskills\u002Fmantis-reproduce\u002FSKILL.md",[],[172,173,37,34,32,174,175,176,135,177,178,179,163,111,22],"mantis reproduce","reproduce","verify","write","execute","crash","payload","script"]