posit-dev

Analyze e2e test failures from a GitHub Actions run. Provide a run ID or URL to download reports, extract traces/screenshots/logs, identify root causes, and get suggested actions. Works with both posit-dev/positron and posit-dev/positron-builds repos.

Generates well-structured PR bodies with dynamically fetched e2e test tags

Triage a specific Positron e2e test that is already failing or flaking in CI. Given a test name, surface its recent distinct failure modes from history, pull the evidence (trace, screenshots, logs) for each mode, and reason through the evidence to a root cause collaboratively with the engineer, landing on a concrete test fix or a product-bug repro. Test-centric counterpart to e2e-failure-analyzer (run-centric). For authoring a brand-new test, use author-e2e-tests.

Use when writing, debugging, or maintaining Playwright e2e tests for Positron -- new test files, test cases, flaky-test fixes, test infrastructure, or performance/metric tests.

Analyze Copilot session history for standup reports, usage tips, session search, and session reindexing. Use when the user asks for a standup, daily summary, usage tips, workflow recommendations, wants to search or find past sessions by keyword/file/PR, wants to reindex their session store, or asks about deleting session data.

Use when working on the Chat Customizations editor — the management UI for agents, skills, instructions, hooks, prompts, MCP servers, and plugins.

Find and read logs from Code OSS dev builds. Use when: finding logs, reading log files, debugging Code OSS, checking renderer logs, extension host logs, agent host logs, main process logs, investigating errors in dev builds.

Agents window architecture — covers the agents-first app, layering, folder structure, chat widget, menus, contributions, entry points, and development guidelines. Use when implementing features or fixing issues in the Agents window.

Create and manage todo tracking documents for features, bugs, and multi-step tasks. Use when starting new work that benefits from a persistent record of decisions, progress, and context.

Set a tracking document as the source of truth for the current feature or task. Use when starting work on a feature, bug fix, or multi-step task that benefits from a persistent record of decisions, discoveries, and progress. Keeps the document updated as work proceeds.

Guidance for managing R package lifecycle according to tidyverse principles using the lifecycle package. Use when: (1) Setting up lifecycle infrastructure in a package, (2) Deprecating functions or arguments, (3) Renaming functions or arguments, (4) Superseding functions, (5) Marking functions as experimental, (6) Understanding lifecycle stages (stable, experimental, deprecated, superseded), or (7) Writing deprecation helpers for complex scenarios.

Address PR review feedback by systematically working through every unresolved PR review thread on the current branch's PR - analyze each comment, make the requested code changes (with tests where useful), commit, and optionally reply and resolve.

Bulk resolve unresolved PR review threads on the current branch’s PR — typically after threads have been addressed manually or via /pr-threads-address

Build modern Shiny dashboards and applications using bslib (Bootstrap 5). Use when creating new Shiny apps, modernizing legacy apps (fluidPage, fluidRow/column, tabsetPanel, wellPanel, shinythemes), or working with bslib page layouts, grid systems, cards, value boxes, navigation, sidebars, filling layouts, theming, accordions, tooltips, popovers, toasts, or bslib inputs. Assumes familiarity with basic Shiny.

Review test code for quality, design, and completeness after implementing a feature or fixing a bug. Use when the user asks to "review my tests", "check my test quality", "are these tests good enough", "review testing", or after completing a feature implementation that includes tests. Also use when tests feel brittle, flaky, or superficial. Cross-references production code to find coverage gaps.

Guide for drafting issue closure and decline responses as an open-source package maintainer. Use when helping compose a reply that says "no" to a feature request, closes an issue as won't-fix, redirects a user to a different package, explains why a design choice is intentional, or otherwise declines or closes a community contribution. Also use when the maintainer needs to explain a deprecation, point out a user misunderstanding, or communicate an effort/scope tradeoff to a contributor.

Use when observing server-side state of a Shiny for Python (py-shiny) app - inspecting reactive/calc values in a running session, capturing current input/output state, exposing internal values to a test harness, asserting server-side values in snapshot tests, or when tempted to add print statements or hidden outputs to see server-side values. (For writing Playwright end-to-end tests against the rendered UI, use the testing skill.)

Use when writing or running end-to-end tests for a Shiny for Python (py-shiny) app - launching an app under pytest, locating and asserting on UI components (inputs, outputs, cards, navsets), simulating user interaction with Playwright, or when tempted to hand-roll CSS selectors, raw Playwright locators, or sleep() waits against Shiny-rendered HTML.

Use when adding observability to a Shiny for Python (py-shiny) app with OpenTelemetry - tracing reactive execution, profiling slow outputs or update cycles, monitoring sessions in production, exporting spans to a backend (Jaeger, Logfire, Honeycomb, Datadog, OTLP), suppressing telemetry for sensitive code, or when tempted to call trace.set_tracer_provider() inside app code to set up instrumentation.

Use when a Shiny for Python (py-shiny) app needs to save and restore its state - shareable URLs that reproduce the current inputs, restoring state after a page refresh, persisting session state to the server, excluding inputs from saved state, or when tempted to hand-roll query-string parsing or a custom persistence layer to remember input values.

Walk through the full Shiny for Python release train interactively, phase by phase. Use when the user says "release", "start a release", "py-shiny release", "release train", or wants to publish new versions of py-shiny and its ecosystem packages (py-htmltools, py-shinyswatch, py-shinywidgets, shinylive, py-shinylive, r-shinylive). Guides through version bumps, CI checks, tagging, PyPI publishing, conda-forge, Huggingface, site updates, and blog post publication.

Manage GitHub sub-issues using the gh-sub-issue extension. Use when the user asks to create, list, add, or remove sub-issues (child issues) from a parent issue.

Comprehensive guide for porting UI components from R's bslib package to py-shiny. Use this skill when: (1) User asks to "port this feature" or "port a component" and mentions bslib or links to a bslib PR (e.g., github.com/rstudio/bslib/pull/...), (2) Porting a new component from bslib to py-shiny, (3) Adding a new input, output, or UI component that exists in bslib, (4) Implementing feature parity with bslib, (5) Working on bslib-related features or components. Covers the complete workflow including understanding source implementation, creating Python equivalents, vendoring assets (SCSS, CSS, JavaScript), creating tests, documentation, and all necessary project files.

Generate documentation sites for Python packages with Great Docs. Covers init, build, preview, configuration (great-docs.yml), API reference, CLI docs, user guides, theming, deployment, and the llms.txt agent-context files. Use when creating, configuring, building, or troubleshooting Python package documentation.

Configure a Great Docs documentation site through great-docs.yml. Covers theming (navbar gradients, content glow, dark mode), hero sections, logos, announcements, sidebar options, page tags, page status badges, SEO, analytics, and deployment settings. Use when customizing site appearance, enabling features, or tuning build behavior.

Write and maintain narrative user-guide pages for a Great Docs site. Covers page creation, QMD frontmatter, section grouping, sidebar ordering, callouts, executable code cells, cross-references, and content guidelines. Use when adding, reorganizing, or improving user-guide content.

Review and improve Python docstrings for Great Docs API reference generation. Covers NumPy and Google style conventions, parameter documentation, return types, examples, cross-references, and Great Docs directives (%seealso, %nodoc). Use when auditing, writing, or fixing docstrings in a Python package.

Author, configure, and distribute Agent Skills for a Great Docs site. Covers the three scenarios: automatic skill generation, adding a single hand-written skill, and distributing multiple named skills with a switcher page. Use when creating, editing, or configuring SKILL.md files for package documentation.

Capture screenshots and PDFs from raw HTML strings or local HTML files using nokap. Use when rendering HTML output from packages like Great Tables, Plotly, or custom report generators to images or PDFs.

Generate PDFs from web pages or HTML using nokap. Use when writing code that produces PDF output from URLs or HTML strings, configures paper sizes, margins, or creates element-bounded PDFs sized exactly to content.

Capture screenshots from live web pages using nokap. Use when writing code that screenshots URLs, configures viewports, handles page load timing, or captures specific page elements from remote sites.

Capture screenshots and PDFs from web pages using headless Chrome via CDP. Use when writing Python code that captures, screenshots, or renders web pages, local HTML files, or raw HTML strings to images or PDFs.

Guides authoring the in-product release notes in release-notes/next.md, especially adding and iterating on images/GIFs with a local in-product preview loop before committing the asset to release-notes/assets/. Use when writing or revising next.md ahead of a release or patch (typically invoked as /prepare-release-notes). The later ship-day promotion of next.md into release.md is handled by /release-update and /patch-update, not this skill.

Walks through the ship-day site update for a Positron patch release. Bumps versions, copies the new patch entry from next.md into release.md, resets next.md, refreshes _freeze, and opens the PR. Use when the user starts the ship-day PR for a patch (typically invoked as /patch-update). The earlier "Prepare release notes" PR that lands patch content into next.md is a separate workflow and is not part of this skill.

Walks through the monthly release-day site update for positron-website. Archives last month's notes, promotes next.md into release.md, bumps versions, refreshes _freeze, flags downstream doc updates, and opens the PR. Use when the user starts the monthly release PR (typically invoked as /release-update).

Build and deploy data apps, dashboards, APIs, and reports using Posit tools on Snowflake. Use when the user asks to build, create, or deploy any of: Shiny (R or Python), Streamlit, Dash, FastAPI, Plumber, Quarto, R Markdown, Jupyter, Panel, or Bokeh apps — especially with Snowflake data. Also triggers for: "deploy to Posit Connect", "rsconnect", tidyverse, tidymodels, orbital, querychat, chatlas, Positron, "publish my app", or any R/Python data product targeting Snowflake. Do NOT use for Node.js, Next.js, React, or custom JS/TS web apps — that is the snowflake-apps skill (Snowflake App Runtime). Boundary: data science apps, dashboards, reports, and APIs in R or Python deployed to Posit Connect → this skill; custom JavaScript web apps on App Runtime → snowflake-apps. Do NOT use for pure SQL.

Prepare Snowflake data for analysis in Posit Workbench. Use when the user wants to: discover relevant tables, profile data quality, create curated views or dynamic tables, apply governance policies, or set up a data layer for their R or Python analysis. Triggers include: "find tables for", "profile this data", "create a view for analysis", "build a dynamic table", "prepare data", "curate", "set up data for my team", "tag columns", "mask PII", "what data is available", or "explore the catalog". Do NOT use for writing R/Python analysis code (that is Posit Assistant's job inside the IDE) or for building/deploying apps (use $posit for that).

Write ggsql queries — a grammar of graphics for SQL. Use when the user wants to create, modify, or understand a ggsql visualization query.

Use the `btw` CLI to access R documentation, manage R package development, query CRAN, inspect the R environment, and discover or fetch skills from the command line. Use when you need to: (1) read R help pages or vignettes, (2) run R CMD check, tests, or devtools::document(), (3) search CRAN for packages, (4) check installed package versions or R platform info, (5) list or fetch skills from R packages or GitHub repositories.

Set up the Posit Publisher development environment. Use this skill when a developer wants to onboard onto the Publisher project, set up their dev environment, get started contributing, or troubleshoot setup issues. Trigger on phrases like "set up my dev environment", "onboard me", "get started developing", "dev setup", "configure my environment", or when someone mentions having build/test failures that sound like missing prerequisites.

Scaffold a new config option for Posit Team products

Python bindings to cmark-gfm: CommonMark/GFM parsing and rendering (HTML, LaTeX, man, XML, CommonMark). Use when writing Python code that converts Markdown to other formats using the multimark package.