task

Task

$ARGUMENTS

Your Instructions

1. Use Existing Plan or Create Task Plan

If a PLAN file was provided or mentioned (e.g., from a prior /plan command) with structured phases, it is your working document — do not create a separate TASK file.

Never replace or condense a PLAN file. It is the user's reviewed work product: goals, file references, verification details, rationale. Add tracking to it in place — convert implementation bullets to checkboxes (- Item → - [ ] Item), append new items or sections as gaps appear, update status markers as you progress — so that the checkboxes sit alongside the existing prose, never instead of it. An edit that removes more text than it adds is almost certainly wrong.

If no suitable PLAN file exists, create a markdown file TASK_[descriptor]_[timestamp].md containing:

• Task description
• Checklist of specific steps/subtasks
• Success criteria
• Any dependencies or prerequisites

Keep it brief: one concise line per item, links to files instead of explanations ([config](./src/config.js)). This is a tracking tool, not documentation.

Status markers:

• [ ] Not started
• [~] In progress
• [x] Complete
• [!] Blocked or needs attention

2. Execute While Updating

Update the checklist after every significant action — [~] when starting an item, [x] when done, [!] on blockers — and add subtasks as they surface. The file is the live record: sessions crash mid-run, and anyone (including a fresh session) must be able to read current progress from the file alone. Keep notes extremely brief or link to files.

3. Completion Expectations

Complete the full task/plan. Do not skip items, defer work, or stop halfway; minor deviations and unexpected issues are normal — handle them and continue. Stop early only for an overwhelming reason (core assumptions fundamentally wrong, blocking dependencies unresolvable).

When finished, the file shows the final status of all items, any unresolved issues (with explanation if incomplete), and a brief completion summary.