New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Incident Response Network

by LeoYeAI in LeoYeAI/openclaw-master-skills

Network forensics evidence collection and analysis during security incidents.

Apache-2.0Auto-check passedSecurity

Install Incident Response Network

skills CLI
$ npx skills add LeoYeAI/openclaw-master-skills --skill incident-response-network -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install LeoYeAI/openclaw-master-skills incident-response-network --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/LeoYeAI/openclaw-master-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/incident-response-network .claude/skills/incident-response-network && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
incident-response-network
GitHub stars
2.2k
Token cost
~5k tokens
SKILL.md length
2,145 words
Files
4 (incl. references)
Skills in repo
1,235
Repo updated
First seen
Licence
Apache-2.0

At a glance

Network forensics evidence collection and analysis during security incidents.

  • Works in 6 steps: Evidence Preservation → Initial Triage → Lateral Movement Detection → …
  • Tasks that involve Incident response
  • SKILL.md covers When to Use, Prerequisites, Procedure and Threshold Tables, plus 3 more sections
  • Calls bash

What it does

Incident Response Network is an agent skill from LeoYeAI/openclaw-master-skills. Network forensics evidence collection and analysis during security incidents. Guides volatile evidence preservation, lateral movement detection via flow records and ARP/MAC/CAM table analysis, and read-only containment verification across Cisco IOS-XE/NX-OS, Juniper JunOS, and Arista EOS. Scoped to network artifacts only — packet captures, flow data (NetFlow/sFlow/IPFIX), forwarding tables, routing state, and device logs. Not general incident response, endpoint forensics, or malware analysis.

Its SKILL.md is about 5k tokens, which your agent loads only when the skill is triggered. The skill folder holds 4 other files, including reference files (for example `_meta.json`, `references/cli-reference.md` and `references/forensics-workflow.md`).

It sits in Security, covering Incident response, Digital forensics and Network security. It works with iOS. The repository describes itself as: 🧠 Curated collection of 1209+ best OpenClaw skills — weekly updated by MyClaw.ai. The licence is Apache-2.0.

When your agent uses it

  • Tasks that involve Incident response
  • Tasks that involve Digital forensics
  • Tasks that involve Network security

Example prompts

  • “/incident-response-network”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Evidence Preservation
  2. Initial Triage
  3. Lateral Movement Detection
  4. Containment Verification (Read-Only)
  5. Timeline Reconstruction
  6. Post-Incident Documentation

What it can do on your machine

Read from SKILL.md and the folder at commit e5199b5. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • bash

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Incident Response Network loads about 5k tokens when it runs, and up to ~9.9k if it reads all its reference files. Until then it costs about 131 tokens; SKILL.md has 2,145 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~131
When it runs · the whole SKILL.md, loaded when a task matches
~5k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~9.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from LeoYeAI/openclaw-master-skills at commit e5199b5, republished under its Apache-2.0 licence (© LeoYeAI). 2,145 words, ~5,019 tokens.

Download SKILL.mdSave it as .claude/skills/incident-response-network/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
name
incident-response-network
description
Network forensics evidence collection and analysis during security incidents. Guides volatile evidence preservation, lateral movement detection via flow records and ARP/MAC/CAM table analysis, and read-only containment verification across Cisco IOS-XE/NX-OS, Juniper JunOS, and Arista EOS. Scoped to network artifacts only — packet captures, flow data (NetFlow/sFlow/IPFIX), forwarding tables, routing state, and device logs. Not general incident response, endpoint forensics, or malware analysis.
license
Apache-2.0
metadata.safety
read-only
metadata.author
network-security-skills-suite
metadata.version
1.0.0
metadata.openclaw
{"emoji":"🚨","safetyTier":"read-only","requires":{"bins":["ssh"],"env":[]},"tags":["incident","forensics","network"],"mcpDependencies":[],"egressEndpoints":[]}

Network Incident Response — Network Forensics

Network-specific evidence collection and analysis during security incidents. This skill covers network artifacts only: packet captures, flow records (NetFlow/sFlow/IPFIX), ARP/MAC/CAM tables, routing table state, and device syslog events. It does not cover general incident response lifecycle (NIST 800-61), endpoint forensics, malware analysis, or organizational communication plans.

The procedure follows an event-driven lifecycle shaped around forensic evidence: preserve volatile data → triage scope → detect lateral movement → verify containment → reconstruct timeline → document findings. All commands are read-only. Containment verification confirms that previously applied controls are effective — it does not execute containment actions.

Commands use [Cisco], [JunOS], or [EOS] vendor labels where syntax diverges. See references/cli-reference.md for the full command reference and references/forensics-workflow.md for evidence methodology, chain-of-custody templates, and timeline reconstruction guidance.

When to Use

  • Active security incident requiring network-level evidence collection (packet captures, flow analysis, device logs)
  • Post-incident network forensics — reconstructing what happened on the network after a confirmed security event
  • Lateral movement investigation — tracing attacker movement between internal hosts using flow records, ARP/MAC table changes, and routing state analysis
  • Unauthorized access investigation — identifying how an external or internal actor reached target systems via network path analysis
  • Data exfiltration analysis — quantifying outbound data transfers via flow record byte counts and packet capture content analysis
  • Containment verification — confirming (read-only) that ACLs, null routes, or VLAN isolation applied by responders are blocking attacker traffic effectively

Prerequisites

  • Device CLI access — read-only access to network devices in the incident scope is sufficient for all evidence collection commands. No enable/configure privilege is required.
  • Flow collection infrastructure — NetFlow, sFlow, or IPFIX collectors must be receiving exports from network devices. Verify with flow export commands in references/cli-reference.md. Without flow data, lateral movement analysis (Step 3) is limited to ARP/MAC/syslog correlation.
  • Centralized logging — device syslog events must be forwarded to a SIEM or syslog server. Local device log buffers are small and rotate quickly. Missing centralized logs create timeline gaps.
  • NTP synchronization — all devices must be time-synchronized. Verify with [Cisco] show ntp status, [JunOS] show system ntp, [EOS] show ntp status. Skewed clocks corrupt timeline correlation.
  • Known-good baseline — saved copies of routing tables, ARP tables, and device configurations from before the incident for comparison. Without baselines, anomaly detection relies on general heuristics rather than delta analysis.

Procedure

Follow these six steps in order. Earlier steps capture volatile evidence before it ages out; later steps analyze and document. Each step references specific commands from references/cli-reference.md and methodology from references/forensics-workflow.md.

Step 1: Evidence Preservation

Capture volatile network evidence before it ages out or is overwritten. Follow the volatility ordering from references/forensics-workflow.md — most volatile first.

1a. ARP / MAC / CAM tables (highest volatility — minutes to hours):

Collect the current ARP and MAC address tables from every device in the incident scope. These tables map IP addresses to MAC addresses and MAC addresses to physical switch ports — essential for identifying which hosts were connected where.

  • [Cisco] — show arp and show mac address-table
  • [JunOS] — show arp no-resolve and show ethernet-switching table
  • [EOS] — show arp and show mac address-table

Save output to files with timestamps. ARP entries typically age out in 4 hours; CAM entries in 5 minutes. Delay here means losing L2 mapping.

1b. Active packet captures (real-time — exists only while traffic flows):

If the incident is active and the investigation requires payload-level evidence, initiate packet captures on relevant interfaces immediately.

  • [Cisco] — monitor capture CAP1 interface <intf> both then monitor capture CAP1 start — export with monitor capture CAP1 export flash:evidence.pcap
  • [JunOS] — monitor traffic interface <intf> write-file /var/tmp/capture.pcap
  • [EOS] — bash tcpdump -i <intf> -w /mnt/flash/evidence.pcap -c 10000

Performance note: On-device packet capture consumes CPU. Monitor device health during capture and set packet count or duration limits.

1c. Routing table snapshots (hours — convergence overwrites state):

  • [Cisco] — show ip route and show ip route summary
  • [JunOS] — show route and show route summary
  • [EOS] — show ip route and show ip route summary

Also capture routing protocol adjacency state (show ip ospf neighbor, show ip bgp summary or vendor equivalents) to document peering status at the time of collection.

1d. Flow export verification (hours to days — collector retention):

Confirm that flow data from the incident time window is available in the flow collector. Verify export is active and records exist:

  • [Cisco] — show flow monitor and show flow exporter <name> statistics
  • [JunOS] — show services flow-monitoring version-ipfix template and show services accounting status
  • [EOS] — show flow tracking and show flow tracking counters

1e. Device configuration and comprehensive state:

Save the running configuration and full technical support output for each device in scope:

  • [Cisco] — show tech-support | redirect flash:tech-<hostname>-<date>.txt
  • [JunOS] — request support information | save /var/tmp/tech-<hostname>-<date>.txt
  • [EOS] — show tech-support | redirect flash:tech-<hostname>-<date>.txt

Compute SHA-256 hashes immediately after saving evidence files (see references/forensics-workflow.md for hash verification commands).

Step 2: Initial Triage

Determine the scope of the incident — affected devices, time window, involved IP addresses — using log and flow data collected in Step 1.

Identify the time window: Find the earliest indicator (first alert, first anomalous event) and the latest known malicious activity. Add a buffer of ±2 hours to account for undetected precursor activity.

Identify involved IPs: Extract unique source and destination IP addresses from alerts, SIEM events, and flow records within the time window. Classify each as internal, external, or infrastructure.

Identify affected devices: Determine which network devices handled traffic to/from involved IPs. Use routing tables to trace the forwarding path and identify all transit devices.

Scope assessment output: A list of (1) affected time window, (2) involved IP addresses with classification, (3) affected network devices, and (4) evidence types available for each device. This scoping drives the depth of Steps 3–5.

Step 3: Lateral Movement Detection

Trace internal-to-internal connections that indicate attacker movement between hosts. Lateral movement leaves evidence in flow records (new internal connections), ARP/MAC tables (new L2 entries), and syslog (authentication events, new sessions).

Flow record analysis: Query the flow collector for internal-to-internal connections involving known compromised IPs during the incident time window. Look for:

  • Connections to ports commonly used for lateral movement (SMB/445, RDP/3389, SSH/22, WinRM/5985, WMI/135)
  • Connections from a compromised host to hosts it has never contacted before (new destination analysis)
  • High byte-count transfers between internal hosts (staging or exfil prep)
  • Sequential connections from one host to many hosts in a short time window (scanning behavior)

ARP/MAC table analysis: Compare current ARP/MAC tables against baseline captures. Look for:

  • New MAC addresses on access ports (rogue devices)
  • MAC address appearing on a different port than baseline (device moved or MAC spoofing)
  • Multiple IP addresses mapped to a single MAC (IP aliasing, potential MITM)

Syslog correlation: Review authentication events on network devices during the incident window. Attacker lateral movement often involves:

  • Failed authentication attempts from internal IPs against network device management interfaces
  • Successful logins from unexpected source IPs
  • Configuration view commands from unusual user accounts
Step 4: Containment Verification (Read-Only)

Verify that containment measures applied by the incident response team are functioning as intended. This step is strictly read-only — it confirms effectiveness, it does not apply containment.

ACL hit count verification: Confirm that blocking ACLs are matching the attacker's traffic. Rising hit counters on deny rules confirm the ACL is intercepting traffic.

  • [Cisco] — show access-lists <containment-acl-name> — check hit counters on deny entries
  • [JunOS] — show firewall filter <containment-filter> — check term counters for deny actions
  • [EOS] — show access-lists <containment-acl-name> — check per-entry match counts

Routing containment verification: If null routes or route modifications were applied for containment, verify they are present and effective:

  • Confirm the null route exists in the routing table (show ip route <attacker-prefix> should show Null0/discard)
  • Verify no more-specific routes bypass the null route
  • Check routing protocol advertisements to confirm containment routes are not being overridden by dynamic protocols

Network isolation verification: If VLAN isolation was applied, verify that the isolated segment has no unintended paths:

  • Check the routing table for routes to/from the isolated VLAN
  • Verify trunk port allowed VLAN lists exclude the isolated VLAN on uplinks
  • Confirm no layer-3 interfaces provide alternative paths
Show full SKILL.md (840 more words)Show less
Step 5: Timeline Reconstruction

Build a unified chronological sequence of network events from all evidence sources. This timeline is the primary deliverable of network forensics investigation.

Source integration: Merge events from syslog, flow records, routing changes, and ARP/MAC transitions into a single timeline sorted by UTC timestamp. Follow the full timeline reconstruction methodology in references/forensics-workflow.md.

Key timeline elements:

  1. Anchor events — high-confidence events that serve as fixed points (first alert, interface state changes, BGP/OSPF adjacency changes)
  2. Correlated events — events linked by shared IP addresses, timestamps, or session identifiers across multiple devices
  3. Gaps — time periods with missing evidence from devices that should have been active (document explicitly as uncertainty)
  4. Phase transitions — points where activity shifts from reconnaissance to access, access to lateral movement, lateral movement to objective or exfiltration

Timeline validation: Cross-reference the reconstructed timeline against multiple evidence sources. Events confirmed by two or more independent sources (e.g., firewall deny in syslog + flow record for same session) are high confidence. Single-source events are medium confidence.

Step 6: Post-Incident Documentation

Compile investigation findings into a structured evidence package. This documentation supports organizational incident response and any subsequent legal or compliance review.

Required documentation artifacts:

  • Evidence inventory with chain-of-custody records (use the template in references/forensics-workflow.md)
  • Reconstructed timeline of network events (from Step 5)
  • Lateral movement map showing affected hosts and connection paths (from Step 3, if lateral movement was detected)
  • Containment verification results (from Step 4)
  • List of affected network devices with evidence types collected
  • Identified gaps in evidence and their impact on conclusions

Threshold Tables

Evidence Priority Classification
PriorityEvidence TypeConditionRationale
CriticalActive packet capturesIncident is active, payload evidence requiredLive traffic cannot be recovered after the fact
CriticalARP/MAC/CAM tablesAny incident within the last 4 hoursAging timers overwrite entries — shortest evidence lifespan
HighFlow recordsIncident time window within collector retentionReveals communication patterns and lateral movement paths
HighSyslog eventsIncident time window within log retentionProvides the event narrative — auth, config, state changes
MediumRouting table snapshotsSuspected route manipulation or path analysis neededShows forwarding state but only captures current point-in-time
MediumSNMP trap historyCorroborating physical or threshold eventsSupplements syslog but with less detail
LowHistorical config archivesBaseline comparison or configuration drift analysisPersistent data — available for later retrieval if needed
Containment Verification Criteria
CheckExpected ResultFailure Indicator
ACL deny countersIncrementing on containment rulesZero or static counters — ACL not matching traffic
Null route presenceAttacker prefix routes to Null0/discardRoute missing or overridden by dynamic protocol
VLAN isolationNo L3 routes to/from isolated segmentRoutes exist, providing bypass path
Flow records post-containmentNo new flows from/to attacker IPsContinuing flows indicate containment bypass

Decision Trees

Evidence Collection Priority
Incident reported
├── Is the incident currently active?
│   ├── Yes — Active threat
│   │   ├── Is payload-level evidence needed?
│   │   │   ├── Yes → Start packet capture immediately (Step 1b)
│   │   │   └── No → Proceed to ARP/MAC collection (Step 1a)
│   │   └── Simultaneously: collect ARP/MAC tables (Step 1a)
│   │       └── Then: routing snapshots (Step 1c) → flow verification (Step 1d)
│   │
│   └── No — Post-incident investigation
│       ├── How long ago did the incident occur?
│       │   ├── < 4 hours → ARP/MAC tables may still have entries (Step 1a)
│       │   ├── 4–24 hours → ARP tables likely aged out; start with flow data
│       │   └── > 24 hours → Rely on syslog and flow collector retention
│       └── Verify flow data and syslog coverage for incident window (Steps 1d, 1e)
│
├── Has containment been applied?
│   ├── Yes → Add containment verification (Step 4) after triage
│   │   └── Check ACL counters, null routes, VLAN isolation
│   └── No → Skip Step 4, proceed through Steps 1–3, 5–6
│
└── Proceed to initial triage (Step 2)

Report Template

NETWORK FORENSICS EVIDENCE SUMMARY
=====================================
Incident Reference:   [ticket/tracking number]
Investigation Period: [start] — [end] (UTC)
Network Scope:        [number] devices across [number] sites
Analyst:              [name/identifier]
Collection Date:      [date evidence collection began]

EVIDENCE INVENTORY:
| # | Device | Evidence Type | File | SHA-256 | Collected At |
|---|--------|--------------|------|---------|-------------|
| 1 | [host] | [type] | [file] | [hash] | [time UTC] |

INCIDENT TIMELINE:
| # | Time (UTC) | Device | Event | Details | Confidence |
|---|-----------|--------|-------|---------|------------|
| 1 | [time] | [host] | [event] | [details] | [H/M/L] |

LATERAL MOVEMENT MAP (if detected):
- Source host → destination host : port (first seen, last seen, byte count)
- [list all observed internal-to-internal attacker paths]

CONTAINMENT VERIFICATION:
| Control | Device | Status | Evidence |
|---------|--------|--------|----------|
| [ACL/route/VLAN] | [host] | [Effective/Bypassed] | [counter values] |

EVIDENCE GAPS:
- [device/time period with missing evidence and impact on conclusions]

RECOMMENDATIONS:
1. [network-level remediation or monitoring improvement]

Troubleshooting

Insufficient Flow Data Coverage

Symptom: Flow records do not exist for devices or time windows critical to the investigation.

Diagnosis: Verify flow export configuration on each device using commands in references/cli-reference.md. Check collector storage — retention may have expired for the incident time window.

Workaround: Substitute with syslog events (lower fidelity but covers event timestamps) and ARP/MAC table correlation. Document the flow gap and its impact on lateral movement analysis completeness.

Time Synchronization Gaps

Symptom: Events from different devices appear out of order or correlation produces implausible sequences.

Diagnosis: Check NTP status on each device. Compare timestamps of events that should be near-simultaneous (e.g., both ends of a link-down event logged by adjacent devices).

Workaround: Calculate clock offset per device and apply correction to the timeline. Note the correction in evidence documentation. Reduce correlation confidence for events involving desynchronized devices.

Evidence Overwritten by Log Rotation

Symptom: Syslog events from the incident time window no longer exist on the device or in the SIEM.

Diagnosis: Check device log buffer size (show logging to see buffer capacity and oldest retained message). Check SIEM retention policy for the relevant index.

Workaround: Use flow records or SNMP trap history as alternative event sources. Note the syslog gap in the timeline with an explicit confidence reduction for that time period.

Packet Capture Performance Impact

Symptom: Device CPU spikes or forwarding performance degrades during on-device packet capture.

Diagnosis: Monitor CPU utilization during capture. On-device capture processes packets in software, bypassing hardware forwarding.

Workaround: Limit captures with ACL filters (capture only relevant traffic), set packet count limits (-c flag), use span/mirror sessions to an external capture appliance instead of on-device capture, or reduce capture duration. If performance impact is unacceptable, stop capture and rely on flow records for metadata-level analysis.

Incomplete ARP/MAC Table Recovery

Symptom: ARP or MAC address tables are mostly empty — entries have already aged out by the time evidence collection begins.

Diagnosis: Default ARP aging is 4 hours; default CAM aging is 5 minutes. If more than 4 hours have elapsed since the incident, ARP entries for inactive hosts will be gone.

Workaround: Cross-reference DHCP lease logs for IP-to-MAC mappings during the incident window. Use flow records to identify involved IP addresses without L2 mapping. Check if any NMS polled ARP/MAC tables via SNMP during the incident window.

© LeoYeAI, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 3 other files (references) in skills/incident-response-network of LeoYeAI/openclaw-master-skills.

  • SKILL.md
  • _meta.json
  • references/cli-reference.md
  • references/forensics-workflow.md

Open the folder on GitHubat commit e5199b5

Compare with similar skills

Incident Response Network next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Incident Response Network compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Incident Response Network this skillLeoYeAI/openclaw-master-skills2.2k—~5kAutomated safety check: PassApache-2.0
Forensics OsqueryAgentSecOps/SecOpsAgentKit2201 repos~4.9kAutomated safety check: NotesCustom licence
Analyzing Network Traffic Of Malwaremukul975/Anthropic-Cybersecurity-Skills34k—~3kAutomated safety check: PassApache-2.0
Ir VelociraptorAgentSecOps/SecOpsAgentKit2201 repos~3.1kAutomated safety check: PassCustom licence
Detecting Privilege Escalation Attemptsmukul975/Anthropic-Cybersecurity-Skills34k—~922Automated safety check: PassApache-2.0
Performing Network Packet Capture Analysismukul975/Anthropic-Cybersecurity-Skills34k—~2.3kAutomated safety check: PassApache-2.0

Similar skills

  • Forensics Osquery

    AgentSecOps/SecOpsAgentKit

    SQL-powered forensic investigation and system interrogation using osquery to query operating systems as relational databases.

    220 GitHub starsUsed in 1 repo~4.9k tokens
    SecurityAuto-check: notes

  • Analyzing Network Traffic Of Malware

    mukul975/Anthropic-Cybersecurity-Skills

    Analyzes network traffic generated by malware during sandbox execution or live incident response to identify C2 protocols, data exfiltration channels, payload downloads, and lateral movement…

    34k GitHub stars~3k tokensUpdated 1 mo ago
    SecurityAuto-check passed

  • Ir Velociraptor

    AgentSecOps/SecOpsAgentKit

    Endpoint visibility, digital forensics, and incident response using Velociraptor Query Language (VQL) for evidence collection and threat hunting at scale.

    220 GitHub starsUsed in 1 repo~3.1k tokens
    SecurityAuto-check passed

  • Detecting Privilege Escalation Attempts

    mukul975/Anthropic-Cybersecurity-Skills

    Detect privilege escalation attempts across Windows and Linux, including access token manipulation, UAC bypass, unquoted service path abuse, kernel exploits, and sudo/doas abuse.

    34k GitHub stars~922 tokensUpdated 1 mo ago
    SecurityAuto-check passed

  • Performing Network Packet Capture Analysis

    mukul975/Anthropic-Cybersecurity-Skills

    Perform forensic analysis of network packet captures (PCAP/PCAPNG) using Wireshark, tshark, and tcpdump to reconstruct network communications, extract transferred files, identify malicious traffic…

    34k GitHub stars~2.3k tokensUpdated 1 mo ago
    SecurityAuto-check passed

  • Analyzing Linux Audit Logs For Intrusion

    mukul975/Anthropic-Cybersecurity-Skills

    Uses the Linux Audit framework (auditd) with ausearch and aureport utilities to detect intrusion attempts, unauthorized access, privilege escalation, and suspicious system activity.

    34k GitHub stars~2.4k tokensUpdated 1 mo ago
    SecurityAuto-check: notes

More from LeoYeAI/openclaw-master-skills

All 1,235 skills in this repo

  • DevOps Pipeline Management

    LeoYeAI/openclaw-master-skills

    Manages pipelines on a DevOps quality and efficiency platform through its OpenAPI: list workspaces and templates, create, update, run and cancel pipelines, and read run records.

    2.2k GitHub stars~4.2k tokensUpdated 2 mo ago
    Auto-check: notes

  • Feishu Document Collaboration

    LeoYeAI/openclaw-master-skills

    Patches OpenClaw's Feishu extension so an edited document triggers an isolated agent session that reads the doc and replies inline, turning it into a live chat space.

    2.2k GitHub stars~2k tokensUpdated 2 mo ago
    Auto-check passed

  • Files Memory System

    LeoYeAI/openclaw-master-skills

    Multi-context memory management system for OpenClaw agents with group-isolated storage, global shared memory, workspace organization, and group-specific skills isolation.

    2.2k GitHub stars~3.8k tokensUpdated 2 mo ago
    Auto-check passed

  • GEO-Claw AI Visibility Agent

    LeoYeAI/openclaw-master-skills

    Runs a brand's AI-search visibility work end to end: diagnosing how AI platforms represent it, repositioning it, producing AI-optimized content and monitoring ongoing mentions.

    2.2k GitHub stars~4.7k tokensUpdated 2 mo ago
    Auto-check passed

  • Google Workspace CLI

    LeoYeAI/openclaw-master-skills

    Installs and authenticates the gws CLI, then automates Gmail, Drive, Sheets, Calendar, Docs, Chat and Tasks with ready-made recipes, persona bundles and security audits.

    2.2k GitHub stars~2.6k tokensUpdated 2 mo ago
    Auto-check: notes

  • HealthFit Health Advisors

    LeoYeAI/openclaw-master-skills

    Runs four advisor roles, a fitness coach, nutritionist, data analyst and TCM practitioner, to build a health profile and track workouts, diet and wellness over time.

    2.2k GitHub stars~4.4k tokensUpdated 2 mo ago
    Auto-check passed

Works with

Categories

Questions about Incident Response Network

What does Incident Response Network do?

Network forensics evidence collection and analysis during security incidents. Incident Response Network is an agent skill from LeoYeAI/openclaw-master-skills. Network forensics evidence collection and analysis during security incidents.

When should I use Incident Response Network?

Incident Response Network fits situations like: tasks that involve Incident response; tasks that involve Digital forensics; tasks that involve Network security.

How do I install Incident Response Network in Claude Code?

Run `npx skills add LeoYeAI/openclaw-master-skills --skill incident-response-network -a claude-code`. Or copy the skill folder (skills/incident-response-network in LeoYeAI/openclaw-master-skills) into .claude/skills/incident-response-network in your project. Claude Code loads it when a task matches its description.

How do I install Incident Response Network in Codex?

Run `npx skills add LeoYeAI/openclaw-master-skills --skill incident-response-network -a codex`. Or copy the skill folder (skills/incident-response-network in LeoYeAI/openclaw-master-skills) into .agents/skills/incident-response-network in your project. Codex loads it when a task matches its description.

Can I use Incident Response Network in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add LeoYeAI/openclaw-master-skills --skill incident-response-network -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/incident-response-network, .gemini/skills/incident-response-network, .github/skills/incident-response-network and .opencode/skills/incident-response-network in your project.

What does Incident Response Network need to run?

Going by SKILL.md and its folder, Incident Response Network needs the command-line tools its instructions call (bash).

Does Incident Response Network access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Incident Response Network safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Incident Response Network use?

Incident Response Network is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Incident Response Network use?

About 5k tokens (SKILL.md is roughly 20k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 4.9k tokens, read only when the agent opens those files.

What are the alternatives to Incident Response Network?

Skills that share tags, products or a category with Incident Response Network: Forensics Osquery (AgentSecOps/SecOpsAgentKit, 220 stars), Analyzing Network Traffic Of Malware (mukul975/Anthropic-Cybersecurity-Skills, 34k stars), Ir Velociraptor (AgentSecOps/SecOpsAgentKit, 220 stars) and Detecting Privilege Escalation Attempts (mukul975/Anthropic-Cybersecurity-Skills, 34k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Incident Response Network?

LeoYeAI (a GitHub user) maintains it in LeoYeAI/openclaw-master-skills, which has 2,161 GitHub stars. The repository holds 1,235 skills in this directory. The repository was last updated on July 20, 2026.

Source: LeoYeAI/openclaw-master-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.