Release intelligence sounds simple: read sources, summarize the important updates, publish the useful ones.

The hard part is not the first good summary. The hard part is staying trustworthy after the pipeline runs every day.

Shipstone is built around one operating idea: every public brief should be explainable.

Crawl less, know more

A useful source list is not just “more feeds.” It needs balance:

  • official blogs for release truth
  • engineering blogs for implementation detail
  • changelogs for version changes
  • research feeds for early signals
  • video sources when the release happens on YouTube first

Broad news sources can help, but they need stricter filtering. If they flood the system with weak items, they reduce trust.

Store the process

The pipeline stores more than the article:

  • source selected
  • fetch status
  • parse result
  • item version
  • relevance decision
  • summary candidate
  • quality rejection or approval
  • social delivery status

That sounds heavy for a small project, but it is what lets the operator answer practical questions:

  • Did the source fail or did it publish nothing relevant?
  • Was the item skipped because it was stale, duplicated, or off-topic?
  • Was the summary generated by the current prompt?
  • Did Telegram and Bluesky receive the same briefing?

If the answer is not in the database, the system is guessing.

Reject boring summaries

The public brief should not copy the title and pad it with generic impact text. A useful brief says what changed and why an engineer should care.

A good summary is specific:

  • names the release, paper, API, or platform change
  • states the practical impact
  • gives a next action when there is one
  • avoids pretending every update is urgent

Weak summaries should be rejected before publishing. The rejection is not failure. It is quality control.

Social delivery is part of the system

Posting to Bluesky and Telegram should not be a separate script that forgets what it did.

Shipstone queues delivery in D1, posts only approved current summaries, stores the provider reference, and spaces different briefings at least one minute apart. If a bad post gets through, cleanup deletes it from the platform and marks the D1 row skipped.

That is the difference between autoposting and operated publishing.

The practical test

A release intelligence pipeline is ready when you can inspect:

  • what ran
  • what failed
  • what was rejected
  • what was published
  • what was posted socially
  • what was pruned later

Without that, the product may look alive, but it is not yet dependable.