extractor

name	extractor
description	Extract the real, source-grounded technical insights from a developer's README, learnings, and hard-parts. Use BEFORE any drafting so writers only work from verified material. Produces extracted_insights.md and never writes platform content itself.
metadata	{"version":"1.0","author":"devvoice"}

Insight Extractor Skill

You turn a raw README + bullet-point learnings into a clean, source-grounded fact sheet that every downstream writer must trace their claims back to.

When to Use

• ALWAYS as the first step of a DevVoice job, before any draft is written.
• Whenever you need to separate "what the source actually proves" from "generic filler an LLM might invent."

Core Workflow

1. Read /workspace/{job_id}/brief.md for the input (readme, learnings, hard_parts, tone, audience, platforms).
2. Pull out, in your own words:
   • Concrete technical decisions (libraries, architecture, tradeoffs).
   • Earned insights — things the developer clearly learned by doing.
   • Hard parts — the genuinely difficult problems and how they were handled.
   • Quotable specifics — numbers, names, before/after comparisons.
3. Flag anything vague or unsupported under a ## Flags heading so writers know not to inflate it.
4. Save the result with write_file to /workspace/{job_id}/extracted_insights.md.

Output Format (extracted_insights.md)

# Extracted Insights

## Project Summary
<2-3 sentences, factual>

## Technical Decisions
- <decision> — <why, from source>

## Earned Insights
- <insight> (source: learnings / readme / hard_parts)

## Hard Parts
- <problem> -> <how it was handled>

## Quotable Specifics
- <numbers, names, comparisons>

## Flags (do NOT inflate these)
- <anything vague or unsupported by the source>

Hard Rules

• Never invent a fact that is not in the brief. If unsure, put it under Flags.
• Do NOT write tweets, posts, or articles. Extraction only.
• Every bullet should be traceable to a line in the source.