ワンクリックで
release
// Tend release workflow. Use when user asks to "do a release", "release a new version", "cut a release", or wants to publish a new version to PyPI.
// Tend release workflow. Use when user asks to "do a release", "release a new version", "cut a release", or wants to publish a new version to PyPI.
Generic CI environment rules for GitHub Actions workflows. Use when operating in CI — covers security, CI monitoring, comment formatting, and investigating session logs from other runs.
Polls GitHub notifications and handles items that dedicated workflows miss — fork PR comments, cross-repo mentions, and stale unanswered items. Runs on a schedule.
Sets up tend — an autonomous junior maintainer for a GitHub repo, powered by Claude or OpenAI Codex — that reviews PRs, triages issues, and fixes CI. Creates config, generates workflows, configures secrets and branch protection via API, creates the bot account, and provisions the harness auth token (Claude OAuth or OpenAI API key). Use when setting up tend on a new repo or when asked to install/configure tend.
Investigates a specific tend GitHub Actions run by downloading its session-log artifacts and parsing the JSONL traces. Surfaces which skill tend loaded, what tools it called with what inputs, files it read or wrote, and where decisions went wrong. Use when asked to "debug a tend run", "investigate a tend run", "why did tend do X", "what did the bot do in CI", "look at the session logs", or to reconstruct tend's behavior step-by-step from a run ID, URL, or PR number.
Nightly code quality sweep — resolves bot PR conflicts, reviews recent commits, surveys existing code, checks resolved issues, and updates tend workflows.
Triages new GitHub issues — classifies, reproduces bugs, attempts conservative fixes, and comments. Use when a new issue is opened and needs automated triage.
| name | release |
| description | Tend release workflow. Use when user asks to "do a release", "release a new version", "cut a release", or wants to publish a new version to PyPI. |
| metadata | {"internal":true} |
wt test and pre-commit run --all-filesversion in generator/pyproject.tomlgit log <last-version>..HEAD --oneline to understand scopeversion in generator/pyproject.toml, then cd generator && uv lockchore: release X.Y.Z with a one-line summary of changes since last release. Don't create a new branch — this worktree is already on the release branch, and the PR opens from it to main.gh pr create, wait for CI, merge with gh pr merge --squashgit tag X.Y.Z && git push origin X.Y.Z (triggers PyPI release workflow in .github/workflows/pypi-release.yaml)uvx tend@X.Y.Z --help succeedsrelease branch (don't create a new one — same as step 6). The squash-merge deleted origin/release, so git fetch && git reset --hard origin/main to realign with the squashed history. Then uvx tend@latest init, commit, push, and open a PR titled chore: regenerate workflows with tend X.Y.Z. Until this merges, tend's deployed workflows lag the just-released generator, so critical fixes (e.g. loop-prevention filters) remain unreachable on tend itself.Tags are bare versions (0.0.9), not prefixed (v0.0.9).
Generated workflows pin the action to the generator's own version
(max-sixty/tend@X.Y.Z); there is no floating v1. Each X.Y.Z tag is the
immutable ref consumers run, enforced by a tag ruleset on max-sixty/tend
(update/deletion restricted). Never force-move or delete a published tag.
Step 8 (tag) must precede step 10 (regenerate via uvx tend@latest) so the
pinned ref resolves to an existing tag.
chore: release X.Y.Z
Bumps generator version to X.Y.Z and syncs lockfile.
N commits since A.B.C: <brief list of notable changes with PR numbers>.