Working On

posit-dev/skills/posit-dev/working-on

by posit-deve20b71b2ab527b7c480f4f60dcce2b18df1a99aeMITListed Oct 9, 2026Updated Oct 9, 2026

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.

Instructions onlyProductivity & Workflow
AI-generated overview

Maintains a tracking document as the source of truth for a task, updating it with decisions, discoveries and progress.

What it does
Treats a specified tracking document as a living record for the current feature, bug fix or multi-step task. It updates that document after decisions, new problems, requirements, completed work, commits and plans, and creates the document with a sensible structure if it does not exist. Updates are kept concise, record the reasoning behind decisions, and stale sections are moved to an archive rather than deleted.
When to use it
Use when starting work on a feature, bug fix or multi-step task that benefits from a persistent record of decisions, discoveries and progress. It suits work spanning multiple sessions where context should survive beyond the chat.
Requirements
Requires a path to a tracking document, passed as an argument. Instructions only; no scripts, packages or credentials. Git is referenced only for deciding whether the document may be committed.

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

Source and attribution

Source:posit-dev/skillsinposit-dev/working-onat commite20b71b

License: MIT

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal