content-summarizer

始终按以下七步工作流执行。每一步必须完成后才能进入下一步。

工作流

Step 0: 识别内容类型

若 $ARGUMENTS 为空（用户未提供 URL），询问用户提供 URL 后再继续。

多 URL 处理 — 若 $ARGUMENTS 包含多个 URL（用户希望合并总结）：

1. 从中提取所有 URL，对每个 URL 分别运行检测脚本
2. 确定一个主类型（以主要内容的类型为准，如一篇博客 + 一条推特讨论 → 主类型为 article）
3. 在 Step 1 中分别抓取每个 URL 的内容
4. 在 Step 2 中整合分析，生成一篇合并笔记，在笔记中为每个来源标注原始链接

必须运行检测脚本 — 使用 Glob 定位本 skill 目录下的 scripts/detect_content_type.py，然后用 python3 运行该脚本并传入 URL 作为参数（多 URL 时对每个 URL 分别调用）。不得跳过此步骤手动判断类型。脚本返回 JSON，包含 type、platform、fetcher、template、metadata 字段。脚本根据 URL 模式匹配返回 references/fetchers/ 下对应的策略文件路径和 references/templates/ 下对应的模板路径；未匹配已知平台时默认返回通用策略。

记录脚本返回的所有字段，进入 Step 1。若脚本执行失败或返回无法解析的结果，回退到默认值：type=article、fetcher=references/fetchers/common.md、template=references/templates/article.md。

Step 1: 抓取内容

先用 Glob 将 fetcher（相对路径）解析为 skill 目录内的唯一绝对路径，再用 Read 读取该绝对路径对应文件，遵循其中的抓取策略获取内容。严格按策略中的优先级顺序尝试，首选方案失败后再尝试下一个。

若 fetcher 解析失败（0 个或多个匹配），回退到 references/fetchers/common.md 并重复“Glob 解析绝对路径 → Read”流程；仍无法唯一定位时终止并报告错误。

平台专用抓取规则（如 Twitter/X）只在对应 references/fetchers/*.md 中维护；主 SKILL.md 不重复定义。读取到专用 fetcher 后，必须完整执行其“抓取策略”“验证门”和字段映射约定。

所有类型均需估算阅读元数据：

• word_count — 大致字数（中文按字数，英文按 word count）
• reading_time — 预估阅读时长（中文 300 字/分钟，英文 200 words/min，向上取整，格式 "N min"）
• difficulty — 内容难度：beginner（无需背景知识）、intermediate（需要一定领域了解）、advanced（需要深度专业知识）

抓取失败时（URL 不可达、404、paywall、内容为空）：

• 告知用户失败原因
• 请用户手动提供内容（粘贴文本或提供替代 URL）
• 获得内容后继续 Step 2

验证门：确认已获取到有效的正文内容后才能进入 Step 2。如果抓取结果为空或仅含导航/广告文本，视为抓取失败。

Step 2: 分析与摘要

遵循 Step 1 已读取的 fetcher 文件中的分析策略和评分解读处理内容。

所有类型均需完成：

2a. 提取核心信息 — 按类型特定的策略提取

2b. 生成一行摘要（description 字段）— 用于 frontmatter、索引条目和快速浏览的单句摘要

2c. 评分 — 按三个维度（1-5 分）评估内容：

维度	1（低）	3（中）	5（高）
novelty	广为人知的常见知识	有部分新角度或新组合	全新观点或鲜为人知的信息
quality	缺乏论据、逻辑松散	论证基本完整但不算深入	论证严密、证据充分、来源权威
actionability	纯理论/纯新闻，无可执行要点	有一些可参考的建议	提供具体步骤/代码/工具可直接应用

各维度在不同内容类型下的具体解读见对应 fetcher 文件的"评分解读"section。

计算 overall_score 为三项评分的四舍五入均值。根据 overall_score 确定 recommended_action：

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

以用户语言输出摘要（用户使用中文时默认中文）。

Step 3: 确定输出路径

发现输出根目录 — 扫描目录树，定位存放笔记的目录（查找 frontmatter 中含 source: 的 Markdown 文件所在目录，或名称暗示内容集合的目录）。如有多个候选或找不到，询问用户。

分类目录发现（动态推断）：

1. 扫描输出根目录下的现有子目录，推断命名惯例
2. 将内容匹配到现有分类子目录
3. 需要时创建新分类，遵循现有命名惯例
4. 用户显式指定路径时优先使用

Step 4: 写入 Obsidian 笔记

4a. 读取模板 — 先用 Glob 将 template（相对路径）解析为 skill 目录内的唯一绝对路径，再用 Read 读取模板文件，确保笔记结构严格匹配模板。不得凭记忆构建笔记结构。若 template 为 null，根据判断的类型选择：

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

若模板路径解析失败（0 个或多个匹配），按上面的类型默认值回退，并重复“Glob 解析绝对路径 → Read”流程；仍无法唯一定位时终止并报告错误。

4b. 标签对齐 — 写入笔记前，用 Grep 搜索 vault 中所有 frontmatter tags（搜索模式 ^ - 在 *.md 文件中），收集已有标签集合。为新笔记选择标签时：

• 优先复用已有标签（如 vault 中已有 架构 则不创建 软件架构）
• 仅在确认无近义已有标签时才创建新标签

4c. 写入笔记 — 遵循所选模板的结构、callout 用法和适配规则。如果项目的 CLAUDE.md 要求使用 obsidian-markdown skill，该 skill 提供基础格式规范，笔记模板在其上叠加内容特定结构。

个人反思 section：用对话上下文（用户为什么分享此内容、正在做什么）草拟初始条目。上下文不足时留占位提示。

多媒体处理：遵循 references/templates/article.md 中的"多媒体处理"指南。

保存笔记到 Step 3 确定的分类子目录。

Step 5: インデックスを構築する

新しいノートを vault のインデックスシステムに統合します。

1. インデックスファイルが存在することを確認する — カテゴリのサブディレクトリで既存の *INDEX* または *index* ファイルを探し、命名パターンを確認します。見つからない場合は、references/templates/index.md に従って作成します。

2. インデックス項目を追加する — 形式：- `YYYY-MM-DD` [[Title]] - description。公開日順に並べます（新しいものが先頭）。publish が利用できない場合は、creation の日付を使用します。

3. 順方向リンク — ノート本文で [[wikilinks]] を使い、vault 内にある関連概念のノートへリンクします。具体的な手順：

   • Grep を使って、ノートに含まれる重要な概念語（技術用語や方法論の名称など）を vault 内で検索します。
   • 一致する既存のノートが見つかったら、本文の関連する箇所に [[wikilink]] を挿入します。
   • 一致するものが見つからない場合、新しいノートを作成する必要はありません。既存のノートのみリンクします。

4. 逆方向リンク — 最も関連性の高い既存ノートを1〜3件選び、新しいノートへの wikilink を追加します。具体的な手順：

   • Grep を使って、現在の内容のテーマに関連するノート（キーワードや同じタグを含むもの）を vault 内で検索します。
   • 見つかった関連ノートの中から適切な場所（「関連記事」「おすすめリソース」「個人的な振り返り」の関連部分など）を選び、リンクを追加します。
   • 明らかに関連する既存ノートが見つからない場合は、無理に追加せず、この手順を省略します。

5. MOC を更新する — 出力ルートディレクトリの親ディレクトリで *MOC* ファイル（例：0_Resources_资源库_MOC.md）を探します。

   • 「最近追加」リストの先頭に新しい項目を挿入します。形式：- `YYYY-MM-DD` [[Title]]。その MOC ファイルで明示されているリストの項目数の要件に従います。指定がない場合はデフォルトで10件以下とし、最も古い項目を削除します。
   • カテゴリの統計表で該当するカテゴリのノート数を更新します（そのカテゴリの INDEX ファイルの項目数を数え直します）。
   • 新しいカテゴリの場合（表に存在しない場合）は、表の末尾に行を追加します。
   • MOC ファイルが見つからない場合は、この手順を省略します。

Step 6: 品質を確認する

以下のチェックリストを項目ごとに確認します。不足が見つかった場合はすぐに修正し、すべての項目に合格してから完了とします。

• Frontmatter が完全である：tags, type, source, authors, publish, creation, date_saved, word_count, reading_time, difficulty, status, novelty, quality, actionability, overall_score, recommended_action, description
• 読書メタデータが存在する：word_count, reading_time, difficulty
• AI 評価が存在する：novelty, quality, actionability, overall_score, recommended_action
• 内容の種類が正しく識別されている（article / repo / thread）
• ノート本文の構成が内容の種類に対応するテンプレートと一致している（Step 4a でテンプレートを読み込んで確認済み）
• Tags が vault 内の既存タグと一致している（Step 4b で検索して確認済み）
• TL;DR がタイトルの直下にあり、frontmatter の description と一致している
• 元のリンクが TL;DR の上にある
• 重要な見解で、孤立した要点ではなく論理関係が捉えられている
• 個人的な振り返りのセクションに内容が記入されているか、実行可能なプレースホルダーの指示がある
• 有効な Obsidian 構文が使用されている（callouts, wikilinks, highlights）
• 言語がユーザーの言語と一致している
• ノートが正しいカテゴリのサブディレクトリに保存されている
• インデックス項目が追加されている
• 順方向の wikilinks が vault 内の既存ノートを参照している（または一致するものがないことを確認済み）
• 関連する既存ノートに逆方向リンクが追加されている（または一致するものがないことを確認済み）
• MOC が更新されている：最近追加リストとカテゴリ別のノート数（MOC が存在する場合）