Skip to main content
ClaudeWave
Skill403 repo starsupdated today

new-work

The new-work skill creates and manages markdown-based todo documents with YAML front matter for tracking features, bugs, and multi-step tasks in a `_dev/todos/` directory. Use it when starting work that requires persistent tracking of status, decisions, progress, and context across sessions, updating the document as work advances through pending, in-progress, review, blocked, or done states.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/posit-dev/skills /tmp/new-work && cp -r /tmp/new-work/posit-dev/new-work ~/.claude/skills/new-work
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# New Work

Todo notes track work items as markdown files with YAML front matter capturing status, context, and progress.

## Storage Location

Use `_dev/todos/` if it exists in the repository root; otherwise ask the user where to store todo notes before creating anything. It contains two subdirectories: `pending/` (active) and `done/` (finished).

## File Naming

`YYYY-MM-DD_short-kebab-slug.md`, e.g. `2026-02-18_add-oauth-support.md`.

## File Contents

YAML front matter plus a markdown body. Only `status` is required.

```markdown
---
status: pending   # pending | in progress | review | blocked | done
issue: https://github.com/org/repo/issues/123   # optional
pr: https://github.com/org/repo/pull/456        # optional
---

# Title

Overview of what this is about and why it matters.

## Key Files

- `src/relevant-file.ts` — what it does
- `src/other-file.ts:functionName()` — why it matters

## Work Items

- [ ] First thing to do
- [ ] Second thing to do

## Design Decisions

Context, constraints, or choices worth capturing.

## Decision Log

<!--
### YYYY-MM-DD — Short Decision Title
**Decision:** What was decided?
**Rationale:** Why?
-->
```

## Lifecycle

- **Create:** make `pending/` if needed, create the date-prefixed file with `status: pending`, and write enough context to resume later.
- **In progress:** update `status`; add `issue`/`pr` links when they exist; check off Work Items (`- [ ]` → `- [x]`); record significant decisions in the Decision Log.
- **Complete:** set `status: done` and `mv` the file from `pending/` to `done/`.

## Keeping the Document Current

Treat the todo as a living record for the rest of the session. Update it after any decision, newly discovered problem or requirement, issue raised/resolved, significant implementation work, or commit. When in doubt, update it.

When you form a plan — whether in response to a user request or on your own initiative — write it to the todo document rather than presenting it only in chat. The document is the persistent record; the chat is not.

To resume in a future session, use `/working-on <path-to-todo>` — same live-document behavior without re-creating the file.
alt-textSkill

>

brand-ymlSkill

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.

ggsqlSkill

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

pr-createSkill

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.

pr-threads-addressSkill

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.

pr-threads-resolveSkill

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

create-release-checklistSkill

>

maintainer-declineSkill

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.