// 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.
| name | working-on |
| description | 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. |
| disable-model-invocation | true |
| arguments | ["path"] |
| argument-hint | [path-to-tracking-doc] [additional instructions] |
| metadata | {"author":"Garrick Aden-Buie (@gadenbuie)","version":"1.0"} |
| license | MIT |
You are managing a tracking document that serves as the source of truth for the current task or feature.
The tracking document is: $path
Once activated, treat the tracking document as a living record. Update it after:
If in doubt, update the document. It is better to over-document than to lose context.
Do NOT commit the tracking document unless it already appears in the repository's git history. If the file is not tracked by git, leave it out of any commits.
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.
R 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.
Comprehensive R package for command-line interface styling, semantic messaging, and user communication. Use this skill when working with R code that needs to: (1) Format console output with inline markup and colors, (2) Display errors, warnings, or messages with cli_abort/cli_warn/cli_inform, (3) Show progress indicators for long-running operations, (4) Create semantic CLI elements (headers, lists, alerts, code blocks), (5) Apply themes and customize output styling, (6) Handle pluralization in user-facing text, (7) Work with ANSI strings, hyperlinks, or custom containers. Also use when migrating from base R message/warning/stop, debugging cli code, or improving existing cli usage.
Help users write correct R code for async, parallel, and distributed computing using mirai. Use when users need to run R code asynchronously or in parallel, write mirai code with correct dependency passing, set up parallel workers, convert from future or parallel, use mirai_map, integrate with Shiny or promises, or configure cluster/HPC computing.