원클릭으로 Manus에서 모든 스킬 실행

pull-requests

스타2

포크0

업데이트2026년 6월 25일 09:35

Use when the user asks to open a PR or MR, draft a PR description, fill the PR template, request reviewers, or merge a PR in a Serokell repo. Triggers on phrases like "open a PR", "create a pull request", "make an MR", "write PR description", "fill the PR template", "request review", "merge this PR", "tick the checkboxes".

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

serokell

serokell/metatemplates

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Pull requests and merge requests

Use this skill when opening, updating, or reviewing a PR (GitHub) or MR (GitLab).

Title

Scheme: [ISSUE-ID] Brief description.

Omit [ISSUE-ID] if the repository is public and the issue is in a private tracker (e.g. YouTrack).
Brief description: short but understandable on its own.

Description

Must not be empty.

This repo provides templates at .github/pull_request_template.md (GitHub) or .gitlab/merge_request_templates/default.md (GitLab). Use whichever applies to the host.
Fill every section of the template (Description, Related issue(s), the various Checklist subsections, and Release Checklist where applicable).
Describe what changed AND why.
Link related issues. For GitHub / GitLab public issues, use Fixed #N / Resolves #N to auto-close them on merge. For YouTrack issues, paste the full URL (https://issues.serokell.io/issue/<PROJECT>-<N>) prefixed with Resolves.

Checkboxes

This is the rule that catches people out:

Tick every checkbox you can substantiate.
If a checkbox is irrelevant to this PR, still tick it. That signals you considered the item and judged it irrelevant. Do not silently leave irrelevant items unticked.
The only acceptable unticked checkbox is one you can justify (e.g. in a PR comment).

The PR template itself states this explicitly in its meta-comments; follow that instruction.

What each checkbox actually means

The PR template groups checkboxes into conditional sections. For each one, know what triggers it and what evidence backs ticking it:

Tests — fires when the PR adds functionality or fixes a bug. For new functionality: add tests covering it. For a bugfix: add a regression test that would have caught the bug.
Documentation — fires when the PR changes behaviour visible to users or to other code. Update the README and in-code API documentation as needed.
Public contracts — fires when the PR changes public API or protocol. Comply with the project's public-contracts policy (semver, deprecation cycles, etc.), add a CHANGES.md entry, and provide a migration note for breaking changes.
Release Checklist — fires on release PRs only. Bump the version in the project's package manifest; add @since-style annotations to new public API where the language supports them; create the GitHub releases entry after merge with the vX.Y.Z tag; publish to the relevant package registry for public libraries (e.g. Hackage for Haskell).
Stylistic guide (mandatory) — never irrelevant. Confirm commit policy compliance, plus code style compliance if the repo has a style guide.
Agent instructions (conditional) — fires when the PR touches .claude/skills/ or .github/copilot-instructions.md. Keep the two in sync: when one changes, verify the other still reflects the changed content.

Scope

One PR per issue (1:1 mapping). Don't bundle unrelated work.
An exception: trivial in-place fixes (a typo, wrong formatting) in a file you're already editing are fine.
Size guideline: aim for ≤500 additions+deletions. If your PR is larger, think first whether the issue can be split.

Reviewers

Request review from the project's expected number of reviewers (project-dependent, often 2). If unsure, check CODEOWNERS and recent merged PRs, or ask the user. Look for people who touched this code before or are likely interested.
Codeowners may be auto-requested; check the final reviewer list after opening the PR.

During review

Make requested changes in separate commits — do NOT amend earlier commits during review. Use git commit --fixup=<sha> (see the committing-work skill).
Do NOT force-push during review, except to rebase on a newer target branch (and use --force-with-lease, never -f).
Sync with the target branch periodically by rebasing onto it, not by merging it in.
Do not mark a reviewer's comment as resolved. That is the reviewer's call — they decide whether their concern was addressed.
If reviewers don't respond within ~3 working days, ping them explicitly. If still silent, ping the team lead too — tag their username (from PROJECT.md) in a comment.

Merging

Use a merge commit (GitHub's "Create a merge commit" option).
Do NOT use "Squash and merge" unless the PR has exactly one commit.
Do NOT use "Rebase and merge" by default. (Exception: fast-forwarding a release branch from master.)
Before merging, ensure the commit history satisfies the project's commit policy (see the committing-work skill). PR author usually cleans history before merge.
When merging someone else's PR: confirm the author is fine with merging and doesn't want to touch the commit history first. If the PR is trivial (e.g. a one-line fix) you can merge without asking; otherwise ping the author. On GitLab, the author's self-approval counts as agreement to merge.

이 저장소의 다른 Skills

같은 저장소

bootstrap-repo

serokell/metatemplates

Use when the user asks to create a new Serokell repository, bootstrap a fresh repo from `metatemplates`, fork an external repo into the Serokell org, initialize a new project, or sequence the full new-repo setup (create → customise → license → CI → settings). Triggers on phrases like "create a new Serokell repo", "bootstrap this repo", "set up a fresh repo", "fork this repo into serokell", "initialize new project", "new repo from metatemplates", "start a new project", "first commit on a new repo".

2026-06-252

changelog

serokell/metatemplates

Use when the user asks to add a changelog entry, set up a `CHANGES.md` / `CHANGELOG.md` file, document user-facing changes in a release, or write a migration note for a breaking change. Triggers on phrases like "add to changelog", "CHANGES.md entry", "document this release", "release notes", "breaking change migration note", "what's new", "user-facing changes".

2026-06-252

code-review

serokell/metatemplates

Use when the user asks to review a pull request, leave review comments, decide between approve / request changes / comment, or resolve conversations on someone else's PR. Triggers on phrases like "review this PR", "leave a code review", "approve or request changes", "review someone's PR", "resolve this conversation", "PR review comments", "comment on the PR".

2026-06-252

code-testing

serokell/metatemplates

Use when the user asks to add tests, write a regression test for a bug, set up CLI execution tests or coverage in CI, or pick the kind of test (unit / property / blackbox / acceptance) to write. Triggers on phrases like "add a test for this", "write a regression test", "add test coverage", "test this CLI", "property-based test", "fuzzing", "what kind of test should I write", "edge-case test".

2026-06-252

committing-work

serokell/metatemplates

Use when the user asks to commit work, draft a commit message, create a branch for an issue, or make a fixup commit in a Serokell repo. Triggers on phrases like "commit these changes", "draft a commit message", "create a branch for this issue", "make a fixup commit", "git commit", "what should the branch be called", "Problem/Solution".

2026-06-252

gitignore

serokell/metatemplates

Use when the user asks to add patterns to `.gitignore`, fix imprecise ignore patterns, decide between project / global / local-only ignores, or set up `.gitignore` for a new Haskell or multi-language repo. Triggers on phrases like "add to gitignore", "ignore these files", "fix gitignore", "what goes in gitignore", "global git ignore", "ignore build output", ".stack-work", "dist-newstyle", "editor files in gitignore".

2026-06-252

name	pull-requests
description	Use when the user asks to open a PR or MR, draft a PR description, fill the PR template, request reviewers, or merge a PR in a Serokell repo. Triggers on phrases like "open a PR", "create a pull request", "make an MR", "write PR description", "fill the PR template", "request review", "merge this PR", "tick the checkboxes".

Pull requests and merge requests

Use this skill when opening, updating, or reviewing a PR (GitHub) or MR (GitLab).

Title

Scheme: [ISSUE-ID] Brief description.

Omit [ISSUE-ID] if the repository is public and the issue is in a private tracker (e.g. YouTrack).
Brief description: short but understandable on its own.

Description

Must not be empty.

This repo provides templates at .github/pull_request_template.md (GitHub) or .gitlab/merge_request_templates/default.md (GitLab). Use whichever applies to the host.
Fill every section of the template (Description, Related issue(s), the various Checklist subsections, and Release Checklist where applicable).
Describe what changed AND why.
Link related issues. For GitHub / GitLab public issues, use Fixed #N / Resolves #N to auto-close them on merge. For YouTrack issues, paste the full URL (https://issues.serokell.io/issue/<PROJECT>-<N>) prefixed with Resolves.

Checkboxes

This is the rule that catches people out:

Tick every checkbox you can substantiate.
If a checkbox is irrelevant to this PR, still tick it. That signals you considered the item and judged it irrelevant. Do not silently leave irrelevant items unticked.
The only acceptable unticked checkbox is one you can justify (e.g. in a PR comment).

The PR template itself states this explicitly in its meta-comments; follow that instruction.

What each checkbox actually means

The PR template groups checkboxes into conditional sections. For each one, know what triggers it and what evidence backs ticking it:

Tests — fires when the PR adds functionality or fixes a bug. For new functionality: add tests covering it. For a bugfix: add a regression test that would have caught the bug.
Documentation — fires when the PR changes behaviour visible to users or to other code. Update the README and in-code API documentation as needed.
Public contracts — fires when the PR changes public API or protocol. Comply with the project's public-contracts policy (semver, deprecation cycles, etc.), add a CHANGES.md entry, and provide a migration note for breaking changes.
Release Checklist — fires on release PRs only. Bump the version in the project's package manifest; add @since-style annotations to new public API where the language supports them; create the GitHub releases entry after merge with the vX.Y.Z tag; publish to the relevant package registry for public libraries (e.g. Hackage for Haskell).
Stylistic guide (mandatory) — never irrelevant. Confirm commit policy compliance, plus code style compliance if the repo has a style guide.
Agent instructions (conditional) — fires when the PR touches .claude/skills/ or .github/copilot-instructions.md. Keep the two in sync: when one changes, verify the other still reflects the changed content.

Scope

One PR per issue (1:1 mapping). Don't bundle unrelated work.
An exception: trivial in-place fixes (a typo, wrong formatting) in a file you're already editing are fine.
Size guideline: aim for ≤500 additions+deletions. If your PR is larger, think first whether the issue can be split.

Reviewers

Request review from the project's expected number of reviewers (project-dependent, often 2). If unsure, check CODEOWNERS and recent merged PRs, or ask the user. Look for people who touched this code before or are likely interested.
Codeowners may be auto-requested; check the final reviewer list after opening the PR.

During review

Make requested changes in separate commits — do NOT amend earlier commits during review. Use git commit --fixup=<sha> (see the committing-work skill).
Do NOT force-push during review, except to rebase on a newer target branch (and use --force-with-lease, never -f).
Sync with the target branch periodically by rebasing onto it, not by merging it in.
Do not mark a reviewer's comment as resolved. That is the reviewer's call — they decide whether their concern was addressed.
If reviewers don't respond within ~3 working days, ping them explicitly. If still silent, ping the team lead too — tag their username (from PROJECT.md) in a comment.

Merging

Use a merge commit (GitHub's "Create a merge commit" option).
Do NOT use "Squash and merge" unless the PR has exactly one commit.
Do NOT use "Rebase and merge" by default. (Exception: fast-forwarding a release branch from master.)
Before merging, ensure the commit history satisfies the project's commit policy (see the committing-work skill). PR author usually cleans history before merge.
When merging someone else's PR: confirm the author is fine with merging and doesn't want to touch the commit history first. If the PR is trivial (e.g. a one-line fix) you can merge without asking; otherwise ping the author. On GitLab, the author's self-approval counts as agreement to merge.