prep-release
Skill455 starsChanged 4 months agoMITView on GitHub
Prepare a new wigglystuff release. Follow these steps:
- Commits and pushes
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 4 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 7
Determine the new version: Read pyproject.toml for the current version and the latest entry in CHANGELOG.md.
- Very specific: line 12
Use ## [x.y.z] - YYYY-MM-DD header with today's date
- Very specific: line 13
Add ### Added, ### Changed, ### Fixed, or ### Removed subsections as appropriate
- Distinctive: line 14
Look at the git diff against main to determine what changed
- Distinctive: line 26
Place them in the "3rd party widgets" section of the galleries (not the main gallery)
- Distinctive: line 27
Use a molab link for the demo instead of a local example page
- Very specific: line 28
Use MOLAB_LINK_HERE as a placeholder if the molab link is not yet available and tell the user they need to fill it in
- Distinctive: line 35
Verify nothing is missed: Check the git diff to make sure all new/changed widgets have corresponding updates in all locations listed above.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Release Preparation
Prepare a new wigglystuff release. Follow these steps:
Instructions
- Determine the new version: Read
pyproject.tomlfor the current version and the latest entry inCHANGELOG.md. If the version has already been bumped, use that. Otherwise, bump the patch version (e.g., 0.2.24 -> 0.2.25). - Bump version in
pyproject.toml(if not already done). - Add a changelog entry at the top of
CHANGELOG.mdfollowing the existing format:- Use
## [x.y.z] - YYYY-MM-DDheader with today's date - Add
### Added,### Changed,### Fixed, or### Removedsubsections as appropriate - Look at the git diff against
mainto determine what changed
- Use
- Update all documentation locations for any new widgets:
docs/reference/<widget-name>.md— create a reference doc following the pattern in existing reference pages (use::: wigglystuff.module.ClassNamemkdocstrings directive + a synced traitlets table)zensical.toml— add the widget to thenavReference sectiondocs/index.md— add to the appropriate gallery section (main gallery or 3rd party gallery)readme.md— add to the appropriate gallery table (main gallery or 3rd party table)docs/llms.txt— add a one-line entry in the appropriate sectionCLAUDE.md— add a row to the quick reference tablewigglystuff/__init__.py— verify the widget is imported and listed in__all__
- For 3rd party widgets (those requiring non-core dependencies like neo4j, torch, wandb):
- Place them in the "3rd party widgets" section of the galleries (not the main gallery)
- Use a molab link for the demo instead of a local example page
- Use
MOLAB_LINK_HEREas a placeholder if the molab link is not yet available and tell the user they need to fill it in - Screenshot path should be
docs/assets/gallery/<widgetname>.webp— tell the user if one is missing (runuv run python scripts/png_to_webp.pyif a PNG was added)
- Check dependencies: Read
pyproject.tomland verify that no 3rd party widget dependency (neo4j, torch, wandb, etc.) has been added to core[project] dependencies. These must only appear under[project.optional-dependencies]as extras. Core dependencies should only include packages needed by all widgets (anywidget, numpy, pillow, python-dotenv). If a 3rd party dep has leaked into core dependencies, remove it. - Bump demo
wigglystuff==X.Y.Zpins: Everydemos/*.pynotebook has a PEP 723# /// scriptheader pinning a publishedwigglystuffversion. For any demo that was added or modified in this release (anything ingit diff origin/main -- demos/since the previous tag), update its pin to the new version. Otherwiseuv run demos/<name>.pywill fetch the old release and the new feature will be missing. Grepdemos/ -l "wigglystuff=="to find pins; you do not need to bump untouched demos. - Verify nothing is missed: Check the git diff to make sure all new/changed widgets have corresponding updates in all locations listed above.
- Commit, push, and open a PR — but do NOT merge. Run the mechanics without asking for confirmation: commit the release changes, push the branch, and open a PR against
main(gh pr create --base main). Then STOP — leave the merge to the user; never rungh pr merge. Only pause earlier if there's a genuine blocker (failing tests, merge conflicts, ambiguous diff) — not for the commit/PR steps themselves. - Report what was done and what still needs manual action (e.g., adding screenshots, replacing molab link placeholders).
In this repository17 other files it gives its agents.
- AGENTS.mdAGENTS.md
- docs/llms.txtllms.txt
- brainstormingSkill
- dispatching-parallel-agentsSkill
- executing-plansSkill
- explain-diff-htmlSkill
- finishing-a-development-branchSkill
- receiving-code-reviewSkill
- requesting-code-reviewSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- using-superpowersSkill
- verification-before-completionSkill
- writing-plansSkill
- writing-skillsSkill
- anywidget-devSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

