Markdown to Summary#

Use when (1) user provides a long markdown document and asks to summarize, abstract, or condense it. (2) user says "summarize this", "tl;dr", "give me the key points", or "what's the main idea". (3) user pastes a README, article, or doc and wants a short version.

Core Position#

This skill solves the specific problem of: long markdown content needs to be distilled into its essential points without losing critical information.

This skill IS NOT:

• A translation tool — it condenses, it does not translate language
• An analysis tool — it summarizes facts, not opinions or sentiment
• A code documentation tool — for code comments use code-to-mindmap instead

This skill IS activated ONLY when: markdown text + summary/condense intent are both present.

Modes#

/markdown-to-summary#

Default mode. Produces a concise summary preserving key information structure.

When to use: User provides markdown and wants a shorter version covering main points.

/markdown-to-summary/bullet#

Outputs key points as a structured bullet list instead of prose.

When to use: User wants action items, highlights, or a quick-scan list rather than paragraph summary.

/markdown-to-summary/tl-dr#

Produces a single-sentence and single-paragraph tl;dr.

When to use: User wants the absolute shortest version possible.

Execution Steps#

Step 1 — Analyze the Document Structure#

1. Receive markdown input (pasted text, file, or path)
2. Detect document type:
   • Technical doc (README, API docs, guide): preserve architecture, setup steps, key concepts
   • Article/post: preserve main argument, evidence, conclusion
   • Meeting notes: preserve decisions, action items, owners
   • Changelog/release notes: preserve version, key changes, breaking changes
3. Extract hierarchy: H1/H2/H3 headings define primary sections; body text fills them
4. Identify key content signals:
   • Repeated terms → core topics
   • Numbers/dates → factual claims worth preserving
   • Code blocks → technical detail to keep reference to
   • Tables → structured data to preserve

Step 2 — Extract Key Points#

For each major section (H2 level):

Section TypeKeepDiscardTechnical docPrerequisites, setup steps, key concepts, examplesInstallation chatter, release notes noiseArticleThesis statement, supporting evidence, conclusionDigressions, tangents, filler examplesMeeting notesDecisions made, action items, ownersMeeting meta (time, attendees unless relevant)ChangelogNew features, bug fixes, breaking changesVersion numbers, dates, contributor lists unless significant

Step 3 — Compose Summary#

Choose output format based on mode:

• Default: prose paragraphs, ~20-30% of original length
• Bullet: labeled bullet points, one per H2 section
• Tl;dr: 1 sentence + 1 paragraph max

Key principles:

• Preserve specific numbers, names, dates, and version numbers
• Keep code examples as references (not full code)
• Use original heading structure as outline
• Maintain logical flow (don't reorder unrelated sections)

Step 4 — Validate#

• Summary length is ≤40% of original (unless user specified a different ratio)
• Every major H2 section has at least one mention
• No new information added that wasn't in the original
• Technical accuracy preserved (version numbers, commands, paths match)

Mandatory Rules#

Do not#

• Do not add opinions, analysis, or commentary not in the original
• Do not reorder sections — keep the original logical flow
• Do not change technical values (version numbers, paths, commands)
• Do not produce a summary longer than the original without explicit permission

Do#

• Preserve exact technical values (version numbers, URLs, paths)
• Keep section structure aligned with original headings
• Flag when a section was condensed significantly vs. kept intact
• Note any sections that were dropped entirely and why

Quality Bar#

A good output:

• Every major section appears in the summary
• Technical facts match the original exactly
• Length is 20-40% of original
• Structure mirrors original (sections in same order)

A bad output:

• Introduces new information not in source
• Drops an entire H2 section with no mention
• Changes technical specifics (wrong version number, command)
• Summary is longer than original

Good vs. Bad Examples#

ScenarioBad OutputGood Output2000-word README200-word summary missing setup stepsPreserves: prerequisites, key commands, architectureChangelog with 20 entriesLists all 20Groups: 3 features, 5 fixes, 1 breaking changeArticle with digressionIncludes the tangentSkips digression, keeps main argumentAPI doc with code examplesRewrites code in proseKeeps code block, summarizes surrounding text

References#

• references/ — Document type taxonomies, summary length guidelines by use case