respond-ransomware

Respond to a ransomware incident following PICERL methodology. Use when ransomware is detected or suspected. Orchestrates identification, containment, eradication, and recovery phases. Requires CASE_ID and initial indicators.

Quality

76%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

Securityby

Advisory

Suggest reviewing before use

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/respond-ransomware/SKILL.md

Quality

Discovery

89%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This is a strong skill description that clearly identifies its domain (ransomware incident response), specifies the methodology (PICERL), includes explicit trigger conditions ('when ransomware is detected or suspected'), and states input requirements. The main weakness is that the specific actions within each phase could be more concrete — it names phases rather than listing discrete actions like 'isolate affected systems, identify encryption variants, restore from backups'.

Suggestions

Add more concrete action examples within the phases, e.g., 'isolate affected hosts, identify ransomware variant, restore from clean backups, generate forensic timeline' to improve specificity.

Dimension	Reasoning	Score
Specificity	Names the domain (ransomware incident response) and references the PICERL methodology phases (identification, containment, eradication, recovery), but doesn't list specific concrete actions beyond naming the phases. It's more of a framework reference than a list of discrete capabilities.	2 / 3
Completeness	Clearly answers both 'what' (respond to ransomware incident following PICERL methodology, orchestrates identification/containment/eradication/recovery) and 'when' (use when ransomware is detected or suspected). Also specifies requirements (CASE_ID and initial indicators).	3 / 3
Trigger Term Quality	Includes strong natural trigger terms: 'ransomware', 'incident', 'detected', 'suspected', 'containment', 'eradication', 'recovery', 'PICERL', and 'CASE_ID'. These are terms a user dealing with a ransomware situation would naturally use.	3 / 3
Distinctiveness Conflict Risk	Highly distinctive — 'ransomware incident' combined with 'PICERL methodology' and specific phase names creates a very clear niche that is unlikely to conflict with other security or general incident response skills.	3 / 3
	Total	11 / 12 Passed

Implementation

62%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This is a solid incident response playbook with clear phase sequencing and good use of confirmation gates for destructive actions. Its main weaknesses are incomplete actionability in the eradication/recovery phases where guidance becomes vague, and the monolithic structure that could benefit from splitting detailed tool-specific procedures into referenced files. The workflow clarity is the strongest dimension, with explicit validation steps and prioritization guidance.

Suggestions

Add concrete tool invocations for endpoint isolation in Step 3.1 (e.g., specific EDR API calls) rather than deferring to 'via EDR or network'

Split detailed eradication and recovery procedures into separate referenced files (e.g., ERADICATION.md, RECOVERY.md) to improve progressive disclosure and allow more detailed guidance without bloating the main skill

Condense the Required Outputs tables into a more compact format—these could be a simple bulleted list per phase since the descriptions are self-evident

Dimension	Reasoning	Score
Conciseness	The skill is reasonably efficient but includes some unnecessary structure like the detailed output tables that could be more compact, and the Preparation phase is thin enough to be a bullet point rather than a full section. The tables for required outputs add bulk without proportional value.	2 / 3
Actionability	Provides concrete tool calls (gti-mcp, secops-mcp, secops-soar) and specific slash commands, but several critical steps are vague—eradication says 'requires EDR/endpoint tools' without specifics, recovery defers to IT Ops without concrete commands, and containment isolation lacks actual tool invocations for the isolation itself.	2 / 3
Workflow Clarity	The PICERL phases are clearly sequenced with explicit validation checkpoints (Step 3.4 verify containment, Step 5.3 verify backup integrity), confirmation gates via /confirm-action before destructive operations, and a clear feedback loop of contain→verify→proceed. The critical warning about not delaying containment reinforces the workflow priorities.	3 / 3
Progressive Disclosure	The content is well-structured with clear sections and a quick reference table, but it's entirely monolithic—everything is in one file with no references to external detailed guides. The eradication and recovery phases could benefit from linking to separate detailed playbooks rather than providing incomplete inline guidance.	2 / 3
	Total	9 / 12 Passed

Validation

90%

Warnings & errors only

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: 13 days ago

Table of Contents

Discovery Implementation Validation

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.