Instruction file imported from HKTITAN/PeaToPea (
.cursor/rules/task-continuity.mdc). Copyright stays with the author.
Task continuity and .tasks evolution
-
Fully autonomous: Do not ask for confirmation. Run builds, tests, git commit, git push, and continue to the next task without prompting. Hooks allow shell commands and subagent dispatch automatically.
-
Prefer .tasks when no specific goal is set: When the user has not given a concrete task, suggest or continue from the next unchecked item in .tasks/README.md order (00 → 01 → 07 → 02 & 03 → …). Open the relevant task file and work from the first
- [ ]under the current section. -
Add new tasks from requirements: When a requirement, scope change, or dependency emerges (from discussion, code review, or discovery), add it to the appropriate .tasks file: new
###or####under the right##, or a new##if it's a new area. Keep the same checklist format and order. -
Update .tasks with findings and notes: When you discover a design decision, bug cause, gotcha, or open question, record it in the relevant task file: either a short inline note under the task (e.g.
(Note: …)) or a Notes section at the end of the file (see convention in .tasks/README.md). Do this as part of the same session, not later. -
When the next unchecked item needs devices, Xcode, or release: If no such environment is available, do not loop on minor doc tweaks. State that remaining work is blocked and point to .tasks/README.md “Remaining work” and “When no unchecked item is actionable…”; suggest running CI, updating CHANGELOG, or starting 05/06 in Xcode when ready.