Menu
This writes a pull request (PR) description for the current branch.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle 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 | write-pr |
| description | This writes a pull request (PR) description for the current branch. |
Before starting, always double check the current git status
Write a pull request for the current branch. The pull request should follow the template and it should focus on the impact of the change as well as the technical changes made in the current pull request. Under the Tests heading, if the PR includes changes to production code functionality (i.e. not purely documentation, test-only, CI/CD config, dev dependency, or formatting changes), populate the "Manual Verification Steps" checklist with specific, actionable steps that a release deployer can follow to manually verify that the PR's functionality works correctly. These steps should be tailored to the actual changes in the PR (e.g., navigate to a specific page, perform an action, verify an expected outcome). If there are no production code changes, remove the Manual Verification Steps section entirely.
The language used should be clear and unambiguous. Additionally, use the gh command-line tool to create the pull request with the generated description. If there is already a pull request created for the current branch, update the pull request description for the current branch using the gh command-line tool. You should also update the pull request for the current branch with a title
Do not ask for permission to read and create the PR using the gh cli
Closes [insert issue #]
Breaking Changes
Features:
Improvements:
Bug Fixes:
BEFORE:
AFTER:
Manual Verification Steps:
New scripts:
script : script detailsNew dependencies:
dependency : dependency detailsNew dev dependencies:
dependency : dependency details