[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FASEKEDF5SVEPFK260WWGH":3,"skill-same:01M6FASEKEDF5SVEPFK260WWGH":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":27,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":36,"commitSha":63,"skillDirectory":64,"forksCount":65,"repositoryHtmlUrl":66,"repositoryHomepageUrl":6,"ownerHtmlUrl":67,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":68,"install":69,"resources":82},"01M6FASEKEDF5SVEPFK260WWGH","redteam-report-template",null,"Client-facing red-team deliverable format","boisenoise\u002Fskills-collections","boisenoise","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F193180?v=4","01M6CDBDQK6BDN55ZMA6B6PKBM","01M6CDBDVSJ3JPTBYN26FZ7TZK",12,"MIT","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-redteam-report-template\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"RedTeam","report","redteam report template","template","process","2026","blob","upstream","main","community","guidance","tooling","engagement","only","safe","format","team","Enterprise","red-team","https","license","security","github","2026-11-10 10:12:30",false,"---\nname: redteam-report-template\ndescription: Client-facing red-team deliverable format\ncategory: security\nrisk: safe\nsource: https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\nsource_repo: elementalsouls\u002FClaude-BugHunter\nsource_type: community\ndate_added: '2026-09-20'\nlicense: MIT\nlicense_source: https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\u002Fblob\u002Fmain\u002FLICENSE\ncompatibility: Process guidance; no tooling required. Docs-only; upstream templates\n  not bundled.\nsources: authorized-engagement-deliverable, enterprise-redteam-report-conventions\nreport_count: 1\n---\n\n## When to use\n\nUse this skill for **client-deliverable** reports:\n- External red-team engagements with a signed SOW\n- Pentest reports going to a CISO \u002F IT-Sec team (not a triager)\n- Findings that will be reviewed by both technical and non-technical stakeholders\n- Reports that need DOCX\u002FPDF output (not just markdown \u002F platform UI)\n\nDo NOT use for:\n- Bug-bounty platform submissions (use `report-writing` \u002F `bugcrowd-reporting` instead)\n- Quick proof-of-concept memos\n- Internal team writeups\n\n---\n\n## The 6-section format per finding\n\nThis is the canonical structure each finding follows:\n\n````markdown\n## Finding F##: \u003Cdescriptive title>\n\n**Severity:** Critical \u002F High \u002F Medium \u002F Low \u002F Informational\n**Status:** Confirmed \u002F Patched mid-engagement \u002F Suspected (1 signal)\n**CVSS 3.1:** \u003Cscore> (\u003Cvector>)\n**Affected Asset:** \u003CURL \u002F IP \u002F app name>\n\n### 1. Subject\n\u003COne-line statement of the issue. Plain English, no jargon.>\n\n### 2. Observations\n\u003CBulleted list of what was observed during testing. Concrete facts only — no interpretation yet.>\n- \u003CObservation 1>\n- \u003CObservation 2>\n- ...\n\n### 3. Description\n\u003CTechnical explanation of the vulnerability. 2-4 paragraphs. Reader should understand WHY the observations indicate a vulnerability, what the underlying flaw is.>\n\n### 4. Impact\n\u003CWhat an attacker could achieve. Concrete attacker outcomes, NOT generic CIA triad statements. Tie to the client's business — money, data, reputation, regulatory exposure.>\n\n### 5. Recommendation\n\u003CSpecific, actionable remediation. Vendor patch, configuration change, code-level fix. Avoid \"implement security best practices\" — say what specifically.>\n\n### 6. Proof of Concept (PoC)\n\u003CSteps to reproduce, numbered. Include the exact HTTP requests, payloads, tools used.>\n\n**Step 1:** \u003Caction>\n```http\n\u003Cfull HTTP request or curl one-liner>\n```\n\n**Step 2:** \u003Caction>\n```\n\u003Cresponse excerpt>\n```\n\n**Screenshot:**\nEvidence attachment placeholder: screenshots\u002FF\u003CNN>_\u003Cdescriptive>.png (insert a real local image link only after creating the sanitized file).\n````\n\n---\n\nBefore delivery, separate observed impact from plausible but untested impact; repeated exploitation is unnecessary when it would create harm. Protect raw requests, cookies, credentials and identifiers in a restricted evidence appendix, redacting client-facing excerpts. Do not execute PoCs merely to fill this template. A DOCX image-count check is not visual QA: render and inspect pages, redactions, table flow and citations. Cleanup claims require verified artifact inventory, not boilerplate.\n\n## Severity & status disciplines\n\n### Severity table (client-facing — different from CVSS-only)\n\n| Severity | Business definition | CVSS rough range |\n|---|---|---|\n| Critical | Direct revenue\u002Fdata loss without prerequisites | 9.0-10.0 |\n| High | Full account\u002Fsystem takeover with limited prerequisites | 7.0-8.9 |\n| Medium | Significant data exposure or partial compromise | 4.0-6.9 |\n| Low | Information disclosure with limited exploitation path | 0.1-3.9 |\n| Informational | Hygiene finding, no immediate exploit | N\u002FA |\n\n### Status field (red-team-specific)\n\nThis is the field that distinguishes red-team deliverables from bug-bounty reports. Use one of:\n\n- **Confirmed** — reproduced multiple times, with full PoC\n- **Confirmed; patched mid-engagement** — was reproducible, client patched during the test window (still ship the finding — see `mid-engagement-ir-detection`)\n- **Confirmed; partially reproducible** — works but needs specific conditions\n- **Suspected (1 signal)** — single indicator, not confirmed (rare — usually drop)\n- **Out-of-band** — finding from passive recon, not actively tested\n\n---\n\n## Mistakes to avoid (from authorized-engagement)\n\n### 1. Don't retract findings that stopped reproducing\nIf a previously demonstrated finding stops reproducing, preserve the original evidence and timestamps. Record the current retest result; possible causes include a patch, changed state, rate limits, configuration or initial measurement error. Use \"patched\" only with supporting change\u002Fretest evidence, not inference from failure alone. See `mid-engagement-ir-detection`.\n\n### 2. Don't hedge in the Impact section\nBad: \"An attacker could potentially be able to access user data, which may lead to...\"\nGood: \"An attacker reads any user's profile data. Demonstrated on test user `victim@target.com` at 14:22 IST.\"\n\n### 3. Don't generic-CIA the impact\nBad: \"Loss of confidentiality and integrity of customer data\"\nGood: \"Read access to 247,000 customer records including PAN cards, addresses, GST numbers. Any legal notification duty needs current jurisdiction-specific counsel review; this technical evidence alone does not establish a statutory deadline.\"\n\n### 4. Don't list every recon finding as a finding\nRecon notes (subdomains found, ports open, technologies fingerprinted) belong in a separate **Recon \u002F Attack Surface** appendix, not the findings list. A finding must have an attacker-attainable outcome.\n\n### 5. Don't bury the PoC\nEach finding MUST have reproducible steps. The PoC section is what proves the finding to a skeptical reader. If you can't write the PoC clearly, the finding probably isn't ready to ship.\n\n---\n\n## Document-level structure\n\n```\n1. Executive Summary (1 page, non-technical)\n   - Engagement overview (dates, scope)\n   - Risk posture summary (heat-map: \u003CX critical, Y high, Z medium...>)\n   - Top 3 strategic recommendations\n   - Comparison to industry baseline (optional)\n\n2. Engagement Details\n   - Scope (in-scope, out-of-scope, exclusions)\n   - Methodology (recon → exploit → reporting; or align with PTES \u002F OSSTMM)\n   - Tools used\n   - Timeline (start \u002F end \u002F key milestones)\n   - Team\n\n3. Risk Summary Table\n   | F# | Title | Severity | Status |\n   |----|-------|----------|--------|\n   | F01 | ... | Critical | Confirmed |\n   ...\n\n4. Findings (one per ## section, in severity order — Critical first)\n\n5. Attack Surface \u002F Recon Appendix\n   - Subdomains discovered\n   - Open ports \u002F services\n   - Technology fingerprints\n   - APKs found\n   - Credentials in breach corpora (count + sample only — redact)\n   - Identity-fabric map (IdP, MFA posture)\n\n6. Indicators of Compromise (IoCs)\n   - Source IPs used during testing (so SOC can correlate)\n   - User-Agent strings\n   - Test accounts created\n   - Files uploaded (with cleanup status)\n\n7. Cleanup Statement\n   - Confirmation that all test artifacts (accounts, uploads, persistence) were removed\n   - Outstanding cleanup items requiring client action\n\n8. Appendices (raw output, screenshots index, full target list)\n```\n\n---\n\n## DOCX generation pipeline (markdown → docx with embedded images)\n\n```bash\n# Prerequisite: pandoc installed; python-docx separately required for the optional check.\n# No reference.docx is bundled; provide an actually reviewed local file only if available.\nbrew install pandoc\n\n# Convert\npandoc REPORT_FINAL.md \\\n  -o REPORT_FINAL.docx \\\n  --resource-path=engagement_log\u002Fpoc \\\n  --toc \\\n  --toc-depth=2 \\\n  --highlight-style=tango\n\n# Verify image count\npython3 -c \"\nfrom docx import Document\nd = Document('REPORT_FINAL.docx')\nimgs = [r for r in d.part.rels.values() if 'image' in r.target_ref]\nprint(f'Embedded images: {len(imgs)}')\nprint(f'Paragraphs: {len(d.paragraphs)}')\nprint(f'Headings: {sum(1 for p in d.paragraphs if p.style.name.startswith(\\\"Heading\\\"))}')\n\"\n```\n\n### Image filename convention\n\n```\nscreenshots\u002FF\u003CNN>_\u003Cdescriptive>.png\n\nExamples:\nF01_locked_accounts.png\nF02a_saml_landing.png\nF02b_saml_ca_block_page.png\nF03_sqli_timing_chart.png\nF15_saml_metadata.png\n```\n\nVariants get letter suffixes (F02a, F02b). Always zero-pad finding number.\n\n---\n\n## Writing tone — for client deliverables\n\n| Section | Tone |\n|---|---|\n| Subject | Plain English, jargon-free, 1 line |\n| Observations | Bulleted facts, past tense (\"observed that...\") |\n| Description | Technical but accessible; assume CISO reader |\n| Impact | Business-translated; tie to revenue\u002Fregulation |\n| Recommendation | Imperative, specific, actionable |\n| PoC | Operator-level technical; copy-pasteable |\n\n**Always:**\n- Use past tense for observations (\"The endpoint returned a 200 status code\")\n- Use present tense for descriptions of the flaw (\"The application does not validate...\")\n- Use imperative for recommendations (\"Apply patch ... by ...\")\n- Number reproduction steps; never \"first... then... also...\"\n\n**Never:**\n- \"Could potentially\" — prove it or drop it\n- \"It might be possible\" — same\n- \"We recommend implementing security best practices\" — say which one specifically\n- \"The application is vulnerable to...\" without saying what specifically\n\n---\n\n## Audience translation — same finding, different framing\n\nExample: hardcoded JWT in APK\n\n| Section | Technical framing | CISO framing | Board framing |\n|---|---|---|---|\n| Impact | \"JWT signing key extracted from APK enables forging admin tokens\" | \"Anyone with the customer-facing mobile app can read any customer's invoice\" | \"A leaked secret in our mobile app lets attackers impersonate users\" |\n\nThe same finding's Impact paragraph should cover both ends — start with the business outcome, then drop into technical detail.\n\n---\n\n## Findings that are sometimes wrongly excluded\n\nRed-team deliverables should include — not just bug-bounty payable bugs:\n\n- **Information disclosure that helps attack mapping** (CodeIgniter debug toolbar leaking routes, version banners on appliances) — Medium\n- **User enumeration** (Microsoft OneDrive 302 vs 404 differential) — Medium\n- **Pre-existing security state observations** (247 accounts already locked by external attacker; weak password policies) — Informational with stakeholder relevance\n- **Defensive observations** (SOC patched our SQLi within 30 min — evidence of working detection) — Informational\u002Fpositive\n- **Sister-app pattern issues** (same code template across 7 apps) — Medium (multiplied blast radius)\n\nBug bounty would reject most of these. Red-team deliverables embrace them — the client paid for the assessment to know.\n\n---\n\n## Mid-engagement events to document\n\nBeyond findings themselves, the deliverable should include:\n\n- Detected SOC responses (timestamps when defenses kicked in)\n- Concurrent external attacker activity (if any was observed)\n- Findings the client patched during the engagement (with PoC pre-patch as evidence)\n- Tooling failures (e.g., MCP timeout, CAPTCHA not solvable) — these affect what was\u002Fwasn't testable\n\nEach gives the client context about their real-world detection capability, which often matters more than the findings themselves.\n\n---\n\n## Template library (where to put canned text)\n\nMaintain reusable boilerplate in:\n```\n~\u002F.claude\u002Fskills\u002Fredteam-report-template\u002Ftemplates\u002F\n    executive_summary.md      # Reusable exec summary skeleton\n    methodology.md            # Standard methodology section\n    cleanup_statement.md      # Standard cleanup language\n    reference.docx            # Pandoc style template (fonts, headings, colors)\n    cover.docx                # Cover page template\n```\n\nDon't write these from scratch each engagement; clone and customize.\n\n---\n\n## Quality checks before delivery\n\nPre-delivery checklist:\n\n- [ ] Every finding has all 6 sections populated (no \"TBD\")\n- [ ] Every finding has at least one screenshot or HTTP-level evidence\n- [ ] Every PoC includes redactions for client PII (mask emails, phone numbers, IDs)\n- [ ] Every screenshot is referenced in the MD with a relative path that resolves\n- [ ] DOCX render check — image count matches MD reference count\n- [ ] Severity ordering: Critical findings first, then High, etc.\n- [ ] Executive summary is updated to match final findings (count, themes)\n- [ ] Cleanup statement explicitly says what was created and what was removed\n- [ ] IoC section enables the SOC to reconstruct what they saw\n- [ ] Spell-check (especially client company name, product names)\n- [ ] All tool versions noted in methodology\n- [ ] Status field set correctly on every finding (especially patched-mid-engagement)\n\n---\n\n## Bridge to neighboring skills\n\n- `report-writing` — bug-bounty platform reports (different format, different audience)\n- `redteam-mindset` — informs what counts as a finding worth shipping\n- `mid-engagement-ir-detection` — informs the \"patched mid-engagement\" status pattern\n- `evidence-hygiene` — informs screenshot redaction discipline\n- `m365-entra-attack`, `enterprise-vpn-attack`, etc. — each provides finding-templates specific to its attack surface\n\n---\n\n## Anti-patterns\n\n- **DO NOT** write a 50-page report for 3 findings — pad-by-page erodes credibility\n- **DO NOT** use the same severity for everything — calibrate\n- **DO NOT** copy-paste OWASP top-10 boilerplate into Description sections\n- **DO NOT** include findings without PoCs — they read as speculative\n- **DO NOT** skip the Recommendation section's specificity — \"patch and review\" doesn't help\n- **DO NOT** mix bug-bounty CVSS scoring with red-team severity unthinkingly — context differs (e.g., a Medium on a CVSS basis can be Critical for the client if it touches a regulated dataset)\n\n---\n\n## Real engagement metric (authorized-engagement)\n\nFor calibration:\n- 14 findings shipped (2 Critical, 4 High, 5 Medium, 3 Low\u002FInfo)\n- 18 screenshots embedded\n- 52,737 bytes markdown \u002F 2,262,484 bytes DOCX\n- 414 paragraphs, 123 headings in DOCX\n- 16 inline images (2 were inline in MD-only edge cases)\n- Time-to-deliverable: ~6 hours after engagement close for first draft\n\nThese are an upstream anecdote, not a representative benchmark or expected deliverable quota. No underlying engagement evidence is bundled here; scale the report to the actual authorized scope and supported findings.\n\n---\n\n## Related Skills & Chains\n\n- **`triage-validation`** — This template ingests findings that have ALREADY passed the 7-Question Gate. Engagement flow: every finding through `triage-validation` first → only validated findings → `redteam-report-template` packaging. Skipping triage produces a deliverable padded with informational noise that erodes client trust.\n- **`evidence-hygiene`** — The DOCX with 16 embedded screenshots only works if evidence was captured systematically throughout the engagement. Engagement flow: `evidence-hygiene` discipline at session start → timestamped, organized screenshot folder → `redteam-report-template` consumes that folder to populate Evidence blocks.\n- **`redteam-mindset`** — The Subject \u002F Observations \u002F Description \u002F Impact \u002F Recommendation \u002F PoC structure assumes the operator already thinks like a red-teamer (impact-first, blast-radius framing). Engagement flow: `redteam-mindset` loaded at engagement start → findings collected with red-team framing baked in → `redteam-report-template` produces deliverable without rewriting every Impact section.\n- **`mid-engagement-ir-detection`** — Defensive-action findings (SOC patches mid-test, new IPS rules deployed, account lockouts triggered by external attacker) are first-class findings in red-team deliverables. Engagement flow: `mid-engagement-ir-detection` captures behavior-change events → each becomes its own Subject in the deliverable, framed as \"client capability observation\" not as \"bug we missed.\"\n- **`report-writing`** + **`bugcrowd-reporting`** — Bug-bounty platform reports use DIFFERENT structure (one finding per submission, platform-specific severity scoring, OOS-clause counters). Engagement flow: if engagement mode is `bug-bounty` per project memory → use `report-writing` \u002F `bugcrowd-reporting` instead. This template is ONLY for external red-team \u002F enterprise client deliverables.\n\n## Limitations\n\n- Process guidance only; it does not authorize probing or exploitation — those steps need their own authorized skill and confirmation gate.\n- Docs-only import: upstream templates, commands, and research assets are not bundled.\n\n### Example\n\n```markdown\nApply this skill's checklist to the current engagement notes and report gaps.\n```\n\n> Adapted from [elementalsouls\u002FClaude-BugHunter](https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter) (MIT); frontmatter, When to Use\u002FLimitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.\n","## When to use\n\nUse this skill for **client-deliverable** reports:\n- External red-team engagements with a signed SOW\n- Pentest reports going to a CISO \u002F IT-Sec team (not a triager)\n- Findings that will be reviewed by both technical and non-technical stakeholders\n- Reports that need DOCX\u002FPDF output (not just markdown \u002F platform UI)\n\nDo NOT use for:\n- Bug-bounty platform submissions (use `report-writing` \u002F `bugcrowd-reporting` instead)\n- Quick proof-of-concept memos\n- Internal team writeups\n\n---\n\n## The 6-section format per finding\n\nThis is the canonical structure each finding follows:\n\n````markdown\n## Finding F##: \u003Cdescriptive title>\n\n**Severity:** Critical \u002F High \u002F Medium \u002F Low \u002F Informational\n**Status:** Confirmed \u002F Patched mid-engagement \u002F Suspected (1 signal)\n**CVSS 3.1:** \u003Cscore> (\u003Cvector>)\n**Affected Asset:** \u003CURL \u002F IP \u002F app name>\n\n### 1. Subject\n\u003COne-line statement of the issue. Plain English, no jargon.>\n\n### 2. Observations\n\u003CBulleted list of what was observed during testing. Concrete facts only — no interpretation yet.>\n- \u003CObservation 1>\n- \u003CObservation 2>\n- ...\n\n### 3. Description\n\u003CTechnical explanation of the vulnerability. 2-4 paragraphs. Reader should understand WHY the observations indicate a vulnerability, what the underlying flaw is.>\n\n### 4. Impact\n\u003CWhat an attacker could achieve. Concrete attacker outcomes, NOT generic CIA triad statements. Tie to the client's business — money, data, reputation, regulatory exposure.>\n\n### 5. Recommendation\n\u003CSpecific, actionable remediation. Vendor patch, configuration change, code-level fix. Avoid \"implement security best practices\" — say what specifically.>\n\n### 6. Proof of Concept (PoC)\n\u003CSteps to reproduce, numbered. Include the exact HTTP requests, payloads, tools used.>\n\n**Step 1:** \u003Caction>\n```http\n\u003Cfull HTTP request or curl one-liner>\n```\n\n**Step 2:** \u003Caction>\n```\n\u003Cresponse excerpt>\n```\n\n**Screenshot:**\nEvidence attachment placeholder: screenshots\u002FF\u003CNN>_\u003Cdescriptive>.png (insert a real local image link only after creating the sanitized file).\n````\n\n---\n\nBefore delivery, separate observed impact from plausible but untested impact; repeated exploitation is unnecessary when it would create harm. Protect raw requests, cookies, credentials and identifiers in a restricted evidence appendix, redacting client-facing excerpts. Do not execute PoCs merely to fill this template. A DOCX image-count check is not visual QA: render and inspect pages, redactions, table flow and citations. Cleanup claims require verified artifact inventory, not boilerplate.\n\n## Severity & status disciplines\n\n### Severity table (client-facing — different from CVSS-only)\n\n| Severity | Business definition | CVSS rough range |\n|---|---|---|\n| Critical | Direct revenue\u002Fdata loss without prerequisites | 9.0-10.0 |\n| High | Full account\u002Fsystem takeover with limited prerequisites | 7.0-8.9 |\n| Medium | Significant data exposure or partial compromise | 4.0-6.9 |\n| Low | Information disclosure with limited exploitation path | 0.1-3.9 |\n| Informational | Hygiene finding, no immediate exploit | N\u002FA |\n\n### Status field (red-team-specific)\n\nThis is the field that distinguishes red-team deliverables from bug-bounty reports. Use one of:\n\n- **Confirmed** — reproduced multiple times, with full PoC\n- **Confirmed; patched mid-engagement** — was reproducible, client patched during the test window (still ship the finding — see `mid-engagement-ir-detection`)\n- **Confirmed; partially reproducible** — works but needs specific conditions\n- **Suspected (1 signal)** — single indicator, not confirmed (rare — usually drop)\n- **Out-of-band** — finding from passive recon, not actively tested\n\n---\n\n## Mistakes to avoid (from authorized-engagement)\n\n### 1. Don't retract findings that stopped reproducing\nIf a previously demonstrated finding stops reproducing, preserve the original evidence and timestamps. Record the current retest result; possible causes include a patch, changed state, rate limits, configuration or initial measurement error. Use \"patched\" only with supporting change\u002Fretest evidence, not inference from failure alone. See `mid-engagement-ir-detection`.\n\n### 2. Don't hedge in the Impact section\nBad: \"An attacker could potentially be able to access user data, which may lead to...\"\nGood: \"An attacker reads any user's profile data. Demonstrated on test user `victim@target.com` at 14:22 IST.\"\n\n### 3. Don't generic-CIA the impact\nBad: \"Loss of confidentiality and integrity of customer data\"\nGood: \"Read access to 247,000 customer records including PAN cards, addresses, GST numbers. Any legal notification duty needs current jurisdiction-specific counsel review; this technical evidence alone does not establish a statutory deadline.\"\n\n### 4. Don't list every recon finding as a finding\nRecon notes (subdomains found, ports open, technologies fingerprinted) belong in a separate **Recon \u002F Attack Surface** appendix, not the findings list. A finding must have an attacker-attainable outcome.\n\n### 5. Don't bury the PoC\nEach finding MUST have reproducible steps. The PoC section is what proves the finding to a skeptical reader. If you can't write the PoC clearly, the finding probably isn't ready to ship.\n\n---\n\n## Document-level structure\n\n```\n1. Executive Summary (1 page, non-technical)\n   - Engagement overview (dates, scope)\n   - Risk posture summary (heat-map: \u003CX critical, Y high, Z medium...>)\n   - Top 3 strategic recommendations\n   - Comparison to industry baseline (optional)\n\n2. Engagement Details\n   - Scope (in-scope, out-of-scope, exclusions)\n   - Methodology (recon → exploit → reporting; or align with PTES \u002F OSSTMM)\n   - Tools used\n   - Timeline (start \u002F end \u002F key milestones)\n   - Team\n\n3. Risk Summary Table\n   | F# | Title | Severity | Status |\n   |----|-------|----------|--------|\n   | F01 | ... | Critical | Confirmed |\n   ...\n\n4. Findings (one per ## section, in severity order — Critical first)\n\n5. Attack Surface \u002F Recon Appendix\n   - Subdomains discovered\n   - Open ports \u002F services\n   - Technology fingerprints\n   - APKs found\n   - Credentials in breach corpora (count + sample only — redact)\n   - Identity-fabric map (IdP, MFA posture)\n\n6. Indicators of Compromise (IoCs)\n   - Source IPs used during testing (so SOC can correlate)\n   - User-Agent strings\n   - Test accounts created\n   - Files uploaded (with cleanup status)\n\n7. Cleanup Statement\n   - Confirmation that all test artifacts (accounts, uploads, persistence) were removed\n   - Outstanding cleanup items requiring client action\n\n8. Appendices (raw output, screenshots index, full target list)\n```\n\n---\n\n## DOCX generation pipeline (markdown → docx with embedded images)\n\n```bash\n# Prerequisite: pandoc installed; python-docx separately required for the optional check.\n# No reference.docx is bundled; provide an actually reviewed local file only if available.\nbrew install pandoc\n\n# Convert\npandoc REPORT_FINAL.md \\\n  -o REPORT_FINAL.docx \\\n  --resource-path=engagement_log\u002Fpoc \\\n  --toc \\\n  --toc-depth=2 \\\n  --highlight-style=tango\n\n# Verify image count\npython3 -c \"\nfrom docx import Document\nd = Document('REPORT_FINAL.docx')\nimgs = [r for r in d.part.rels.values() if 'image' in r.target_ref]\nprint(f'Embedded images: {len(imgs)}')\nprint(f'Paragraphs: {len(d.paragraphs)}')\nprint(f'Headings: {sum(1 for p in d.paragraphs if p.style.name.startswith(\\\"Heading\\\"))}')\n\"\n```\n\n### Image filename convention\n\n```\nscreenshots\u002FF\u003CNN>_\u003Cdescriptive>.png\n\nExamples:\nF01_locked_accounts.png\nF02a_saml_landing.png\nF02b_saml_ca_block_page.png\nF03_sqli_timing_chart.png\nF15_saml_metadata.png\n```\n\nVariants get letter suffixes (F02a, F02b). Always zero-pad finding number.\n\n---\n\n## Writing tone — for client deliverables\n\n| Section | Tone |\n|---|---|\n| Subject | Plain English, jargon-free, 1 line |\n| Observations | Bulleted facts, past tense (\"observed that...\") |\n| Description | Technical but accessible; assume CISO reader |\n| Impact | Business-translated; tie to revenue\u002Fregulation |\n| Recommendation | Imperative, specific, actionable |\n| PoC | Operator-level technical; copy-pasteable |\n\n**Always:**\n- Use past tense for observations (\"The endpoint returned a 200 status code\")\n- Use present tense for descriptions of the flaw (\"The application does not validate...\")\n- Use imperative for recommendations (\"Apply patch ... by ...\")\n- Number reproduction steps; never \"first... then... also...\"\n\n**Never:**\n- \"Could potentially\" — prove it or drop it\n- \"It might be possible\" — same\n- \"We recommend implementing security best practices\" — say which one specifically\n- \"The application is vulnerable to...\" without saying what specifically\n\n---\n\n## Audience translation — same finding, different framing\n\nExample: hardcoded JWT in APK\n\n| Section | Technical framing | CISO framing | Board framing |\n|---|---|---|---|\n| Impact | \"JWT signing key extracted from APK enables forging admin tokens\" | \"Anyone with the customer-facing mobile app can read any customer's invoice\" | \"A leaked secret in our mobile app lets attackers impersonate users\" |\n\nThe same finding's Impact paragraph should cover both ends — start with the business outcome, then drop into technical detail.\n\n---\n\n## Findings that are sometimes wrongly excluded\n\nRed-team deliverables should include — not just bug-bounty payable bugs:\n\n- **Information disclosure that helps attack mapping** (CodeIgniter debug toolbar leaking routes, version banners on appliances) — Medium\n- **User enumeration** (Microsoft OneDrive 302 vs 404 differential) — Medium\n- **Pre-existing security state observations** (247 accounts already locked by external attacker; weak password policies) — Informational with stakeholder relevance\n- **Defensive observations** (SOC patched our SQLi within 30 min — evidence of working detection) — Informational\u002Fpositive\n- **Sister-app pattern issues** (same code template across 7 apps) — Medium (multiplied blast radius)\n\nBug bounty would reject most of these. Red-team deliverables embrace them — the client paid for the assessment to know.\n\n---\n\n## Mid-engagement events to document\n\nBeyond findings themselves, the deliverable should include:\n\n- Detected SOC responses (timestamps when defenses kicked in)\n- Concurrent external attacker activity (if any was observed)\n- Findings the client patched during the engagement (with PoC pre-patch as evidence)\n- Tooling failures (e.g., MCP timeout, CAPTCHA not solvable) — these affect what was\u002Fwasn't testable\n\nEach gives the client context about their real-world detection capability, which often matters more than the findings themselves.\n\n---\n\n## Template library (where to put canned text)\n\nMaintain reusable boilerplate in:\n```\n~\u002F.claude\u002Fskills\u002Fredteam-report-template\u002Ftemplates\u002F\n    executive_summary.md      # Reusable exec summary skeleton\n    methodology.md            # Standard methodology section\n    cleanup_statement.md      # Standard cleanup language\n    reference.docx            # Pandoc style template (fonts, headings, colors)\n    cover.docx                # Cover page template\n```\n\nDon't write these from scratch each engagement; clone and customize.\n\n---\n\n## Quality checks before delivery\n\nPre-delivery checklist:\n\n- [ ] Every finding has all 6 sections populated (no \"TBD\")\n- [ ] Every finding has at least one screenshot or HTTP-level evidence\n- [ ] Every PoC includes redactions for client PII (mask emails, phone numbers, IDs)\n- [ ] Every screenshot is referenced in the MD with a relative path that resolves\n- [ ] DOCX render check — image count matches MD reference count\n- [ ] Severity ordering: Critical findings first, then High, etc.\n- [ ] Executive summary is updated to match final findings (count, themes)\n- [ ] Cleanup statement explicitly says what was created and what was removed\n- [ ] IoC section enables the SOC to reconstruct what they saw\n- [ ] Spell-check (especially client company name, product names)\n- [ ] All tool versions noted in methodology\n- [ ] Status field set correctly on every finding (especially patched-mid-engagement)\n\n---\n\n## Bridge to neighboring skills\n\n- `report-writing` — bug-bounty platform reports (different format, different audience)\n- `redteam-mindset` — informs what counts as a finding worth shipping\n- `mid-engagement-ir-detection` — informs the \"patched mid-engagement\" status pattern\n- `evidence-hygiene` — informs screenshot redaction discipline\n- `m365-entra-attack`, `enterprise-vpn-attack`, etc. — each provides finding-templates specific to its attack surface\n\n---\n\n## Anti-patterns\n\n- **DO NOT** write a 50-page report for 3 findings — pad-by-page erodes credibility\n- **DO NOT** use the same severity for everything — calibrate\n- **DO NOT** copy-paste OWASP top-10 boilerplate into Description sections\n- **DO NOT** include findings without PoCs — they read as speculative\n- **DO NOT** skip the Recommendation section's specificity — \"patch and review\" doesn't help\n- **DO NOT** mix bug-bounty CVSS scoring with red-team severity unthinkingly — context differs (e.g., a Medium on a CVSS basis can be Critical for the client if it touches a regulated dataset)\n\n---\n\n## Real engagement metric (authorized-engagement)\n\nFor calibration:\n- 14 findings shipped (2 Critical, 4 High, 5 Medium, 3 Low\u002FInfo)\n- 18 screenshots embedded\n- 52,737 bytes markdown \u002F 2,262,484 bytes DOCX\n- 414 paragraphs, 123 headings in DOCX\n- 16 inline images (2 were inline in MD-only edge cases)\n- Time-to-deliverable: ~6 hours after engagement close for first draft\n\nThese are an upstream anecdote, not a representative benchmark or expected deliverable quota. No underlying engagement evidence is bundled here; scale the report to the actual authorized scope and supported findings.\n\n---\n\n## Related Skills & Chains\n\n- **`triage-validation`** — This template ingests findings that have ALREADY passed the 7-Question Gate. Engagement flow: every finding through `triage-validation` first → only validated findings → `redteam-report-template` packaging. Skipping triage produces a deliverable padded with informational noise that erodes client trust.\n- **`evidence-hygiene`** — The DOCX with 16 embedded screenshots only works if evidence was captured systematically throughout the engagement. Engagement flow: `evidence-hygiene` discipline at session start → timestamped, organized screenshot folder → `redteam-report-template` consumes that folder to populate Evidence blocks.\n- **`redteam-mindset`** — The Subject \u002F Observations \u002F Description \u002F Impact \u002F Recommendation \u002F PoC structure assumes the operator already thinks like a red-teamer (impact-first, blast-radius framing). Engagement flow: `redteam-mindset` loaded at engagement start → findings collected with red-team framing baked in → `redteam-report-template` produces deliverable without rewriting every Impact section.\n- **`mid-engagement-ir-detection`** — Defensive-action findings (SOC patches mid-test, new IPS rules deployed, account lockouts triggered by external attacker) are first-class findings in red-team deliverables. Engagement flow: `mid-engagement-ir-detection` captures behavior-change events → each becomes its own Subject in the deliverable, framed as \"client capability observation\" not as \"bug we missed.\"\n- **`report-writing`** + **`bugcrowd-reporting`** — Bug-bounty platform reports use DIFFERENT structure (one finding per submission, platform-specific severity scoring, OOS-clause counters). Engagement flow: if engagement mode is `bug-bounty` per project memory → use `report-writing` \u002F `bugcrowd-reporting` instead. This template is ONLY for external red-team \u002F enterprise client deliverables.\n\n## Limitations\n\n- Process guidance only; it does not authorize probing or exploitation — those steps need their own authorized skill and confirmation gate.\n- Docs-only import: upstream templates, commands, and research assets are not bundled.\n\n### Example\n\n```markdown\nApply this skill's checklist to the current engagement notes and report gaps.\n```\n\n> Adapted from [elementalsouls\u002FClaude-BugHunter](https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter) (MIT); frontmatter, When to Use\u002FLimitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.\n",{"name":5,"risk":42,"source":56,"license":14,"sources":57,"category":49,"date_added":58,"description":7,"source_repo":59,"source_type":37,"report_count":60,"compatibility":61,"license_source":62},"https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter","authorized-engagement-deliverable, enterprise-redteam-report-conventions","2026-09-20","elementalsouls\u002FClaude-BugHunter",1,"Process guidance; no tooling required. Docs-only; upstream templates not bundled.","https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\u002Fblob\u002Fmain\u002FLICENSE","7bf2279c8a65758319526a721d5c4b75683aec9c","skills\u002Fantigravity-redteam-report-template",3,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections","https:\u002F\u002Fgithub.com\u002Fboisenoise","2026-11-13 14:20:47",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add boisenoise\u002Fskills-collections --skill redteam-report-template",{"tool":75,"command":76},"bunx","bunx skills add boisenoise\u002Fskills-collections --skill redteam-report-template",{"tool":78,"command":79},"pnpm","pnpm dlx skills add boisenoise\u002Fskills-collections --skill redteam-report-template","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-redteam-report-template\u002FSKILL.md",true,[],[84,112,134,157,176,199],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":88,"licenseFileUrl":89,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":51},"01M6WNH92BHVFXHGPDZCPJ0AG0","web-access","Use Treg for public web or platform data only when existing search, browser and connected tools cannot cover the task, with explicit cost and data boundaries.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FSKILL.md",[],[93,94,95,96,97,98,99,100,101,102,103,41,104,105,106,107,108,109,110,111,33],"web","access","web access","official","development","browser","search","data","Tools","read","fetch","youtube","free tools","platform","critical","free","cover","normal","when",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":88,"licenseFileUrl":116,"sourceHtmlUrl":117,"categories":118,"keywords":122,"publishedAt":51},"01M6WNF9XAYAB2CZDDJBAKNM93","treg","Use the Treg CLI or MCP catalog to discover, price and call authorized external tools with team-scoped credentials and a user-approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FSKILL.md",[119],{"categoryNo":120,"categoryName":121,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[114,123,124,50,96,97,48,101,125,126,44,127,128,129,130,107,131,132,133,34,33],"MCP","cli","Budget","credentials","catalog","use","call","discover","external tools","with","scoped",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":88,"licenseFileUrl":138,"sourceHtmlUrl":139,"categories":140,"keywords":144,"publishedAt":51},"01M6WN93MEAZ4E41DYAHJRPHQT","recruit","Turn a job description into an evidence-linked candidate shortlist through Treg, with job-related ranking and optional authorized business contact enrichment.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FSKILL.md",[141],{"categoryNo":142,"categoryName":143,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000038","人力资源",[136,50,96,48,47,145,146,147,148,149,107,150,151,152,132,153,154,155,156,34,114,33],"email","enrichment","business","evidence","phone","ranking","post","job description","for","person","candidate","reason",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":88,"licenseFileUrl":161,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":51},"01M6WN8R5RXSMHM9B4D9FAFX42","rea-growth","Analyze a company’s public growth and content through Treg, distinguish observations from hypotheses, and produce an evidence-linked playbook within an approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FSKILL.md",[],[165,166,167,50,96,48,168,169,47,170,125,171,172,173,148,107,174,175,34,114,33],"growth","rea","rea growth","produce","content","playbook","marketing","analyze","public","observations","company",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":88,"licenseFileUrl":180,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":51},"01M6WN2EVE3RQRGWAKBT4S7YT2","make-ugc","Create original AI UGC-style product videos through Treg: research hooks, approve a licensed presenter and voice, generate clips, add captions and report costs.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FSKILL.md",[],[184,185,50,186,96,187,48,188,189,190,191,192,107,193,194,195,196,197,198,34],"make","make ugc","research","create","Video","Captions","ads","short","hooks","head","style","niche","trending","talking-head","approve",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":88,"licenseFileUrl":203,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":51},"01M6WN10ARAA63Y8K1YNGXJ2RM","lead-signals","Find and qualify public buying signals through Treg, rank fitting business accounts and optionally enrich authorized business contact information.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FSKILL.md",[],[207,208,209,50,96,48,210,211,147,212,213,107,214,215,216,217,218,219,220,34],"signals","lead","lead signals","how","find","ready","as","how to","qualify","people","information","enrich","changes","funding"]