一键导入
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Hourly outcome-based analysis of tend's CI behavior — checks whether tend's outputs were accepted or rejected, escalating to session logs only when outcomes look wrong.
Tend-specific guidance for tend CI workflows. Adds non-standard workflow inclusion for usage analysis and repo conventions on top of the generic tend-* skills.
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.
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.
Debug and fix failing CI on the default branch. Use when CI fails on main.
| 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} |
release branch is long-lived and may sit behind main (or carry leftover state) when a cycle starts. Basing the changelog on a stale branch silently drops any commit merged to main after the branch was last realigned — git log <last-version>..HEAD won't show it. Bring it current first: git fetch origin && git merge origin/main (resolve any conflicts; if release has no commits of its own, git reset --hard origin/main instead). Then wt test and pre-commit run --all-files.version in generator/pyproject.tomlgit log <last-version>..origin/main --oneline to understand scope — against origin/main (not HEAD), so the range is the full set of commits this release ships even if step 1 was skippedversion in generator/pyproject.toml, then cd generator && uv lock## X.Y.Z section at the top of CHANGELOG.md (see "CHANGELOG" below). The release workflow publishes this section verbatim as the GitHub Release notes and fails the GitHub Release job if the section is missing (PyPI publish has already happened by then; recovery is a manual gh release create), so it must land in the release commit — before the tag.chore: release X.Y.Z (version bump, lockfile, and CHANGELOG). 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 .github/workflows/pypi-release.yaml, which publishes to PyPI and creates a GitHub Release from the version's CHANGELOG section.uvx tend@X.Y.Z --help succeeds and the release appears (gh release view X.Y.Z).release branch (don't create a new one — same as step 7). 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.CHANGELOG.md holds one ## X.Y.Z section per release, newest first. The header must be exactly ## X.Y.Z — the release workflow matches it literally to extract the notes.
Draft the section from the commits since the last release (git log <last-version>..origin/main --oneline):
([#a](url), [#b](url)) list. Use full https://github.com/max-sixty/tend/pull/N URLs so links resolve from the GitHub Release page.git show <sha> anything user-facing before trusting its bullet.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 9 (tag) must precede step 11 (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>.