Grim Prompter: threat model вашого репо силами агента

Встановлення: один клон, симлінк в агента

Репозиторій клонують один раз, а skill threat-model підключають до агента симлінком. Перед цим перевірте, чи немає вже встановленої копії: автори просять уникати дублікатів.

• Клон: git clone https://github.com/jmanico/grim-prompter.git ~/grim-prompter
• Claude Code: mkdir -p ~/.claude/skills && ln -s ~/grim-prompter/skills/threat-model ~/.claude/skills/threat-model
• Codex CLI: mkdir -p ~/.agents/skills && ln -s ~/grim-prompter/skills/threat-model ~/.agents/skills/threat-model

Команди розраховані на локальний shell macOS або Linux. Клон не переносьте: skill посилається на промпти з нього. Після встановлення відкрийте нову сесію агента. Для інших агентів замість skill додають проєктний сніпет у AGENTS.md вашого репозиторію.

Режими і що дати агентові на вході

Крім базового /threat-model, де архітектуру агент обирає сам, є ще два режими. У Codex аргументи ті самі, лише після $threat-model.

• /threat-model quick api — швидка модель під конкретну архітектуру;
• /threat-model STRIDE per element — один метод, застосований до вашого коду.

Якість результату залежить від постановки. Скажіть агенту, яке рішення має підтримати огляд, які сервіси чи директорії дивитися і що поза скоупом. Додайте дизайн-документи й наявну threat model, якщо вона є.

Deep і change: як не загубити контекст

Deep-прогін іде шістьма етапами: скоуп, моделювання системи, аналіз загроз, challenge, планування обробки ризиків і звіт. Кожен етап читає файл попереднього, тож перерваний прогін продовжують, назвавши агенту його папку.

Для change-огляду одного діапазону гілок мало: агенту потрібні і diff, і модель, яку він оновлює. Базовий JSON називають явно, наприклад додають до запиту using threat-model/2026-10-28-quick-api/quick-report.json as the baseline. Якщо модель не вказати, агент спитає.

Для MCP-серверів та інструментів агента огляд зіставляє інструменти з бекенд-обліковими даними й фактичними правами там, де це підтверджують докази, а невідомі гранти чи доступ до креденшелів записує як прогалини. Окремо розглядаються радіус ураження спільного токена та розділення читання й запису.

Де воно ламається і що перевірити

Read-only — вимога ранбука, тобто інструкція для агента, а не технічне обмеження. Збірки, тести, скрипти, встановлення й мережа потребують вашого явного дозволу, але забезпечувати ці межі автори радять дозволами самого агента. Налаштуйте їх так, щоб ці дії вимагали підтвердження.

• Відкрийте SYSTEM_UNDER_REVIEW.md: там скоуп, докази, припущення й відсутня інформація. Хибні припущення тягнуть за собою хибні висновки в report.md.
• Пройдіться посиланнями на файл і рядок у знахідках: перевірте, що цитований код справді робить описане.
• Мітигації та плани перевірки в report.md — пропозиції, а не готові виправлення.
• Не комітьте звіти, доки не перевірили їх на чутливі дані. .gitignore бібліотеки покриває лише прогони всередині її власного checkout, а не у вашому проєкті.