working-on — Claude Code skill: a task tracking doc
Makes one tracking file the source of truth for the current task. The agent keeps appending decisions, findings and plans to it as work moves.
npx skills add posit-dev/skills --skill working-on -a claude-codeWhat working-on does
This skill turns a chosen document into a running record of the task. The agent updates it whenever a decision lands, a bug or edge case shows up, a requirement changes, an issue closes, or files get committed. Plans go into the file rather than staying in the chat, so the record survives the session.
What ships is a set of behavioural rules, not scripts. Updates should stay short: bullets and small paragraphs beat long prose. Capture why a call was made, not just what it was. Sections that go stale get moved into “Archive” or “Resolved” instead of being dropped. When no document exists yet, the agent builds one around the task.
Git has its own clause. A tracking file that is not already in the repository history must stay out of commits, so keep that in mind if you place it inside the project. The skill needs a path argument: with no path it has nothing to track.
What it helps with
- carry decisions across agent sessions on one feature
- keep a bug and its workaround in a single file
- rebuild context after the chat is gone
- list open questions for a multi-step task
- write the plan to disk instead of leaving it in the thread
Example prompts for the agent
- Use
docs/auth-refactor.mdas the tracking doc for this task - We're fixing a bug, track it in
notes/bug-142.md - Starting the export feature, keep the record in
docs/export.md
How to install working-on
1Skills CLI (Vercel)
npx skills add posit-dev/skills --skill working-on -a claude-code2Manually: put the files in place
~/.claude/skills/working-on/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/working-on/
1Skills CLI (Vercel)
npx skills add posit-dev/skills --skill working-on -a codex2Manually: put the files in place
.agents/skills/working-on/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add posit-dev/skills --skill working-on -a cursor2Manually: put the files in place
.cursor/skills/working-on/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install posit-dev/skills working-on2Manually: put the files in place
.github/skills/working-on/SKILL.md1Skills CLI (Vercel)
npx skills add posit-dev/skills --skill working-on -a gemini-cli2Platform CLI
gemini skills install https://github.com/posit-dev/skills --path posit-dev/working-onManually: put the files in place
.devin/skills/working-on/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add posit-dev/skills --skill working-on -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about working-on
How do I install working-on in Claude Code?
Run npx skills add posit-dev/skills --skill working-on -a claude-code. The skill then sits at ~/.claude/skills/working-on/SKILL.md.
What does working-on do?
It makes the given file the source of truth for the task and has the agent append decisions, discoveries, plans and commit notes there. The record stays after the session ends.
Will the tracking document end up in a commit?
Only if it already exists in the repository's git history. Otherwise the skill keeps it out of commits.
Source text
SKILL.md · MIT
--- 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.1" license: MIT --- # 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 - Any plan you form — write it to the document rather than presenting it only in chat; the document is the persistent record 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
© Garrick Aden-Buie (@gadenbuie) · MIT · posit-dev/skills
