How to use the Changelog Breaking Change Extractor.
A breaking-change extract should identify the old behavior, new behavior and stated migration action. Do not treat every release note as a breaking change.
Make the workflow fit your task.
Locate changes explicitly described as incompatible, removed or requiring migration. Record the affected version, previous behavior, replacement and supplied migration action. Keep deprecations with future removal dates separate from changes that already break existing integrations.
- What you provide
- Visible release documentation.
- What you get
- Breaking changes and required migration actions.
See the input and the result.
Illustrative input and output · a teaching example, not a live WebAct run
Example input
Release notes say field full_name is replaced by display_name in version 2.
Completed example
Breaking change: consumers using full_name must review the version-2 response and migrate to display_name as documented.
Load this input into the prompt, then copy it to WebAct to try the task. Your result may differ from the illustration.
Decisions and troubleshooting.
Is every deprecated feature already a breaking change?
No. Deprecation can precede removal. Preserve the timeline and current support status stated in the release notes.
Why is the migration action unclear in the changelog?
The release note may point to a separate guide or omit implementation detail. Retain that gap rather than inventing replacement behavior.
Try it with your own source.
Replace the example with your material in the task prompt. Keep the requirements you need, then copy the task into WebAct.
Customize and copy the task ↑