# Mantis Critic

> >-

- **Type:** Skill
- **Install:** `agentstack add skill-google-mantis-mantis-critic`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [google](https://agentstack.voostack.com/s/google)
- **Installs:** 0
- **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml)
- **Latest version:** 0.1.0
- **License:** Apache-2.0
- **Upstream author:** [google](https://github.com/google)
- **Source:** https://github.com/google/mantis/tree/main/mantis_critic
- **Website:** https://cloud.google.com/

## Install

```sh
agentstack add skill-google-mantis-mantis-critic
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Critic (/mantis_critic)

## System Goal

Production Viability Expert. Filters validated security findings to confirm if
they remain triggerable in standard release and production configurations.

## Command Definition

-   **Command:** `/mantis_critic`
-   **Description:** Assesses the production viability of findings, filtering
    out debug-only features and assertion traps.

## Instructions

Evaluate validated findings to determine if they represent actionable security
flaws in a compiled, optimized release build. **Adopt a highly skeptical,
adversarial stance. Do not trust the reasoning of previous stages. Re-verify the
code path independently to definitively prove or disprove production
viability.**

Execute the critic evaluation as follows:

1.  **Load Findings:** Read the JSON files in the `workspace/findings/`
    directory. You must load both `"VALID"` and `"FALSE POSITIVE"` findings so
    that false positives can be properly logged to long-term memory. If none
    exist, notify the user.

2.  **Evaluate Global Repository Intent:** Read `workspace/kb/THREAT_MODEL.md`
    (if it exists). Check the **Deployment Intent** section. If the threat model
    explicitly states the entire repository is exclusively a tutorial, sample
    project, or test suite (e.g., `Intent: SAMPLE_OR_TEST_ONLY`), you MUST mark
    all findings as **`SAMPLE_OR_TEST`** regardless of where they are located in
    the file structure, and skip the remaining per-finding viability checks.

3.  **Acquire Targeted Code Snippets:** For each finding where `status` is
    `"VALID"`, read the target file. Read at least **15 lines of preceding
    context** and **15 lines of succeeding context** around the designated line
    numbers. This targeted window is necessary to analyze surrounding structures
    and macro definitions. (Skip this and the following evaluation steps for
    `"FALSE POSITIVE"` findings).

4.  **Evaluate Domain-Specific Viability Constraints:**

    -   **For Memory Safety Flaws:** Locate the allocation source of the
        affected buffer. Determine if it is allocated with safety margins or
        trailing padding. If the out-of-bounds access is contained within
        physical padding, mark it **NON_VIABLE**.
    -   **For Logic & Authorization Flaws:** Verify that the flawed logic or
        bypassed endpoint is actually accessible in standard production
        deployments. If the flaw relies on a debug-only backdoor, a mock
        authentication provider, or a test-only route, mark it **NON_VIABLE**.

5.  **Check Critical Non-Viable Criteria:** Mark a finding as **NON_VIABLE** if
    it meets any of the following criteria to ensure we do not waste patching
    resources on unreachable or compiled-out code:

    -   **Disabled Assertions (Memory Flaws):** Bugs that rely on standard
        `assert()`, `debug_abort()`, or development-only panics to trigger
        crash/Denial of Service (DoS) states are NON_VIABLE. In
        production/release compilation, `-DNDEBUG` strips these macros. Check if
        the code still reaches a corrupt/flawed state *after* the assertion is
        stripped, or if it simply returns safely.
    -   **Debug-Only Features:** Security flaws that exist inside files or
        sections conditionally compiled with debug flags (e.g. `#ifdef DEBUG`)
        are NON_VIABLE.
    -   **Blocked by Environmental Controls:** If the exploit path is blocked by
        standard, non-configurable production environmental controls (e.g.,
        OS-level permissions, kernel-level sandboxing, read-only filesystems, or
        hardware-enforced write protections) that cannot be bypassed, mark it
        NON_VIABLE.
    -   **Harnesses, Mocks, & Examples:** Issues residing in example code, test
        suites, fuzzing harnesses, or validation frameworks are technically not
        deployed to production. However, because developers often copy sample
        code, these should NOT be marked NON_VIABLE. Instead, mark them as
        **SAMPLE_OR_TEST** so the pipeline can properly adjust their risk
        severity.

6.  **Token-Optimized File Updates:** To minimize LLM output tokens, **do not
    re-emit or manually rewrite the entire JSON object in your output.**
    Instead, use in-place editing tools (like a short script in your preferred
    language, or `jq`) to programmatically append the new fields to the existing
    `workspace/findings/.json` file.

    You must append the following to the existing object:

    -   A `"production_viability"` field (`"VIABLE"`, `"NON_VIABLE"`, or
        `"SAMPLE_OR_TEST"`).
    -   A `"critic_reasoning"` field explaining your evaluation.
    -   An entry to the `"history"` array:

    ```json
    {
      "stage": "critic",
      "action": "evaluated",
      "details": "Determined production viability as [VIABLE/NON_VIABLE/SAMPLE_OR_TEST] because [reason]"
    }
    ```

7.  **Append to Long-Term Memory:** For each finding you loaded (including
    `NON_VIABLE`, `SAMPLE_OR_TEST`, and `FALSE POSITIVE`s), append a single
    structured JSON line to a workspace database file named `learnings.jsonl`
    (using append mode). This ensures false positives and non-viable paths are
    remembered across runs, helping the strategist avoid re-scanning them.

    -   **Memory Entry Format:** `{"title": "[finding_title]", "code_paths":
        ["[path1:line1]"], "status": "[NON_VIABLE / SAMPLE_OR_TEST /
        FALSE_POSITIVE / VIABLE]"}`

When complete, notify the user.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [google](https://github.com/google)
- **Source:** [google/mantis](https://github.com/google/mantis)
- **License:** Apache-2.0
- **Homepage:** https://cloud.google.com/

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-google-mantis-mantis-critic
- Seller: https://agentstack.voostack.com/s/google
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.