Use These Prompts to Analyse Competitor Changelogs

A changelog is the friendliest competitor source there is. Everything is already in order, everything has a date, and nothing has to be interpreted. That is exactly what makes it easy to over-read.

Start with the dates, because they are doing more than one job. On the developer changelog we used for the run below, most entries are stamped with the day the change was announced. A few are stamped with the day it went live. Both sit in the same column, in the same format. An entry announced in August and one that shipped in August are a month or more apart in reality.

The second thing to hold on to is who wrote the entry. Somebody decided this piece of work was worth telling customers about, and wrote it in words chosen for customers. Plenty of engineering never gets an entry at all. A changelog is a record of what was published, and that is a narrower thing than a record of what was built.

Three passes. The first reads the period, the second splits a stream that is carrying two opposite things, and the third only works once you have a second capture to compare against.

Notice what the first one forbids. It may not infer a roadmap, and it has to say where the period is too short to read. Both rules are there because the opposite is the default behaviour, and the section below shows what that looks like.

Three inputs, and the third is the one nobody has. A period only means something against another period, and a model has no memory of what the same changelog looked like in spring.

Copy the entries rather than summarising them. A one-line summary of a release note has already thrown away the vocabulary, and the vocabulary is where a theme is visible. Two entries that both say “agent” are a pattern. The same two, summarised as “automation improvements”, are not.

We pasted the ten entries showing on a real developer changelog, with their dates, and asked two questions about them. Both answers are good. One sentence in each is not supported by anything on the page.

A date range built from two kinds of date

The themes in the first answer are fair. Every entry is real and every grouping is one a person would defend. The date ranges beside them are not fair, and they are the part that would travel into a report.

Seven of those ten dates mark an announcement. Three mark the day something went live. Adding them produces a range that describes neither. The entry titled August 2026 Rollup sits under 31 July, so a range ending in July contains a month of work that had not happened yet.

Concentration needs something to compare against

The second answer says effort is concentrated on the platform. Concentrated compared with what? There is no earlier period in the context window, so the claim is really a description of the only period the model can see. A vendor who always spends six entries in ten on platform work looks identical to one who has just started.

The closing line is the one to watch. A period with no migration tooling in it is an observation about ten entries on page one of a paginated log. Absence from a sample is not absence from the record, and the answer does not distinguish the two. That is why the prompt asks for the counts behind every claim: a claim with a denominator attached can be argued with.

Six of the ten entries take something away. They retire an API, disable a way of building apps, drop support for two runtimes, or tighten a rule so that code which used to work stops working. The other four add or describe something new.

Both kinds sit in one list, in one typeface, with nothing separating them. A theme count run over the whole stream mixes them, and the mixture is what produces a sentence like “heavy investment in the platform”. Retiring things and building things are both platform work. They are not the same signal.

The withdrawals are worth pulling out for a reason that has nothing to do with tidiness. A withdrawal names a date on which a known set of their customers has to do unplanned work. Very little else in a competitor’s public record comes with a scheduled moment attached, and a scheduled moment is something a sales team can plan around. A weekly competitor digest that carries one line about a sunset date three months out is more useful than the same digest listing five new features.

The same split is worth keeping when the output lands somewhere permanent. A competitor tracking sheet with one column for what was added and another for what was withdrawn answers a question a single feed of entries cannot: whether their product is getting broader or narrower.

The reading you have just done covers whatever was on the page the day you copied it. Changelogs are paginated and older entries drop off the first screen. A quarter from now, the period you analysed will be two clicks deep and the entries around it will have changed.

That matters more here than for most sources, because the value of a changelog is almost entirely in the comparison. One period tells you what a team was working on. Two periods tell you whether that changed, which is the only version of the question anybody acts on. Keeping the first capture is what makes the second one worth running.

There is also a gap no reading closes. A changelog says what shipped. It does not say what it cost them, whether customers adopted it, or what was cancelled before it got an entry. Those are the questions a release log is structurally unable to answer, and no prompt recovers them.

Flares watches competitor changelogs and release notes as they publish, and keeps each entry with the date it appeared. The period you sit down to analyse is then already assembled, including the entries that have since scrolled off the first page.