Detect kernel-level rootkits in Linux memory dumps using Volatility3 linux plugins (check_syscall, lsmod, hidden_modules), rkhunter system scanning, and /proc vs /sys discrepancy analysis to identify hooked syscalls, hidden kernel modules, and tampered system structures.
55
45%
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/analyzing-linux-kernel-rootkits/SKILL.mdQuality
Discovery
82%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, highly specific description that clearly names concrete tools (Volatility3, rkhunter), specific techniques (/proc vs /sys discrepancy analysis), and target artifacts (hooked syscalls, hidden kernel modules). Its main weakness is the absence of an explicit 'Use when...' clause, which would help Claude know exactly when to select this skill over others.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks about rootkit detection, kernel forensics, suspicious kernel modules, or analyzing Linux memory dumps for compromise indicators.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: detecting kernel-level rootkits, checking hooked syscalls, hidden kernel modules, tampered system structures, using named tools (Volatility3 linux plugins with specific plugin names, rkhunter, /proc vs /sys discrepancy analysis). | 3 / 3 |
Completeness | The 'what' is thoroughly covered with specific tools and techniques, but there is no explicit 'Use when...' clause or equivalent trigger guidance. The when is only implied by the nature of the described actions, which per the rubric caps completeness at 2. | 2 / 3 |
Trigger Term Quality | Excellent coverage of natural terms a user would use: 'rootkit', 'kernel', 'memory dump', 'Volatility3', 'syscall', 'hidden modules', 'rkhunter', '/proc', '/sys', 'lsmod', 'Linux'. These are precisely the terms a security analyst would mention when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive niche: kernel-level rootkit detection in Linux memory dumps using specific forensic tools. This is unlikely to conflict with other skills due to its very specialized domain and named tools. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
7%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads more like a high-level overview or blog post than actionable guidance for Claude. The steps are abstract descriptions without executable commands, the example output references a non-existent script, and significant token budget is wasted on explaining concepts Claude already knows and displaying an overly verbose example. The skill needs a complete rewrite focused on concrete, executable Volatility3 commands with actual flags, real cross-view analysis scripts, and validation checkpoints.
Suggestions
Replace vague step descriptions with actual executable commands, e.g., `python3 vol.py -f /evidence/linux-mem.lime linux.check_syscall.Check_syscall` with expected output snippets for each plugin.
Remove the Overview paragraph explaining what kernel rootkits are and the generic 'When to Use' section — Claude already knows these concepts.
Add validation checkpoints: verify ISF symbol table matches kernel version before analysis, verify memory dump integrity, cross-validate findings between multiple detection methods before concluding.
Replace the fictional rootkit_analyzer.py example with real Volatility3 command outputs and a concrete Python/bash script for the cross-view /proc vs /sys analysis.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The overview explains what kernel rootkits are and how they work at ring 0 — concepts Claude already knows. The 'When to Use' section is generic boilerplate that adds no value. The example output is extremely verbose (60+ lines) when a compact example would suffice. Much of the content is padding rather than actionable instruction. | 1 / 3 |
Actionability | The steps are vague descriptions rather than executable commands. 'Run linux.check_syscall, linux.lsmod...' doesn't show actual command-line invocations with flags and arguments. There's no executable code for the cross-view analysis, no actual rkhunter commands, and the example references a fictional 'rootkit_analyzer.py' script that doesn't exist. Nothing is copy-paste ready. | 1 / 3 |
Workflow Clarity | The four steps are high-level descriptions without specific commands, validation checkpoints, or error recovery. There's no guidance on what to do if symbol tables don't match, if memory acquisition fails, or how to verify findings. For a multi-step forensic process involving destructive/sensitive operations, the complete absence of validation steps is a critical gap. | 1 / 3 |
Progressive Disclosure | The content has some structural organization with clear section headers (Overview, Prerequisites, Steps, Expected Output, Example Output), but it's somewhat monolithic — the massive example output is inline rather than referenced. There are no references to supplementary files for detailed plugin usage, symbol table setup, or advanced analysis techniques. | 2 / 3 |
Total | 5 / 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 | |
888bbe4
Table of Contents
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.