grouping-releases
Grouping Releases
What this is for
Releases enter the index from sources — individual URLs we track for an organization. One org typically has several sources: a product changelog, a news page, an engineering blog, a GitHub repo. When a big launch happens, it's common for multiple sources to cover the same event. A model launch might show up on a marketing post, a platform changelog, and an app-level version note — three releases, one story.
That overlap is signal, not a bug. Readers want the clearest explanation first, with the corroborating entries attached as supporting coverage. This skill decides which releases belong together and which one leads.
When this skill runs
Not at ingest. Ingest-time grouping is deterministic code — the changesets clusterer (clusterAndPersistCascades, decided_by = "system:changesets") links version-cascade coverage automatically as releases land. This skill is the operator lane for the judgment calls that code can't make:
- Batch reconciliation. Reviewing a window of an org's recent releases (e.g.
releases tail --org <org> --json) and deciding the full grouping — typically after a big launch scattered coverage across a marketing post, a changelog entry, and an app note. - Fixing a bad grouping. Unlinking a wrong cluster or re-pointing the canonical.
Scope the candidate set explicitly before judging (an org + a date window). Do not go looking beyond it.