report-to-blog

Prompt file imported from anuraagbaishya/blog (.claude/commands/report-to-blog.md). Copyright stays with the author.

Convert a responsible disclosure report into a blog post for this Hugo site.

Usage

The user will provide:

1. A path to the responsible disclosure report (required)
2. A post name slug for the URL, e.g. cve-2025-12345 (required)

If either is missing, ask the user before proceeding.

Instructions

Step 1 — Read the report

Read the full report file at the path the user provided. Understand every technical detail: the vulnerability class, affected component, root cause, attack flow, proof of concept, fix, and any timeline information. Do not invent or extrapolate facts not present in the report.

Step 2 — Read existing posts to internalise the voice

Read ALL of the following posts in full before writing anything:

• content/posts/nicegui-xss.md
• content/posts/cve-2024-47821.md
• content/posts/cve-2025-30161.md
• content/posts/pyload-cves.md

Pay close attention to:

• Tone: first-person, conversational, occasionally self-deprecating and humorous (references to laziness, jumping between ideas, incomplete projects). Not formal or stiff. The self-deprecation is always directed at the author, never at the developers of the affected software. The existing posts never mock, belittle, or editorially judge the quality of a developer's code choices. Describe bugs factually and analytically; any amusement or surprise is expressed from the author's own perspective of discovery, not as a verdict on developer competence.
• Structure: opening paragraph summarises the vuln and links to the CVE/advisory → background/context of how the author found it → technical deep-dive with code snippets → attack flow (sometimes ASCII diagram) → PoC → additional findings if any → fix → conclusion → timeline.
• Code blocks: always syntax-highlighted, language specified. Command output uses plain code blocks.
• Links: CVE NVD page, GitHub advisory, affected code lines, fix PR — all linked inline.
• Timeline: always a bulleted list at the very end, each entry Date: Event.
• Tags: lowercase, from the set python, php, javascript, cve-analysis, development, security etc. — pick only what applies.
• No fabrication: every claim, payload, code snippet, link, date, and CVE number must come directly from the report.

Step 3 — Create the Hugo post file

Run:

hugo new content/posts/<post-name>.md

This will create the file with default frontmatter.

Step 4 — Write the blog post

Rewrite the frontmatter and body of the newly created file. Follow these rules:

Frontmatter (YAML, not TOML):

---
title: "<concise title matching the CVE/vuln — model on existing post titles>"
date: <keep the date generated by hugo new>
draft: false
toc: true
images:
tags:
  - <relevant tags>
---

Body rules:

• Open with a crisp paragraph: what the software is, what the vulnerability is, its CVE/advisory links, affected versions, fixed version. This mirrors the opening of existing posts.
• Use the same narrative voice as the existing posts — write as if the author is telling the story of how they found it.
• Include all technical details from the report: vulnerable code, root cause, attack flow, payloads/PoC.
• Use code blocks with correct syntax highlighting for all code and payloads.
• If the report includes an attack flow or data flow, represent it clearly — use an ASCII diagram if it helps clarity (see nicegui-xss.md for an example).
• Include a "Fix" section describing how the issue was resolved (only if the report contains this information).
• End with a "Timeline" section as a bulleted list.
• Do not add sections, claims, CVE numbers, links, scores, or any information that is not present in the report.
• Do not add closing pleasantries like "Thank you for reading" unless the report or its context clearly warrants it.
• Match sentence length, paragraph rhythm, and vocabulary density to the existing posts.

Step 5 — Write the file

Use the Edit tool to replace the generated file's contents with the completed blog post.

Step 6 — Voice check

Re-read the draft alongside the existing posts and critically evaluate whether the voice is convincing. Ask yourself:

• Does it read like a person telling a story, or like a report being reformatted?
• Is there a human reaction to the code — surprise, amusement, frustration — where the findings warrant it?
• Are there conversational asides, self-aware observations, or personality visible between the technical paragraphs?
• Does the opening pull the reader in, or does it just list facts?
• Would a reader who enjoyed cve-2024-47821.md or nicegui-xss.md feel at home reading this?
• Is any language condescending toward the software's developers? (It should not be — the existing posts never mock developers, and sometimes explicitly praise them.)

If the answer to any of these is "no" or "not really", rewrite the post — or the failing sections — until it passes. Do not settle for technically accurate but lifeless prose. The goal is for the post to be indistinguishable in voice from the existing ones.

Step 7 — Confirm

Tell the user the file path of the new post and give a brief one-sentence summary of what was written.