Generate structured technical documentation from security analysis

Generates technical write-ups from work that is already finished, writing the file into the user's own project directory (not the skill's package directory) rather than printing it inline. It triggers after a reverse-engineering task has produced a core conclusion (algorithm recovery, signature crack, bypass method), after a penetration test has found and verified a vulnerability, after a CTF challenge is solved and the flag captured, or whenever the user asks directly for a report, document, or writeup. It picks a template by task type: a reverse-engineering report for APK/binary/.so analysis, a penetration-test report, a CTF writeup, or a signature-reversal report for JS/web signature work - all drawn from a shared security-report-template reference - or, for general software documentation, a README or API-documentation template instead.

For security reports specifically, it applies a vendor-report-rules reference that governs structure only, never wording lifted from a real vendor report: a malware flavor (overview, infection flow, sample analysis, incident response, IOCs, in the style of a consumer AV vendor writeup) for a confirmed malicious sample, trojan, or phishing payload; an apt flavor (executive summary, infection chain, investigation narrative, interesting findings, technical analysis, detection/mitigation, IOCs, in the style of a threat-intel vendor's research post) for an APT campaign, actor group, or multi-stage infection chain; and flavor = null - the default - for ordinary APK/ELF/PE/Mach-O reverse engineering, algorithm or firmware analysis, penetration testing, CTF, or JS signature work, which uses the plain task template with no malware/APT-specific sections forced in. An optional thin vuln overlay (overview, impact/reproduction, crash-and-patch analysis, mitigation advice) layers on top of flavor = null only when the user explicitly asks for vulnerability, patch, or CVE-style technical analysis - it is never a third default full template. Every report must carry an Evidence-to-Finding-to-Path chain so each conclusion traces back to what was actually observed, must give reproduction steps a third party could follow independently, must replace any real token, password, or internal URL with a placeholder, and must contain no placeholder text or unresolved TODOs. Where it helps, it calls a companion diagram-generator skill to embed a Mermaid diagram appropriate to the report type - a function-call graph or data-flow diagram for reverse-engineering, an attack-path or network-topology diagram for pentesting, a solution-flow diagram for a CTF writeup, or a request-sequence/algorithm-flow diagram for signature reversal.

For general documentation it applies four core principles instead: progressive disclosure (one-sentence description, then a quick-start snippet, then the full API reference, then an architecture deep dive, with warnings and breaking changes always at the top); task-oriented section titles ("Authenticating Users", not "AuthService Class"); a concrete example for every concept; and formatting standards (sentence-case headings, at most three heading levels, a specified language on every code block, relative links, and a table for any structured data with three or more attributes).

Use it once an analysis is actually finished and needs turning into a structured, shareable report, or to standardize write-ups across multiple cases - triggered automatically as the last step after a companion analysis skill (APK reverse engineering, binary/IDA analysis, radare2 CLI analysis, generic reverse engineering, or JS signature reversal) completes, or manually whenever the user says "write a report"/"writeup"/"generate docs". Its own limitations note that report quality is bounded by the evidence actually captured during the analysis itself, and that its templates assume a technical audience - an executive summary needs separate tailoring.

Input is the completed analysis's findings, evidence, and case context (case scope.md/timeline.md files when a companion case-init script produced them). Output is a single Markdown file named YYYY-MM-DD_[type]-[target]-report.md, written in UTF-8 into the project's docs/ directory when one exists, in the same natural language as the user's conversation (Chinese conversation produces a Chinese report, English produces English), with an embedded Mermaid diagram code block when one applies. For general documentation it instead follows README, API-endpoint, or file-system-organization templates with fully worked code and table examples.

Calls a companion diagram-generator skill to render Mermaid flowcharts and sequence diagrams directly inside the generated report so they render natively on GitHub/GitLab, and is designed as the automatic final step after sibling analysis skills such as APK reverse engineering, IDA-based binary analysis, radare2 CLI analysis, generic reverse engineering, or JS signature reversal. Is purely a text-generation skill with no external tool dependency of its own.

Security researchers, reverse engineers, and pentesters who need a consistent, evidence-backed report out of finished analysis work, and developers who want README or API documentation written to a task-oriented, progressive-disclosure standard. Community-sourced from zhaoxuya520/reverse-skill under the MIT license, added 2026-08-25.