Write clear Toasty issues by choosing the right template for a bug report or feature proposal and filling in its required fields. It helps describe observed behavior, reproduction steps, proposed APIs, and alternatives in concise, factual language.
한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.
Always use this skill before opening an issue in the Toasty repository
실행 점수 미검증
설치 방법 보기설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
Load this skill before filing any issue in this project.
An issue is project documentation. Follow the conventions from the
prose skill: be fact-focused, direct,
and concrete. No buzzwords, no fluff, no dramatic terms. State what
happened or what is being proposed, not how important it is.
Maintainers reading the issue already know Toasty and Rust. Keep the prose high-signal: lead with the bug or proposal, then the reproducer or API sketch, then the alternatives. Skip restated background and throat-clearing. A maintainer should grasp the problem in seconds, not paragraphs.
Issue templates live in
.github/ISSUE_TEMPLATE/:
bug_report.yml —
incorrect or unexpected behavior. Asks what you did, what you expected,
and what happened instead; the affected driver(s); the Toasty version;
and a reproducer.feature_proposal.yml —
new features, public-API changes, or anything that affects driver
implementations. Requires the problem, proposed solution,
alternatives considered, and a scope estimate.Read the template before writing. Fill in every field it asks for; don't drop sections or leave placeholders. If a field does not apply, say so explicitly rather than leaving it blank.
Report what you observed, not why you think it happened. A bug report has five parts:
crates/toasty-driver-integration-suite/src/tests/ is ideal; a small
standalone snippet works too. This is the single most useful thing in
the report.Leave out root-cause analysis. Diagnosing the bug is the maintainer's job, and a guess at the cause sends triage down the wrong path. Describe the behavior; the reproducer shows the rest.
Describe the problem before the solution. Name who is affected — Toasty users, driver implementors, or both. Sketch the user-facing API concretely; vague proposals are hard to discuss. List the alternatives you considered and why you discarded them.
Non-trivial features follow the path in
CONTRIBUTING.md: discuss in an issue,
land a roadmap entry and design doc, then land the implementation.
Do not apply labels when creating the issue. The templates set the
initial C-* label; maintainers triage and add the rest. See
docs/dev/labels.md.
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
Prepare concise Git commit messages for the Toasty project by first checking its authoritative commit guide. The skill focuses on describing what changed and why, using the project's required format, types, scopes, and breaking-change notation.
한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.
Prepare Toasty design documents under `docs/dev/design/` using the required template, audience, and concise writing conventions. The skill guides document structure and illustrative Rust examples, and outlines the proposal and roadmap steps for non-trivial features.
한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.
Prepare a Toasty pull request by reviewing the full change against its base branch and drafting a concise title and body from the net diff. It also covers the required template, rendered links for major Markdown changes, and label handling.
한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.
Write or edit Toasty documentation, design notes, READMEs, pull request descriptions, issues, and commit bodies using the project's prose conventions. It favors direct, factual language, concrete examples, active voice, and descriptions of current behavior.
한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.