القائمة
Weekly release check — review changes since last tag and optionally cut a new release.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | check-release |
| description | Weekly release check — review changes since last tag and optionally cut a new release. |
Walk through the release process incrementally, with decision points at each stage. Designed for weekly invocation but doesn't assume a release will happen.
main branch with a clean working treeRead the wiki release process page:
cat /scratch/gpfs/MSALGANIK/niznik/GitHub/cruijff_kit_wiki/Release-Process.md
Present the checklist to the user so everyone can see the full process before starting.
Proceed to Step 1.
Find the latest git tag:
git describe --tags --abbrev=0
List commits since that tag:
git log <latest_tag>..HEAD --oneline
List PRs merged since that tag:
module load anaconda3/2025.6 && conda activate cruijff && gh pr list --repo niznik-dev/cruijff_kit --state merged --search "merged:>=$(git log -1 --format=%ai <latest_tag> | cut -d' ' -f1)" --json number,title,mergedAt --limit 50
List open PRs and present them for review — each should be merged, deferred, or closed before release:
module load anaconda3/2025.6 && conda activate cruijff && gh pr list --repo niznik-dev/cruijff_kit --state open --json number,title
Check for anything already in [Unreleased] in CHANGELOG.md.
Check KNOWN_ISSUES.md for stale entries (closed issues, resolved problems).
Present a summary to the user:
Decision point: Ask the user whether to proceed with a release or stop here.
Read the current version from pyproject.toml (line 7).
Default to a patch bump. The project versioning policy:
When in doubt, it's a patch.
Decision point: Confirm the version number with the user.
Draft a changelog entry using the Keep a Changelog format already in CHANGELOG.md:
Include PR numbers and contributor attribution (e.g., @username) where applicable.
Present the draft to the user for review.
Decision point: User approves or edits the changelog entry.
Once approved:
[Unreleased] (if any) into the new version section[Unreleased] in CHANGELOG.mdpyproject.tomlCreate a release branch:
git checkout -b release-<VERSION>
Commit changelog + version bump + any KNOWN_ISSUES changes.
Push branch and open PR:
git push -u origin release-<VERSION>
Decision point: Confirm PR is ready. Wait for CI to pass.
User merges the PR using merge commit (not squash or rebase).
Pull the merge commit:
git checkout main && git pull
Create annotated tag on the merge commit with a minimal message:
git tag -a v<VERSION> -m "v<VERSION>"
Push tag:
git push origin v<VERSION>
Create GitHub Release with the changelog entry as release notes:
gh release create v<VERSION> --title "v<VERSION>" --notes "<changelog entry>"
Confirm success by printing the release URL.
"vX.Y.Z" only) — GitHub Releases carry the full notesmainPlan LLM fine-tuning and evaluation experiments. Use when the user wants to design a new experiment, plan training runs, or create an experiment_summary.yaml file.
Create custom inspect-ai evaluation tasks through interacted, guided workflow.
Open-ended, Claude-driven exploration of a completed experiment — you decide per-experiment which figures matter and what the results mean. Optional and runnable any time after run-experiment (summarize-experiment is the required post-run step). Produces "Claude's Exploration": a non-deterministic report of what you examined and concluded, with an audit log.
Execute the complete experimental workflow - model optimization followed by evaluation - for all runs in a scaffolded experiment. Use after scaffold-experiment to submit jobs to SLURM.
Archive a completed experiment, preserving all experiment files while deleting bulk checkpoint artifacts. Use after summarize-experiment or explore-experiment when an experiment is complete and results have been reviewed.
Set up complete experimental infrastructure for all runs in a designed experiment. Orchestrates parallel generation of fine-tuning configs (via scaffold-torchtune) and evaluation configs (via scaffold-inspect). Use after design-experiment to prepare configs before running experiments.