@bgicli/bgicli 2.2.8 → 2.2.10

package/data/skills/openai-screenshot/SKILL.md

@@ -0,0 +1,267 @@
+---
+name: "screenshot"
+description: "Use when the user explicitly asks for a desktop or system screenshot (full screen, specific app or window, or a pixel region), or when tool-specific capture capabilities are unavailable and an OS-level capture is needed."
+---
+
+
+# Screenshot Capture
+
+Follow these save-location rules every time:
+
+1) If the user specifies a path, save there.
+2) If the user asks for a screenshot without a path, save to the OS default screenshot location.
+3) If Codex needs a screenshot for its own inspection, save to the temp directory.
+
+## Tool priority
+
+- Prefer tool-specific screenshot capabilities when available (for example: a Figma MCP/skill for Figma files, or Playwright/agent-browser tools for browsers and Electron apps).
+- Use this skill when explicitly asked, for whole-system desktop captures, or when a tool-specific capture cannot get what you need.
+- Otherwise, treat this skill as the default for desktop apps without a better-integrated capture tool.
+
+## macOS permission preflight (reduce repeated prompts)
+
+On macOS, run the preflight helper once before window/app capture. It checks
+Screen Recording permission, explains why it is needed, and requests it in one
+place.
+
+The helpers route Swift's module cache to `$TMPDIR/codex-swift-module-cache`
+to avoid extra sandbox module-cache prompts.
+
+```bash
+bash <path-to-skill>/scripts/ensure_macos_permissions.sh
+```
+
+To avoid multiple sandbox approval prompts, combine preflight + capture in one
+command when possible:
+
+```bash
+bash <path-to-skill>/scripts/ensure_macos_permissions.sh && \
+python3 <path-to-skill>/scripts/take_screenshot.py --app "Codex"
+```
+
+For Codex inspection runs, keep the output in temp:
+
+```bash
+bash <path-to-skill>/scripts/ensure_macos_permissions.sh && \
+python3 <path-to-skill>/scripts/take_screenshot.py --app "<App>" --mode temp
+```
+
+Use the bundled scripts to avoid re-deriving OS-specific commands.
+
+## macOS and Linux (Python helper)
+
+Run the helper from the repo root:
+
+```bash
+python3 <path-to-skill>/scripts/take_screenshot.py
+```
+
+Common patterns:
+
+- Default location (user asked for "a screenshot"):
+
+```bash
+python3 <path-to-skill>/scripts/take_screenshot.py
+```
+
+- Temp location (Codex visual check):
+
+```bash
+python3 <path-to-skill>/scripts/take_screenshot.py --mode temp
+```
+
+- Explicit location (user provided a path or filename):
+
+```bash
+python3 <path-to-skill>/scripts/take_screenshot.py --path output/screen.png
+```
+
+- App/window capture by app name (macOS only; substring match is OK; captures all matching windows):
+
+```bash
+python3 <path-to-skill>/scripts/take_screenshot.py --app "Codex"
+```
+
+- Specific window title within an app (macOS only):
+
+```bash
+python3 <path-to-skill>/scripts/take_screenshot.py --app "Codex" --window-name "Settings"
+```
+
+- List matching window ids before capturing (macOS only):
+
+```bash
+python3 <path-to-skill>/scripts/take_screenshot.py --list-windows --app "Codex"
+```
+
+- Pixel region (x,y,w,h):
+
+```bash
+python3 <path-to-skill>/scripts/take_screenshot.py --mode temp --region 100,200,800,600
+```
+
+- Focused/active window (captures only the frontmost window; use `--app` to capture all windows):
+
+```bash
+python3 <path-to-skill>/scripts/take_screenshot.py --mode temp --active-window
+```
+
+- Specific window id (use --list-windows on macOS to discover ids):
+
+```bash
+python3 <path-to-skill>/scripts/take_screenshot.py --window-id 12345
+```
+
+The script prints one path per capture. When multiple windows or displays match, it prints multiple paths (one per line) and adds suffixes like `-w<windowId>` or `-d<display>`. View each path sequentially with the image viewer tool, and only manipulate images if needed or requested.
+
+### Workflow examples
+
+- "Take a look at <App> and tell me what you see": capture to temp, then view each printed path in order.
+
+```bash
+bash <path-to-skill>/scripts/ensure_macos_permissions.sh && \
+python3 <path-to-skill>/scripts/take_screenshot.py --app "<App>" --mode temp
+```
+
+- "The design from Figma is not matching what is implemented": use a Figma MCP/skill to capture the design first, then capture the running app with this skill (typically to temp) and compare the raw screenshots before any manipulation.
+
+### Multi-display behavior
+
+- On macOS, full-screen captures save one file per display when multiple monitors are connected.
+- On Linux and Windows, full-screen captures use the virtual desktop (all monitors in one image); use `--region` to isolate a single display when needed.
+
+### Linux prerequisites and selection logic
+
+The helper automatically selects the first available tool:
+
+1) `scrot`
+2) `gnome-screenshot`
+3) ImageMagick `import`
+
+If none are available, ask the user to install one of them and retry.
+
+Coordinate regions require `scrot` or ImageMagick `import`.
+
+`--app`, `--window-name`, and `--list-windows` are macOS-only. On Linux, use
+`--active-window` or provide `--window-id` when available.
+
+## Windows (PowerShell helper)
+
+Run the PowerShell helper:
+
+```powershell
+powershell -ExecutionPolicy Bypass -File <path-to-skill>/scripts/take_screenshot.ps1
+```
+
+Common patterns:
+
+- Default location:
+
+```powershell
+powershell -ExecutionPolicy Bypass -File <path-to-skill>/scripts/take_screenshot.ps1
+```
+
+- Temp location (Codex visual check):
+
+```powershell
+powershell -ExecutionPolicy Bypass -File <path-to-skill>/scripts/take_screenshot.ps1 -Mode temp
+```
+
+- Explicit path:
+
+```powershell
+powershell -ExecutionPolicy Bypass -File <path-to-skill>/scripts/take_screenshot.ps1 -Path "C:\Temp\screen.png"
+```
+
+- Pixel region (x,y,w,h):
+
+```powershell
+powershell -ExecutionPolicy Bypass -File <path-to-skill>/scripts/take_screenshot.ps1 -Mode temp -Region 100,200,800,600
+```
+
+- Active window (ask the user to focus it first):
+
+```powershell
+powershell -ExecutionPolicy Bypass -File <path-to-skill>/scripts/take_screenshot.ps1 -Mode temp -ActiveWindow
+```
+
+- Specific window handle (only when provided):
+
+```powershell
+powershell -ExecutionPolicy Bypass -File <path-to-skill>/scripts/take_screenshot.ps1 -WindowHandle 123456
+```
+
+## Direct OS commands (fallbacks)
+
+Use these when you cannot run the helpers.
+
+### macOS
+
+- Full screen to a specific path:
+
+```bash
+screencapture -x output/screen.png
+```
+
+- Pixel region:
+
+```bash
+screencapture -x -R100,200,800,600 output/region.png
+```
+
+- Specific window id:
+
+```bash
+screencapture -x -l12345 output/window.png
+```
+
+- Interactive selection or window pick:
+
+```bash
+screencapture -x -i output/interactive.png
+```
+
+### Linux
+
+- Full screen:
+
+```bash
+scrot output/screen.png
+```
+
+```bash
+gnome-screenshot -f output/screen.png
+```
+
+```bash
+import -window root output/screen.png
+```
+
+- Pixel region:
+
+```bash
+scrot -a 100,200,800,600 output/region.png
+```
+
+```bash
+import -window root -crop 800x600+100+200 output/region.png
+```
+
+- Active window:
+
+```bash
+scrot -u output/window.png
+```
+
+```bash
+gnome-screenshot -w -f output/window.png
+```
+
+## Error handling
+
+- On macOS, run `bash <path-to-skill>/scripts/ensure_macos_permissions.sh` first to request Screen Recording in one place.
+- If you see "screen capture checks are blocked in the sandbox", "could not create image from display", or Swift `ModuleCache` permission errors in a sandboxed run, rerun the command with escalated permissions.
+- If macOS app/window capture returns no matches, run `--list-windows --app "AppName"` and retry with `--window-id`, and make sure the app is visible on screen.
+- If Linux region/window capture fails, check tool availability with `command -v scrot`, `command -v gnome-screenshot`, and `command -v import`.
+- If saving to the OS default location fails with permission errors in a sandbox, rerun the command with escalated permissions.
+- Always report the saved file path in the response.

package/data/skills/openai-security-best-practices/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: "security-best-practices"
+description: "Perform language and framework specific security best-practice reviews and suggest improvements. Trigger only when the user explicitly requests security best practices guidance, a security review/report, or secure-by-default coding help. Trigger only for supported languages (python, javascript/typescript, go). Do not trigger for general code review, debugging, or non-security tasks."
+---
+
+# Security Best Practices
+
+## Overview
+
+This skill provides a description of how to identify the language and frameworks used by the current context, and then to load information from this skill's references directory about the security best practices for this language and or frameworks.
+
+This information, if present, can be used to write new secure by default code, or to passively detect major issues within existing code, or (if requested by the user) provide a vulnerability report and suggest fixes.
+
+## Workflow
+
+The initial step for this skill is to identify ALL languages and ALL frameworks which you are being asked to use or already exist in the scope of the project you are working in. Focus on the primary core frameworks. Often you will want to identify both frontend and backend languages and frameworks.
+
+Then check this skill's references directory to see if there are any relevant documentation for the language and or frameworks. Make sure you read ALL reference files which relate to the specific framework or language. The format of the filenames is `<language>-<framework>-<stack>-security.md`. You should also check if there is a `<language>-general-<stack>-security.md` which is agnostic to the framework you may be using.
+
+If working on a web application which includes a frontend and a backend, make sure you have checked for reference documents for BOTH the frontend and backend!
+
+If you are asked to make a web app which will include both a frontend and backend, but the frontend framework is not specified, also check out `javascript-general-web-frontend-security.md`. It is important that you understand how to secure both the frontend and backend.
+
+If no relevant information is available in the skill's references directory, think a little bit about what you know about the language, the framework, and all well known security best practices for it. If you are unsure you can try to search online for documentation on security best practices.
+
+From there it can operate in a few ways.
+
+1. The primary mode is to just use the information to write secure by default code from this point forward. This is useful for starting a new project or when writing new code.
+
+2. The secondary mode is to passively detect vulnerabilities while working in the project and writing code for the user. Critical or very important vulnerabilities or major issues going against security guidance can be flagged and the user can be told about them. This passive mode should focus on the largest impact vulnerabilities and secure defaults.
+
+3. The user can ask for a security report or to improve the security of the codebase. In this case a full report should be produced describe anyways the project fails to follow security best practices guidance. The report should be prioritized and have clear sections of severity and urgency. Then offer to start working on fixes for these issues. See #fixes below.
+
+## Workflow Decision Tree
+
+- If the language/framework is unclear, inspect the repo to determine it and list your evidence.
+- If matching guidance exists in `references/`, load only the relevant files and follow their instructions.
+- If no matching guidance exists, consider if you know any well known security best practices for the chosen language and or frameworks, but if asked to generate a report, let the user know that concrete guidance is not available (you can still generate the report or detect for sure critical vulnerabilities)
+
+# Overrides
+
+While these references contain the security best practices for languages and frameworks, customers may have cases where they need to bypass or override these practices. Pay attention to specific rules and instructions in the project's documentation and prompt files which may require you to override certain best practices. When overriding a best practice, you MAY report it to the user, but do not fight with them. If a security best practice needs to be bypassed / ignored for some project specific reason, you can also suggest to add documentation about this to the project so it is clear why the best practice is not being followed and to follow that bypass in the future.
+
+# Report Format
+
+When producing a report, you should write the report as a markdown file in `security_best_practices_report.md` or some other location if provided by the user. You can ask the user where they would like the report to be written to.
+
+The report should have a short executive summary at the top.
+
+The report should be clearly delineated into multiple sections based on severity of the vulnerability. The report should focus on the most critical findings as these have the highest impact for the user. All findings should be noted with an numeric ID to make them easier to reference.
+
+For critical findings include a one sentence impact statement.
+
+Once the report is written, also report it to the user directly, although you may be less verbose. You can offer to explain any of the findings or the reasons behind the security best practices guidance if the user wants more info on any findings.
+
+Important: When referencing code in the report, make sure to find and include line numbers for the code you are referencing.
+
+After you write the report file, summarize the findings to the user.
+
+Also tell the user where the final report was written to
+
+# Fixes
+
+If you produced a report, let the user read the report and ask to begin performing fixes.
+
+If you passively found a critical finding, notify the user and ask if they would like you to fix this finding.
+
+When producing fixes, focus on fixing a single finding at a time. The fixes should have concise clear comments explaining that the new code is based on the specific security best practice, and perhaps a very short reason why it would be dangerous to not do it in this way.
+
+Always consider if the changes you want to make will impact the functionality of the user's code. Consider if the changes may cause regressions with how the project works currently. It is often the case that insecure code is relied on for other reasons (and this is why insecure code lives on for so long). Avoid breaking the user's project as this may make them not want to apply security fixes in the future. It is better to write a well thought out, well informed by the rest of the project, fix, then a quick slapdash change.
+
+Always follow any normal change or commit flow the user has configured. If making git commits, provide clear commit messages explaining this is to align with security best practices. Try to avoid bunching a number of unrelated findings into a single commit.
+
+Always follow any normal testing flows the user has configured (if any) to confirm that your changes are not introducing regressions. Consider the second order impacts the changes may have and inform the user before making them if there are any.
+
+# General Security Advice
+
+Below is a few bits of secure coding advice that applies to almost any language or framework.
+
+### Avoid Using Incrementing IDs for Public IDs of Resources
+
+When assigning an ID for some resource, which will then be used by exposed to the internet, avoid using small auto-incrementing IDs. Use longer, random UUID4 or random hex string instead. This will prevent users from learning the quantity of a resource and being able to guess resource IDs.
+
+### A note on TLS
+
+While TLS is important for production deployments, most development work will be with TLS disabled or provided by some out-of-scope TLS proxy. Due to this, be very careful about not reporting lack of TLS as a security issue. Also be very careful around use of "secure" cookies. They should only be set if the application will actually be over TLS. If they are set on non-TLS applications (such as when deployed for local dev or testing), it will break the application. You can provide a env or other flag to override setting secure as a way to keep it off until on a TLS production deployment. Additionally avoid recommending HSTS. It is dangerous to use without full understanding of the lasting impacts (can cause major outages and user lockout) and it is not generally recommended for the scope of projects being reviewed by codex.

package/data/skills/openai-security-ownership-map/SKILL.md

@@ -0,0 +1,206 @@
+---
+name: "security-ownership-map"
+description: "Analyze git repositories to build a security ownership topology (people-to-file), compute bus factor and sensitive-code ownership, and export CSV/JSON for graph databases and visualization. Trigger only when the user explicitly wants a security-oriented ownership or bus-factor analysis grounded in git history (for example: orphaned sensitive code, security maintainers, CODEOWNERS reality checks for risk, sensitive hotspots, or ownership clusters). Do not trigger for general maintainer lists or non-security ownership questions."
+---
+
+# Security Ownership Map
+
+## Overview
+
+Build a bipartite graph of people and files from git history, then compute ownership risk and export graph artifacts for Neo4j/Gephi. Also build a file co-change graph (Jaccard similarity on shared commits) to cluster files by how they move together while ignoring large, noisy commits.
+
+## Requirements
+
+- Python 3
+- `networkx` (required; community detection is enabled by default)
+
+Install with:
+
+```bash
+pip install networkx
+```
+
+## Workflow
+
+1. Scope the repo and time window (optional `--since/--until`).
+2. Decide sensitivity rules (use defaults or provide a CSV config).
+3. Build the ownership map with `scripts/run_ownership_map.py` (co-change graph is on by default; use `--cochange-max-files` to ignore supernode commits).
+4. Communities are computed by default; graphml output is optional (`--graphml`).
+5. Query the outputs with `scripts/query_ownership.py` for bounded JSON slices.
+6. Persist and visualize (see `references/neo4j-import.md`).
+
+By default, the co-change graph ignores common “glue” files (lockfiles, `.github/*`, editor config) so clusters reflect actual code movement instead of shared infra edits. Override with `--cochange-exclude` or `--no-default-cochange-excludes`. Dependabot commits are excluded by default; override with `--no-default-author-excludes` or add patterns via `--author-exclude-regex`.
+
+If you want to exclude Linux build glue like `Kbuild` from co-change clustering, pass:
+
+```bash
+python skills/skills/security-ownership-map/scripts/run_ownership_map.py \
+  --repo /path/to/linux \
+  --out ownership-map-out \
+  --cochange-exclude "**/Kbuild"
+```
+
+## Quick start
+
+Run from the repo root:
+
+```bash
+python skills/skills/security-ownership-map/scripts/run_ownership_map.py \
+  --repo . \
+  --out ownership-map-out \
+  --since "12 months ago" \
+  --emit-commits
+```
+
+Defaults: author identity, author date, and merge commits excluded. Use `--identity committer`, `--date-field committer`, or `--include-merges` if needed.
+
+Example (override co-change excludes):
+
+```bash
+python skills/skills/security-ownership-map/scripts/run_ownership_map.py \
+  --repo . \
+  --out ownership-map-out \
+  --cochange-exclude "**/Cargo.lock" \
+  --cochange-exclude "**/.github/**" \
+  --no-default-cochange-excludes
+```
+
+Communities are computed by default. To disable:
+
+```bash
+python skills/skills/security-ownership-map/scripts/run_ownership_map.py \
+  --repo . \
+  --out ownership-map-out \
+  --no-communities
+```
+
+## Sensitivity rules
+
+By default, the script flags common auth/crypto/secret paths. Override by providing a CSV file:
+
+```
+# pattern,tag,weight
+**/auth/**,auth,1.0
+**/crypto/**,crypto,1.0
+**/*.pem,secrets,1.0
+```
+
+Use it with `--sensitive-config path/to/sensitive.csv`.
+
+## Output artifacts
+
+`ownership-map-out/` contains:
+
+- `people.csv` (nodes: people)
+- `files.csv` (nodes: files)
+- `edges.csv` (edges: touches)
+- `cochange_edges.csv` (file-to-file co-change edges with Jaccard weight; omitted with `--no-cochange`)
+- `summary.json` (security ownership findings)
+- `commits.jsonl` (optional, if `--emit-commits`)
+- `communities.json` (computed by default from co-change edges when available; includes `maintainers` per community; disable with `--no-communities`)
+- `cochange.graph.json` (NetworkX node-link JSON with `community_id` + `community_maintainers`; falls back to `ownership.graph.json` if no co-change edges)
+- `ownership.graphml` / `cochange.graphml` (optional, if `--graphml`)
+
+`people.csv` includes timezone detection based on author commit offsets: `primary_tz_offset`, `primary_tz_minutes`, and `timezone_offsets`.
+
+## LLM query helper
+
+Use `scripts/query_ownership.py` to return small, JSON-bounded slices without loading the full graph into context.
+
+Examples:
+
+```bash
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out people --limit 10
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out files --tag auth --bus-factor-max 1
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out person --person alice@corp --limit 10
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out file --file crypto/tls
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out cochange --file crypto/tls --limit 10
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out summary --section orphaned_sensitive_code
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out community --id 3
+```
+
+Use `--community-top-owners 5` (default) to control how many maintainers are stored per community.
+
+## Basic security queries
+
+Run these to answer common security ownership questions with bounded output:
+
+```bash
+# Orphaned sensitive code (stale + low bus factor)
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out summary --section orphaned_sensitive_code
+
+# Hidden owners for sensitive tags
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out summary --section hidden_owners
+
+# Sensitive hotspots with low bus factor
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out summary --section bus_factor_hotspots
+
+# Auth/crypto files with bus factor <= 1
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out files --tag auth --bus-factor-max 1
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out files --tag crypto --bus-factor-max 1
+
+# Who is touching sensitive code the most
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out people --sort sensitive_touches --limit 10
+
+# Co-change neighbors (cluster hints for ownership drift)
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out cochange --file path/to/file --min-jaccard 0.05 --limit 20
+
+# Community maintainers (for a cluster)
+python skills/skills/security-ownership-map/scripts/query_ownership.py --data-dir ownership-map-out community --id 3
+
+# Monthly maintainers for the community containing a file
+python skills/skills/security-ownership-map/scripts/community_maintainers.py \
+  --data-dir ownership-map-out \
+  --file network/card.c \
+  --since 2025-01-01 \
+  --top 5
+
+# Quarterly buckets instead of monthly
+python skills/skills/security-ownership-map/scripts/community_maintainers.py \
+  --data-dir ownership-map-out \
+  --file network/card.c \
+  --since 2025-01-01 \
+  --bucket quarter \
+  --top 5
+```
+
+Notes:
+- Touches default to one authored commit (not per-file). Use `--touch-mode file` to count per-file touches.
+- Use `--window-days 90` or `--weight recency --half-life-days 180` to smooth churn.
+- Filter bots with `--ignore-author-regex '(bot|dependabot)'`.
+- Use `--min-share 0.1` to show stable maintainers only.
+- Use `--bucket quarter` for calendar quarter groupings.
+- Use `--identity committer` or `--date-field committer` to switch from author attribution.
+- Use `--include-merges` to include merge commits (excluded by default).
+
+### Summary format (default)
+
+Use this structure, add fields if needed:
+
+```json
+{
+  "orphaned_sensitive_code": [
+    {
+      "path": "crypto/tls/handshake.rs",
+      "last_security_touch": "2023-03-12T18:10:04+00:00",
+      "bus_factor": 1
+    }
+  ],
+  "hidden_owners": [
+    {
+      "person": "alice@corp",
+      "controls": "63% of auth code"
+    }
+  ]
+}
+```
+
+## Graph persistence
+
+Use `references/neo4j-import.md` when you need to load the CSVs into Neo4j. It includes constraints, import Cypher, and visualization tips.
+
+## Notes
+
+- `bus_factor_hotspots` in `summary.json` lists sensitive files with low bus factor; `orphaned_sensitive_code` is the stale subset.
+- If `git log` is too large, narrow with `--since` or `--until`.
+- Compare `summary.json` against CODEOWNERS to highlight ownership drift.

package/data/skills/openai-security-threat-model/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: "security-threat-model"
+description: "Repository-grounded threat modeling that enumerates trust boundaries, assets, attacker capabilities, abuse paths, and mitigations, and writes a concise Markdown threat model. Trigger only when the user explicitly asks to threat model a codebase or path, enumerate threats/abuse paths, or perform AppSec threat modeling. Do not trigger for general architecture summaries, code review, or non-security design work."
+---
+
+# Threat Model Source Code Repo
+
+Deliver an actionable AppSec-grade threat model that is specific to the repository or a project path, not a generic checklist. Anchor every architectural claim to evidence in the repo and keep assumptions explicit. Prioritizing realistic attacker goals and concrete impacts over generic checklists.
+
+## Quick start
+
+1) Collect (or infer) inputs:
+- Repo root path and any in-scope paths.
+- Intended usage, deployment model, internet exposure, and auth expectations (if known).
+- Any existing repository summary or architecture spec.
+- Use prompts in `references/prompt-template.md` to generate a repository summary.
+- Follow the required output contract in `references/prompt-template.md`. Use it verbatim when possible.
+
+## Workflow
+
+### 1) Scope and extract the system model
+- Identify primary components, data stores, and external integrations from the repo summary.
+- Identify how the system runs (server, CLI, library, worker) and its entrypoints.
+- Separate runtime behavior from CI/build/dev tooling and from tests/examples.
+- Map the in-scope locations to those components and exclude out-of-scope items explicitly.
+- Do not claim components, flows, or controls without evidence.
+
+### 2) Derive boundaries, assets, and entry points
+- Enumerate trust boundaries as concrete edges between components, noting protocol, auth, encryption, validation, and rate limiting.
+- List assets that drive risk (data, credentials, models, config, compute resources, audit logs).
+- Identify entry points (endpoints, upload surfaces, parsers/decoders, job triggers, admin tooling, logging/error sinks).
+
+### 3) Calibrate assets and attacker capabilities
+- List the assets that drive risk (credentials, PII, integrity-critical state, availability-critical components, build artifacts).
+- Describe realistic attacker capabilities based on exposure and intended usage.
+- Explicitly note non-capabilities to avoid inflated severity.
+
+
+### 4) Enumerate threats as abuse paths
+- Prefer attacker goals that map to assets and boundaries (exfiltration, privilege escalation, integrity compromise, denial of service).
+- Classify each threat and tie it to impacted assets.
+- Keep the number of threats small but high quality.
+
+### 5) Prioritize with explicit likelihood and impact reasoning
+- Use qualitative likelihood and impact (low/medium/high) with short justifications.
+- Set overall priority (critical/high/medium/low) using likelihood x impact, adjusted for existing controls.
+- State which assumptions most influence the ranking.
+
+### 6) Validate service context and assumptions with the user
+- Summarize key assumptions that materially affect threat ranking or scope, then ask the user to confirm or correct them.
+- Ask 1–3 targeted questions to resolve missing context (service owner and environment, scale/users, deployment model, authn/authz, internet exposure, data sensitivity, multi-tenancy).
+- Pause and wait for user feedback before producing the final report.
+- If the user declines or can’t answer, state which assumptions remain and how they influence priority.
+
+### 7) Recommend mitigations and focus paths
+- Distinguish existing mitigations (with evidence) from recommended mitigations.
+- Tie mitigations to concrete locations (component, boundary, or entry point) and control types (authZ checks, input validation, schema enforcement, sandboxing, rate limits, secrets isolation, audit logging).
+- Prefer specific implementation hints over generic advice (e.g., "enforce schema at gateway for upload payloads" vs "validate inputs").
+- Base recommendations on validated user context; if assumptions remain unresolved, mark recommendations as conditional.
+
+### 8) Run a quality check before finalizing
+- Confirm all discovered entrypoints are covered.
+- Confirm each trust boundary is represented in threats.
+- Confirm runtime vs CI/dev separation.
+- Confirm user clarifications (or explicit non-responses) are reflected.
+- Confirm assumptions and open questions are explicit.
+- Confirm that the format of the report matches closely the required output format defined in prompt template: `references/prompt-template.md`
+- Write the final Markdown to a file named `<repo-or-dir-name>-threat-model.md` (use the basename of the repo root, or the in-scope directory if you were asked to model a subpath).
+
+
+## Risk prioritization guidance (illustrative, not exhaustive)
+- High: pre-auth RCE, auth bypass, cross-tenant access, sensitive data exfiltration, key or token theft, model or config integrity compromise, sandbox escape.
+- Medium: targeted DoS of critical components, partial data exposure, rate-limit bypass with measurable impact, log/metrics poisoning that affects detection.
+- Low: low-sensitivity info leaks, noisy DoS with easy mitigation, issues requiring unlikely preconditions.
+
+## References
+
+- Output contract and full prompt template: `references/prompt-template.md`
+- Optional controls/asset list: `references/security-controls-and-assets.md`
+
+Only load the reference files you need. Keep the final result concise, grounded, and reviewable.