When should you put a squad on a schedule?
Schedule a squad when the same maintenance job comes back every week and the objective doesn't change. You tune it once, and from then on a reviewed result is waiting for you instead of a chore.
- Dependency upgrades, the example on this page.
- Lint and type-error cleanup after a rules or compiler bump.
- Keeping coverage from slipping, with the test coverage squad on a weekly schedule.
- Not for work that needs product decisions every run. Those questions pile up.
How do you set up the squad?
Build the squad first from Build + review, as in the build and review playbook, and run it once by hand. When the result looks right, click Save as squad.
| Role | Agent (example) | What it does |
|---|---|---|
| Leader | Claude Code | Sends the objective to the builder, gets the reviewer's verdict, loops until approval and writes the report. |
| Builder | Codex | Upgrades dependencies and fixes breaking changes. |
| Reviewer | Claude Code | Reviews the changelog risks and the test run. |
- 1
Open Saved squads
Find the squad and open its row actions.
- 2
Choose Schedule
Tallos opens the Schedule dialog, which runs the squad on a recurring schedule like an automation.
- 3
Pick project, frequency and time
Frequency is Every hour, Every day, Weekdays or Every week. In this example: Weekdays, 07:00.
- 4
Write the objective
"What should the squad do each run?" Paste the objective below, then click Create schedule.
What objective should you paste?
Nobody is watching at 07:00, so decide the usual questions in advance. Tell the leader what to do in each case instead of asking.
Upgrade outdated dependencies and fix what breaks.
Scope
- Upgrade patch and minor versions. Majors only if the changelog
shows no breaking change that affects us.
- Fix code that breaks. pnpm test and pnpm build must pass.
Decide without asking me
- A major that drops a runtime we support: hold it back, list it.
- A package still failing after one fix attempt: revert it, list it.
Report
- Upgraded, held back (with the reason), and what I should check.What limits should you set?
Set 4 rounds and 2 members at once. An unattended run should be tightly bounded: enough rounds for one review loop and a revert, not enough to wander.
| Setting | Recommended | Why |
|---|---|---|
| Max rounds | 4 | Build, review, one fix round, one spare. |
| Max members at once | 2 | One builder, one reviewer. |
| Frequency | Weekdays | Daily enough to keep upgrades small. Every week works for slower repos. |
Save a squad once and let Tallos run it every weekday.
How does a scheduled run go?
An example weekday run. Package counts and findings are illustrative.
- 1
07:00: the run starts
Tallos starts the saved squad in a new, separate workspace. The leader counts nine outdated packages.
- 2
The builder upgrades
It upgrades all nine and fixes two breaking API changes.
- 3
The reviewer pushes back
One major version drops Node 18 in its changelog. Hold it back.
- 4
Round 2
The leader has the builder revert that major. Tests are green.
- 5
Report
The leader files the report with
tallos squad report. The run waits in Running & history for your review.
What happens if the leader asks a question while you're away?
The question stays pending in the squad view, and the run shows Needs your answer until you reply. Nothing is decided for you.
- "Open an issue for the held-back major?"
- "Two packages need a peer dependency bump. Upgrade both or skip both?"
If the same question shows up on several runs, move the answer into the objective.
What do you get each morning?
- Final report: what was upgraded, what was held back and why, what to verify. In the example: 8 packages upgraded with tests green, 1 major held back because it drops Node 18.
- Results by worktree: the builder's worktree marked Recommended, with View changes.
- Accept or Discard: Accept turns the recommended row into Open to create PR. Discard can also delete the members' worktrees, which keeps daily runs from piling up.
- Run history: every run with its rounds, succeeded and failed members, and an estimated cost when the models have a known price.
Review the diff in diff review before you open the PR. Each run lives in its own workspace, like any parallel workspace.
What variations work well?
- Weekly majors, daily minors. Two saved squads with two objectives: patch and minor on weekdays, majors every week.
- Hourly triage, light objective. Keep hourly runs for small read-only jobs such as summarizing new failures.
- Scheduled coverage. Schedule the test coverage squad weekly on the modules that changed most.
What are the common mistakes?
- Scheduling before a manual run. Run it once by hand, fix the objective, then schedule.
- Leaving decisions open. Every open decision becomes a question waiting for you.
- Letting runs pile up. Accept or discard each morning. Discard with worktree deletion clears old runs.
- Deleting the saved squad. The schedule needs it; a run then fails with "The scheduled squad was deleted."
New to squads? Start with your first squad, read the squads overview, or see what else you can schedule with automations.
Frequently asked questions
How do I schedule a squad in Tallos?
Save the squad, open Saved squads, choose Schedule from its actions, then pick a project, frequency, time and objective and click Create schedule.
Which schedules can a squad run on?
Every hour, every day, weekdays or every week, at the time you choose.
Does each scheduled run start from a clean workspace?
Yes. Each run starts in a new, separate workspace, so runs don't build on each other's leftovers.
What if the leader needs me at 7 a.m.?
The question stays pending with Needs your answer until you reply. To avoid it, decide the common cases in the objective.
Does my computer need to be on for a scheduled squad?
Yes. The agents run locally on the computer where the schedule was created, so it has to be on and awake at the scheduled time.
Does a scheduled squad merge anything on its own?
No. Like every squad, it stops at the end for your accept or discard. Nothing touches your base branch until you open the PR.
