User confirmation workflows and interaction patterns for obtaining approval
at critical points to prevent repeated edits and ensure accuracy.
After PR analysis, before writing release notes
Verify which features to highlight
I've analyzed all PRs for v[VERSION]. Here are the changes I found:
**Major Features:**
[List major features with brief descriptions]
**Bug Fixes:** [COUNT] fixes
**QOL Improvements:** [COUNT] improvements
**Other Changes:** [COUNT] items
Which features should I highlight with expanded sections in the release notes?
Highlight all major features as listed above
Focus on [specific feature 1] and [specific feature 2]
Keep all changes in grouped sections (no expanded features)
Let me specify which features to expand
]]>
Do not proceed unless the response clearly matches one of the provided options.
If the user types a freeform response, re-ask using ask_followup_question with options reformulated from their input; require selection of one provided option.
Repeat this gating loop until a provided option is explicitly selected.
To proceed I need an explicit selection. Based on your input, which option should I follow?
Highlight all major features as listed
Highlight only: [feature A], [feature B]
Keep everything grouped (no expanded sections)
Let me specify which features to expand
]]>
After fetching PRs and before feature selection
Partition PRs by presence in the changelog and select inclusion policy
Present counts and reasons for exclusion, then offer three paths:
- Only changelog PRs
- All PRs
- Review excluded PRs one by one
Changelog alignment for v[VERSION]: [IN_COUNT] PRs referenced, [EX_COUNT] not referenced. How should I proceed?
Only include the PRs referenced in the changelog
Include all PRs from the date range
Review each excluded PR one by one so I can choose
]]>
Include PR #[NUMBER] - [TITLE]? Short analysis: [USER IMPACT / WHY IT MATTERS].
Yes, include this PR
No, skip this PR
]]>
Do not proceed until an explicit option is selected.
For freeform answers, re-ask with options that reflect the user's intent; require selection.
After creating patch notes, before updating combined notes
Ensure patch notes are final before propagating
NEVER update combined notes until explicit confirmation
I've created the release notes for v[VERSION]. The file includes:
- [COUNT] bug fixes
- [COUNT] QOL improvements
- [COUNT] other changes
Would you like to review before I update the combined v[X.Y] notes?
Show me the release notes file for review
The content looks good, proceed with all updates
Let me make some adjustments first
Change the emphasis on certain features
]]>
After identifying documentation flags
Confirm documentation update requirements
I've identified [COUNT] items that need documentation updates:
[List of flagged items with docs-new, docs-update, etc.]
Should I create a documentation update task after completing the release notes?
Yes, create the documentation task with all items
Create task for new features only
Skip documentation task for now
Let me review the specific items first
]]>
After all updates complete
Final confirmation before PR creation
I've completed all updates for v[VERSION]:
✓ Release notes created
✓ Index and sidebar updated
[✓ Combined notes updated - if patch]
[✓ Documentation tasks identified: [COUNT] - if any]
Would you like to create a PR or make any final adjustments?
Create a PR with all changes
Show me all modified files
Make additional adjustments
Create documentation update task first
]]>
User says "latest"
Detect missing versions from changelog
Present found versions
I found [COUNT] versions in the changelog that don't have release notes:
[List versions]
Which would you like to process?
All missing versions ([list])
Just the most recent version
Let me select specific versions
Show changelog entries first
]]>
Each adjustment triggers new confirmation cycle
User requests change
Apply specific change only
Show result of change
Ask for confirmation before proceeding
Reorder sections
Change feature emphasis (expanded vs grouped)
Edit descriptions or benefits
Add missing items
Discord release notes for X.Y.Z
Generate Discord format for one version
Combine multiple versions
Compress minor items if over 2000 chars or on request
User says "compress", "condense", or content exceeds 2000 chars
Keep Feature Highlights section intact
Count all improvements below Feature Highlights
Replace all sections with single "Other Improvements and Fixes" paragraph
Include contributor acknowledgments in compressed section
- Verify actual count of improvements (not estimate)
- Ensure all contributors are acknowledged
- Maintain markdown code block wrapper
How would you like the Discord announcement formatted?
Standard format with all details
Compressed format (group minor items)
Highlights only (major features)
Multiple versions combined
]]>
Combined Discord announcement for multiple versions
Identify all versions to combine
Read release notes for each version
Merge and format according to Discord rules
Present formatted output in markdown code block
- Title uses version range (X.Y.Z-X.Y.Z)
- Intro sentence summarizes all versions
- Features merged and deduplicated
- No version numbers in body text
- Footer has links to each version
- Entire output wrapped in ```markdown block
- No "Happy coding!" or similar closings
- "Feature Highlights" not "Major Features"
I'll create a combined Discord announcement for versions [list]. Should I:
Include all features and changes from all versions
Focus on major features only
Group similar changes across versions
Create separate announcements for each version
]]>
Never assume approval - require explicit confirmation
For patch releases, always confirm before updating combined notes
Show concrete examples in confirmation questions
Provide clear options covering common scenarios
Order suggestions by likelihood or importance
Keep confirmation cycles focused on specific decisions
Track confirmation state to avoid re-asking
Release notes file doesn't exist for Discord format
The release notes for v[VERSION] don't exist yet. Would you like to:
Create the release notes first
Process a different version
Cancel the Discord format request
No PRs found in date range
No PRs found for the specified date range. This might mean:
Try a wider date range
Check if the version tag exists
Manually provide PR numbers
Cancel and investigate