content-summarizer

Always follow the seven-step workflow below. Each step must be completed before proceeding to the next.

Workflow

Step 0: Identify content type

If $ARGUMENTS is empty (the user has not provided a URL), ask the user to provide a URL before continuing.

Multiple URL handling — If $ARGUMENTS contains multiple URLs (the user wants a combined summary):

1. Extract all URLs from it, and run the detection script separately for each URL
2. Determine a primary type (based on the type of the main content, e.g., a blog post + a Twitter discussion → the primary type is article）
3. In Step 1, fetch the content of each URL separately
4. In Step 2, integrate the analysis and generate a single merged note, annotating the original link for each source in the note

Must run the detection script — Use Glob to locate the scripts/detect_content_type.pyin this skill's directory, then use python3 to run that script and pass the URL as an argument (for multiple URLs, call it separately for each URL). Do not skip this step and manually determine the type. The script returns JSON, containing the type、platform、fetcher、template、metadata field. Based on URL pattern matching, the script returns the corresponding policy file path under references/fetchers/ and the corresponding template path under references/templates/ ; when no known platform is matched, it returns the generic policy by default.

Record all fields returned by the script, and proceed to Step 1. If the script fails to execute or returns an unparseable result, fall back to the default values:type=article、fetcher=references/fetchers/common.md、template=references/templates/article.md。

Step 1: Fetch content

First use Glob to resolve fetcher(relative path) within the skill directory to theunique absolute path, then use Read to read the file corresponding to that absolute path, and follow thefetching policyin it to obtain the content. Strictly try in the priority order given in the policy; only after the preferred option fails, try the next one.

If fetcher fails to resolve (0 or multiple matches), fall back to references/fetchers/common.md and repeat the "Glob resolve absolute path → Read" process; if it still cannot be uniquely located, terminate and report an error.

Platform-specific fetching rules (such as Twitter/X) are maintained only in the corresponding references/fetchers/*.md ; the main SKILL.md does not define them repeatedly. After reading a dedicated fetcher, you must fully execute its "fetching policy", "verification gate", and field mapping conventions.

All types require estimating reading metadata:

• word_count — approximate word count (for Chinese, by character count; for English, by word count)
• reading_time — estimated reading time (Chinese 300 characters/minute, English 200 words/min, rounded up, format "N min"）
• difficulty — content difficulty:beginner(no background knowledge required),intermediate(requires some domain understanding),advanced(requires deep professional knowledge)

When fetching fails(URL unreachable, 404, paywall, empty content):

• Inform the user of the reason for the failure
• Ask the user to provide the content manually (paste text or provide an alternative URL)
• After obtaining the content, continue to Step 2

Verification gate: Confirm that valid body content has been obtained before proceeding to Step 2. If the fetching result is empty or contains only navigation/advertising text, treat it as a fetching failure.

Step 2: Analyze and summarize

Follow theanalysis policyandscore interpretationin the fetcher file already read in Step 1 to process the content.

All types must complete:

2a. Extract core information — Extract using type-specific strategies

2b. Generate a one-line summary（description field) — A single-sentence summary for frontmatter, index entries, and quick browsing

2c. Scoring — Evaluate content across three dimensions (1-5 points):

Dimension	1 (Low)	3 (Medium)	5 (High)
novelty	Widely known common knowledge	Has some new angles or new combinations	Entirely new perspectives or little-known information
quality	Lacks evidence, loose logic	Argument is basically complete but not particularly in-depth	Rigorous argumentation, sufficient evidence, authoritative sources
actionability	Purely theoretical/purely news, no actionable points	Has some suggestions worth referencing	Provides specific steps/code/tools that can be directly applied

For the specific interpretation of each dimension under different content types, see the "Scoring Interpretation" section of the corresponding fetcher file.

Calculate overall_score as the rounded average of the three scores. Based on overall_score determine recommended_action：

• deep_read: overall_score ≥ 4
• skim: overall_score = 3
• reference: overall_score = 2
• archive: overall_score ≤ 1

Output the summary in the user's language (default to Chinese when the user uses Chinese).

Step 3: Determine the output path

Discover the output root directory — Scan the directory tree to locate the directory where notes are stored (find the directory containing Markdown files with source: in the frontmatter, or a directory whose name suggests a content collection). If there are multiple candidates or none can be found, ask the user.

Category directory discovery (dynamic inference):

1. Scan existing subdirectories under the output root directory to infer naming conventions
2. Match content to existing category subdirectories
3. Create new categories when needed, following existing naming conventions
4. Use the path explicitly specified by the user when available

Step 4: Write the Obsidian note

4a. Read the template — First use Glob to resolve template(relative path) to theunique absolute pathwithin the skill directory, then use Read to read the template file, ensuring the note structure strictly matches the template. Do not construct the note structure from memory. If template is null, choose based on the determined type:

• article → references/templates/article.md
• repo → references/templates/repo.md
• thread → references/templates/thread.md

If template path resolution fails (0 or multiple matches), fall back to the type defaults above and repeat the "Glob resolve absolute path → Read" process; if it still cannot be uniquely located, terminate and report an error.

4b. Tag alignment — Before writing the note, use Grep to search all frontmatter tags in the vault (search pattern ^ - in *.md files) to collect the existing tag set. When selecting tags for the new note:

• Prefer reusing existing tags (e.g., if the vault already has 架构 then do not create 软件架构）
• Only create new tags when it is confirmed that there are no existing synonymous tags

4c. Write the note — Follow the structure, callout usage, and adaptation rules of the selected template. If the project's CLAUDE.md requires the use of the obsidian-markdown skill, that skill provides the basic formatting specification, and the note template layers content-specific structure on top of it.

Personal reflection section: Draft initial entries using the conversation context (why the user shared this content, what they are doing). If the context is insufficient, leave a placeholder prompt.

Multimedia handling: Follow the "Multimedia handling" guidelines in references/templates/article.md in the "Multimedia handling" guidelines.

Save the note to the category subdirectory determined in Step 3.

Step 5: Build the index

Integrate the new note into the vault's index system:

1. Ensure the index file exists — Look in the category subdirectory for an existing *INDEX* or *index* file to determine the naming pattern. If it does not exist, create it according to references/templates/index.md .

2. Add an index entry — Format:- `YYYY-MM-DD` [[Title]] - description. Sort by publication date (newest first).publish When unavailable, fall back to the creation date.

3. Forward links — In the note body, use [[wikilinks]] to link to existing related concept notes in the vault. Specific steps:

   • Use Grep to search the vault for key concept terms involved in the note (such as technical terms, methodology names)
   • After finding a matching existing note, insert it at the relevant position in the body [[wikilink]]
   • If no match is found, there is no need to create a new note; only link to existing ones

4. Backlinks — In the 1-3 most relevant existing notes, add a wikilink pointing to the new note. Specific steps:

   • Use Grep to search the vault for notes related to the current content topic (search keywords, same tags)
   • In the related notes found, choose the most appropriate position (such as the related section of "Related Reading", "Recommended Resources", "Personal Reflections") and append the link
   • If no clearly related existing note can be found, skip this step rather than forcing an addition

5. Update the MOC — Look in the parent of the output root directory for the *MOC* file (such as 0_Resources_资源库_MOC.md）：

   • Insert a new entry at the top of the "Recently Added" list, format:- `YYYY-MM-DD` [[Title]], keep the number of entries according to the list length requirement explicitly specified in that MOC file; when not explicitly specified, default to no more than 10 entries (remove the oldest)
   • Update the number of entries for the corresponding category in the category statistics table (recount the entries in that category's INDEX file)
   • If it is a new category (not present in the table), append a row at the end of the table
   • If no MOC file is found, skip this step

Step 6: Quality verification

Check the following checklist item by item. Fix any omissions immediately; only consider it complete after all pass.

• Frontmatter complete: tags, type, source, authors, publish, creation, date_saved, word_count, reading_time, difficulty, status, novelty, quality, actionability, overall_score, recommended_action, description
• Reading metadata present: word_count, reading_time, difficulty
• AI scoring present: novelty, quality, actionability, overall_score, recommended_action
• Content type correctly identified (article / repo / thread)
• Note body structure matches the template for the content type (template already read and confirmed in Step 4a)
• Tags aligned with existing vault tags (already searched and confirmed in Step 4b)
• TL;DR immediately below the title, consistent with the frontmatter's description Consistent
• Original link present above the TL;DR
• Core viewpoints capture logical relationships rather than isolated points
• Personal Reflections section is filled in or has actionable placeholder prompts
• Valid Obsidian syntax (callouts, wikilinks, highlights)
• Language matches the user's language
• Note saved in the correct category subdirectory
• Index entry added
• Forward wikilinks point to existing notes in the vault (or confirmed no match)
• Backlinks added to relevant existing notes (or confirmed no match)
• MOC updated: recent inclusions list and category article count (if the MOC exists)