# Report Writer

> Use when writing up a security vulnerability finding for a bug bounty program (HackerOne, Bugcrowd, Intigriti) or a disclosure — turns raw notes about a bug into a structured, triage-ready report with proper impact framing. Symptoms: "how do I write this up", "draft a report", "submit this finding", messy repro notes that need formatting.

- **Type:** Skill
- **Install:** `agentstack add skill-amansingh909-claude-bounty-skills-report-writer`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [amansingh909](https://agentstack.voostack.com/s/amansingh909)
- **Installs:** 0
- **Category:** [Security](https://agentstack.voostack.com/c/security)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [amansingh909](https://github.com/amansingh909)
- **Source:** https://github.com/amansingh909/claude-bounty-skills/tree/master/skills/report-writer

## Install

```sh
agentstack add skill-amansingh909-claude-bounty-skills-report-writer
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# report-writer

## Overview

Turn a hunter's raw finding — the bug, what they did, what happened — into a
clean, triage-ready vulnerability report. Triagers skim fast and reject reports
that are vague, missing repro steps, or that overstate impact. A well-structured
report with realistic, clearly-argued impact gets triaged faster and rated
higher.

**Core principle:** A report's job is to let a triager reproduce the bug and
understand its impact in under two minutes, without asking follow-up questions.

## When to Use

- The user has found a bug and needs to submit it to a program.
- The user has messy notes ("I changed the id param and got another user's
  data") that need to become a real report.
- The user asks to "write up", "draft", or "format" a finding.

**When NOT to use:** for triaging/prioritizing recon output (that's
`recon-triage`), or for deciding whether a target is in scope (that's
`scope-check`).

## Required Inputs — Ask If Missing

Do not fabricate any of these. If the user hasn't provided one, ask for it
before writing the report:

1. **Vulnerability type** (e.g. IDOR, reflected XSS, SSRF, broken access control)
2. **Affected asset** — exact URL/endpoint/parameter, and which program
3. **Reproduction steps** — the actual sequence performed
4. **Observed result** — what proved the bug (the response, the data leaked)
5. **Impact** — what a malicious actor could actually do with this

If impact is unclear, help the user reason about it from the vulnerability type
and affected asset — but never invent capabilities that the evidence does not
support. Overstated impact gets reports rejected.

## Report Structure

Produce the report in this order. Use the full template in
[report-template.md](report-template.md) for the exact section layout and a
worked IDOR example.

1. **Title** — ` on  allows `. Specific, not "XSS found".
2. **Summary** — 2–3 sentences: what the bug is, where, and why it matters.
3. **Steps to Reproduce** — numbered, copy-pasteable, starting from a clean
   state. Include exact requests (method, path, headers, body) where relevant.
4. **Proof of Concept** — the request/response or payload that demonstrates it.
   Redact real victim data; use the hunter's own second account instead.
5. **Impact** — concrete, realistic consequences. Tie to CVSS if the program
   uses it, but explain in plain terms first.
6. **Classification** — the CWE ID (e.g. CWE-639 for IDOR) plus the program's
   own taxonomy: a HackerOne weakness, a Bugcrowd VRT category, or an Intigriti
   type. Not every program uses CVSS — if it uses Bugcrowd's VRT or a custom
   rating, map to that instead of forcing a CVSS vector.
7. **Remediation** — the standard fix for this class of bug, specific to what
   was seen.

## Severity Guidance

Suggest a severity, but frame it as a suggestion and justify it:

| Signal | Pushes severity up | Pushes severity down |
|--------|--------------------|--------------------|
| Data accessed | PII, credentials, financial | Public/non-sensitive data |
| Auth required | None (unauthenticated) | Admin/privileged only |
| Scope of impact | Any user, mass exploitable | Self-only, single record |
| Preconditions | None | User interaction, rare config |

State the reasoning ("unauthenticated access to other users' PII → High/Critical")
so the triager can agree or adjust, rather than asserting a number.

## Common Mistakes

- **Overclaiming impact.** "Full account takeover" when you only read one
  non-sensitive field. Triagers downgrade and lose trust. Claim exactly what the
  evidence shows.
- **Vague repro.** "Change the id and you get other data." Give the exact
  request and the exact response field that proves it.
- **Real victim data in the PoC.** Use two accounts you control. Never include
  another real user's data.
- **No clean starting state.** Steps that assume prior setup the triager doesn't
  have. Start from login/fresh.
- **Missing the "so what".** A bug with no articulated impact reads as a
  non-issue. Always connect the technical fact to a real-world consequence.

## Continuity (session log)

If a local engagement log for this program exists (`notes/.md` in your
working directory — gitignored, one file per program), read it first for prior
findings and context, then append the finished report (or a note of where you
saved it). Only read a log that's actually present — never invent past findings.

## Ethics

Only write reports for testing the user is authorized to do — an active program
they are enrolled in, or a target they own. If the finding describes testing
that appears out of scope or unauthorized, say so and stop.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [amansingh909](https://github.com/amansingh909)
- **Source:** [amansingh909/claude-bounty-skills](https://github.com/amansingh909/claude-bounty-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-amansingh909-claude-bounty-skills-report-writer
- Seller: https://agentstack.voostack.com/s/amansingh909
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.