菜单
Generates validated URL manifest from kb/SOURCES.yaml for a given DATE_RANGE. Use when starting Phase 1A of the newsletter pipeline. Reads SOURCES.yaml canonical URLs and feed endpoints, generates candidate URLs per source, validates existence, and outputs a manifest file. Keywords: url manifest, phase 1a, url generation, source discovery.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Validates newsletter output against quality standards. Use after Phase 4 assembly to verify the newsletter meets all requirements. Runs automated checks for required sections, link format, forbidden patterns, and structural compliance. Keywords: newsletter validation, quality check, post-pipeline, validation rubric.
Transforms the compiled Phase 3 working set into polished, newsletter-ready content sections, with Phase 1C discoveries used only as a missing-data fallback. Use when running Phase 3 of the newsletter pipeline. Selects and structures high-value items, applies GA/PREVIEW labels, and prepares complete section material for assembly. Keywords: content curation, phase 3, selection, formatting, enterprise relevance.
Fetches and extracts content from Phase 1A URL manifest into 5 interim files by source. Use when running Phase 1B of the newsletter pipeline. Processes URLs sequentially by source, extracts relevant items using universal extraction format, outputs one interim file per source. Keywords: content retrieval, phase 1b, web extraction, interim files.
Processes the human curator's monthly notes file into pipeline-ready content. Reads raw URLs, text hints, and structured sections from the curator's brain dump, classifies each item, filters internal/industry content, visits surviving URLs, and outputs processed items + editorial signals. Use between Phase 1C and Phase 3 when a curator notes file exists. Keywords: curator notes, brain dump, links file, monthly notes, human curation, editorial signals.
Extracts and formats upcoming events and webinars from provided URLs. Use when running Phase 2 of the newsletter pipeline after the Phase 1C discoveries receipt exists. Fetches event pages, classifies into canonical categories, formats virtual and in-person event tables. Keywords: events extraction, phase 2, webinars, conferences, event formatting.
Maintains kb/ knowledge base through automated polling and health checks. Use for monthly kb/ refresh, link health validation, and SOURCES.yaml updates. Polls RSS/Atom feeds for new content, validates canonical URLs, generates delta reports. Keywords: kb maintenance, knowledge base, link health, sources refresh, monthly maintenance.
| name | url-manifest |
| description | Generates validated URL manifest from kb/SOURCES.yaml for a given DATE_RANGE. Use when starting Phase 1A of the newsletter pipeline. Reads SOURCES.yaml canonical URLs and feed endpoints, generates candidate URLs per source, validates existence, and outputs a manifest file. Keywords: url manifest, phase 1a, url generation, source discovery. |
| metadata | {"category":"domain","phase":"1A"} |
Generate and validate candidate URLs from known sources for a given DATE_RANGE.
kb/SOURCES.yaml for canonical URLs and feed endpointsworkspace/newsletter_phase1a_url_manifest_YYYY-MM-DD_to_YYYY-MM-DD.mdworkspace/newsletter_phase1a_url_manifest_YYYY-MM-DD_to_YYYY-MM-DD.mdBefore generating URLs, verify DATE_RANGE has no gap with the previous newsletter. Check archive/ for the most recent newsletter to find its coverage end date. If a gap exists (e.g., previous newsletter covered through Dec 3, but current DATE_RANGE starts Jan 1), extend the START date backward to close the gap. Never leave uncovered days between newsletters.
For each source, generate candidate URLs using known patterns and DATE_RANGE months. See url-patterns.md for per-source URL architecture.
Key Innovation: Read kb/SOURCES.yaml for canonical URLs rather than guessing URL patterns. The YAML provides:
canonical_urls for each sourceupdate_feeds with type (RSS, Atom, API, none) and endpointslatest_known.version and latest_known.release_date for version-based URLsCRITICAL: VS Code Version Enumeration (L64 + L66)
Do NOT rely on SOURCES.yaml latest_known.version alone for VS Code. That field only contains the newest version. VS Code now ships weekly, so a 30+ day DATE_RANGE includes 4-5+ versions. You MUST:
https://code.visualstudio.com/updates (the index page)Example: A 30-day DATE_RANGE will typically include 4-5 weekly versions. All must be in the manifest.
Cross-cycle meta-analysis (L29, L30) shows these sources are consistently missed by changelog-only scanning but always appear in published newsletters. The manifest MUST include:
github.blog/changelog/YYYY/MM/) — primary, richest sourcegithub.blog/latest/page/1/) — catches strategic CPO/CEO postsgithub.blog/news-insights/company-news/) — major announcements NOT in changelogcode.visualstudio.com/updates/v1_{VERSION}) — deep feature contentdevblogs.microsoft.com/visualstudio/) — VS Copilot monthly updatesdevblogs.microsoft.com/devops/) — Azure ecosystem itemsplugins.jetbrains.com/api/plugins/17718/updates) — plugin versionsgithub.com/github/CopilotForXcode/blob/main/CHANGELOG.md) — Xcode versionslearn.microsoft.com/en-us/visualstudio/releases/2022/release-notes) — patches and CVEs onlyFor each source, fetch 1-2 URLs to confirm:
Verify the generated URLs span the full DATE_RANGE:
Output validated candidate URLs grouped by source with:
Named month in release titles often LAGS actual release date by 1-2 months.
| Example | Named Month | Actual Release Date |
|---|---|---|
| VS Code v1.105 | "September 2025" | October 9, 2025 |
| VS Code v1.106 | "October 2025" | November 12, 2025 |
Actual release dates govern inclusion, NOT the named month. Always verify actual release dates against DATE_RANGE boundaries.
workspace/newsletter_phase1a_url_manifest_*.md