next-task

name	next-task
description	Use when the user says "next task" or asks to continue the app implementation plan from app_plan.md/task_list.md. Select the next incomplete task, implement it, mark it complete, test, commit, and report the next task.

Next Task Workflow

Use this skill whenever the user says next task, asks to continue the plan, or asks what to work on next.

Before starting a new task

1. Compact or summarize the current conversation context before selecting work so the next task starts with a clean, task-focused context window. Preserve: current task state, blockers, test/deploy state, uncommitted changes, relevant credentials/secrets location (not secret values), and the next unchecked task.
2. After compacting, continue with the source-document reads below.

Source documents

1. Read AGENTS.md for current project conventions.
2. Read app_plan.md for the implementation plan and architectural intent.
3. Read task_list.md for the ordered task checklist and difficulty labels.

Selecting work

1. Find the first unchecked task in task_list.md, using checklist items formatted like - [ ] N. **Task name** — difficulty.
2. Treat tasks as chronological. Do not skip ahead unless the next task is already complete, blocked, impossible in the current environment, or the user explicitly directs a different task.
3. If a task is blocked, add a short indented Blocked: note beneath it in task_list.md, leave it unchecked, report the blocker, and ask the user whether to skip or resolve it.
4. If a task is too large, split it into smaller subtasks directly below that task in task_list.md, but keep the original task unchecked until its acceptance criteria are satisfied.

Implementing the task

1. Keep files small and single-purpose, following AGENTS.md.
2. Prefer existing architectural seams named in AGENTS.md.
3. Keep secrets and user credentials out of function .env files; use Firestore credential documents for per-user provider credentials.
4. For Firebase operations, use the firebase-ops skill.
5. Add automated regression coverage in the same task for new or changed behavior (unit tests for parsers/validators/mappers/path helpers, integration-style tests or testable helpers for API/repository/job behavior, and frontend tests for non-trivial UI when infrastructure exists). Do not retroactively test old work unless touched. If tests are impractical, document why and prefer adding a small test seam over skipping.
6. Run relevant test command(s), then existing lint/build checks, before marking the task complete.
7. If the task changes production-served code and credentials/environment allow it, deploy the changed surface with the narrowest scoped deploy before final smoke/log verification. Use firebase deploy --only functions for functions/, firebase deploy --only hosting for frontend hosting, and gcloud run deploy session-worker --source workers/session-worker --region us-central1 for workers/session-worker/ Cloud Run changes.
8. After deployment, check the relevant production logs and confirm the new code path is active. For session-worker, read recent Cloud Run logs with gcloud logging read 'resource.type="cloud_run_revision" AND resource.labels.service_name="session-worker"' --limit=100 --format=json; look for task-specific evidence such as Pi runtime attached to actor for Pi runtime delegation work. If deployment or log access is unavailable, report the blocker and provide the exact command for the user to run.
9. After code edits, feature additions, or bug fixes, run the test-improvements skill automatically. If unavailable or no dev server is running, state that clearly.

Marking completion

When the selected task is complete:

1. Update task_list.md by changing the task checkbox from - [ ] to - [x].
2. Add a short indented Completed: note with the date and a concise summary when helpful.
3. Do not mark a task complete if tests or acceptance checks fail, unless the user explicitly accepts the failure.

Committing

After completing and marking the task:

1. Review git status --short.
2. Stage only files relevant to the completed task. Do not stage unrelated user changes.
3. Commit with a concise message that references the task number and goal, for example: Task 12: add authenticated API baseline
4. If committing is impossible, report the exact reason and leave the working tree state clear.

Final response

End every task run with:

1. Goal: restate the user/requested task goal.
2. Completed: summarize what changed.
3. Tests: summarize automated/manual checks and any skipped QA reason.
4. Commit: provide the commit hash or explain why there is no commit.
5. Next task: list the next unchecked task with its difficulty.

The user should be able to continue by saying only next task.