Scrape Content Report

• Input is a scrape artifact (often docs/context/*.md).
• User wants a digest, brief, report, or readable synthesis from captured content.
• Main material may live under ## Transcript, ## Content, or similar.

Where to read from (order)

1. ## Transcript if present.
2. Else ## Main content, ## Article, ## Content, or ## Body (first match).
3. Else the largest prose block after metadata; skip ## Extraction notes, nav junk, and scraper boilerplate.

What the output is

A source-grounded thematic brief:

• Short orientation: what the source is and who the brief is for (one or two sentences).
• One section per major theme from the source—not a transcript dump.
• Per section: a thesis for that whole theme (what this block argues, why it matters).
• Under each thesis: labeled sub-points—a short label plus explanation that carries evidence from the source (examples, bad vs good, hard constraints, vendor or author guidance, cause → effect). The logic matches how a strong SKILL.md teaches: claim structure, not decoration.

Do not produce a video index: avoid littering the brief with timestamps and per-claim deep links into a video. They add noise, rot, and distract from durable claims. Optional: one plain canonical source reference if provenance matters; omit if the user prefers. Never use search-redirect URLs.

Completeness

• Every major theme from the source gets a section.
• Do not drop plan-driving detail (constraints, examples, evidence chains) to hit a word count—compress wording, not themes.

Length / audience

• Brief / standard / deep dive only if the user signals it; otherwise judge by source size.
• Implementation handoff: reader will turn this into plans, tickets, or kit changes—preserve testable specifics and do not sacrifice substance for brevity. This overrides generic word-count pressure.

Handoff: never drop on purpose

• Framing the source uses (questions, “number one …”, chapter-style pivots)—keep that in prose, as part of the relevant theme.
• Bad vs good examples where the source gives them; keep near-verbatim when short.
• Named guidance (e.g. vendor lines)—preserve as stated, not only a vague paraphrase.
• Hard constraints (single-line fields, formatter breaks, “model won’t read X”)—state clearly; these become work items.
• Claim → example → consequence chains—keep the chain.

Steps

1. Read the full capture.
2. Isolate main content using the discovery order above.
3. Strip obvious boilerplate unless the user asked for full fidelity.
4. Synthesize only what the source supports; fix obvious ASR errors in transcripts; add no new facts.
5. Build a theme map (heading → thesis → labeled sub-points with evidence).
6. Write the new file (or in-place summary if requested).
7. Re-read for coverage and fidelity—not for markdown trivia.

Avoid

• Overwriting captures without explicit ask.
• Timestamp / link scaffolding as the main artifact.
• Search-redirect or fragile URL farms.
• Invented claims.
• Treating this skill as the place to define markdownlint/Prettier rules.

Checklist

• New file vs in-place matches user intent.
• Major themes covered; key specifics preserved for handoff.
• Thesis + labeled sub-points per section; not a raw transcript paste.
• No video-index noise unless user asked for timecodes.
• Grounded in the capture only.