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 ke...
---
name: markdown-to-summary
description: >
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.
license: MIT
metadata:
version: "1.0"
category: productivity
author: wangjipeng
sources:
- https://github.com/MiniMax-AI/skills
---
# 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 Type | Keep | Discard |
|---|---|---|
| Technical doc | Prerequisites, setup steps, key concepts, examples | Installation chatter, release notes noise |
| Article | Thesis statement, supporting evidence, conclusion | Digressions, tangents, filler examples |
| Meeting notes | Decisions made, action items, owners | Meeting meta (time, attendees unless relevant) |
| Changelog | New features, bug fixes, breaking changes | Version 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
| Scenario | Bad Output | Good Output |
|---|---|---|
| 2000-word README | 200-word summary missing setup steps | Preserves: prerequisites, key commands, architecture |
| Changelog with 20 entries | Lists all 20 | Groups: 3 features, 5 fixes, 1 breaking change |
| Article with digression | Includes the tangent | Skips digression, keeps main argument |
| API doc with code examples | Rewrites code in prose | Keeps code block, summarizes surrounding text |
## References
- `references/` — Document type taxonomies, summary length guidelines by use casedon't have the plugin yet? install it then click "run inline in claude" again.