소스 정보
- 저장소
- tokio-rs/toasty
- 최근 소스 활동
- 2026년 5월 23일 07:57
- 감지된 SKILL.md 언어
- 영어
- 스타
- 3,210
- 포크
- 143
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
SKILL.md 표시 중
SKILL.md
소스 지침 · 읽기 전용 미리보기- name
- pr
- description
- Always use this skill before opening a pull request in the Toasty repository
# Opening Pull Requests
Load this skill before opening a pull request in this project.
## Base the title and body on the PR diff, not the latest commit
A branch usually contains several commits — initial work, fixups,
review responses, rebases. The PR title and body describe the **net
change that will land on the base branch**, not the most recent commit.
Identify the PR's base branch first. It is usually `main`, but a PR
stacked on another feature branch has that feature branch as its base.
Then read the full diff against the base:
```
git diff <base>...HEAD
git log <base>..HEAD
```
Draft the title and body from what that diff actually contains.
## Title
Follows the same Conventional Commits format as a commit message — it
becomes the squash-merge commit. See
[`docs/dev/COMMITS.md`](../../../docs/dev/COMMITS.md).
## Body
Fill in the template at
[`.github/pull_request_template.md`](../../../.github/pull_request_template.md).
Keep the section headings and the checklist; replace the HTML comment
placeholders with real content. Delete checklist items that do not
apply rather than leaving them unchecked with no explanation.
## Markdown-doc PRs: link the rendered version
When a PR's primary change is adding or substantially modifying a single
markdown file (e.g., a design doc or a major docs rewrite), put a link
to the rendered version on the branch as the first line under
`## Summary`:
```
## Summary
[Rendered](https://github.com/tokio-rs/toasty/blob/<branch-name>/<path-to-file>.md)
<rest of summary>
```
Use the PR's head branch name in the URL so the link renders the
version under review, not what's on `main`. PR
[#787](https://github.com/tokio-rs/toasty/pull/787) is an example.
## Be succinct
Reviewers already know Toasty and Rust. Keep the body high-signal:
state the problem, the change, and anything a reviewer needs to know
to evaluate it. Skip restated context, obvious explanations, and
throat-clearing. A reviewer should grasp the important bits in
seconds.
## Labels
Do not apply labels when creating the PR. Maintainers triage and label
PRs separately — see [`docs/dev/labels.md`](../../../docs/dev/labels.md).
Passing `--label` to `gh pr create` bypasses that process.
GitHub에서 보기