Menú
Use when asked to prepare new Flet release by bumping versions and author release notes.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
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__.
| 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.