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.
中文简介正在准备中。当前显示英语简介。
Always use this skill before authoring or editing a Toasty design document under docs/dev/design/
实测评分 未实测
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Load this skill before writing or editing a design document in
docs/dev/design/.
Always read docs/dev/design/_template.md
before writing. It is the authoritative source for section order,
section purposes, and the framing the doc should adopt. Copy the
template to docs/dev/design/<feature-name>.md and fill it in. Keep the
section order; if a section genuinely does not apply, delete it and
explain why in one line rather than leaving it empty.
Follow the conventions from the prose skill: be
fact-focused, direct, and concrete. No buzzwords, no fluff, no dramatic
terms.
Readers already know Toasty and Rust. Lead with the problem and the proposal so a maintainer can grasp the important bits quickly. Cut restated background, obvious explanations, and throat-clearing. Length is not a virtue; clarity is.
Rust code blocks in design docs are illustrative. They do not need to compile and are not run through rustdoc or any other test.
Do not add #-prefixed hidden boilerplate — no # use … imports, no
# async fn __example(…) { … } wrappers, no # fn main, nothing hidden
to satisfy a compiler. Show only the lines that matter to the reader, even
if the snippet would not compile on its own.
This overrides the doctest-preamble instruction in _template.md's
User-facing API section: that preamble is for the user guide, where
examples are tested. Design docs are not.
A design doc is guide-level, not implementation-level. Write it for the two audiences the template names:
Driver trait.Describe what those audiences will see, call, and have to do. Omit
internal module layouts and implementation choices that have no
observable effect on either audience. The User-facing API section
should read like a chapter of the user guide — prose with worked
examples, not an API catalog. The examples are still illustrative only
(see Rust examples above) — do not add doctest boilerplate to them.
Non-trivial features follow the path in
CONTRIBUTING.md: open a feature-proposal
issue first, then land a roadmap entry in
docs/dev/roadmap/ and the design doc
in the same PR. The implementation lands as a follow-up PR once the
design is accepted.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
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.
中文简介正在准备中。当前显示英语简介。
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.
中文简介正在准备中。当前显示英语简介。
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.
中文简介正在准备中。当前显示英语简介。