القائمة
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
