القائمة
Use when cutting a new fused-render release, bumping the version, or creating a release tag — bumps __version__, commits, tags vX.Y.Z, and pushes to trigger the DMG build/release workflow.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
How to create and register a custom preview template for fused-render — a user-owned template that overrides, reorders, or extends the built-in extension → template mode list, so opening a file of that extension renders the user's template (or offers it as a switchable mode) instead. Use this whenever the user wants a custom/own preview for a file extension (e.g. "my own parquet viewer", "add a mode for .xyz files", "render .xyz files with my template"), wants to override, add, reorder, or disable template modes, mentions ~/.fused-render, registry.json, or _mode, or asks to "register a template". For actually writing the template's html and py files, this skill delegates to the fused-render-authoring skill — read that one too.
How to run and use a fused-render project — open files and views in the FusedRender desktop app and browse the filesystem. Use this whenever the user wants to open, run, launch, start, show, or explore a fused-render project or its views/files; asks to "open this in fused-render", "run fused-render", "show me this view", "look at this file in the explorer"; or is orienting inside a fused-render repo without yet authoring code. For creating/editing/debugging an .html view or .py data file, use fused-render-authoring instead; for registering custom preview templates, use fused-render-custom-templates.
How to author HTML views and Python data files for fused-render (the local HTML explorer with a fused.runPython() bridge, URL-synced params, and file IO helpers). Use when creating, editing, or debugging an .html view, a .py data file, or a preview template; when a view renders blank, shows a traceback overlay, or params don't sync to the URL; or when the user mentions fused.runPython/params/readFile/writeFile or asks for "a view for <file/data>".
Use when setting up a fused-render checkout or git worktree for the first time — before running pytest, the dev server, or any daemon — so tests and the server actually work instead of silently failing on missing deps or an unbuilt React shell.
| name | making-a-release |
| description | Use when cutting a new fused-render release, bumping the version, or creating a release tag — bumps __version__, commits, tags vX.Y.Z, and pushes to trigger the DMG build/release workflow. |
A release is: bump __version__, commit it, create a matching vX.Y.Z tag, and push the tag. Pushing the tag is what triggers .github/workflows/release.yml (build → sign → notarize → publish DMG + GitHub Release).
Single source of truth: the version lives ONLY in fused_render/__init__.py. pyproject.toml derives it dynamically ([tool.hatch.version]) — never edit a version into pyproject.toml.
The invariant that matters: the git tag name must equal __version__. Tag v0.3.5 ⟺ __version__ = "0.3.5". A mismatch ships the wrong version silently.
Start clean and on the latest main. Always pull first — tagging a stale
commit ships an old build. Use --ff-only so a diverged local branch errors
out loudly instead of creating a merge commit:
git switch main
git pull --ff-only origin main # REQUIRED: get the latest before releasing
git status --porcelain
If git pull --ff-only fails, your local main has diverged — reconcile it
before continuing. If git status --porcelain prints anything, stop and
resolve it first.
Pick the new version. Read the current value and the latest tag; choose the next semver:
grep __version__ fused_render/__init__.py
git tag --sort=-creatordate | head -1
Bump __version__ in fused_render/__init__.py (Edit tool). This is the only file to change.
Commit (message matches the repo's history convention exactly):
git commit -am "Bump version to X.Y.Z"
Tag — annotated, name is v + the exact version:
git tag -a vX.Y.Z -m "vX.Y.Z"
Push commit and tag. The tag push is the release trigger:
git push origin main
git push origin vX.Y.Z
Verify the release workflow started:
gh run list --workflow=release.yml --limit 3
| Thing | Value |
|---|---|
| Version source | fused_render/__init__.py → __version__ |
| Tag format | vX.Y.Z (must match __version__) |
| Release trigger | pushing a v* tag → .github/workflows/release.yml |
| Commit message | Bump version to X.Y.Z |
| Do NOT edit | pyproject.toml version (dynamic via hatchling) |
pyproject.toml. It's dynamic; the value there is ignored/derived. Edit __init__.py only.__version__. e.g. tagging v0.3.5 while __version__ is still 0.3.4. Bump and commit before tagging.git tag first.main branch. Start from clean main.git pull. Tagging a stale local main builds and ships an old
commit. Always pull (step 1) so the tag points at the true latest.Historically version bumps often went through a PR (Bump version to X.Y.Z (#NNN)) before tagging main. If your project requires PRs into main, open the bump PR first, let it merge, then tag the merged commit on main (steps 5–6). The tag must point at a commit already on main.