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/
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
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.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
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.