respond-malware
Respond to a malware incident following PICERL methodology. Use when malware is detected on endpoints. Orchestrates triage, containment, eradication, and recovery. Works with triage-malware skill for analysis.
69
62%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/respond-malware/SKILL.mdQuality
Discovery
75%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description is well-structured with explicit 'what' and 'when' clauses and good distinctiveness from related skills. Its main weaknesses are moderate specificity (phases are named but concrete actions within each phase are absent) and limited trigger term coverage that misses common synonyms users might naturally use like 'virus', 'ransomware', or 'compromised'.
Suggestions
Add more natural trigger terms users would say, such as 'virus', 'ransomware', 'infected machine', 'compromised endpoint', or 'security incident'.
List more concrete actions within each phase, e.g., 'isolate affected hosts, collect forensic artifacts, remove malicious files, restore systems from clean backups'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (malware incident response) and mentions specific phases (triage, containment, eradication, recovery) and the PICERL methodology, but doesn't list granular concrete actions like 'isolate infected hosts', 'collect forensic artifacts', or 'restore from backup'. | 2 / 3 |
Completeness | Clearly answers both 'what' (respond to malware incidents following PICERL, orchestrating triage/containment/eradication/recovery) and 'when' ('Use when malware is detected on endpoints'). Also notes its relationship to the triage-malware skill. | 3 / 3 |
Trigger Term Quality | Includes relevant terms like 'malware', 'incident', 'endpoints', 'containment', 'eradication', and 'recovery', but misses common user-facing variations like 'virus', 'infected', 'ransomware', 'compromised host', 'security incident', or 'breach'. | 2 / 3 |
Distinctiveness Conflict Risk | The description carves out a clear niche around malware incident response specifically, references the PICERL methodology, and even distinguishes itself from the related 'triage-malware' skill by noting it orchestrates the broader workflow rather than just analysis. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a competent incident response workflow that provides clear phase sequencing and useful slash-command references, but falls short on actionability in the eradication and recovery phases where steps are abstract rather than executable. The workflow would benefit from explicit validation gates between phases (especially eradication→recovery) and better progressive disclosure by moving detailed phase content into linked files.
Suggestions
Add explicit validation gates between phases—e.g., a mandatory scan verification step with specific tool calls before transitioning from eradication to recovery, rather than just a warning in the Critical Warnings section.
Make eradication and recovery steps more actionable by specifying actual EDR tool commands or API calls instead of generic placeholders like '*(Requires EDR/endpoint tools)*'.
Consider splitting detailed phase instructions into separate files (e.g., CONTAINMENT.md, ERADICATION.md) and keeping SKILL.md as a concise overview with the quick reference table and links to phase details.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably structured but includes some redundancy—the outputs tables at the top partially duplicate information found in the phase descriptions. The quick reference table at the end also restates what's already covered. However, it avoids explaining basic concepts Claude would know. | 2 / 3 |
Actionability | The skill provides concrete slash-commands and some API calls, but many steps are vague placeholders like '*(Requires EDR/endpoint tools)*' and 'Execute removal plan' without specifying actual tool calls or commands. Eradication and recovery phases lack executable specifics. | 2 / 3 |
Workflow Clarity | The PICERL phases are clearly sequenced with numbered steps, and containment includes a verification step (Step 3.4). However, eradication lacks explicit validation checkpoints—there's no feedback loop for confirming persistence removal succeeded before moving to recovery. The 'DO NOT restore without verifying eradication' warning exists but isn't embedded as a gate in the workflow itself. | 2 / 3 |
Progressive Disclosure | The skill references other skills via slash-commands (/triage-malware, /enrich-ioc, /respond-compromised-account) which is good progressive disclosure. However, the content is quite long (~180 lines) and could benefit from splitting detailed phase instructions into separate files, with the main SKILL.md serving as an overview with links. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- dandye/ai-runbooks
- Commit
086cbf6
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.