Grim Prompter: 36 architectures and 29 methodologies for threat modeling in Claude Code

⚡ The gist in 5 seconds

• grim-prompter has landed on GitHub: a set of prompts that makes Claude Code, Codex CLI, or another coding agent build a threat model for your repository — 36 architecture scenarios and 29 methodologies, MIT licensed.
• Installation is cloning the repo plus a symlink skills/threat-model into ~/.claude/skills/threat-model or ~/.agents/skills/threat-model; for other agents, a snippet in AGENTS.md.
• It only works in a local macOS/Linux shell, reports land in the threat-model/ folder and require manual cleanup before committing.

🔍 What happened

An author going by jmanico has published the grim-prompter repository on GitHub — not a service or SaaS, but a folder of prompts and working scenarios. main has seven commits; inside are skills/threat-model, methods/, deep/, quick/, reference/, plus catalog.md, runbook.md, and start-here.md. The project claims 36 scenarios for different architectures and 29 methodologies and analytical prompts.

Setup works like this: clone the repo into ~/grim-prompter, then link the skill — for Claude Code into ~/.claude/skills/threat-model, for Codex CLI into ~/.agents/skills/threat-model. The clone must stay in place, because the skill references its own prompts. Then, in an agent session, the following commands become available: /threat-model (it picks the architecture itself), /threat-model quick api, /threat-model deep web, a separate methodology /threat-model STRIDE per element, and branch change review — /threat-model change main...feature, where you can supply an old JSON report as a baseline.

A deep run goes through six stages: scope, system modeling, threat analysis, challenge, treatment plan, reporting. Each stage reads the previous stage's file, and you can resume a run by naming its folder. The result is written into a new directory under threat-model/: SYSTEM_UNDER_REVIEW.md with scope, evidence, assumptions, and gaps, report.md with findings and verification plans, plus JSON artifacts for subsequent runs. The runbook requires read-only inspection and "file:line" references, while builds, tests, scripts, installs, and network access require explicit user permission.

🧠 Our take

The dedicated block of prompts covering MCP servers and agent tools is the most interesting part of this release. The tool maps tools to backend credentials and effective permissions where there's enough evidence, and records unknown grants and credential access as gaps. It also looks at the blast radius of shared tokens, read/write separation, and whether a tool's description — or its update after approval — could steer other trusted tools. Our assessment: this is where the real nerve of the story lies. The threat is no longer that "an agent stole a secret," but that an agent faithfully executed a suggested step.

Threat models usually die on the second iteration: one enthusiast builds it, and the document is outdated by the next sprint. Prompts with quotes from the code are an attempt to make the process repeatable and cheap. For a three-person team, this is the difference between "no threat model at all" and "a draft that can be verified line by line." That already counts for something, even if the draft itself is weak.

Who wins? Those with a security review culture: they'll save hours of routine work. Who loses — in our assessment — the lower segment of the automated threat modeling market: a free MIT-licensed prompt set covers the "at least something" need no worse than a paid checkbox form. But it doesn't compete with audits and pentesting, and doesn't try to.

⚠️ What we don't know

The repository contains not a single example of a finished report — only the folder structure and a format description. No tests, no versions, no public benchmarks: how many real threats the deep run actually catches and how many false positives it produces, nobody has counted. Seven commits — the project is young, so it's too early to talk about stability. A separate open question is large monorepos: the agent's context will run out before the file list does. I'd first run the tool on my own project and compare it with a manual threat model, and only then plug it into the process.

Prediction: within a quarter, forks or analogs with public example reports will appear — competition in this niche will be decided not by the number of methodologies, but by the number of confirmed findings on real code.

Source: GitHub — jmanico/grim-prompter