quarto-dev
- 18 skills
- 0 followers
- 8 hours ago last updated
- ▌ Brand Yml · quarto-dev bundleCreate and use brand.yml files for consistent branding across Shiny apps and Quarto documents. Covers: (1) Creating new _brand.yml files, (2) Applying to Shiny (R and Python), (3) Using in Quarto, (4) Modifying existing files, and (5) Troubleshooting. Includes complete specifications and integration guides.
- ▌ Testing R Packages · quarto-dev bundleBest practices for writing R package tests using testthat version 3+. Use when writing, organizing, or improving tests for R packages. Covers test structure, expectations, fixtures, snapshots, mocking, and modern testthat 3 patterns including self-sufficient tests, proper cleanup with withr, and snapshot testing.
- ▌ R Package Development · quarto-devR package development with devtools, testthat, and roxygen2. Use when the user is working on an R package, running tests, writing documentation, or building package infrastructure.
- ▌ Quarto Blog Post · quarto-dev bundleUse when writing, drafting, or editing Quarto blog posts, creating Quarto feature or release announcements, or reviewing Quarto blog post drafts. Quarto posts publish on the Posit Open Source blog (posit-dev/open-source-website), not on quarto.org.
- ▌ Capturing Screenshots · quarto-dev bundleCapture or update documentation screenshots for the Quarto website using Playwright. Use when screenshots need refreshing, new screenshots are needed for docs pages, or the user mentions screenshots, screen captures, or visual documentation.
- ▌ Release Merge · quarto-dev bundleUse when merging the quarto-web prerelease branch into main for a Quarto release (publishing new stable docs), or when a release-time merge hits conflicts, backport-action noise, or _freeze hook failures. Not for ordinary PRs to main.
- ▌ Review Extension Prs · quarto-dev bundleUse when asked to review open pull requests that add Quarto extensions to the listing YAML files in docs/extensions/listings/. Triggers include "review extension PRs", "check extension submissions", "are there new listing PRs", or any request to triage or verify community extension submissions before merge.
- ▌ Braid · quarto-devReference for braid, this project's issue tracker (the "skein" of "strands"). Use whenever you need braid command syntax — finding ready work, creating/updating/closing strands, dependencies, ready/blocked queries — or when a user mentions braid, a strand, or a bd- issue id and you need the authoritative, version-matched usage. The body defers to `braid agents-info` for the full guide.
- ▌ Triage · quarto-dev bundleSet up an isolated worktree and triage a GitHub issue into a durable on-branch record. Use when the user says "triage issue
- ▌ Snyk Pr · quarto-dev bundleRemediate a Snyk bot PR ([Snyk] Upgrade ..., author posit-snyk-bot, branch snyk-upgrade-*) so it goes green on CI and becomes mergeable. Use when the user asks to fix, unblock, or "make mergeable" a Snyk PR, mentions a red Snyk upgrade PR, or pastes a snyk-upgrade-* branch name. Invoke as /snyk-pr <PR#>; with no argument, list open posit-snyk-bot PRs and stop. Fixes the branch only — never weakens or skips the CI guard tests.
- ▌
- ▌ Investigate Beads · quarto-dev bundleInvestigate a braid strand (bd-XXXX issue) in the current checkout, gather context from its dependency graph, and produce a plan-skeleton + triage verdict (ready / needs-info / blocked). Use when the user provides a strand ID (bd-XXXX) and asks to investigate, scope, or understand the work needed.
- ▌ Upgrade Cargo Deps · quarto-dev bundleSurvey the workspace for available Rust dependency upgrades, apply patch/minor bumps in an isolated worktree, run full `cargo xtask verify`, and produce a plan doc + per-major braid strands so the user can review and merge. Also reconciles previously-filed `Cargo:` upgrade strands against the current tree, closing ones that unrelated work already resolved. Use when the user says "upgrade cargo deps", "check for dependency upgrades", "do the bi-weekly cargo upgrade", asks about outdated dependencies, or asks whether existing `Cargo:` chore strands are still real. Runs on demand only — there is no schedule.
- ▌ Preview Render Parity · quarto-devDiagnose and fix DOM / style differences between `q2 preview` and `q2 render` so the two pipelines produce visually-equivalent output. Use when the user reports that the preview's appearance, spacing, classes, or DOM structure doesn't match the rendered site — phrases like "preview vs render differs", "preview shows X differently", "spacing/margin/padding off", "DOM doesn't match", "missing class in preview", or shows a specific computed-style mismatch (e.g. "17px in preview, 34px in render"). Also invoked explicitly via `/preview-parity`.
- ▌ Reader Expectations Prose · quarto-devImprove prose clarity using the reader-expectations methodology of Gopen & Swan ("The Science of Scientific Writing", American Scientist, Nov-Dec 1990). Use when the user asks for writing improvement, prose review, revision suggestions, help making writing clearer or more readable, feedback on a draft, or mentions clarity, flow, emphasis, sentence structure, or "why this passage is hard to read". Works on any expository prose (papers, reports, memos, docs, essays), not only scientific writing.
- ▌ Investigate Issue · quarto-devUse when investigating a suspected quarto-cli bug — a document that renders incorrectly, an unexpected error, or behavior that changed between versions. Not for "how does X work" or general architecture questions.
- ▌ Quarto Preview Test · quarto-dev bundleUse when testing `quarto preview` behavior — verifying live reload, validating a preview-related bug fix, or running the manual preview test matrix by ID or topic.
- ▌ Make Release · quarto-devDrive a Quarto release end-to-end from the dev-docs release checklists. Handles three release types — a routine dev prerelease off main, the first stable release of a new major.minor cycle, or a patch release on an existing stable branch — by asking which one applies (or reading it from an unambiguous request), then follows the matching checklist, verifying real git/gh state at each step and pausing for explicit human confirmation before every irreversible or externally-visible action.