Release Notes Generator

Generate release notes for a new Boundless release. The audience for broker changes is prover operators -- people running the broker who need to understand what changed, how to configure it, and how to migrate.

Process

Step 1: Gather inputs

Ask the user for:

1. Version number for this release
2. Previous release tag to compare against (e.g., v1.2.2)
3. Key PRs or features to highlight -- the user will tell you which PRs or topics matter. Don't try to cover every commit.
4. Current market context if relevant (e.g., current pricing in USD/Bcycle, token prices) for realistic examples

Step 2: Research

For each feature the user wants covered:

1. Fetch PR details with gh pr view <number> --repo boundless-xyz/boundless --json title,body
2. Read the actual code to understand how the feature works -- don't rely solely on PR descriptions
3. Read config structs, default values, and broker.toml template to get accurate config examples
4. Check compose.yml for env var support and justfile for how provers actually run things (just prover up)

Use subagents to research multiple PRs in parallel.

Step 3: Write the notes

Follow these principles:

Structure

• Start with a brief overview paragraph summarizing all highlighted features in one sentence
• Include a full changelog link: [vOLD...vNEW](https://github.com/boundless-xyz/boundless/compare/vOLD...vNEW)
• Each feature gets its own section with: what changed (1-3 sentences on the change, new paragraph, then 1-3 sentences on why it matters), how to use it (how to enable with examples)
• End with an "Upgrade Notes" section summarizing action items

Writing style

• Write for prover operators, not developers. Focus on config changes, CLI flags, and operational impact.
• Lead with what the user needs to do, not how the code works internally
• Be direct and concise. No filler, no marketing language.
• Use "the broker" not "we" or "the system"
• Don't use emojis

Config examples

• Show the recommended/minimal config first, not the full config with all options
• Use realistic values based on current market rates (ask the user if unsure)
• For broker.toml changes, always show the TOML syntax exactly as it would appear in the file. Show before + after if relevant.
• For CLI flags, show how to pass them via BROKER_EXTRA_ARGS in .env (since most provers use just prover up) AND as direct CLI flags
• For env vars, show the export syntax

Migration guides

• Show a clear before/after comparison with labeled TOML blocks
• Call out which fields are removed, renamed, or have new defaults
• Always note backward compatibility -- existing configs should work without changes unless there's a breaking change

Worked examples

• Use real order data where possible. Ask the user for a reference order from the explorer if they don't provide one.
• Convert all comparisons to USD when demonstrating USD-based features
• Show the math step by step so operators can verify their own config

Features to watch for

When researching broker changes, pay attention to:

• Pricing: min_mcycle_price, collateral pricing, pricing overrides in crates/boundless-market/src/prover_utils/config.rs
• Config: broker.toml template at broker-template.toml, MarketConfig struct
• RPC/monitoring: chain monitors, gas estimation in crates/broker/src/
• CLI flags: Args struct in crates/broker/src/lib.rs, check for BROKER_EXTRA_ARGS support in compose.yml
• Telemetry: crates/broker/src/telemetry.rs
• Hot-reload: note when config changes take effect without restart

Step 4: Iterate

The user will review and give feedback. Common adjustments:

• Reordering sections to lead with the most impactful change
• Adjusting example values to match current market conditions
• Adding or removing detail from specific sections
• Changing the framing of a feature (e.g., "show the simplification, not the mechanism")

References

Use v1.4.0 release from https://github.com/boundless-xyz/boundless/releases as a reference for tone, structure, and level of detail.