Menu
Use when asked to prepare new Flet release by bumping versions and author release notes.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Implement a new Flet extension/control that wraps a third-party Flutter package end-to-end, including dependency selection, version pinning, compatibility checks, Python/Flutter integration, docs, examples, tests, and CI updates. Use when adding any flet_* package backed by an external pub.dev package.
Use when adding or changing deprecations for Python controls/APIs in sdk/python/packages/, including V.deprecated fields, deprecated decorators, version lifecycle, and docs admonitions/labels.
Use when testing or debugging Flet apps in maintainer/contributor development mode with local Python package sources and the local Flutter client, including web, desktop, browser, and computer-use verification workflows.
Use when writing or reviewing Flet documentation, including Python docstrings (Google style, reST roles, admonitions), Markdown docs (cross-references, images, code examples), and sidebar navigation.
Use when asked to add, revise, or review a changelog or release-notes entry in this repo. Inspect the existing changelog section style and the relevant PR, issue, and commit context first, then write a focused entry in the correct release section without overstating docs, tests, or chores unless they are the primary user-facing change.
Use whenever editing validation for Python controls in sdk/python/packages/: adding/changing constrained properties, `Raises: ValueError` docstrings, `before_update()` checks, `raise ValueError`, Annotated/V rules, or __validation_rules__.
Based on SOC occupation classification
| name | prepare-flet-release |
| description | Use when asked to prepare new Flet release by bumping versions and author release notes. |
Always use flet-deprecation during release prep
to audit deprecations for the target version. Also use it when release prep includes:
delete_version equals this release version,Use write-changelog-entry for drafting or refining individual changelog items.
That skill is the source of truth for item wording, scope selection, and what should or should not be mentioned in a single entry.
main and create a new branch named prepare-release-{new_version} from main.packages/flet/CHANGELOG.md and /CHANGELOG.md from the git log since the last release.
write-changelog-entry for every individual item.{version} milestone attached on GitHub.{version} milestone, update the milestone on GitHub and keep the link in the changelog.packages/flet/CHANGELOG.md, prefer items with meaningful Flutter-side impact.sdk/python/packages/*/CHANGELOG.md, prefer published Python-facing changes; do not include extension-internal Flutter implementation work unless it materially changes user-visible Python behavior.website/docs/release/release-notes.md and
website/docs/release/breaking-changes/index.md.
flet-deprecation for deprecation
guide requirements and sidebar placement.website/sidebars.yml.Unreleased sections, not only the root ones:
/CHANGELOG.mdpackages/flet/CHANGELOG.mdsdk/python/packages/*/CHANGELOG.md
Recommended check command:
rg -n "^##\\s*\\[?Unreleased\\]?|^##\\s*Unreleased" -S CHANGELOG.md packages/flet/CHANGELOG.md sdk/python/packages/*/CHANGELOG.mdUnreleased section, convert that section into the new release section (## {new_version}), preserving and re-sorting its items. Do not leave duplicate release content in both Unreleased and {new_version}.
This conversion must be done for every matched changelog from the scan above.Breaking changes, and
keep newly deprecated-but-still-working APIs under Deprecations.sdk/python/templates/ and automatically packaged as zip artifacts with the GitHub Release. No manual branch creation in external repos is needed.