working-on
The working-on skill maintains a tracking document as the authoritative record for an ongoing feature, bug fix, or multi-step task. Activate it when beginning work that requires persistent documentation of decisions, discoveries, and progress, then update the document after each decision, problem discovery, implementation milestone, or commit to preserve context and enable effective recall across work sessions.
git clone --depth 1 https://github.com/posit-dev/skills /tmp/working-on && cp -r /tmp/working-on/posit-dev/working-on ~/.claude/skills/working-onSKILL.md
# Working On You are managing a tracking document that serves as the source of truth for the current task or feature. The tracking document is: `$path` ## Behavior Once activated, treat the tracking document as a living record. Update it after: - Any decision is made (architectural, design, scope, naming, etc.) - A new problem, bug, or edge case is discovered - A new sub-feature or requirement emerges - An issue is raised or resolved - Any significant implementation work is completed - A key part of a conversation with the user that would be useful to recall later - Any time you commit files — a commit is a strong signal that the tracking document should also be reviewed and updated If in doubt, update the document. It is better to over-document than to lose context. ## Git Handling 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. ## Guidelines - Keep updates concise — bullet points and short paragraphs are preferred over prose - Use timestamps or date headers when the document spans multiple sessions - Record the *why* behind decisions, not just the *what* - When a section becomes stale or irrelevant, move it to an "Archive" or "Resolved" section rather than deleting it - If the document doesn't exist yet, create it with a sensible structure based on the task at hand
>
Create 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.
Write ggsql queries — a grammar of graphics for SQL. Use when the user wants to create, modify, or understand a ggsql visualization query.
Creates a pull request from current changes, monitors GitHub CI, and debugs any failures until CI passes. Activate when the user says "create pr", "make a pr", "open pull request", "submit pr", "pr for these changes", or wants to get their current work into a reviewable PR. Assumes the project uses git, is hosted on GitHub, and has GitHub Actions CI with automated checks (lint, build, tests, etc.). Does NOT merge - stops when CI passes and provides the PR link.
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
>
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.