Use subtasks and dependencies
Describe a work breakdown and record which outcomes block others.
A subtask belongs to a larger outcome. A dependency records an ordering requirement between tasks. Use these relationships for different reasons: breaking a feature into parts and preventing delivery before a prerequisite is complete.
Read the visual explanation
A database task blocks a UI task. Completing the prerequisite changes the dependency context; starting execution still follows the task workflow.
Break down an outcome
Open the parent task and add or link the subtasks offered by the task controls. Give each child a clear result, owner, and source context. Keep the parent focused on the combined outcome rather than repeating every child's implementation steps.
For example, “Add searchable activity” can have a database-index task, an API-query task, and a UI task. Follow the child links to inspect their sessions and evidence.
Record a blocker
Add the prerequisite relationship from the task's dependency controls. Confirm the direction: if the UI needs a new API field, the API task blocks the UI task.
Read the blocker list before starting work. Removing a dependency changes the delivery requirement; record why it is no longer needed. A canceled or duplicate prerequisite does not count as successful completion.
Follow completion
Task progression evaluates prerequisites, subtasks, required delivery contributions, acceptance, and PR evidence. Completing one child does not establish that the entire parent is done. A completed blocker also does not automatically launch its dependent's session.
Use start work and follow progress for execution and automatic-update controls. If a status change is rejected, read the listed completion or dependency requirement instead of repeatedly moving the task.
Keep the relationship graph small enough to explain. Use a specification for detailed behavior and a session for implementation discussion.