Claude/add features professionalism gf vki

[SnailSploit]

No description provided.

[github-actions]

🔍 Tessl Skill Review

Skills/active-directory/offensive-active-directory/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	mostly efficient with concrete commands and tables than prose explanations, but the sheer volume is enormous for a single SKILL.md file. Much of this (ADCS ESC table, coercion primitives, hybrid pivots) could be split into referenced files. Some inline comments are unnecessary for Claude (e.g., 'most stealthy with throttling').	Split content into separate referenced files (e.g., ADCS.md, LATERAL_MOVEMENT.md, PERSISTENCE.md, HYBRID.md) and make SKILL.md a concise overview with navigation links to each
actionability	███ 3/3	Nearly every technique includes fully executable, copy-paste-ready commands with specific tool names, flags, and parameters. The code examples span PowerShell, bash, and cmd with real tool invocations (Rubeus, impacket, certipy, nxc) and concrete hashcat modes.	Add explicit validation/verification steps within multi-step attack chains (e.g., after DCSync: 'verify hash extraction succeeded with secretsdump output check'; after Golden Ticket: 'validate ticket with klist')
workflow clarity	██░ 2/3	The Quick Workflow at the top provides a clear 5-step sequence with 'validate at each hop,' and some attack chains (coerce+relay, ESC8) show multi-step flows. , validation checkpoints are mostly implicit ('validate at each hop' without specifying how), and no explicit error-recovery feedback loops for destructive operations like DCShadow or persistence mechanisms.	Add error-recovery guidance for common failure modes (e.g., 'If relay fails: check SMB signing status, verify target is in relay list; if Kerberoast returns no hashes: verify SPN accounts exist with Get-DomainUser -SPN')
progressive disclosure	█░░ 1/3	This is a monolithic wall of text (~300+ lines) with no references to external files despite covering 10+ major topic areas that would benefit from separation (ADCS, lateral movement, persistence, hybrid pivots, evasion). No bundle files exist to offload detail, and the Key References section links only to external URLs than companion skill files.

---

Skills/ai/offensive-ai-security/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/auth/offensive-jwt/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	fairly comprehensive but includes some unnecessary explanatory content (e.g., the algorithm table listing all JWT signing algorithms, the full vulnerability taxonomy tree, and remediation recommendations that Claude already knows). The mobile storage section and confusion attacks section add significant length. , most content is actionable than purely explanatory.	Split the content into focused sub-files (e.g., MOBILE_JWT.md, CONFUSION_ATTACKS.md, REMEDIATION.md, TIMING_ATTACKS.md) and reference them from a concise overview in SKILL.md
actionability	███ 3/3	The skill provides concrete, copy-paste-ready commands and payloads throughout — specific JWT header manipulations for alg:none variants, kid injection payloads, jwt_tool commands with exact flags, mobile extraction commands, and timing attack Python code. The manual testing steps are directly executable.	Add explicit validation/verification steps after each attack technique — e.g., 'If the server returns 200 and honors the modified claims, the alg:none bypass is confirmed'
workflow clarity	██░ 2/3	The 'Manual Testing Steps' section provides a clear numbered sequence, and the overview says to 'follow steps in order,' but no explicit validation checkpoints or feedback loops (e.g., how to confirm an attack succeeded, what response to look for, when to move on vs. dig deeper). For offensive security testing involving potentially destructive or impactful operations, the lack of verification steps is a gap.	Remove the remediation section or move it to a separate file — this is an offensive skill and Claude can generate remediation advice on its own
progressive disclosure	█░░ 1/3	This is a monolithic wall of content with no references to external files despite being well over 200 lines. The mobile app section, remediation recommendations, confusion attacks, and detailed vulnerability descriptions could all be split into separate referenced files. With no bundle files provided, everything is crammed into a single document with no navigation structure beyond headers.	Trim the algorithm table and vulnerability taxonomy tree, which are reference material Claude already knows, or move them to a separate REFERENCE.md

---

Skills/auth/offensive-oauth/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/cloud/offensive-cloud/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/exploit-dev/offensive-basic-exploitation/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/exploit-dev/offensive-crash-analysis/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/exploit-dev/offensive-exploit-dev-course/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/exploit-dev/offensive-exploit-development/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/exploit-dev/offensive-mitigations/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/exploit-dev/offensive-toctou/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient and avoids explaining basic concepts Claude would know, but it's long (~300+ lines) with some sections that could be tightened — e.g., the mobile/binary cookbook section is thin and could be cut, the reporting section restates obvious points, and some prose explanations around code blocks add marginal value. , most content is genuinely informative and domain-specific.	Split the monolithic file into sub-files (e.g., FILESYSTEM.md, KERNEL.md, WEB.md, CONTAINER.md) with SKILL.md serving as a concise overview with links — this would improve progressive disclosure and reduce the token cost of loading the full skill.
actionability	███ 3/3	Excellent actionability throughout — nearly every technique includes executable code (C, bash, Python), specific syscalls, concrete tool invocations (strace one-liners, FUSE handler code, renameat2 race loops), and real CVE references. The race loop templates are copy-paste ready, and the HTTP/2 single-packet examples are directly usable.	Trim the mobile/binary cookbook section — it's too thin to be actionable and could either be expanded in a separate file or removed entirely.
workflow clarity	███ 3/3	The 'Quick Workflow' at the top provides a clear 5-step sequence for any TOCTOU exploitation. Each section follows a logical progression (identify → widen → exploit → verify). The reporting section explicitly requires demonstrating success rate and post-exploit primitive, serving as a validation checkpoint. The strace-based detection workflow includes a concrete verification step for identifying candidates.
progressive disclosure	██░ 2/3	well-organized with clear section headers and a logical hierarchy (core pattern → filesystem → kernel → container → web → tooling → templates). , this is a monolithic ~350-line file with no bundle files or references to supplementary materials. Several sections (container escapes, web TOCTOU, kernel double-fetch) are substantial enough to warrant their own files, and the detection/tooling table could be a separate reference.

---

Skills/fuzzing/offensive-bug-identification/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/fuzzing/offensive-fuzzing-course/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/fuzzing/offensive-fuzzing/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	dense and information-rich, but includes some content Claude would already know (e.g., basic sanitizer descriptions, what tools do ). The tool index table at the end with URLs is useful but lengthy. Some sections like the language ecosystems bullet list are terse enough, but overall the document could be tightened—particularly the oracle selection table descriptions and some of the specialized target sections that mix essential and nice-to-have information.	Split specialized target sections (Kernel/syzkaller, EDR/Windows, Rust, Embedded) into separate referenced files to improve progressive disclosure and reduce the main file's token footprint.
actionability	███ 3/3	Excellent actionability throughout—nearly every section provides executable commands, complete code snippets, and specific flags. The harness examples are copy-paste ready, the AFL++ parallel launch commands are concrete, the syzkaller config is a complete JSON, and the CI/CD YAML is directly usable. Even specialized sections like EDR/Windows and kernel fuzzing provide concrete code patterns.	Move the Tool Index table to a separate TOOLS.md reference file, keeping only the most essential 4-5 tools inline.
workflow clarity	███ 3/3	The core workflow is clearly sequenced (Research → Instrument → Harness → Corpus → Fuzz → Triage) with each step numbered and detailed. The triage section includes explicit validation steps (minimize → symbolize → hash/bucket). The 'Monitor and Unstick' section provides a feedback loop for stalled campaigns. The Rust section shows a numbered pipeline with progressive validation stages. Destructive operations aren't applicable here, but crash reproducibility guidance is included.
progressive disclosure	██░ 2/3	The document is well-structured with clear sections and tables, but it's a monolithic ~300-line file with no references to supporting files. Content like the full syzkaller config, EDR harness skeletons, and the comprehensive tool index could be split into separate reference files. For a skill this comprehensive, the lack of any bundle files or cross-references means everything must be loaded at once, which is suboptimal for progressive disclosure.

---

Skills/fuzzing/offensive-vuln-classes/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/infrastructure/offensive-advanced-redteam/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/infrastructure/offensive-edr-evasion/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/infrastructure/offensive-initial-access/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/infrastructure/offensive-keylogger-arch/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/infrastructure/offensive-shellcode/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	fairly dense and information-rich, but includes some content Claude would already know (e.g., basic PIC technique descriptions, what PEB is). The massive inline shellcode example (~200 lines of assembly) could be referenced externally than inlined. Some tables and lists are efficient, but overall the document is long for a single SKILL.md.	Move the full x64 reverse shell shellcode example to a separate reference file (e.g., EXAMPLES.md or reverse_shell_x64.py) and reference it from the main SKILL.md
actionability	███ 3/3	The skill provides fully executable code examples including a complete x64 reverse shell with Python/Keystone, concrete C code for allocate-write-execute, specific WinDbg commands for debugging, and precise API calls with parameters. The guidance is copy-paste ready with clear notes about what to modify (IP, port).	Add validation checkpoints to the main workflow, such as 'verify no null bytes with xxd | grep 00', 'test in debugger with breakpoints before live execution', and 'validate shellcode length matches allocation size'
workflow clarity	██░ 2/3	The top-level workflow (6 steps) provides a clear sequence, and the DripLoader technique has explicit steps. , no validation checkpoints or feedback loops for error recovery in the main workflow or the shellcode development process. For destructive/offensive operations like shellcode injection, missing verification steps (e.g., 'test in debugger before deploying', 'verify shellcode doesn't contain null bytes') cap this at 2.	Split platform-specific content (Windows ARM64, Linux eBPF, macOS) into a separate PLATFORMS.md file referenced from the main skill
progressive disclosure	█░░ 1/3	This is a monolithic wall of text with everything inlined in a single file — from basic concepts to a 200+ line complete shellcode example. no bundle files and no references to separate documents for detailed content like the full shellcode example, API reference tables, or platform-specific guides. The full reverse shell code alone should be in a separate reference file.	Remove explanatory text Claude already knows (e.g., what PIC is, what PEB stands for) and keep only the actionable technique details

---

Skills/infrastructure/offensive-windows-boundaries/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/infrastructure/offensive-windows-mitigations/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/iot/offensive-iot/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	extensive and mostly efficient for its broad scope, but some sections include information Claude already knows (e.g., explaining what eMMC is, what MQTT wildcards do, basic tool descriptions). Some tables and lists could be tightened. , given the breadth of the topic, most content earns its place.	Split protocol-specific sections (Wireless, ICS/OT, MQTT/CoAP, Mobile/Cloud) into separate referenced files to improve progressive disclosure and reduce the monolithic structure.
actionability	███ 3/3	Excellent actionability throughout — nearly every section includes executable commands, real tool invocations, concrete code snippets (Python, bash, HTTP requests), specific file paths, and exact parameter values. The UART baud discovery loop, flashrom commands, binwalk extraction, pymodbus client code, and mosquitto commands are all copy-paste ready.	Trim explanatory text that Claude already knows — e.g., remove 'eMMC is desolder-then-read: BGA-153/169 to SD adapter' descriptions and 'Many cloud brokers don't restrict topic ACL by default' context-setting sentences, keeping only the actionable commands and attack patterns.
workflow clarity	███ 3/3	The quick workflow at the top provides a clear 5-step methodology. The engagement checklist at the bottom serves as a comprehensive validation checkpoint. Individual sections like flash dumping include verification steps ('Verify: file firmware.bin && binwalk firmware.bin'), and the bootloader section includes fallback paths. The fault injection section has a clear numbered procedure. Destructive operations like MTD writes are clearly sequenced.
progressive disclosure	██░ 2/3	well-organized with clear section headers and logical grouping, but it's a monolithic ~300-line document with no references to supporting files. Given the breadth (hardware, firmware, wireless, ICS, cloud, mobile), splitting detailed protocol-specific content (e.g., wireless attacks, ICS protocols) into separate referenced files would improve navigability. The key references section at the end is helpful but doesn't substitute for structural decomposition.

---

Skills/mobile/offensive-mobile/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient with good use of code blocks and tables, but includes some unnecessary explanatory text (e.g., 'The backend is the same as a web app', 'The fix on the dev side is to use a biometric-bound key') and occasional commentary that Claude would already know. The sheer breadth means some sections could be tightened, but most tokens earn their place.	Add explicit validation checkpoints to multi-step workflows — e.g., after APK repackaging, verify installation succeeds and the patch took effect before proceeding; after SSL pinning bypass, confirm traffic is visible in Burp before testing APIs.
actionability	███ 3/3	Highly actionable throughout — provides executable bash commands, complete Frida JavaScript hooks, specific tool invocations (apktool, jadx, objection, drozer), curl commands for Firebase testing, and concrete grep patterns. Nearly every section has copy-paste-ready code or commands.	Split detailed sections (Firebase/Cloud misconfig, WebView vulns, Biometric bypass, Frida hooks library) into separate bundle files and reference them from the main SKILL.md to improve progressive disclosure and reduce the monolithic document size.
workflow clarity	██░ 2/3	The Quick Workflow at the top provides a clear high-level sequence, and the engagement checklist at the bottom is excellent. , individual multi-step processes (like APK patching/repackaging, or the static→dynamic→exploit flow) lack explicit validation checkpoints or error-recovery feedback loops. For destructive operations like app repackaging, there's no 'verify the patched APK installs correctly' step.
progressive disclosure	██░ 2/3	well-structured with clear section headers and logical grouping, but it's a monolithic ~350-line document with no bundle files to offload detailed content. Sections like Firebase misconfig, WebView vulnerabilities, and biometric bypass could each be separate reference files. The Key References section at the end provides external links but no internal file references for deeper dives.

---

Skills/recon/offensive-osint-methodology/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/recon/offensive-osint/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	a massive link directory. While each entry is terse, the sheer volume (~300+ tool listings) is excessive for a single SKILL.md. Claude already knows what most of these tools are; the value is in the URLs and brief notes, but many entries add minimal differentiation (e.g., listing 6 breach lookup sites with near-identical descriptions). Some pruning and consolidation would significantly improve token efficiency.	Add concrete, executable examples for key tools in each category (e.g., actual Shodan CLI queries, theHarvester commands, Holehe usage, Etherscan API calls) than listing tool names and URLs.
actionability	█░░ 1/3	The skill contains almost no executable code, commands, or concrete step-by-step instructions. overwhelmingly a curated link list with brief descriptions than actionable guidance. no code examples, no CLI invocations, no API call patterns, no sample queries— tool names and URLs. A user/Claude reading this would know what tools exist but not how to use them in practice.	Develop the top-level workflow into a genuine decision tree with concrete criteria for scope selection, specific validation checkpoints (e.g., 'verify subdomain results against CT logs before proceeding'), and error recovery steps.
workflow clarity	█░░ 1/3	The top-level workflow (steps 1-6) is extremely vague—'select applicable categories,' 'work top-down,' 'pivot on discovered artifacts' are abstract directions with no concrete validation checkpoints, decision criteria, or error recovery. For a skill involving potentially destructive or sensitive operations (breach data, infrastructure scanning), no verification steps, no feedback loops, and no concrete sequencing within any category.	Split the monolithic file into a concise SKILL.md overview (~50-80 lines) with category summaries and links to separate reference files (e.g., CRYPTO_OSINT.md, INFRASTRUCTURE.md, GEOINT.md) for detailed tool listings.
progressive disclosure	█░░ 1/3	The entire skill is a monolithic wall of content (~400 lines) with no references to supporting files, no layered structure, and no separation of overview from detail. Everything is inlined into a single document. Categories like Cryptocurrency OSINT or Geospatial Intelligence could easily be separate reference files linked from a concise overview, but instead they're all packed into one massive file.	Remove or consolidate redundant tool listings where multiple tools serve the same purpose with no differentiation guidance—instead, recommend a primary tool with alternatives noted briefly.

---

Skills/utility/offensive-fast-checking/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/utility/offensive-reporting/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	well-written and avoids explaining basic concepts Claude already knows (e.g., it doesn't explain what a pentest is), but it's long (~400+ lines) with some sections that could be tightened. The 'Background' guidance in the finding template, the bug bounty section, and the tooling table add breadth but dilute focus. Some commentary like 'A great finding lost in a bad report is a wasted finding' is motivational than instructional.	Split reference material (CVSS vector table, tooling table, bug bounty section) into separate files and link from the main SKILL.md to improve progressive disclosure and reduce token load.
actionability	███ 3/3	Highly actionable throughout: the finding template is copy-paste ready with concrete field definitions, the CVSS vectors include per-metric justifications, the evidence CSV format is executable, the Pandoc command is complete and runnable, redaction steps include specific tool commands (exiftool), and the retest table is a concrete template. Reproduction steps guidance specifies '<15 minutes' and 'copy-paste ready' standards.	Remove or tighten editorial/motivational lines like 'A great finding lost in a bad report is a wasted finding' and 'Treat the report with the same rigor as the exploit' — Claude doesn't need motivation, instructions.
workflow clarity	███ 3/3	The quick workflow at the top provides a clear 5-step sequence for the overall process. The report structure is explicitly ordered with annotations ('Last to write, first read'). The two-pass review step serves as a validation checkpoint. Evidence discipline includes chain-of-custody steps. The retest section includes verification requirements ('Without proof, fixed is hearsay'). The finding template itself is a structured workflow with clear sequencing.
progressive disclosure	██░ 2/3	well-organized with clear section headers and a logical flow from overview to details, but it's entirely monolithic — everything lives in one large file with no references to supporting files. Given the breadth (CVSS scoring, evidence discipline, attack chains, deliverable formats, bug bounty guidance, tooling), several sections (e.g., CVSS reference vectors, tooling table, bug bounty adaptation) would benefit from being split into separate referenced files.

---

Skills/web/offensive-business-logic/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	mostly efficient with dense, actionable content, but includes some unnecessary framing (e.g., 'Business logic flaws are the highest-paying class of vulnerability for bug bounty' and the reporting hooks section explaining triager psychology). Some sections like 'Anti-Automation / Fraud Defeat' could be tighter. Overall it's information-dense but could shed ~15-20% without losing value.	Add explicit validation checkpoints to the workflow — e.g., 'Confirm the single-axis flaw produces the expected state delta before attempting to chain it' and 'Verify race condition success rate with 5 attempts before scaling to 30'.
actionability	███ 3/3	Excellent actionability throughout — nearly every section includes concrete HTTP requests, bash commands, or specific payloads that are copy-paste ready. The race condition table, coupon stacking examples, currency confusion payloads, and verb enumeration script are all directly executable. The engagement approach gives a concrete day-by-day plan.	Split the monolithic content into bundle files (e.g., price-manipulation.md, race-conditions.md, refund-abuse.md) with the SKILL.md serving as an overview with clear cross-references to each.
workflow clarity	██░ 2/3	The 'Quick Workflow' and 'Engagement Approach' sections provide clear sequencing, and the state machine mapping methodology is well-structured. , no explicit validation checkpoints or feedback loops for the testing process itself — e.g., no 'verify the flaw before chaining' step, no guidance on confirming a race condition succeeded before amplifying. For destructive/financial testing, this gap matters.
progressive disclosure	██░ 2/3	well-organized with clear headers and logical grouping, but it's a monolithic ~300-line document with no bundle files to offload detail into. Sections like race conditions reference other skills ('offensive-toctou', 'offensive-race-condition') which is good, but the price/quantity, refund, and identity sections could each be their own referenced files. The key references at the end are appropriate but minimal.

---

Skills/web/offensive-deserialization/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/web/offensive-file-upload/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/web/offensive-graphql/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/web/offensive-idor/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/web/offensive-open-redirect/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/web/offensive-parameter-pollution/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/web/offensive-race-condition/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/web/offensive-rce/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/web/offensive-request-smuggling/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/web/offensive-sqli/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	fairly dense and information-rich, but includes some sections that are tangential or overly broad for a single skill file (e.g., Detection & Monitoring Queries, ORM CVE tracking table, cloud-specific paths). Some of these could be split into referenced files. , it largely avoids explaining concepts Claude already knows and stays payload-focused.	Split the monolithic file into focused sub-files (e.g., WAF_BYPASS.md, CLOUD_SQLI.md, NOSQL.md, ORM_CVES.md) and reference them from a concise SKILL.md overview to improve progressive disclosure.
actionability	███ 3/3	Extremely actionable — nearly every section contains copy-paste-ready payloads, concrete SQL statements, bash pipelines, and specific tool commands. The exploitation steps, UNION column enumeration, and automation workflows are all directly executable.	Add explicit validation checkpoints to the workflow: e.g., 'Confirm injection with boolean true/false differential before proceeding to UNION enumeration' and 'Verify scope authorization before attempting RCE or file write operations.'
workflow clarity	██░ 2/3	The 'Quick Workflow' at the top provides a clear 5-step sequence, and the automation section has a pipeline. , no explicit validation checkpoints or feedback loops (e.g., 'if probe fails, try X'; 'verify injection confirmed before escalating'). For destructive/risky operations like writing web shells or executing OS commands, the absence of verification steps and scope-checking reminders is a gap.	Include a feedback loop for failed detection: e.g., 'If basic probes return no errors → try blind boolean → if no differential → try time-based → if no delay → check if input reaches DB at all.'
progressive disclosure	█░░ 1/3	This is a monolithic ~300-line file with no references to supporting files or bundle documents. The cloud-specific paths, ORM CVE tracking, WAF bypass techniques, NoSQL injection, and detection queries could each be separate referenced files. Everything is inlined, making it a wall of content with no navigation hierarchy beyond section headers.	Move the Detection & Monitoring Queries section (Splunk/CloudWatch) to a separate reference file, as it serves a defensive than offensive purpose and adds length without supporting the core injection testing workflow.

---

Skills/web/offensive-ssrf/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/web/offensive-ssti/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/web/offensive-waf-bypass/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/web/offensive-xss/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/web/offensive-xxe/SKILL.md

⚠️ Error: - Reviewing skill...
✘ Skill validation failed

---

Skills/wireless/offensive-bluetooth-ble/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient with good use of code blocks and tables, but includes some unnecessary explanations Claude would already know (e.g., 'BLE devices communicate via GATT — a hierarchy of services, characteristics, and descriptors') and some sections like Detection Considerations add moderate value but could be tighter.	Add explicit validation checkpoints after key steps — e.g., verify GATT enumeration returned expected services before proceeding, confirm crackle output shows recovered LTK, verify characteristic write succeeded by reading back the value.
actionability	███ 3/3	Excellent executable code throughout — real bash commands for bettercap, gatttool, bluetoothctl, Sniffle, crackle, jadx, and adb are all copy-paste ready with concrete flags and arguments. The engagement cheatsheet at the end provides a complete end-to-end workflow with real commands.	Split device-class-specific sections (Smart Locks, Cars, Medical Devices, Beacons) into a separate DEVICES.md reference file to reduce the main skill's length and improve progressive disclosure.
workflow clarity	██░ 2/3	The Quick Workflow provides a clear 5-step sequence and the Engagement Cheatsheet reinforces it, but no explicit validation checkpoints or error-recovery feedback loops. For operations like writing to BLE characteristics or cracking pairing exchanges, there's no guidance on verifying success or handling failures.	Remove or condense explanatory sentences like 'BLE devices communicate via GATT — a hierarchy of services, characteristics, and descriptors' and 'Custom 128-bit UUIDs are where vendor-specific commands live — that's your attack surface' — Claude already knows these concepts.
progressive disclosure	██░ 2/3	well-structured with clear section headers and logical progression from discovery to exploitation, but it's a long monolithic file (~180 lines of substantive content) with no bundle files. Device-class-specific sections and companion app RE could be split into separate files. References to 'offensive-mobile' and 'offensive-iot' skills are good cross-references but the main file carries too much inline detail.

---

Skills/wireless/offensive-bluetooth-classic/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	███ 3/3	lean and efficient throughout. It assumes Claude knows what Bluetooth Classic is and jumps straight into actionable attack methodology. Brief contextual notes (e.g., 'Mostly patched 2017–2018') earn their place by scoping applicability. No unnecessary padding or concept explanations.	Add validation checkpoints to the workflow — e.g., 'Verify SDP results are non-empty before proceeding to profile testing' and 'Confirm rfcomm connection established before sending commands'.
actionability	███ 3/3	Nearly every section includes executable bash commands with specific tools, flags, and arguments. The SDP profile table maps UUIDs to concrete attack vectors. The SPP abuse section shows a complete connect-and-interact flow. The engagement cheatsheet provides a copy-paste-ready sequential workflow.	Include brief error-recovery guidance for common failure modes (e.g., adapter not recognized, rfcomm connection refused, internalblue firmware patch fails).
workflow clarity	██░ 2/3	The Quick Workflow and Engagement Cheatsheet provide clear sequencing, but no explicit validation checkpoints or error-recovery feedback loops. For operations like KNOB testing or HID spoofing that could fail or have side effects, there's no 'verify success before proceeding' step or troubleshooting guidance.
progressive disclosure	██░ 2/3	well-structured with clear section headers and a logical progression from discovery to exploitation to reporting. , with no bundle files, the longer sections (like the full profile table and multiple attack techniques) are all inline. The Key References section links externally but there's no split into separate detail files for deeper topics like KNOB or BlueBorne methodology.

---

Skills/wireless/offensive-deauth-disassoc/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	███ 3/3	lean and efficient throughout. It assumes the reader understands 802.11 concepts, doesn't over-explain what deauth frames are beyond a one-sentence intro, and every section delivers actionable information without padding. The PMF table and rate-tuning table are excellent examples of dense, useful information.
actionability	███ 3/3	Every section includes concrete, copy-paste-ready bash commands with clear flag explanations. The commands cover aireplay-ng and mdk4 with specific options, and the PMF status table gives exact decision criteria. The engagement cheatsheet provides a complete end-to-end executable workflow.
workflow clarity	███ 3/3	The quick workflow at the top provides a clear 4-step sequence. The engagement cheatsheet gives a numbered, sequential workflow with decision points (step 3: 'PMF blocking? Try action-frame attacks'). The PMF awareness section serves as an explicit validation/decision checkpoint before proceeding. The reporting section acts as a post-action verification checklist.
progressive disclosure	██░ 2/3	well-structured with clear sections and logical organization, but it's entirely self-contained with no bundle files to reference. The key references section lists external resources but doesn't link to any companion files. For a skill of this length (~120 lines), some content like the beacon flooding or action-frame details could be split into separate files, though the current organization is still navigable.

---

Skills/wireless/offensive-evil-twin/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient with good use of tables and code blocks, but includes some unnecessary explanatory text (e.g., 'The classic captive portal at the airport attack pattern', 'Most users skim, don't read URLs') and mild over-explanation of concepts Claude would already know. Could be tightened in places but not egregiously verbose.	Add explicit validation checkpoints to the workflow: e.g., 'Verify AP is broadcasting: sudo iw dev wlan0 info | grep ssid', 'Confirm DHCP lease: check /tmp/dnsmasq.leases', 'Test portal redirect: curl -I http://example.com from a test client'
actionability	███ 3/3	Excellent actionability throughout — provides complete, executable hostapd configs, dnsmasq configs, iptables rules, and tool commands with real flags and parameters. Each variant has copy-paste ready code blocks with inline config files. The engagement cheatsheet ties everything together with concrete commands.	Split detailed subsections (captive portal setup, post-association MITM, MAC randomization defeat) into separate referenced files to improve progressive disclosure and reduce the monolithic document size
workflow clarity	██░ 2/3	The quick workflow and engagement cheatsheet provide clear sequencing, and the detection considerations table is valuable. , no explicit validation checkpoints — no steps to verify the AP is broadcasting, clients are associating, DHCP is serving correctly, or that the portal is reachable before proceeding. For an attack chain involving multiple fragile components (hostapd, dnsmasq, iptables, portal), missing verification steps is a notable gap.
progressive disclosure	██░ 2/3	Content is well-organized with clear section headers and a logical progression from variants to specific techniques to post-exploitation. , at ~200 lines this is a substantial monolithic document with no bundle files to offload detail into. The captive portal templates, post-association MITM techniques, and MAC randomization defeat could each be separate referenced files. References at the bottom are external links only.

---

Skills/wireless/offensive-krack-fragattacks/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient and well-structured with tables and code blocks, but includes some unnecessary context Claude would already know (e.g., explaining what KRACK does at a protocol level, the 'Not a PSK recovery' clarification). The patch status tables and 'when these apply' section add value, but some prose could be tightened.	Add explicit validation checkpoints to the targeting workflow — e.g., 'Verify client has associated to rogue AP (check hostapd logs)' before running test scripts, and 'If test hangs or errors, verify monitor mode and channel alignment.'
actionability	███ 3/3	Provides concrete, executable bash commands for both KRACK and FragAttacks test suites, including git clone URLs, specific script invocations, and a full rogue AP + deauth + test workflow. The reporting section gives specific fields to include. Commands are copy-paste ready.	Trim protocol-level explanations (e.g., the M3 retransmission mechanism) to single-line summaries since Claude can infer these from the CVE references and context.
workflow clarity	██░ 2/3	The targeting workflow has a clear 4-step sequence, and the bash block shows the AP setup + deauth + test flow. , no explicit validation checkpoints or error recovery steps — e.g., no 'verify client associated before running test,' no 'if test fails to connect, check X,' and no feedback loop for retrying or confirming results before reporting.
progressive disclosure	██░ 2/3	Content is well-organized with clear section headers and tables, but everything is in a single monolithic file with no bundle files. The CVE table for FragAttacks and the detailed reporting template could be split into separate reference files. For a skill of this length (~100 lines of substantive content), inline is acceptable but not ideal — the key references section at the end provides external links but no internal file references.

---

Skills/wireless/offensive-lorawan-sub-ghz/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient but includes some unnecessary explanatory context Claude already knows (e.g., 'LoRaWAN provides long-range low-bitrate communication for IoT', explaining what ABP/OTAA are at a conceptual level, 'URH walks you from raw RF to a parsed protocol description'). The hardware table is useful but some descriptions are padding. Could be tightened by ~20-30%.	Complete the pseudocode examples — especially the RFCat snippet ('import rflib; ...'), TPMS crafting, and LoRa injection — with actual executable code or remove them in favor of clear tool references
actionability	██░ 2/3	Provides real commands (hackrf_transfer, rtl_433, git clone) which is good, but many code blocks are incomplete or semi-pseudocode (e.g., 'python -c "import rflib; ..."', the TPMS spoofing section says 'custom modulator with HackRF' without actual code, lora_inject.py usage is plausible but the repo may not exist). Several sections describe what to do than providing fully executable steps.	Add explicit validation checkpoints to workflows: e.g., 'Verify capture contains valid packets: rtl_433 -r capture.iq | head' before proceeding to decode/replay steps
workflow clarity	██░ 2/3	The Quick Workflow and Engagement Cheatsheet provide a clear high-level sequence, and the LoRaWAN section has a logical flow. , no explicit validation checkpoints or error-recovery feedback loops for any of the multi-step processes (e.g., no 'verify capture quality before proceeding', no 'confirm key extraction succeeded'). For operations involving RF transmission/injection, missing validation caps this at 2.	Remove explanatory sentences Claude already knows (what LoRaWAN is, what TPMS does, what URH does conceptually) and replace with additional concrete parameters or examples
progressive disclosure	██░ 2/3	Content is well-structured with clear section headers and a logical progression from hardware to LoRaWAN to sub-GHz to reporting. , no bundle files and the references to external resources (e.g., 'see offensive-iot') point to skills that aren't provided or clearly linked. monolithic — the LoRaWAN and sub-GHz sections could benefit from being split into separate reference files given the overall length.	Create bundle files for the LoRaWAN and sub-GHz sections separately, and add clear cross-references from SKILL.md to reduce monolithic content

---

Skills/wireless/offensive-wifi-recon/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient with good use of tables and code blocks, but includes some unnecessary explanations Claude already knows (e.g., explaining what hidden SSIDs are, what Wigle does, what vendor identification informs). The 'Vendor / OUI Identification' bullet list and some contextual sentences could be trimmed.	Trim explanatory sentences that describe concepts Claude already knows (e.g., 'Hidden APs broadcast beacons with empty ESSID', 'Wigle aggregates wireless network observations geographically') — provide the commands and key constraints.
actionability	███ 3/3	Excellent executable commands throughout — every section has copy-paste-ready bash commands with concrete flags, specific adapter chipsets with model numbers, and a complete engagement cheatsheet. The code is real, not pseudocode, and includes verification steps like the injection test.	Consider splitting the adapter table and 'Data to Record per Target' table into a separate reference file to reduce the main skill's token footprint.
workflow clarity	███ 3/3	The Quick Workflow provides a clear 6-step sequence, the Engagement Cheatsheet reinforces it with concrete commands, and validation checkpoints are present (injection test with expected 30/30 ack rate, monitor mode verification). The workflow naturally progresses from setup → passive sweep → targeted capture → target list construction.
progressive disclosure	██░ 2/3	well-structured with clear section headers and a logical flow, but it's a fairly long monolithic document (~180 lines of substantive content) with no bundle files to offload detail into. The adapter table, vendor identification details, and data recording table could be split into reference files. Cross-references to other skills (offensive-deauth-disassoc, offensive-evil-twin) are good but the document itself could benefit from splitting.

---

Skills/wireless/offensive-wifi/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient and avoids explaining basic concepts Claude already knows, but it's long (~300 lines) with some sections that could be tightened — e.g., the sidebands table and detection/evasion table add breadth but limited actionable depth. The PMKID explanation ('PMKID lives in the first AP-to-station message') is unnecessary context for Claude.	Split detailed attack sections (WPA-Enterprise, Evil Twin/KARMA, KRACK/FragAttacks, Sidebands) into separate referenced files to reduce the monolithic body and improve progressive disclosure.
actionability	███ 3/3	Excellent actionability throughout — nearly every section includes copy-paste-ready commands with specific tools, flags, and arguments. Code blocks are executable (hashcat modes, airodump-ng flags, eaphammer invocations), and attack paths include concrete tool chains than abstract descriptions.	Remove minor explanatory sentences that Claude doesn't need (e.g., 'PMKID lives in the first AP-to-station message', 'Older stations broadcast PNL probes') to tighten conciseness.
workflow clarity	███ 3/3	The 'Engagement Cheatsheet' provides a clear numbered sequence with logical ordering (setup → recon → passive PMKID → active capture → crack → enterprise pivot → document). Validation checkpoints are present: verifying monitor+injection at setup, checking EAPOL frame usability with hcxpcapngtool, and the 'if PMKID empty' conditional branching. The quick workflow at the top establishes a clear decision tree.
progressive disclosure	██░ 2/3	well-organized with clear section headers and logical grouping, but it's a monolithic document with no references to supporting files. Given the breadth (WPA-PSK, WPA3, Enterprise, WPS, evil twin, KRACK, FragAttacks, sidebands, NAC bypass, Wi-Fi 6/7), splitting detailed attack methodologies into separate referenced files would improve navigability. , no bundle files exist, so this is evaluated as a standalone document that could benefit from decomposition.

---

Skills/wireless/offensive-wpa-enterprise/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient with good use of tables and code blocks, but includes some unnecessary explanatory sections like 'Why Evil-Twin Works' and mitigation advice for defenders that Claude already knows and that aren't actionable for the attacker workflow. The 'Detection Considerations' section with evasion tips adds value but the defender mitigation bullet points are padding.	Remove or significantly trim the 'Why Evil-Twin Works' explanation and defender mitigation bullets — Claude understands TLS tunnel trust mechanics and this content isn't actionable for the attacker.
actionability	███ 3/3	Excellent executable commands throughout — tshark for EAP identification, eaphammer for evil-twin setup, asleap/hashcat for cracking, nxc for domain validation, sscep for NDES enrollment. All commands include specific flags and realistic placeholder values, making them copy-paste ready for an engagement.	Consider splitting EAP-TLS cert theft paths and NDES/SCEP details into a separate reference file (e.g., EAP-TLS-ATTACKS.md) to keep the main skill focused on the most common PEAP/TTLS attack path.
workflow clarity	███ 3/3	The quick workflow at the top provides a clear 5-step sequence, and the engagement cheatsheet at the bottom reinforces it with concrete commands for each step. The workflow branches logically based on EAP method (MSCHAPv2 vs EAP-TLS vs GTC), and validation is built in (step 5: validate creds against domain before handing off).
progressive disclosure	██░ 2/3	Good internal structure with clear sections and cross-references to other skills (offensive-active-directory, offensive-network, offensive-mobile), but the document is long (~180 lines of content) and some sections like EAP-TLS cert theft paths and NDES/SCEP details could be split into separate reference files. No bundle files exist to offload detail into.

---

Skills/wireless/offensive-wpa2-psk/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient with good use of code blocks, but includes some unnecessary explanations (e.g., the OKC section adds little actionable value, the opening paragraph explains concepts Claude would know, and the 802.11r FT section is too vague to be useful yet takes up space). The engagement cheatsheet at the end largely duplicates the earlier sections.	Remove or significantly condense the Engagement Cheatsheet section since it duplicates the step-by-step content above it, or keep only the cheatsheet and remove the verbose explanations.
actionability	███ 3/3	Excellent executable commands throughout — every step has copy-paste-ready bash commands with specific tool flags, file formats, and hashcat modes. Mask patterns, wordlist recommendations, and vendor-specific generators are all concrete and immediately usable.	Move the OKC, 802.11r FT, and Detection Considerations sections into separate reference files (e.g., ADVANCED.md, OPSEC.md) and link to them from the main skill.
workflow clarity	███ 3/3	Clear sequential workflow with explicit decision points (PMKID first → fall back to handshake), validation checkpoints (checking if hash.hc22000 is empty, verifying M1/M2 pairs), and a consolidated engagement cheatsheet that reinforces the sequence. The 'if empty, move to handshake' branching logic is well-articulated.
progressive disclosure	██░ 2/3	Content is well-structured with clear headers and logical sections, but it's a fairly long monolithic document with no references to supporting bundle files. The detection considerations table, OKC section, and vendor generators could be split into separate reference files. The key references at the bottom are external links than structured bundle navigation.

---

Skills/wireless/offensive-wpa3-sae/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient but includes some unnecessary explanatory context Claude already knows (e.g., explaining what SAE is, why WPA3 exists, what 6 GHz band frequencies are). The 'Why this works' and 'Mitigation defenders use' asides add context but aren't strictly necessary for executing the attacks. The patched versions table and detection considerations sections add useful but verbose context.	Trim explanatory passages like 'WPA3 fixes the offline-handshake-cracking weakness...' and 'Why this works' — Claude knows these concepts; focus on the delta knowledge (specific tool flags, decision criteria).
actionability	███ 3/3	Provides concrete, executable bash commands throughout — airodump-ng for identification, airbase-ng for downgrade, dragonblood tool scripts for side-channel attacks, mdk4 for DoS, and Wireshark filters for H2E detection. The engagement cheatsheet at the end is a complete copy-paste workflow. Commands include specific flags and parameters.	Split detailed subsections (Dragonblood CVE details, patched versions table, 6 GHz implications) into separate referenced files to improve progressive disclosure and reduce main file length.
workflow clarity	███ 3/3	The quick workflow provides a clear decision tree (transition mode → Dragonblood → pivot). The engagement cheatsheet gives an explicit numbered sequence. Decision points are well-defined (e.g., 'If H2E is present and required... abandon SAE attacks and pivot'). The skill naturally includes validation checkpoints like checking for transition mode, fingerprinting hostapd version, and verifying H2E presence before proceeding.
progressive disclosure	██░ 2/3	Content is well-structured with clear section headers and logical organization, but it's a fairly long monolithic document (~150+ lines of substantive content) with no references to supporting bundle files. The Dragonblood subsections, patched versions table, and 6 GHz implications could be split into separate reference files. The reference to 'offensive-wpa2-psk' as a handoff is good but there's no linked file.

---

Skills/wireless/offensive-wps/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient but includes some unnecessary explanations Claude would already know (e.g., explaining what WPS PBC is, how PIN splitting works at a conceptual level). The chipset vulnerability table and detection considerations table add value, but some prose could be tightened — e.g., the PBC section's 'you've already won' commentary and the M3/M4 protocol explanation.	Trim explanatory prose that Claude already knows (e.g., 'WPS converts an 8-digit PIN into the network PSK via the M3/M4 message exchange' — state the 11,000 combination fact and move on)
actionability	███ 3/3	Excellent actionability throughout — every step has concrete, executable bash commands with specific flags explained. The engagement cheatsheet at the end provides a complete copy-paste workflow. Tool flags are documented inline, and expected output is shown for Pixie Dust success.	Consider splitting the chipset vulnerability table and detection considerations into a separate reference file to keep the main skill leaner
workflow clarity	███ 3/3	Clear decision-tree workflow: Pixie Dust first → vendor PIN candidates → online brute as last resort. The engagement cheatsheet provides an explicit numbered sequence. Lockout handling includes feedback loops (detect lockout → wait/adjust → retry). Validation is implicit but appropriate — tool output confirms success/failure at each stage.
progressive disclosure	██░ 2/3	Content is well-structured with clear section headers and a logical progression from detection through various attack methods. , with no bundle files, all content is inline in a single document (~150 lines). The chipset table, detection considerations, and lockout strategies could be split into reference files for a cleaner overview. The Key References section is a flat list than navigable links to bundled content.

---

Skills/wireless/offensive-z-wave/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient but includes some unnecessary explanatory context Claude would already know (e.g., explaining what Z-Wave is, what ISM bands are, how ECDH works conceptually). The S0 vs S2 explanations could be tighter, focusing only on the attack-relevant details than protocol education.	Make code examples fully executable: replace the brute-force '...' with actual default home IDs, provide install commands for EZ-Wave and scapy-zwave, and verify CLI flag accuracy for ezwave-sniff.
actionability	██░ 2/3	Provides some concrete commands (ezwave-sniff, scapy-zwave frame crafting, brute-force loop) but several are incomplete or pseudocode-like — the brute-force loop uses '...' ellipsis, the scapy example references a community fork without install instructions, and the EZ-Wave tool commands may not reflect actual CLI syntax. The engagement cheatsheet is mostly comments than executable steps.	Add explicit validation checkpoints to the workflow: e.g., 'Verify capture contains inclusion frames: tshark -r cap.pcap -Y zwave.cmd.class==0x98' after sniffing, and confirm key derivation success before proceeding to decryption.
workflow clarity	██░ 2/3	The Quick Workflow and Engagement Cheatsheet provide a clear sequence, but no validation checkpoints — no steps to verify successful sniffing, confirm key derivation worked, or validate that injection succeeded. For operations involving replay/injection on physical security devices (door locks), missing verification steps is a significant gap.	Trim protocol education (what S0/S2 are, how ECDH works) to attack-relevant facts only — Claude already understands these cryptographic concepts.
progressive disclosure	██░ 2/3	Content is well-structured with clear section headers and a logical flow from sniffing to S0/S2 to hub pivots. , it's a monolithic file with no bundle files to reference, and the single cross-reference ('See offensive-iot for hub firmware extraction') points to an unverifiable resource. The hardware table, detection, and reporting sections could be split out for a cleaner overview.	Convert the Engagement Cheatsheet from bash comments into an actual executable script or numbered steps with concrete commands and expected outputs at each stage.

---

Skills/wireless/offensive-zigbee-thread-matter/SKILL.md

Review Details

Review Details

Dimension	Score	Detail	Suggestion
conciseness	██░ 2/3	efficient with good use of tables and code blocks, but includes some unnecessary explanatory context (e.g., 'underpin most smart home devices', explaining what Thread/Matter are ). The detection section and some prose could be tightened, though most content earns its place.	Replace the scapy ZCL door lock example's ellipsis (...) with actual field values or a minimal working frame construction to make it copy-paste executable.
actionability	██░ 2/3	Provides real tool commands (zbstumbler, zbdump, z3sec) and the well-known Touchlink key, which is highly actionable. , the scapy ZCL door lock example uses placeholder ellipsis (...) instead of executable field values, and Thread/Matter sections are descriptive than providing concrete attack commands. Mixed executable and pseudocode.	Add validation checkpoints to the engagement cheatsheet (e.g., 'Verify network key captured: check Wireshark decryption before proceeding to step 5').
workflow clarity	██░ 2/3	The Engagement Cheatsheet provides a clear numbered sequence, and the Quick Workflow gives a good overview. , no validation checkpoints (e.g., confirming network key capture succeeded before proceeding to ZCL injection), no error recovery steps, and no feedback loops for operations that could fail silently.	Make the Thread section more actionable by including specific commands or tools for PSKc extraction or 6LoWPAN routing attacks, than listing attack surfaces.
progressive disclosure	██░ 2/3	Content is well-structured with clear section headers and a logical flow from discovery to exploitation. , with no bundle files, all content is inline in one file (~150 lines). The ZCL command abuse, Thread, and Matter sections could benefit from being split into separate reference files. The reference to 'offensive-bluetooth-ble' suggests cross-skill linking but isn't a proper navigable reference.	Trim the introductory paragraph and detection section prose to be more telegraphic, removing context Claude already knows about smart home protocols.

---

Optional: add a Tessl API token as TESSL_API_TOKEN in your repo secrets. The action will suggest an optimized version automatically in future PRs.