Team workflows

A good team workflow makes agent work reviewable by someone who was not watching the terminal.

That usually means the work starts from a task, leaves a readable plan or log, and ends with a diff a human can inspect.

Start from the shared task

Use a Coldtea task when work needs a record:

• What is being changed.
• Which repo or area is in scope.
• What is out of scope.
• Which checks should run before review.
• Any linked Linear, GitHub, or QA context.

A prompt alone is easy to lose. A task gives the agent, the reviewer, and the next teammate the same starting point.

Keep the handoff visible

Task-linked brews can attach implementation plans and session logs to the task. Use them for facts, not ceremony.

A useful log says:

• What changed.
• What checks ran.
• What failed or was skipped.
• What still needs a human decision.

If someone has to read the whole terminal transcript to learn those basics, the handoff is not done yet.

Use worktrees for parallel work

Worktrees help when two tasks need separate branches or checkouts. They keep Git edits apart so one agent does not trample another branch.

They do not sandbox the machine. Commands in each worktree still use local permissions, network access, credentials, package caches, and local services available to your user account.

Use worktrees for Git separation. Use a disposable checkout, VM, container, or separate machine when you need stronger isolation.

Review before merge

A team workflow should have a review stop, even when the agent looks confident.

Before merging, check:

1. The task description and scope.
2. The implementation plan or session log.
3. The diff in the correct branch or worktree.
4. The checks that matter for that repo.
5. Any integration notes, QA runs, or deployment context your team uses.

Moving a task to a later workflow state is a signal. It is not proof that the code is safe to ship.

Where integrations fit

Integrations can reduce copy-paste between Coldtea and the tools your team already uses.

Where enabled, Linear can bring issue context into tasks or keep selected task fields aligned. Where enabled, GitHub can support repository-aware flows such as PR, QA, or cloud-run setup. The exact behavior depends on your TeaHouse configuration and the upstream provider permissions.

Do not debug every missing task or action as a Coldtea bug. First check the active TeaHouse/team, then the connected provider account, repository, team, or issue access.

Team defaults that age well

Start with boring rules:

• One task per meaningful branch of work.
• One worktree per parallel task.
• Short plans for non-trivial changes.
• Session logs before handoff.
• Normal lint, type, test, or build checks before review.
• Human review before merging agent-authored code.

These rules are not heavy. They are what let someone else trust the work without guessing what happened.

Next: use tasks, run parallel agents, or review agent work.