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):

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

References

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