How do I install the Reporting Pentest Report skill?

Run npx skillmds@latest add noorqureshi/reporting-pentest-report in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Reporting Pentest Report safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Reporting Pentest Report?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Reporting Pentest Report free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Reporting Pentest Report?

NoorQureshi (@noorqureshi) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Reporting Pentest Report by noorqureshi

Name: Reporting Pentest Report
Author: NoorQureshi

Reporting Pentest Report

Structure a professional penetration-test report (engagement deliverable, not a single bug). Load at the end of a pentest, on "write the pentest report", "executive summary", "deliverable", or compiling findings for a client. Signals: engagement wrap-up, multiple findings, client report.

NoorQureshi Updated Sep 17, 2026

File contents

Penetration-test report

When it governs

End of a pentest engagement, when findings become a client deliverable. Different from a bug-bounty report (reporting-bug-bounty-writeup): this is the whole engagement — executive narrative plus detailed findings — read by both executives and engineers.

Structure

Executive summary — non-technical: what was tested, overall risk posture, the 3–5 things that matter, and business impact. One page. No jargon.
Scope & methodology — assets/IPs/apps in scope, dates, testing type (black/grey/white), standards followed (PTES/OWASP WSTG/NIST), and limitations.
Findings — one per issue, ordered by risk. Each: title, severity (CVSS vector + rating), affected assets, description, reproduction steps (exact requests/commands), evidence (screenshots/output), impact (business terms), remediation (specific fix), references.
Risk ratings — a consistent method (CVSS + likelihood/impact matrix); explain it.
Remediation roadmap — prioritized, with quick wins vs strategic fixes; owners/timelines if known.
Appendices — full tool output, methodology detail, out-of-scope notes, retest results.

Quality bar

Reproducible: an engineer can follow each finding from a clean state.
Two audiences: executives read the summary; engineers read the findings — serve both.
Actionable remediation: name the specific fix (parameterize the query, enforce object-level authz), not "sanitize input" (see defense-hardening-baseline).
Evidence hygiene: redact secrets/PII; store raw evidence securely; keep the client's data confidential.

Gotchas

Severity must reflect demonstrated impact in context, not the theoretical max.
Don't bury the critical findings under low-severity noise — lead with what matters.
Deliver the report over a secure channel; it's a map of how to break the client.

References

PTES; OWASP WSTG; NIST SP 800-115; FIRST CVSS 3.1.

---name: reporting-pentest-reportdescription: Structure a professional penetration-test report (engagement deliverable, not a single bug). Load at the end of a pentest, on "write the pentest report", "executive summary", "deliverable", or compiling findings for a client. Signals: engagement wrap-up, multiple findings, client report.---# Penetration-test report## When it governsEnd of a pentest engagement, when findings become a client deliverable. Different from abug-bounty report (`reporting-bug-bounty-writeup`): this is the whole engagement — executivenarrative plus detailed findings — read by both executives and engineers.## Structure1. **Executive summary** — non-technical: what was tested, overall risk posture, the 3–5 things that matter, and business impact. One page. No jargon.2. **Scope & methodology** — assets/IPs/apps in scope, dates, testing type (black/grey/white), standards followed (PTES/OWASP WSTG/NIST), and limitations.3. **Findings** — one per issue, ordered by risk. Each: title, severity (CVSS vector + rating), affected assets, description, **reproduction steps** (exact requests/commands), **evidence** (screenshots/output), **impact** (business terms), **remediation** (specific fix), references.4. **Risk ratings** — a consistent method (CVSS + likelihood/impact matrix); explain it.5. **Remediation roadmap** — prioritized, with quick wins vs strategic fixes; owners/timelines if known.6. **Appendices** — full tool output, methodology detail, out-of-scope notes, retest results.## Quality bar- **Reproducible**: an engineer can follow each finding from a clean state.- **Two audiences**: executives read the summary; engineers read the findings — serve both.- **Actionable remediation**: name the specific fix (parameterize the query, enforce object-level authz), not "sanitize input" (see `defense-hardening-baseline`).- **Evidence hygiene**: redact secrets/PII; store raw evidence securely; keep the client's data confidential.## Gotchas- Severity must reflect *demonstrated* impact in context, not the theoretical max.- Don't bury the critical findings under low-severity noise — lead with what matters.- Deliver the report over a secure channel; it's a map of how to break the client.## ReferencesPTES; OWASP WSTG; NIST SP 800-115; FIRST CVSS 3.1.

Frequently asked questions