# Response Playbooks

> >

- **Type:** Skill
- **Install:** `agentstack add skill-willwebster5-agent-skills-response-playbooks`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [willwebster5](https://agentstack.voostack.com/s/willwebster5)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [willwebster5](https://github.com/willwebster5)
- **Source:** https://github.com/willwebster5/agent-skills/tree/main/plugins/crowdstrike-response-playbooks/skills/response-playbooks

## Install

```sh
agentstack add skill-willwebster5-agent-skills-response-playbooks
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Response Playbooks

Turn detections into automated response. This skill analyzes what a detection looks for, recommends tiered response actions appropriate to the threat, and hands off to `fusion-workflows` for workflow YAML generation. It bridges the gap between "alert fires" and "something happens."

> **Response architect, not workflow builder.** This skill decides *what response* fits a detection. The `fusion-workflows` skill builds the actual workflow YAML.

## When to Use This Skill

- You have detections deployed (or proposed) and need response automation
- You want to design SOAR playbooks for a set of detections
- You need to map detection severity/type to appropriate response actions
- You're deciding which detections warrant automated containment vs. notification-only

## Handoff Input

This skill accepts:
- **Direct invocation** — user points at detections by name, file path, or description
- **Handoff doc from source-threat-modeling** — read the doc and use its context for Phase 1

If consuming a handoff doc, skip Phase 1 questions already answered in the doc.

---

## Phase 1: Detection Intake

**Goal:** Understand what each detection looks for and what's at stake.

For each detection the user wants response automation for:

### Step 1: Read the detection

- If it's a deployed detection: read from `resources/detections/`
- If it's from a handoff doc: read the context provided
- If described verbally: ask enough questions to understand the threat

Gather:
- Detection name and CQL logic
- Severity level
- MITRE ATT&CK mapping (technique + tactic)

### Step 2: Identify the center entity

What is the primary subject of this detection?

| Entity Type | Examples |
|---|---|
| User account | Identity-based threats — credential attacks, privilege escalation |
| Host/endpoint | Malware, LOLBins, persistence, lateral movement |
| IP address | Network-based threats — C2, scanning, exfiltration |
| Cloud resource | Infrastructure threats — config changes, IAM abuse |
| Application | SaaS/app-level threats — data theft, API abuse |

### Step 3: Assess blast radius

If this detection fires as a true positive, how bad is it?

| Blast Radius | Meaning | Examples |
|---|---|---|
| **Critical** | Active compromise, data loss in progress | Ransomware, active exfiltration, admin account takeover |
| **High** | Escalation or movement underway | Privilege escalation, lateral movement, credential theft |
| **Medium** | Suspicious but contained | Policy violation, anomalous login, config change |
| **Low** | Informational, worth tracking | New device, unusual time of day, minor anomaly |

**Present the intake summary** (detection, entity, blast radius) and confirm with user before proceeding.

**STOP** — Get user confirmation on the intake assessment.

---

## Phase 2: Response Recommendation

**Goal:** Propose a tiered response plan for each detection.

### Response Tiers

| Tier | Name | Automation Level | Description |
|---|---|---|---|
| **Tier 1** | Observe | Always auto-fire | Create case, log event, notify Slack/email |
| **Tier 2** | Investigate | Always auto-fire | Enrich alert with host details, user history, related alerts |
| **Tier 3** | Contain | Requires human approval | Disable user, isolate host, revoke session, block IP |
| **Tier 4** | Remediate | Manual only | Reset credentials, remove persistence, restore from backup |

### Recommendation Process

For each detection:

**1. Tier 1 — Observe (every detection gets this)**

- Create case with appropriate severity
- Notify the relevant channel (Slack, email, PagerDuty based on severity)
- Log to SIEM for correlation

**2. Tier 2 — Investigate (based on center entity)**

| Entity Type | Enrichment Actions |
|---|---|
| User account | Recent auth history, group memberships, risk score, MFA status |
| Host/endpoint | Running processes, network connections, login history, installed software |
| IP address | Geo lookup, reputation check, historical connections, associated users |
| Cloud resource | Config change history, access logs, associated IAM roles |
| Application | Recent API calls, data access patterns, admin actions |

**3. Tier 3 — Contain (based on severity + threat type)**

| Severity | Threat Type | Containment Recommendation |
|---|---|---|
| Critical | Active attack (exfil, ransomware, admin takeover) | Immediate containment with approval gate |
| Critical | Credential compromise (MFA fatigue, brute force success) | Disable user + revoke sessions with approval gate |
| High | Lateral movement | Isolate host with approval gate |
| High | Privilege escalation | Suspend elevated access with approval gate |
| Medium or below | Any | Skip containment — observe and investigate only |

**Every Tier 3 action MUST have a human approval gate.** Never auto-execute containment. False positive containment is worse than delayed response.

**4. Tier 4 — Remediate (always manual, but document it)**

Document what the SOC should do after containment:
- Credential reset procedures
- Host reimaging steps
- Config rollback process
- Evidence preservation requirements
- Scope assessment (who/what else was affected?)

### Validate available actions

Before recommending, confirm what's actually available in the tenant:

```bash
python .claude/skills/fusion-workflows/scripts/action_search.py --vendor 
python .claude/skills/fusion-workflows/scripts/action_search.py --use-case 
```

Only recommend actions that are available. If a recommended action isn't available, note it as a gap and suggest alternatives.

### Present the response plan

For each detection, present:

```
Detection: 
Severity:  | Entity:  | Threat: 

Tier 1 (auto):
  - Create case (severity: )
  - Notify  with: detection name, affected entity, key indicators

Tier 2 (auto):
  - 

Tier 3 (approval required):
  -  — requires SOC analyst approval

Tier 4 (manual):
  - 
```

**STOP** — Get user approval on the response plan before generating handoff docs.

---

## Phase 3: Workflow Generation & Handoff

**Goal:** Produce handoff documents for `fusion-workflows` to build the actual workflow YAML.

For each approved response plan, write a handoff doc to `docs/handoffs/`.

**Filename:** `YYYY-MM-DD-response-playbooks-to-fusion-workflows-.md`

**Template:**

```markdown
# Handoff: Response Playbooks → Fusion Workflows

## Objective

Create a Fusion workflow to automate response for: 

## Source

- **Produced by:** response-playbooks skill
- **Date:** 
- **Target skill:** fusion-workflows

## Context

| Field | Value |
|---|---|
| Detection name |  |
| Detection resource_id |  |
| Severity |  |
| Center entity |  |
| MITRE technique |  —  |
| MITRE tactic |  |

## Approved Response Plan

### Tier 1 — Observe (auto-fire)

- **Create case** — severity: , title template: " — "
- **Notify** — channel: , include: detection name, affected entity, source IP, event count

### Tier 2 — Investigate (auto-fire)

- **Enrich** — 

### Tier 3 — Contain (approval required)

- **** — 
- **Approval gate:** SOC analyst must approve before execution via 

### Tier 4 — Remediate (manual)

- 

## Decisions Made

These have been reviewed and approved by the user. The receiving skill should NOT re-ask:

- 
- 

## Constraints

- Tier 3 actions MUST have a human approval gate — never auto-execute containment
- Notification must include: 
- 

## Workflow Structure

- **Trigger:** Detection alert (detection name: )
- **Flow:** Tier 1 actions → Tier 2 enrichment → conditional Tier 3 containment (with approval)
- **Approval mechanism:** 

## Artifacts

- 
```

**Tell the user:** "Handoff doc written to ``. Invoke the `fusion-workflows` skill and point it at this file to generate the workflow YAML."

---

## Response Pattern Library

Common detection-to-response mappings. These inform recommendations but don't override human judgment — use them as starting points.

| Detection Type | Entity | Severity | Tier 1 | Tier 2 | Tier 3 | Tier 4 |
|---|---|---|---|---|---|---|
| Credential attack (brute force, stuffing, MFA fatigue) | User | Critical | Case + Slack | Auth history, risk score | Disable user, revoke sessions | Credential reset |
| Privilege escalation (new admin, role change) | User | High | Case + Slack | Access audit, change history | — | Review and revert access |
| Data exfiltration (bulk download, unusual export) | User/App | Critical | Case + Slack | Download history, data classification | Revoke sessions, block IP | Audit data exposure |
| Suspicious network (C2 beacon, unusual dest) | Host | High | Case + Slack | Process list, network connections | Isolate host | Reimage, hunt for lateral |
| Cloud config change (SG, IAM policy) | Cloud Resource | Medium | Case + Slack | Config diff, who-changed-what | — | Revert change |
| Anomalous login (impossible travel, new device) | User | Medium | Case + Slack | Login history, device inventory | — | — |
| Audit log tampering | Source | Critical | Case + Slack + page | Log gap analysis | Isolate source, freeze state | Forensic investigation |
| Service account abuse | User | High | Case + Slack | Service account scope, recent API calls | Rotate credentials | Audit all service account access |

---

## Key Principles

1. **Never auto-execute containment.** Tier 3 actions always require human approval. False positive containment is worse than delayed response.
2. **Every detection gets Tier 1.** At minimum: create a case and notify someone.
3. **Match response to blast radius.** A medium-severity anomalous login doesn't need host isolation.
4. **Validate before recommending.** Use action discovery to confirm what's available in the tenant.
5. **Document Tier 4 even though it's manual.** The SOC needs to know what comes after containment.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [willwebster5](https://github.com/willwebster5)
- **Source:** [willwebster5/agent-skills](https://github.com/willwebster5/agent-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-willwebster5-agent-skills-response-playbooks
- Seller: https://agentstack.voostack.com/s/willwebster5
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.