Template: Task Plan

Author: Team Lead Date: YYYY-MM-DD Status: Planning | In Progress | Complete

User Request

Restate the user’s original request clearly and completely.

Decomposition

Task List

#	Task	Persona	Depends On	Status	Notes
1	[Task description]	[Persona name]	—	Pending
2	[Task description]	[Persona name]	1	Pending
3	[Task description]	[Persona name]	1	Pending	Can run in parallel with #2
4	[Task description]	[Persona name]	2, 3	Pending

Worktree Strategy

When parallel tasks modify the same repository, each agent should work in its own git worktree for physical directory isolation.

Base branch: The branch this project’s changes will ultimately be merged into (typically main, but could be dev, stage, or a pre-existing feature branch). Record the actual branch name here before work begins. The base branch is never modified locally — all local work targets the integration branch or worktree branches.

Integration branch: ${githubUsername}/${projectName}-integration (created from the base branch before work starts; all worktree branches merge here).

Worktree layout (at workspace root):

Worktree directory	Branch	Agent	Task
`${projectName}-worktrees/${taskName}`	`${githubUsername}/${projectName}/${taskName}`	[agent name]	#

Naming convention: ${projectName}-worktrees/ parent directory at workspace root, with one subdirectory per agent task.

Branch convention: ${githubUsername}/${projectName}/${taskName}.

Merge workflow: Each worktree branch merges into the integration branch (not the base branch) as tasks complete. A single PR is opened from the integration branch to the base branch. Only deviate from this pattern (e.g., separate PRs per sub-task) when explicitly justified.

Agent absolute-path rule: Agents in worktrees MUST use absolute paths for all tool calls (Read, Edit, Write, Glob, Grep) and prefix Bash commands with cd <worktree-absolute-path> &&. Never use relative paths.

If all tasks write to different repositories or a single agent writes at a time, worktrees are not needed. In that case, replace this section with: “Single directory — no worktrees needed” and state why.

Parallelization

Identify which tasks can run concurrently:

Parallel group 1: Tasks [#, #] — independent, can run simultaneously.
Sequential chain: Tasks [# → # → #] — each depends on the previous.

Idle Agent Strategy

When the number of agents exceeds parallel tasks in a phase, declare how idle agents should be used. Choose one or combine:

Buffer tasks: List low-priority tasks (code review, refactoring, linting, documentation) that idle agents can pick up without blocking the critical path.
Phase overlap: Allow idle agents to begin next-phase tasks early in a separate worktree branch. Note: this may introduce merge risk at the next gate.
Accept idle time: Explicitly accept that some agents will be idle during low-demand phases. Preferred when phases are short or buffer tasks add no value.

Strategy for this plan: [Choose and describe]

Personas Required

List the personas that need to be spawned for this work:

Persona	Tasks Assigned	Worktree	Spawn Order
[Persona name]	1, 2	`${projectName}-worktrees/${taskName}`	First
[Persona name]	3	`${projectName}-worktrees/${taskName}`	First (parallel)
[Persona name]	4	(merged integration branch)	After #2, #3 complete

Open Questions and Decisions

#	Question	Options	Recommendation	Decision

Acceptance Criteria

How will the Team Lead know the work is complete?

[Criterion 1]
[Criterion 2]
[Criterion 3]

Risks and Blockers

Risk / Blocker	Impact	Mitigation
[Description]	[Impact on timeline or quality]	[How to resolve]

Project Completion Artifacts

The Team Lead produces these artifacts after all tasks complete, before cleanup:

Byproducts (`byproducts/`)

File	Description
`changelog.md`	Summary of changes made by the team
`learnings.md`	New knowledge about the codebase or technologies
`suggestions.md`	Improvement suggestions, risks, tech debt, doc gaps

Continuous Improvement

Artifact	Produced By	Location
Observation log	CI Observer (runs throughout project)	`session/ci-observations.md`
Improvement proposal	Improvement Analyzer (runs at project end)	`continuous-improvement-proposal.md`

The CI Observer is spawned at project start and receives periodic updates from the Team Lead at task boundaries. The Improvement Analyzer is spawned after all tasks complete and the CI Observer shuts down.

Task Tracking Protocol

The team’s TaskList is the single source of truth for task status. Follow this protocol at every phase boundary:

Project start: Team Lead creates a TaskCreate entry for every task in the plan (including gate tasks).
Task completion: The owning agent calls TaskUpdate to mark the task completed immediately — do not batch completions.
Phase gate checklist (before proceeding to next phase):
- Run TaskList and verify every completed task is marked completed.
- Correct any stale statuses before opening the next phase.
- Create TaskCreate entries for any newly discovered tasks.
Never rely on git log or memory for task status — always use TaskList.

Progress Log

Date	Event	Notes
YYYY-MM-DD	Plan created
YYYY-MM-DD	[Persona] completed task #N	[Brief note]
YYYY-MM-DD	Blocked: [description]	Escalated to [user / Product Owner]