Project Tracker

Problem

During multi-turn discussions about features, requirements, or architecture, decisions are easy to lose in message history: which items are confirmed, which are still pending, and why changes were made can become costly to re-check later. Project Tracker addresses a narrow problem: persist the state of a project discussion into local, reviewable files instead of relying on another system or manual copying.

How It Works

The skill uses the agent’s file read/write tools, without external commands or API calls. By default, notes are stored under ~/.project-notes/, and the location can be overridden with PROJECT_NOTES_DIR. The core workflow is:

• Create a project note for a new project, feature, or requirement in Markdown
• Fill in the template with context, decisions, action items, and confirmation status
• Update the index by maintaining INDEX.md for quick lookup
• Keep it current by moving entries between Confirmed and Pending as the conversation evolves

If the directory is missing, it is created recursively. If the target is not writable, the skill suggests using a custom path. When file conflicts occur, it prefers appending over overwriting.

Boundaries

This fits discussions that need recall across messages, such as feature design, multi-step tasks, or requirements gathering. It is not a good fit for one-shot tasks, transient questions, or work already tracked in external systems like Notion or Jira. Using it for throwaway questions can add unnecessary file noise.