agentleFS
koaningkoaning/wigglystuff/.claude/skills/prep-release/SKILL.md

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
  1. Very specific:

    Determine the new version: Read pyproject.toml for the current version and the latest entry in CHANGELOG.md.

    line 7
  2. Very specific:

    Use ## [x.y.z] - YYYY-MM-DD header with today's date

    line 12
  3. Very specific:

    Add ### Added, ### Changed, ### Fixed, or ### Removed subsections as appropriate

    line 13
  4. Distinctive:

    Look at the git diff against main to determine what changed

    line 14
  5. Distinctive:

    Place them in the "3rd party widgets" section of the galleries (not the main gallery)

    line 26
  6. Distinctive:

    Use a molab link for the demo instead of a local example page

    line 27
  7. Very specific:

    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

    line 28
  8. Distinctive:

    Verify nothing is missed: Check the git diff to make sure all new/changed widgets have corresponding updates in all locations listed above.

    line 35

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Release Preparation

Prepare a new wigglystuff release. Follow these steps:

Instructions

  1. Determine the new version: Read pyproject.toml for the current version and the latest entry in CHANGELOG.md. If the version has already been bumped, use that. Otherwise, bump the patch version (e.g., 0.2.24 -> 0.2.25).
  2. Bump version in pyproject.toml (if not already done).
  3. Add a changelog entry at the top of CHANGELOG.md following the existing format:
    • Use ## [x.y.z] - YYYY-MM-DD header with today's date
    • Add ### Added, ### Changed, ### Fixed, or ### Removed subsections as appropriate
    • Look at the git diff against main to determine what changed
  4. 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.ClassName mkdocstrings directive + a synced traitlets table)
    • zensical.toml — add the widget to the nav Reference section
    • docs/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 section
    • CLAUDE.md — add a row to the quick reference table
    • wigglystuff/__init__.py — verify the widget is imported and listed in __all__
  5. 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_HERE as 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 (run uv run python scripts/png_to_webp.py if a PNG was added)
  6. Check dependencies: Read pyproject.toml and 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.
  7. Bump demo wigglystuff==X.Y.Z pins: Every demos/*.py notebook has a PEP 723 # /// script header pinning a published wigglystuff version. For any demo that was added or modified in this release (anything in git diff origin/main -- demos/ since the previous tag), update its pin to the new version. Otherwise uv run demos/<name>.py will fetch the old release and the new feature will be missing. Grep demos/ -l "wigglystuff==" to find pins; you do not need to bump untouched demos.
  8. Verify nothing is missed: Check the git diff to make sure all new/changed widgets have corresponding updates in all locations listed above.
  9. 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 run gh pr merge. Only pause earlier if there's a genuine blocker (failing tests, merge conflicts, ambiguous diff) — not for the commit/PR steps themselves.
  10. Report what was done and what still needs manual action (e.g., adding screenshots, replacing molab link placeholders).

Download now (ZIP)

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.