User Problem
A user completes their first squads run. The CLI exits. Nothing tells them:
- That this is designed to run on a recurring schedule
- How to set that up
- What the intended pattern is ("org gets smarter every cycle")
Power users average 730 runs — they are all on a schedule. First-timers don't know schedules exist. The product's core value proposition is invisible at the UX layer.
Expected Behavior
Run completion message (once squads-cli#690 ships) should include scheduling guidance:
Run completed — product/product-lead (2.1s)
Output: .squads/runs/product-lead-2026-04-07-09:02.md
Memory: +2 patterns learned
To run on a schedule (cron):
0 9 * * * cd /path/to/project && squads run product product-lead
See: docs/scheduling.md
Acceptance Criteria
Source
Friction log FR-015 (product/friction-log/2026-04-07.md)
Depends on: squads-cli#690 (run completion message must exist first)
D1 retention layer: First-run success (#689/#690) -> scheduling path (FR-015) -> return user flow (#692 log history)
Priority: P1 — without a scheduling signal, users who get a successful first run have no reason or path to return.
User Problem
A user completes their first
squads run. The CLI exits. Nothing tells them:Power users average 730 runs — they are all on a schedule. First-timers don't know schedules exist. The product's core value proposition is invisible at the UX layer.
Expected Behavior
Run completion message (once squads-cli#690 ships) should include scheduling guidance:
Acceptance Criteria
squads run --onceor non-interactive modesSource
Friction log FR-015 (product/friction-log/2026-04-07.md)
Depends on: squads-cli#690 (run completion message must exist first)
D1 retention layer: First-run success (#689/#690) -> scheduling path (FR-015) -> return user flow (#692 log history)
Priority: P1 — without a scheduling signal, users who get a successful first run have no reason or path to return.