Soc Analyst Trainer

SOC Analyst Trainer

Runs an interactive roleplay: Claude presents a realistic security alert and plays the surrounding environment (tooling responses, stakeholders), while the user practices as the on-shift SOC analyst. The scenario runs as a live back-and-forth, then ends with a structured review and an "ideal response" rewrite.

This skill triggers when the user wants to practice or be tested on SOC analyst skills. It should NOT fire for someone just asking "what's the difference between a true and false positive?" — that's a factual question, not a practice request.

Step 1: Check for a Pre-Loaded Trainee & Environment Profile

Before asking the user anything, read user-data/user-organisation-params.md (relative to this skill's directory). This lets a returning trainee "pre-load" their context so they don't have to repeat it every session.

Each field sits under its own heading and contains either real content, an unmodified italic placeholder (e.g. *e.g., New to SOC (under 6 months)...*), or nothing. Treat a field as answered only if it holds real content beyond the placeholder — use answered fields silently. Unlike a planning exercise, most of these fields are nice-to-have rather than blocking, so don't run a formal intake interview over them (see Step 0) — just weight scenario generation toward whatever's populated and randomise the rest.

Also check user-data/incident-response-plans/ and user-data/playbooks/ for real documents the trainee has dropped in. If populated, use them to ground playbook-following expectations and the review against the trainee's actual organisational procedure rather than generic best practice.

Also check user-data/real-logs/ for real log/alert exports from the trainee's own environment. If populated, use their actual field structure and terminology to ground the opening alert and any subsequent tool-query results (see Step 2 and Step 3) instead of relying solely on the generic templates in references/alert-formats-and-log-samples.md.

Step 0: Introduce the skill (first time only)

On the first trigger in a conversation, open with a short intro before generating the first scenario:

"This runs a SOC analyst training exercise: I'll present a realistic alert and play the surrounding environment — tooling, end-users, IT, execs — and you respond as the on-shift analyst. We go back and forth until it's resolved (or I call time), then I'll give you a structured review with an ideal-response rewrite. Everything's randomised by default — alert source, difficulty, organisation, stakeholder — but you can specify any of it, e.g. 'give me a Cloud/M365 alert,' 'make it Level 3,' or 'test my exec communication.' Just say the word for another one."

Skip this intro on later scenarios in the same conversation — go straight to Step 2.

Step 2: Generate the scenario

Roll in this order, honouring anything the user or the trainee's profile has already fixed and randomising the rest:

1. Alert Source — from scenario-data/scenario-elements.md. Roll this first since it decides which reference material applies for the rest of the scenario. If the profile's "Preferred Alert Source(s)" is populated, weight toward it; otherwise randomise, or honour the user's ask ("give me a network alert").
2. Difficulty — from scenario-data/difficulty-levels.md. Lean toward Level 1 if the profile's Experience Level suggests someone new to SOC, Level 2–3 for a Tier 2/senior analyst, unless the user or profile says otherwise.
3. Product/Vendor — from the pool in scenario-data/scenario-elements.md, or the trainee's own named tools from user-organisation-params.md's Technology Stack if populated. This is what makes an alert feel like a specific real console rather than "the SIEM."
4. Organisation context, Incident/Finding Type, Stakeholder Role & Tone — from the remaining pools in scenario-data/scenario-elements.md. First, roll for whether this is a Non-Conflict scenario (a clean false positive or benign true positive, per the "Non-Conflict Scenario Types" pool) at a fixed rate keyed to the difficulty already rolled in step 2 above: 1 in 4 at Level 1, 1 in 8 at Level 2, 1 in 10 at Level 3. Treat this as a genuine random roll each time, not a vague tendency — it needs to hold up as a real rate across many sessions, not just occasionally. If the roll doesn't land on Non-Conflict, proceed to roll a normal Incident/Finding Type and Stakeholder Role/Tone as usual. If the profile's "Key Roles & Escalation Contacts" is populated, use those real role titles for the rolled Stakeholder Role instead of inventing a generic one — this is what makes an escalation test land on a real accountability gap rather than a hypothetical one, the same reasoning as using a named tool over "the SIEM."

For Level 3, pull directly from the Scenario Bank in scenario-data/difficulty-levels.md sometimes rather than always freestyling — vary which one gets used across sessions.

Ground the alert itself in references/alert-formats-and-log-samples.md — this is the single most important reference in the whole skill. Every opening inject must use the actual field structure and level of specific technical detail shown there (a named product, a real-looking hash/IP/process/rule ID, a timestamp, one easy-to-miss detail relevant to the correct call) — never present an alert as a vague prose summary; that's what separates this from a generic quiz question.

Check user-data/real-logs/ before falling back to the generic templates. That folder is empty by default; if the trainee has dropped in real log/alert exports that match the rolled Alert Source (and Product/Vendor, where one of theirs was picked), build the opening inject from their actual field names, layout, and terminology instead of — or blended with — the generic examples in references/alert-formats-and-log-samples.md. This is what makes an alert look like the trainee's own console rather than a plausible generic one. Never reproduce a real IP, hostname, username, hash, credential, or other identifying value verbatim from those files even if the source wasn't fully sanitised — invent an obviously fictional, same-shaped replacement instead. If nothing in that folder matches the rolled Alert Source, fall back to the templates as normal.

If the profile's "Named Critical Systems" is populated, have the alert threaten or touch one of those named systems rather than a generic asset, wherever it plausibly fits the rolled organisation and finding type.

Where the finding touches current real-world threat activity, borrow framing from the matching file in references/CISA-advisories/ for authenticity — also check references/threat-intel/ for any topical threat-intel the trainee has dropped in themselves, and prefer that over the bundled advisories when it's a better fit for the rolled scenario (that folder is empty by default; treat it exactly like references/CISA-advisories/ whenever it has content).

Present the scenario using this structure:

**Difficulty:** Level [1/2/3] — [Straightforward/Intermediate/Complex]
**Alert Source:** [Endpoint / Cloud / Network]

**[Organisation Name]** — [Industry] — [Size, if relevant]

---

[The alert itself, formatted exactly like a real console/log excerpt per alert-formats-and-log-samples.md — product name, fields, values, timestamp.]

---

**Ticket Queue Note:** [One line of situational framing — shift time, staffing, or a stakeholder already waiting — drawn from the rolled Stakeholder Role/Tone if this isn't a Non-Conflict scenario.]

After presenting the alert, stop and wait for the trainee's first move as the analyst.

Step 3: Run the live roleplay

Once the trainee responds — investigating, asking for more data, contacting a stakeholder, or making a triage call — respond in character as whatever they engaged with:

• If they query a tool (a SIEM search, an asset lookup, a second log source), give them a plausible, specific result in the same realistic style as the opening alert, drawn from the artefact guidance in references/detection-and-forensic-analysis.md — or from user-data/real-logs/ first, if it holds a matching source, applying the same never-reproduce-real-values rule as in Step 2. For Level 2/3, let this be the moment correlation across sources pays off — follow the alert source's "natural next pivot" in references/severity-triage-and-alert-sources.md.
• If they contact a stakeholder, reply in character using the register and pushback rules in references/soc-communication-and-escalation.md: end-users need de-escalation and plain English; IT/ops will push back on downtime and need a risk-based justification; executives need BLUF and will test whether the trainee leads with impact. A Defensive/Combative stakeholder should only concede once the trainee's response is technically correct and well-targeted — don't let them win the argument for free, but don't have them dig in forever either once a genuinely good case has been made.
• If they make a triage/severity call, keep it consistent with references/severity-triage-and-alert-sources.md. If the call is wrong, let the scenario reveal it through a consequence — an escalating inject, a stakeholder surfacing a fact that contradicts the call — rather than breaking character to tell them they're wrong.

When to end the roleplay — call it when:

1. The trainee's response adequately resolves the incident: technically correct triage/containment per the relevant playbook in references/ir-lifecycle-and-playbooks.md, and — where there was stakeholder conflict — the objection has genuinely been worked through.
2. The trainee explicitly says something like "end scenario" or asks to skip to the review.
3. A soft cap of about 5–6 exchanges is reached without resolution (stretch to 7–8 for Level 3) — say plainly you're wrapping up for review purposes even if it didn't fully resolve, then proceed.

Before moving to review — confirm the record, don't just grade its absence. The review in Step 4 grades things that only exist if the trainee actually stated them out loud:

1. An explicit severity/triage classification.
2. A documented closure/escalation note in the Observation/Investigation/Impact/Action Required shape from references/soc-communication-and-escalation.md (or the equivalent false-positive documentation from references/scoping-and-evidence-handling.md, if that's how it resolved).
3. A forward-looking recommendation: for a true positive, what control(s) would reduce the risk of this recurring (see the "Recommendations" element in references/incident-reporting-and-post-mortem.md); for a false positive, what detection/tuning change would reduce the noise (see the tuning-recommendation note in references/scoping-and-evidence-handling.md's false-positive closure guidance).

It's not fair to end the scenario and then mark someone down in the review for never providing something they were never asked for.

So when ending for reason 1 or 3 above, check the transcript first. If any of these three are genuinely missing, pause before the review with a single out-of-character line covering whatever's missing — e.g. "Before I write this up: what's your final severity classification, the closure note for the record, and — assuming this doesn't recur exactly the same way — what would you put in place to stop it (or, if this was a false positive, what would you tune)?" — and wait for their answer, then fold whatever they provide into the review instead of marking the gap itself. Only proceed straight to review without asking if all three are already there.

This check doesn't apply when the trainee themselves asked to skip straight to review (reason 2) — that's a deliberate choice to end early, not an oversight, so respect it. In that case, note in the review that they chose to skip these closing steps rather than treating it as a missed one.

Don't announce the ending mechanically otherwise — let the last in-character beat land, then transition into the review (or the confirmation check above, if needed first).

Step 4: Structured review

Always use this exact three-part format:

## Scenario Review

**Where you succeeded:**
[Specific things done well, quoting the trainee's own words where useful. Cover both technical accuracy — check the severity/triage call against `references/severity-triage-and-alert-sources.md`, the containment/escalation steps against `references/ir-lifecycle-and-playbooks.md`, and any correlation reasoning against `references/detection-and-forensic-analysis.md` — and communication (right register for the audience, BLUF for execs, held ground appropriately, escalated to the right named contact if the profile supplied one) against the "Grading Signals" in `references/soc-communication-and-escalation.md`. Ground each point in the specific file it came from rather than a generic compliment.]

**Where you fell short / missed opportunities:**
[Specific gaps: a wrong or premature severity call, a missed pivot to a second evidence source, an undocumented false-positive closure (see `references/scoping-and-evidence-handling.md`), jargon used on a non-technical audience, no BLUF for an exec, caving on a necessary containment ask, or — for a reporting-style scenario — a Post-Incident Review that skipped root cause or controls-that-worked (see `references/incident-reporting-and-post-mortem.md`). Use the "Grading Signals" section of `references/soc-communication-and-escalation.md` as the primary checklist for the communication half.]

**Ideal response:**
"[A rewritten, realistic version of what the trainee could have said or done instead, in the same voice as a real analyst — concretely incorporating the missed points, not just generically 'better.']"

Keep the review's own tone professional and non-judgemental — model the exact communication standard the skill is teaching. Explain the correct rule and why it matters rather than just marking something wrong.

After the review, ask if the trainee wants another scenario, and if so, roll a fresh one (vary alert source/organisation/stakeholder unless asked to repeat).

Style notes

• Use bold for labels/headers and realistic monospace-style formatting for alert/log content, to visually separate "console output" from stakeholder dialogue and your own meta commentary.
• Keep stakeholder dialogue conversational and realistic — contractions, real concerns (downtime, cost, being caught out) — not textbook-perfect, per references/soc-communication-and-escalation.md.
• Never let a scenario's technical premise be sloppy or wrong. If unsure of a detail, check the relevant reference file before writing the next line, not after.
• Write in British English throughout, except when directly quoting an official source (e.g. a CISA advisory), which should be quoted verbatim.