Skip to content
cccskills
FreePublished on GitHub

prose

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.

OriginalShow the original description

Author or edit any prose for the Toasty project — documentation, design docs, READMEs, PR descriptions, issue bodies, commit message bodies, or other human-readable text — following project writing conventions

tokio-rs/toasty3,268 stars(GitHub 3,268 + cccskills 0)
Works withPostgreSQL

Run score Not tested

See how to install

Good for

  • Editing a README or project documentation
  • Writing an issue or pull request description
  • Making design notes more direct and concrete

Files included (1)

  • SKILL.md2.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Writing Toasty Prose

Load this skill whenever writing or editing prose for this project: documentation in docs/, READMEs, design docs, PR descriptions, issue bodies, commit message bodies, or any other human-readable markdown.

Writing Style

  • Be fact-focused: State what things are and what they do
  • Avoid buzzwords: No "leverage", "synergy", "paradigm", etc.
  • Avoid fluff: Every sentence should convey information
  • Avoid business jargon: No "stakeholders", "deliverables", "action items"
  • Avoid weasel words: No "very", "really", "quite", "somewhat"
  • Avoid dramatic terms: No "critical", "crucial", "vital", "essential" unless something will actually break
  • Avoid figurative metaphors: Pick the literal word for the thing, not the analogy. "Features light up on PostgreSQL" → "Toasty enables features on PostgreSQL". "Query shape" → "query pattern" or "query form". Other recurring offenders: "under the hood" (just describe what's there), "out of the box" (just say "by default"), "first-class" (say what's actually supported), "magic" (say what the code does). If you can't replace the metaphor with a literal noun or verb without losing meaning, you probably don't know what you mean yet.
  • Be direct: Say what you mean without hedging
  • Use concrete examples: Show, don't tell
  • Use active voice: "The engine executes queries" not "Queries are executed by the engine"
  • Use present tense: Describe how the system works now, not how it was designed or how it will work
  • Document current behavior only: Omit historical decisions, deprecated approaches, and planned future work

Examples

Bad: "This component is critical for ensuring optimal query performance."

Good: "This component optimizes queries by combining multiple database round-trips into one."

Bad: "The simplification phase leverages various transformations to enhance query efficiency."

Good: "The simplification phase rewrites association traversals into explicit subqueries."

Bad: "Native arrays light up on PostgreSQL for Vec<scalar> fields."

Good: "On PostgreSQL, Vec<scalar> fields use native array columns (text[], int8[], …)."

Bad: "## Query shapes that work"

Good: "## Supported queries"

Document Structure

  • Start with what the thing is
  • Explain why it exists (what problem it solves)
  • Explain what it does
  • Show how to use it (if applicable)
  • Provide examples

Reviews

No reviews yet. Tell others what you thought.

Comments

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.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

commit

FreeSummary

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.

  • Writing a commit subject and body
  • Checking allowed commit types and scopes
  • Marking a breaking change correctly
tokio-rs/toasty3.3KUpdated Oct 26, 2026

design

FreeSummary

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.

  • Drafting a Toasty feature design document
  • Editing an existing design proposal
  • Explaining a feature to users and driver implementors
tokio-rs/toasty3.3KUpdated Oct 26, 2026

issue

FreeSummary

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.

  • Reporting a bug with steps and a reproducer
  • Proposing a feature or public API change
  • Choosing and completing an issue template
tokio-rs/toasty3.3KUpdated Oct 26, 2026

pr

FreeSummary

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.

  • Drafting a pull request title and body
  • Summarizing changes across several commits
  • Preparing a pull request for a Markdown document
tokio-rs/toasty3.3KUpdated Oct 26, 2026

See all skills by tokio-rs

Report a problem with this skill