What happened
Jim Manico published Grim Prompter, a public GitHub repository for threat modeling with AI coding agents. The project is intended to be pointed at a code repository through Claude Code, Codex, or another coding agent. Its stated output is a threat model traced back to the code the agent inspected, rather than a generic security checklist.
The repository provides 36 architecture workflows and 29 method and analysis prompts. The agent is directed to review the system's code, trust boundaries, threats, existing controls, and possible mitigations, while producing evidence that a reviewer can inspect. The documented installation approach is deliberately local: clone the repository once, then symlink its threat-model skill into Claude Code's skills directory or Codex CLI's agents skills directory. For other agents, the project supplies a snippet for a repository's AGENTS.md, CLAUDE.md, GEMINI.md, or equivalent instruction file.
The interface is organized around several review depths. A quick run can select an architecture automatically or target a named architecture such as an API. A deep web run is described as a six-stage analysis. A single method can be applied to the code, for example STRIDE per element. There is also a change-review mode that compares a branch against an earlier JSON report. In that mode, the agent needs both the code diff and the prior model; if the prior model is omitted, the documented workflow says the agent should ask for it.
Each run writes a new folder under threat-model/. SYSTEM_UNDER_REVIEW.md records scope, evidence, assumptions, and missing information. Quick and deep runs create report.md for findings, proposed mitigations, and verification plans, while JSON artifacts preserve the model and stage handoffs for later reviews. Deep analysis proceeds through scope, system modeling, threat analysis, challenge, treatment planning, and reporting; each stage reads the preceding stage's file. The repository advises keeping reports out of version control until they have been reviewed for sensitive information, because its own .gitignore covers only runs inside its checkout.
The runbook places operational limits on the agent. It requires read-only inspection and file-and-line citations. Builds, tests, scripts, installations, and network access require explicit authorization, with the user's agent permissions meant to enforce those limits. For MCP servers and agent tools, the workflow can map tools to backend credentials and effective permissions where the repository evidence supports that mapping. It also asks reviewers to record unknown credential grants as gaps, inspect shared-token blast radius and read/write separation, and consider whether tool descriptions or post-approval updates can steer other trusted tools.
The project is explicit that its prompts are drafts rather than a security certification. It asks users to correct misunderstood boundaries and unsupported assumptions, challenge the prerequisites and affected assets of each threat, provide risk criteria and owners, and verify proposed fixes with pass, fail, and inconclusive criteria. A plan, it says, is not a passed test.
What the archive adds
We have not covered this before; it opens a new thread.
Trend signal
This supports Skills become a portable capability layer. Grim Prompter is distributed as a skill that can be linked into two coding-agent environments and described to others through a project instruction file. Its value is not merely portability: the skill carries a runbook, staged artifacts, constraints on execution, and review instructions. That is closer to a reusable operational capability than to a standalone prompt.
Why it matters
Teams increasingly ask coding agents to understand repositories and propose changes, but a useful security review needs more than a fluent description of likely problems. It needs a declared system boundary, inspectable evidence, explicit unknowns, and a way to revisit the model when code changes. Grim Prompter supplies a starting structure for that work: a quick review for early orientation, a deeper staged process when the risk warrants it, and JSON artifacts that can be used as a baseline during change review.
The more consequential design choice is the separation of analysis from action. The agent may inspect and write review artifacts, while commands, tests, installations, and network access remain separately authorized. That gives a team a concrete way to adopt agent-assisted AppSec without treating the agent's report or its proposed verification plan as proof that a system is secure.
What happens next
- Coding-agent users will adapt the workflow to repository-specific review gates and risk criteria. (3 months, 65%). Watch for: project-local instructions that name required scope, owners, and review artifacts.
- Change-based threat-model reviews will become more useful where teams retain the JSON baseline alongside code changes. (6 months, 55%). Watch for: workflows that require both a diff and a prior model before review.
Limits and uncertainty
The repository describes a workflow and its intended outputs; it does not establish detection accuracy, false-positive rates, coverage against real incidents, or effectiveness across languages and architectures. The source does not provide benchmark results or an independent assessment of the prompts. File-and-line citations can make a finding easier to inspect, but they do not prove that the inferred threat, mitigation, or permission mapping is correct. The workflow itself acknowledges that missing documentation is not evidence of a defect and that conclusions depend on the evidence actually inspected. Teams must still supply their risk criteria, validate assumptions, and authorize verification separately.
Skill to build now
Run one bounded, read-only threat-model exercise on a service your team already understands. Define the decision the review should support, the directories and services in scope, and what is out of scope before invoking an agent. Require it to cite files and lines, record missing information, and write only under a dedicated review folder. Then have an owner challenge each finding's prerequisites, affected asset, current control, and proposed test. Save the resulting artifact as a baseline only after human review.
Reader takeaway
Grim Prompter is useful as a process package, not an automated security verdict. It gives Claude Code, Codex, and similar agents a structured path from repository evidence to a reviewable threat-model artifact, while retaining human control over scope, risk decisions, execution, and validation.
Open question
Can teams demonstrate that these evidence-traced workflows find materially useful issues with acceptable review effort, rather than simply producing more security documentation?