---
name: threat-scenario-enumeration
description: "Generate comprehensive lists of potential attack scenarios from identified infrastructure components. Use this skill whenever the user mentions attack scenario, threat enumeration, kill chain, abuse case, attack tree, red team scenario, threat catalogue, or is working with ATT&CK, Caldera, Atomic Red Team, even if they never say \"threat scenario enumeration\" explicitly. Operates entirely on context the agent already has. Do not use it for unrelated application feature work or general coding questions."
---

# Threat Scenario Enumeration

## What this does

Generate comprehensive lists of potential attack scenarios from identified infrastructure components. It turns a vague request in this area into a decision the caller can
act on, with the evidence attached.

Reach for it when someone is working in ATT&CK, Caldera, Atomic Red Team and needs attack scenario handled
properly rather than guessed at. The value is not the vocabulary — the model already has
that — it is the discipline of covering every case in the same order every time, so two
runs a month apart are comparable.

## Workflow

**1. Establish scope.** Identify exactly what is being assessed: repository, cloud account,
manifest, cluster, or architecture description. If more than one is in play, handle them one
at a time and say which one each finding belongs to. Mixed-scope output is the most common
way this analysis becomes unusable.

**2. Inventory before judging.** List the components in scope first, with no assessment
attached. Judging while enumerating causes the interesting item to swallow the boring ones,
and the boring ones are where the real gaps usually sit.

**3. Assess each item.** Walk `references/playbook.md` for the per-item procedure and the
category-specific checks. Read that file now if this is anything beyond a single trivial item.

**4. Rank by consequence, not by count.** Order findings by what breaks if they are ignored.
Ten low-severity items are not one high-severity item, and presenting them as a flat list
implies they are.

**5. Attach a remediation to every finding.** A finding with no fix is an observation. State
the concrete change — the config line, the policy, the version bump — and where it goes.

**6. Flag what you could not verify.** Anything needing live data — current advisories, live cloud state, current pricing — is outside this skill's scope. Name the gap rather than guessing at it.

## Output format

Use this structure exactly, so results stay diffable between runs:

```markdown
## Summary
<2-3 sentences: what was assessed, and the single most consequential finding>

## Findings
| ID | Component | Finding | Severity | Confidence |
|----|-----------|---------|----------|------------|
| 01 | <name>    | <what>  | high/med/low | high/med/low |

## Remediation
### 01 — <finding title>
**Change:** <the specific edit>
**Where:** <file, resource, or policy>
**Verifies by:** <the command or check that proves it worked>

## Not assessed
<what was out of scope, and why it matters that it was>
```

The "Not assessed" section is not optional. A report that hides its own blind spots gets
trusted more than it should.

## Example

Input: a caller asks for attack scenario on a small service with two dependencies and a public
load balancer.

Output shape: a summary naming the load balancer exposure as the lead item; a findings table
with three rows, the two dependency rows marked medium and the exposure row marked high; a
remediation block giving the exact config change and the command that proves it landed; and
a "Not assessed" note recording that runtime behaviour was never observed, only configuration.

Note what did not happen: no fourth finding was invented to make the table look thorough, and
the two medium rows were not promoted to high to make the report feel urgent.

## Boundaries

Use this skill for attack scenario, threat enumeration, kill chain, abuse case within ATT&CK, Caldera, Atomic Red Team and comparable tooling.

Do not use it for:
- general application feature development or unrelated debugging
- anything requiring credentials the caller has not explicitly provided
- claiming a system is secure or compliant. This produces evidence toward that judgement;
  it does not produce the judgement, and stating otherwise creates liability for the caller.
- live lookups (current advisory data, live cloud state, current pricing). Those need a data-backed skill; say so rather than answering from memory.

Never modify infrastructure, merge a change, or rotate a credential as part of this analysis.
Produce the recommendation and let a human or a separately authorized agent apply it. An
analysis skill that also writes is an analysis skill nobody can safely run.

## Verification

Before returning, check each of these. If any fails, fix it rather than shipping with a caveat:

- [ ] Every component listed in the inventory appears in the findings table or in "Not assessed"
- [ ] Every finding has a remediation with a named file, resource, or policy
- [ ] Every remediation has a verification command or check the caller can actually run
- [ ] Severities are justified by stated consequence, not by gut feel
- [ ] No finding was invented to pad the count, and none was dropped to shorten the report
- [ ] No credential, key, or token appears anywhere in the output
- [ ] Every claim needing live data is marked as unverified rather than asserted

## References

Read `references/playbook.md` for the per-item assessment procedure, the severity rubric,
and the category-specific checks. Read it before step 3 on anything non-trivial.