메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.
| name | new-work |
| description | 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. |
| disable-model-invocation | true |
| metadata | {"author":"Garrick Aden-Buie (@gadenbuie)","version":"1.0"} |
| license | MIT |
Todo notes track work items as markdown files with YAML front matter capturing status, context, and progress.
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).
YYYY-MM-DD_short-kebab-slug.md, e.g. 2026-02-18_add-oauth-support.md.
YAML front matter plus a markdown body. Only status is required.
---
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?
-->
pending/ if needed, create the date-prefixed file with status: pending, and write enough context to resume later.status; add issue/pr links when they exist; check off Work Items (- [ ] → - [x]); record significant decisions in the Decision Log.status: done and mv the file from pending/ to done/.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.