analyzing-releases git:20260424.d324276A

Immutable. This exact content never changes and is served at /api/v1/blob/b8526f982800ee31.

---
name: analyzing-releases
description: >
  Analyze release trends across multiple companies to produce competitive
  intelligence. Use when asked to compare companies, analyze a market segment,
  identify industry trends, forecast upcoming releases, or answer questions
  like "what is X shipping lately" or "how does X compare to Y." Also triggers
  on requests for competitive landscape analysis, feature gap analysis, or
  release velocity comparisons.
---

# Analyzing Releases

Turn changelog data into competitive intelligence by analyzing release patterns across a cohort of related companies.

## Key Operations

| Operation              | CLI                                           | Typed tool                                                            |
| ---------------------- | --------------------------------------------- | --------------------------------------------------------------------- |
| Check existing sources | `releases list --query <company> --json`      | `list_catalog` scoped to an org, or `search` with `type: ["catalog"]` |
| Fetch releases         | `releases admin source fetch <slug> --max 50` | `manage_source` action "fetch" with identifier (ID or slug)           |
| Get latest releases    | `releases tail <slug> --json`                 | `get_latest_releases` with source/org and limit                       |
| Search releases        | `releases search <query> --json`              | `search` with `type: ["releases"]`                                    |
| Summarize              | `releases summary <slug> --json`              | (not available as typed tool)                                         |
| Compare                | `releases compare <slugA> <slugB> --json`     | (not available as typed tool)                                         |

## Workflow

### 1. Define the cohort

Pick 3-6 companies in the same competitive space. Good cohorts share a common buyer or technical layer (e.g., developer databases, frontend frameworks, observability tools).

### 2. Check existing sources

Search for each company to see what sources are indexed. If a company isn't in the system, it needs to be onboarded first.

### 3. Fetch recent releases

Fetch each source. The system skips unchanged feeds automatically.

### 4. Get latest releases

Get structured release data with dates for each source. Use a limit (e.g., 50) to cap results. For org-wide views, filter by organization instead of individual source.

### 5. Search and cross-reference

Search across all indexed releases to find specific features, breaking changes, or patterns. The unified `search` tool is hybrid (lexical + semantic) by default — natural-language queries like "auth refresh tokens" or "cold start improvements" work without exact keyword matches. Pass `type: ["releases"]` to skip entity lookups when you only care about release content; pass `mode: "lexical"` if you need strict keyword behavior.

**Result shape:** release hits carry a `kind` discriminator:

- `kind: "release"` — a normal release row, use as-is.
- `kind: "changelog_chunk"` — a passage from a stored CHANGELOG.md file. The hit nests the payload under `chunk`: `chunk.source.slug`, `chunk.file_path`, `chunk.offset`, `chunk.length`. Chain into `get_catalog_entry({ identifier: chunk.source.slug, changelog_path: chunk.file_path, changelog_offset: chunk.offset, changelog_limit: chunk.length * 3 })` to read the surrounding section before quoting it — `changelog_path` is what routes monorepos with multiple CHANGELOG files to the right one. Chunk hits often surface older or more granular notes than what's in the indexed release rows, so they're useful for "when did X first ship" questions.

For org/product/source discovery (e.g. "find observability vendors with edge offerings"), pass `type: ["orgs", "catalog"]` to `search` — the catalog path is vector-backed on the entity index and matches on description and category, not just slug substring.

### 6. Synthesize

Combine summaries and comparisons into a structured analysis:

- **Release velocity table** — releases per company, cadence pattern
- **Trends adopted across the board** — features 3+ companies shipped in the same window
- **Differentiating bets** — what each company is investing in that others aren't
- **Gaps** — what competitors shipped that a company hasn't
- **Forecasts** — specific predictions based on pre-release tracks, deprecations, and trajectory

## Output

Ask the user where to save the analysis, or use your best judgment based on the project's conventions. Include a "Process Notes" section documenting which CLI commands were used so the analysis is reproducible.

## Important

- Focus on what companies shipped. If a source has noisy data (blog posts mixed in, missing dates), work around it silently. Don't include source quality commentary in the report unless a company had to be substantially excluded.
- Fill data gaps with web fetches. List sources to get release URLs, then WebFetch to spot-check pages for missing dates, versions, or feature details.
- For velocity counting, get the latest releases with dates — CLI: `releases tail <slug> --json`, typed tool: `get_latest_releases`.
- AI-powered summarize and compare are only available via CLI (`releases summary`, `releases compare`). When using typed tools, synthesize manually from raw release data.