/release

description: Walk through the release checklist interactively
allowed-tools: Read, Grep, Write, Edit, Bash(git fetch *), Bash(git checkout *), Bash(git switch *), Bash(git pull *), Bash(git add *), Bash(git commit *), Bash(git push *), Bash(git status*), Bash(git diff*), Bash(git log*), Bash(git branch *), Bash(gh issue view *), Bash(gh issue edit *), Bash(gh issue comment *), Bash(gh issue close *), Bash(gh pr view *), Bash(gh pr list *), Bash(pwsh -Command ./src/scripts/*), Bash(pwsh -Command "./src/scripts/*")

Release

Phase 1: Setup

Fetch origin and create a release prep branch (`{username}/{versionTag}-prep`, e.g., `flanakin/v14-prep`) from `origin/dev`. If the branch already exists locally, switch to it and pull. Push the release prep branch. DO NOT push to origin/dev directly!

pwsh -Command "./src/scripts/Start-Release.ps1 -OutputFile (Join-Path ([System.IO.Path]::GetTempPath()) 'ftk-release.json')"

Read the JSON file from the temp path printed in the output. Report the release issue URL and milestone summary to the user.

Phase 2: Core features

Do the following in parallel:

1. **Launch background build/test commands.** Use Bash with `run_in_background` for each:

• `pwsh -Command ./src/scripts/Build-Toolkit.ps1`
• `pwsh -Command "./src/scripts/Test-PowerShell.ps1 -Unit"`
• `pwsh -Command "./src/scripts/Test-PowerShell.ps1 -Lint"`
• `pwsh -Command "./src/scripts/Test-PowerShell.ps1 -Integration"`

2. **Triage milestone items** using the layered approach below.

Milestone triage

Analyze all milestone items and recommend keep vs push for each. The release is expected within ~7 days, so push anything complex unless it's a bug fix or a feature explicitly targeting this release. Use labels, titles, and summaries to judge — don't over-explain your reasoning in questions.

Group items by topic, then present via AskUserQuestion. Use the version tag from the JSON (e.g., "v14") and the next milestone title (e.g., "v15") in option labels.

**Round 1: Bulk triage by group** (up to 4 groups per AskUserQuestion call).

• **Header:** 1-3 word group name
• **Question:** Plain text, no formatting. "{count} items: #{number} {short title}, #{number} {short title}, ..." Titles 3-5 words each.
• **Options:** Recommendation first with "(Recommended)". Always include: "Keep all", "Push all", "Review individually".

**Round 2: Individual review** (only for groups where user chose "Review individually").

• **Header:** "#{number}: {1-3 word title}"
• **Question:** Plain text summary from JSON data, up to 100 words. State your recommendation and why.
• **Options:** "Keep in {version} (Recommended)" or "Push to {next version} (Recommended)" (whichever you recommend first), the other option, and "Investigate further".
• If "Investigate further" is chosen, fetch details via `gh issue view {number}`, provide deeper analysis, and re-present.

**After triage:** Report which items are staying, pushed, or skipped. Apply changes via `gh issue edit {number} --milestone {version}` — this works for BOTH issues and PRs. Do NOT use `gh pr edit` (not in allowed-tools). Run one command per item, not chained with `&&`.

Build/test results

After triage, check on the background agents. If all passed, report a brief summary. For each failure, show the error output and present via AskUserQuestion with options: "Investigate and fix", "Skip for now".

Changelog review

Read @docs-mslearn/toolkit/changelog.md and review the current version section against the changelog standard in @docs-wiki/Coding-guidelines.md. Apply fixes directly — no AUQ needed. Specific checks:

• Only one version section for this release (no duplicates).
• Unreleased section should be empty (we release from dev). Flag any content there.
• Tool sections match the order from the previous release. Flag any new tools or reordering.
• Categories in order: Added, Changed, Fixed, Deprecated, Removed. Empty categories omitted.
• Every entry starts with a past-tense verb, ends with a period, follows content guidelines.
• Entries are concise. Trim verbose or implementation-detail-heavy text.
• Issue links present where applicable, formatted as `([#{number}](url))`.
• Breaking changes prefixed with `**Breaking:**` and listed first in their category.
• No filler entries ("various bug fixes", "minor improvements").
• Entries placed in the correct category (e.g., new things under Added, not Changed).

After applying fixes, show a summary of what was changed so the user can review.

What's new blurbs

Use Grep to find all `<div id="whats-new">` blocks in `/docs/`, then use the Read tool to inspect each match. Do NOT use `sed`, `cat`, `head`, or `tail` — they are not in allowed-tools. For each block: if the tool has a section in the changelog, uncomment the block (if needed) and update the month, year, version tag, and paragraph with a 1-2 sentence summary. If the tool has no changelog section, comment out the block.

FinOps hubs documentation

Review the changelog's FinOps hubs section and update the following files for any applicable changes. Hub schema version changes (e.g., v1_0 → v1_2) are the primary trigger — update the upgrade guide (steps 7 and 8), data model, data processing, and compatibility chart. Also review for other changelog-driven updates like new datasets, renamed columns, or deprecated functions.

• @docs-mslearn/toolkit/hubs/upgrade.md
• @docs-mslearn/toolkit/hubs/data-model.md
• @docs-mslearn/toolkit/hubs/data-processing.md
• @docs-mslearn/toolkit/hubs/compatibility.md

New tool check

If `NewTools` in the JSON lists any new tools (tool sections in this release's changelog that weren't in the previous release), present via AskUserQuestion:

• **Header:** "New tools"
• **Question:** "{count} new tool(s) in this release: {names}. These may need marketing pages, MS Learn docs, TOC entries, and an advisory council update. Are all set up?"
• **Options:** "Yes, all done", "No, help me