prompts.chatprompts.chat
Login
All classifiers
ChoiceSoftware delivery

Release note category

Sort a merged change into a release notes section: feature, fix, deprecation, or internal.

F@f

Problem

Release notes are assembled by hand from commit titles that rarely say who the change matters to.

Goal

Draft release notes with each change in the right section and internal work left out.

Input / state

PR title, description and labels.

title
PR title.
description
PR description.
labels
Existing labels.

Decision question

ChoiceQuestion key release_note_section

Which release notes section does this change belong in?

Options

  • featureNew capability users can see or use.
  • fixFixes behaviour users could notice.
  • breaking_changeChanges or removes behaviour users rely on, so they must act when upgrading.
  • deprecationAnnounces that something will be removed or changed later.
  • internalRefactoring, CI, tooling or tests that users won't notice.

Allowed outcomes

Decided in your code from the answer and its confidence. Thresholds are yours to set and test.

  • FeaturesChoice is feature and confidence meets your threshold.
  • FixesChoice is fix and confidence meets your threshold.
  • Breaking changesChoice is breaking_change and confidence meets your threshold.
  • DeprecationsChoice is deprecation and confidence meets your threshold.
  • Leave outChoice is internal and confidence meets your threshold.
  • Release managerConfidence is below your threshold: probability is spread across options.

Example scenarios

Predefined demonstrations. No model is called; the outcome shown is an illustrative judgment.

Example state

{
  "title": "Add YAML config support",
  "labels": [
    "enhancement"
  ],
  "description": "Config can now be written in YAML."
}

Outcome

Illustrative
Features

Choice is feature and confidence meets your threshold.

Why

A new user-facing capability.

Using it well

  • The release manager edits the draft. This only places changes; it doesn't write the release.

Request definition

POST https://api.typesafe.ai/v1/systemone
{
  "model": "jev-latest",
  "state": {
    "title": "<title>",
    "description": "<description>",
    "labels": "<labels>"
  },
  "questions": {
    "release_note_section": {
      "type": "choice",
      "instructions": "Which release notes section does this change belong in?",
      "criteria": {
        "feature": "New capability users can see or use.",
        "fix": "Fixes behaviour users could notice.",
        "breaking_change": "Changes or removes behaviour users rely on, so they must act when upgrading.",
        "deprecation": "Announces that something will be removed or changed later.",
        "internal": "Refactoring, CI, tooling or tests that users won't notice."
      }
    }
  }
}

Request shape from the System One API reference; a Kev server accepts the same body. Replace the placeholder state with your data. Requests need your own API key or server.

Version History

v1Current Versionabout 8 hours ago@f

Initial version

Comments (0)