Mantis History

History Analyzer (/mantis-history)

System Goal

Historical Vulnerability Extractor. Analyzes repository's version control system

(VCS) history to extract past vulnerabilities, security-related fixes, patches,

and associated files, creating a historical learnings database to inform

downstream skills.

Command Definition

• Command: /mantis-history
• Description: Analyzes repository's version control system (VCS) history to

extract past vulnerabilities and fixes, producing a structured historical

learnings file (workspace/historical_learnings.jsonl).

• Arguments (optional; supplied by the orchestrator, consumed by Block A):

--snapshot_root/--snapshot_id/--state_root. History reads VCS logs from

the LIVE repository root (Block A step 5), not the snapshot; it uses

--state_root only to place its cache/output/script. All absent -> DEGRADED

(behaves as today, live cwd).

Input/Output Contract

• Reads:
• workspace/.mantis_state.json (to track current loop pass).
• Codebase directory structure and key files (to determine stack).
• VCS history logs (commit messages, titles, diffs).
• mantis-summary.md (optional, if available).
• Internal history analysis cache (optional, if exists).
• Writes:
• VCS extraction script (written on-the-fly to workspace).
• workspace/historical_learnings.jsonl.
• Internal history analysis cache.
• All under --state_root/workspace/ (cache, historical_learnings.jsonl,

extraction script): kept outside the target tree. Optional history_status

marker (UNSUPPORTED_VCS / PARTIAL_SHALLOW).

• Preconditions:
• Target repository and VCS logs must be accessible.
• Idempotency Guarantee:
• The cache is the source of truth: the output DB is rebuilt from it every run

and is never truncated to empty while the cache is non-empty. The cache is

invalidated on VCS-history rewrite (_analyzed_head no longer reachable) or

a vcs_type/repo-identity change. On none/unknown VCS the stage writes an

empty DB + history_status=UNSUPPORTED_VCS and exits.

Instructions

Step 0: Locator Resolution (run first)

LOCATOR RESOLUTION (before reading ANY target code or artifact):
0. ROLE: If this skill NEVER reads target source (report, calibrate, reflect),
   you are a FINDINGS-ONLY stage: skip steps 2-6; still read active_snapshot from
   state for provenance/annotation; NEVER stop merely because a code root is unset.
1. Determine CODE_ROOT, in this priority order:
   a. If --target_root is passed on THIS invocation, CODE_ROOT = --target_root.
      It is AUTHORITATIVE and OVERRIDES SNAPSHOT_ROOT and the state fallback
      (used when a caller hands you a prepared tree, e.g. a patched shadow).
   b. Else if --snapshot_root (or SNAPSHOT_ROOT) is passed, use it.
   c. Else read state_root/workspace/.mantis_state.json (state_root from
      --state_root if passed, else ./workspace/... relative to the current dir)
      -> active_snapshot.root / .snapshot_id / .snapshot_pinned.
   d. Else (no arg AND no readable active_snapshot): CODE_ROOT = current directory,
      treat snapshot_pinned = false (MODE-OFF). Do NOT stop.
2. SENTINEL CHECK (only if snapshot_pinned is true AND you did NOT take path 1a):
   verify CODE_ROOT/.mantis_snapshot_id exists and equals SNAPSHOT_ID. If missing
   or different -> STOP "snapshot sentinel mismatch". (A --target_root tree (1a) is
   deliberately mutated and is sentinel-EXEMPT.)
3. PATH FIELDS:
   - SNAPSHOT-RELATIVE (read under CODE_ROOT): code_paths entries; plan target_files
     that are file paths. Strip ONLY a trailing ":<digits>". A code_paths entry
     containing "://" is a URL/endpoint, NOT a file read. A code_paths entry that is
     NOT of the form <existing-path>:<integer> is a non-source LOCATOR
     (symbol/offset/endpoint): only check that the artifact/symbol exists; skip ALL
     line-range and line-existence logic.
   - STATE-RELATIVE (read/write under state_root/workspace, NEVER prefix CODE_ROOT):
     kb_references, repro_file_path, reattack_file_path, helper scripts, report
     files, and all state/findings JSON.
4. Never WRITE under CODE_ROOT when snapshot_pinned is true. Any command that
   compiles, generates, or writes artifacts MUST run in a PRIVATE SHADOW copy
   (mktemp -d from CODE_ROOT), never with cwd=CODE_ROOT. Read-only inspection may
   cd into CODE_ROOT.
5. VCS-METADATA CARVE-OUT: history-log extraction and any VCS diff/blame command
   run in the LIVE repository root (which still has .git/.hg/.repo), NOT CODE_ROOT
   (the snapshot copy strips VCS metadata). Do NOT stop merely because CODE_ROOT
   lacks .git/.hg/.repo.
6. Every shell command uses ABSOLUTE paths and sets its own working directory on
   that call. Do NOT assume the working directory persists between calls.

CRITICAL for history: the pinned snapshot copy STRIPS .git/.hg/.repo, so

per Block A step 5 you MUST run every VCS log / diff / blame command in the LIVE

repository root (the working directory Mantis was launched in), NOT under

CODE_ROOT. Do NOT stop because CODE_ROOT lacks VCS metadata. Write the cache,

workspace/historical_learnings.jsonl, and your generated extraction script

under --state_root/workspace/ (STATE-RELATIVE) — never into the target tree,

so a sync/clean cannot wipe them. Record active_snapshot.snapshot_id on

entries only for provenance.

Your task is to analyze the codebase architecture, determine what constitutes

security-relevant history, and write a script on-the-fly to extract and document

historical vulnerabilities from the project's version control system (VCS).

Execute the history analysis stage as follows:

• Phase 1: Analyze Codebase and Define Target History:

• Read existing summaries (e.g. mantis-summary.md if available) or quickly

inspect the root codebase structure to understand the primary files,

programming languages, and core components.

• Determine what types of historical security issues (e.g., memory

corruption, authentication bypass, SQL injection, buffer overflow, or

others) are relevant to this project and what keywords or commits should be

targeted.

• Phase 2: Write a History Extraction Script:

• VCS-support guard (run BEFORE writing/executing the script): Determine

vcs_type from .mantis_state.json vcs_info (or detect it in the LIVE

root). If vcs_type is none or unknown, OR the VCS history is

otherwise unreachable: write an EMPTY

workspace/historical_learnings.jsonl, set a top-of-file / sidecar marker

history_status = "UNSUPPORTED_VCS", and EXIT — never fabricate history.

For multi-vcs (.repo): either iterate history per sub-project, or write

the empty file with history_status = "UNSUPPORTED_VCS" rather than run a

git-shaped script that errors. For a SHALLOW git clone

(git rev-parse --is-shallow-repository == true): proceed but set

history_status = "PARTIAL_SHALLOW" so downstream stages do NOT read "no

historical vuln for this file" as "clean."

• Read the active pass number from the state file

workspace/.mantis_state.json and resolve the current ISO 8601 timestamp.

• Write a script (e.g. Python, bash, or your choice) directly in your

workspace that interacts with your repository version control system (VCS)

history logs.

• Cost-Efficiency & Scale Optimization: To ensure the historical analysis

remains cost-effective and runs efficiently, the script must implement the

following optimizations:

• Commit Message/Description Pre-filtering: Before retrieving diffs,

the script should dynamically determine relevant keywords for commit

message screening. It can do this by first inspecting the repository's

files and languages/domains in scope to establish its primary stack (e.g.

software versus hardware/RTL), then either querying an LLM/analysis agent

for a tailored list of security/bug keywords or using a broader set of

keywords augmented with these specific domain terms. Skip revisions whose

messages or titles do not match these relevant keywords to avoid

unnecessarily retrieving and analyzing changesets that are irrelevant to

the codebase in scope.

• Diff Filtering and Size Limits: Ignore commits that only touch

non-production code (e.g., tests, documentation, or configuration files).

Skip commits with excessively large diffs (e.g., more than several

thousand lines changed), as they are usually automated formatting changes

or massive refactorings rather than discrete security patches.

• Caching Results (cache is the source of truth): Maintain a local

cache (JSON or SQLite) under workspace/ mapping

revision_id -> analyzed, AND storing the full extracted record for each

analyzed revision plus an _analyzed_head high-water mark and the

vcs_type + repo identity the cache was built against. On each run,

REBUILD workspace/historical_learnings.jsonl from the cache (do NOT

skip a revision merely because the cache says "analyzed" and then leave

the output empty — that is the desync bug). NEVER truncate a non-empty

output DB to empty. Only analyze revisions NEWER than _analyzed_head.

Rewrite detection: before trusting the cache, verify _analyzed_head

still resolves in the current LIVE history (git:

git cat-file -e <_analyzed_head> succeeds AND

git merge-base --is-ancestor <_analyzed_head> HEAD; hg:

hg log -r <_analyzed_head> succeeds). If it does not (force-push /

rebase / squash) OR vcs_type/repo identity changed, INVALIDATE the

cache and re-extract from scratch.

• Batch Processing (Batching Diffs): Instead of making one LLM call per

commit diff, the script should batch multiple commit diffs and messages

(e.g. 3 to 5 commits) into a single LLM call. Ask the LLM to analyze all

commits in the batch and return a JSON array of findings for the batch,

reducing request overhead and cost.

• Model Selection: Use lightweight and cost-efficient models for the

initial commit analysis/filtering, and only fall back to heavier model

tiers if deeper verification of a suspected vulnerability is needed.

• Detailed Analysis: For revisions or commits that look

security-relevant, the script should retrieve the commit diffs and

messages/change descriptions.

• LLM/Agent Analysis: The script should make API calls (e.g., via

subagent messages or Agent API subcommands) or use an LLM subagent to

analyze the changes' diffs and messages to determine whether a

revision/commit was a security fix, what component was affected, the

vulnerability type, impact, and the mitigation diff. Make sure it uses

batching and caching to minimize API calls.

• Missing Information: Do not overindex on the lack of security-related

keywords. Many security fixes do not get CVEs, and many security

vulnerabilities are fixed without realizing they were vulnerabilities.

• Output Format: Instruct your script to output the extracted findings

into a JSONL file named workspace/historical_learnings.jsonl, matching

the following format:

Historical Learnings Schema Format (workspace/historical_learnings.jsonl)

{
  "revision_id": "...",
  "title": "...",
  "description": "...",
  "code_paths": ["file:line_number"],
  "vuln_type": "...",
  "mitigation_diff": "...",
  "cve": "...",
  "history": [
    {
      "stage": "history_extractor",
      "action": "created",
      "details": "Extracted from repository revision history.",
      "pass_number": <current_pass_number>,
      "timestamp": "<current_iso8601_timestamp>"
    }
  ]
}

• Phase 3: Execute and Verify:
• Run the script you just wrote to analyze the VCS history, process

revisions, and generate the workspace/historical_learnings.jsonl file.

• Wait for the script to finish and verify that

workspace/historical_learnings.jsonl has been written successfully and

contains extracted data.

When complete, notify the user.