一键导入
create-release
This creates a release for the given tag
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
This creates a release for the given tag
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Repository-specific code smells and blessed conventions for the Isomer Next monorepo. Use when writing or reviewing code in this repo (tRPC routers, Kysely/Prisma access, zod schemas, React components, tests) to catch deviations from team conventions, and when the user wants to record a new code smell or best practice ("remember this convention", "add a code smell", "we always/never do X here").
Use this skill when the user asks to review, evaluate, or assess a dependency upgrade — e.g. "review this upgrade", "is bumping X from a.b.c to x.y.z safe?", "what breaks if I upgrade <pkg>?", "check this package bump". Covers pnpm/npm packages and github-actions. Researches breaking changes for every intermediate version and reports which ones actually impact the user's codebase. Also runs unattended on Dependabot PRs via GitHub Actions — no human in the loop.
Implement the minimal fix for an already-triaged bug, run the full test suite, and open a stacked PR via Graphite. Requires the `triage` skill to have run first.
Implement a feature ticket. Hard guardrails — Storybook (FE) or tRPC test (BE) required, area conventions enforced via CLAUDE.md, stacked PRs via Graphite. Picks up from `feature-plan` or one-shot when eligible.
Produce 2-3 implementation approaches with trade-offs for a scoped feature ticket. Stops and waits for a human to pick. Does not write code.
Grade a pull request against the project risk taxonomy, flag hot-path touches, surface missing tests/stories, and post a structured review comment. Does not approve or merge.
| name | create-release |
| description | This creates a release for the given tag |
| allowed-tools | gh |
Before starting, always double check the tag for the current branch. You should use the latest release that is tied to the current tag.
The language used should be clear and unambiguous and should focus on the impact of the change. Use the github published release notes as a base for the release notes.
You should also read the individual PRs to understand the context of the change.
Instead of overriding the existing release notes, you should put the generated release notes above the original and separate the original and the generated using a divider.
:rocket: Isomer Next release notes (v0.17.0) :rocket:
Features
Fixes
Misc
@isorangers take note of those tagged :fyi:! For: @isomer-team @isorangers