Profile presets

A repo usually runs one kind of work — its focus/objective and settings. Profile presets let one repo carry several named work streams you control independently: e.g. a unit-tests preset that runs nightly, a solve-issues preset you trigger by hand, and an explore preset for weekends.

What a preset is

Each preset is a self-contained run config:

• name — e.g. unit-tests.
• enabled — whether it participates in autonomous runs / round-robin.
• mode — schedule (runs in its own window) or manual (only when you trigger it via the Run button, CLI, or API).
• work type — implement (focus/objective), explore, issue_solving, issue_scout, or pr_watch.
• the work bundle — focus, objective, verify command, auto‑merge, reviews, and (for schedule mode) a days/start/end window.

Manage them in Repo settings → Profile presets (add · edit · enable/disable · delete).

How a preset gets picked

• Scheduled runs — the scheduler considers every enabled, schedule‑mode preset whose window matches now. If more than one overlaps, it round‑robins across them so each gets a fair turn.
• Manual runs — Run with a specific preset, or leave it unset to round‑robin across the enabled presets. A manual‑mode preset never runs on its own — only when you ask for it by name.

scheduled  → enabled + schedule-mode + window matches now → round-robin if >1
manual Run → --preset <name>, else round-robin across enabled presets

Only one run executes per repo at a time, so presets take turns — they never run concurrently.

What a run does, per work type

A preset's work type decides what running it actually does — and it means the same thing whether the scheduler runs it or you trigger it manually (Run button, run --preset, or API):

Notes:

• explore, issue_scout, issue_solving, and pr_watch require the Pro plan or higher; issue_scout/pr_watch also need a GitHub token.
• issue_solving and pr_watch act on what's already queued — if there's nothing (no issue candidates / no open PRs), the run reports "nothing to do" rather than failing. Scout/sync first to populate them.

From the CLI / API

This is what lets another agent configure and operate several work streams per repo:

am-cloud platform repo preset <id> list
am-cloud platform repo preset <id> add --name unit-tests --work-type implement \
    --mode schedule --schedule-days "[0,1,2,3,4,5,6]" --start 22 --end 8 --focus "raise coverage"
am-cloud platform repo preset <id> enable|disable|remove <name>
am-cloud platform repo run <id> --preset unit-tests     # omit --preset → round-robin

REST: GET/POST /api/repos/{id}/presets, PATCH/DELETE /api/repos/{id}/presets/{name}, and POST /api/repos/{id}/run?preset=<name>.

Relationship to other settings

• No presets = today's behavior. A repo with no presets just uses its settings above — nothing changes until you add one.
• Playbooks are curated focus+verify starting points; a preset is a named, schedulable instance bound to a repo (you can seed one from a playbook).
• Focus / objectives still apply — a preset simply carries its own focus/objective for its stream.

Costs per preset

Each run records the preset that produced it, so spend can be attributed per profile (e.g. "how much did the unit-tests profile cost on this repo?") — see Run costs.

Related

• Focus · Playbooks · Objectives
• Scheduling · Run costs