CTF Write-up Generator
Generate a standardized submission-style CTF writeup for a solved challenge.
Default behavior:
- - During an active competition, optimize for speed, clarity, and reproducibility
- Keep writeups short enough that a teammate or organizer can validate the solve quickly
- Always produce a
submission-style writeup - Prefer one complete solve script from challenge data to final flag
Workflow
Step 1: Gather Information
Collect the following from the current session, challenge files, and user input:
- 1. Challenge metadata — name, CTF event, category, difficulty, points, flag format
- Solution artifacts — exploit scripts, payloads, screenshots, command output
- Timeline — key steps taken, dead ends, pivots
CODEBLOCK0
Step 2: Generate Write-up
Write the writeup file as writeup.md (or writeup-<challenge-name>.md) using the submission template below.
Templates
Submission Format
CODEBLOCK1
Guidance:
- - Prefer 1-3 short steps total
- Keep code to the smallest complete solving script
- Do not split "recover secret", "derive key", and "decrypt flag" into separate partial snippets
- The script should start from the challenge data and end by printing the flag
- Avoid long background sections
- Avoid dead ends unless they explain a key pivot
- Avoid multiple alternative solves; pick one clean path
- Redact the flag only if the user explicitly asks for redaction
Best Practices Checklist
Before finalizing the writeup, verify:
- - [ ] Metadata complete — title, CTF, date, category, difficulty, points, author all filled
- [ ] Flag handling matches request — keep the real flag unless the user asked for redaction
- [ ] Reproducible steps — a reader can follow your writeup and reproduce the solution
- [ ] Code is runnable — exploit scripts include all imports, correct variable names, and comments
- [ ] No sensitive data — no real credentials, API keys, or private infrastructure details
- [ ] Length stays concise — the writeup is short enough for fast review
- [ ] Tools and versions noted — mention specific tool versions if behavior depends on them
- [ ] Proper attribution — credit teammates, referenced writeups, or tools that were essential
- [ ] Grammar and formatting — consistent heading levels, code blocks have language tags
Quality Guidelines
DO:
- - Explain just enough for fast verification
- Include one complete solving path, not multiple alternative routes
- Include one complete script that goes all the way to the final flag
- Show actual output (truncated if very long) to prove the approach worked
- Tag code blocks with language (
python, bash, sql, etc.) - Keep the main path front-loaded so a reader can validate it quickly
DON'T:
- - Copy-paste raw terminal dumps without explanation
- Paste several partial snippets that force the reader to reconstruct the final solve
- Leave placeholder text in the final writeup
- Include irrelevant tangents that don't contribute to the solution
- Assume the reader knows the specific challenge setup
Challenge
$ARGUMENTS
CTF Write-up 生成器
为已解决的挑战生成标准化的提交式 CTF 解题报告。
默认行为:
- - 在活跃比赛期间,优先考虑速度、清晰度和可复现性
- 保持解题报告足够简短,以便队友或组织者能够快速验证解决方案
- 始终生成 submission 风格的解题报告
- 优先提供一个从挑战数据到最终 flag 的完整解题脚本
工作流程
步骤 1:收集信息
从当前会话、挑战文件和用户输入中收集以下内容:
- 1. 挑战元数据 — 名称、CTF 赛事、类别、难度、分值、flag 格式
- 解题产物 — 利用脚本、payload、截图、命令输出
- 时间线 — 关键步骤、死胡同、转折点
bash
扫描利用脚本和产物
find . -name
.py -o -name .sh -o -name exploit
-o -name solve | head -20
检查输出文件中的 flag
grep -rniE (flag|ctf|eno|htb|pico)\{ . 2>/dev/null
步骤 2:生成解题报告
使用以下提交模板将解题报告写入 writeup.md(或 writeup-<挑战名称>.md)文件。
模板
提交格式
markdown
title: <挑战名称>
ctf:
date: YYYY-MM-DD
category: web|pwn|crypto|reverse|forensics|osint|malware|misc
difficulty: easy|medium|hard
points: <分值>
flag_format: flag{...}
author: <你的名字或团队>
<挑战名称>
摘要
<1-2 句话:描述挑战内容及核心技术。保持简洁直接。>
解决方案
步骤 1:<操作>
<用 3-8 行简短说明关键发现。保持直接。>
\\\python
<一个完整的解题脚本,从提供的挑战数据到打印最终 flag>
\\\
步骤 2:<操作>(可选)
<仅在第二个简短步骤确实有助于提高可读性时添加,例如将核心发现与最终验证分开。>
步骤 3:<操作>(可选)
<仅在挑战确实需要时使用。保持总步骤数较少。>
Flag
\\\
flag{示例flag在此}
\\\
指导原则:
- - 优先使用 1-3 个简短步骤
- 保持代码为最小的完整解题脚本
- 不要将恢复密钥、推导密钥和解密 flag拆分为多个独立的代码片段
- 脚本应从挑战数据开始,以打印 flag 结束
- 避免冗长的背景说明
- 除非需要解释关键转折点,否则避免提及死胡同
- 避免提供多种替代解法;选择一条清晰的路径
- 仅在用户明确要求时才对 flag 进行脱敏处理
最佳实践检查清单
在最终确定解题报告前,请确认:
- - [ ] 元数据完整 — 标题、CTF、日期、类别、难度、分值、作者均已填写
- [ ] flag 处理符合要求 — 除非用户要求脱敏,否则保留真实 flag
- [ ] 步骤可复现 — 读者可以按照你的解题报告复现解决方案
- [ ] 代码可运行 — 利用脚本包含所有导入、正确的变量名和注释
- [ ] 无敏感数据 — 没有真实的凭证、API 密钥或私有基础设施细节
- [ ] 保持简洁 — 解题报告足够简短,便于快速审阅
- [ ] 注明工具和版本 — 如果行为依赖于特定版本,请注明工具版本
- [ ] 适当注明来源 — 对团队成员、引用的解题报告或关键工具给予适当致谢
- [ ] 语法和格式正确 — 标题层级一致,代码块带有语言标签
质量指南
应做:
- - 仅提供足够快速验证的解释
- 包含一条完整的解题路径,而非多条替代路线
- 包含一个完整的脚本,能够一路运行到最终 flag
- 展示实际输出(如果很长可截断)以证明方法有效
- 为代码块添加语言标签(python、bash、sql 等)
- 将主要路径放在前面,以便读者快速验证
不应做:
- - 不加解释地复制粘贴原始终端输出
- 粘贴多个零散的代码片段,迫使读者自行拼凑最终解法
- 在最终解题报告中留下占位文本
- 包含与解决方案无关的题外话
- 假设读者了解特定的挑战设置
挑战
$ARGUMENTS