Standby

Standby

Use this skill when the user has one slot to fill and many people who could take it, and only one of them may end up saying yes — a care home short a nurse at 05:40, a restaurant a commis before dinner service, a depot a loader before the trailer leaves.

standby is a cascade skill. It does not add a CALL-E backend queue, a provider-side campaign, a daemon, or new MCP tools. It sequences the existing one-off CALL-E call workflow: one call at a time, in an order the user supplies, stopping the moment someone accepts.

The distinction that matters: a broadcast campaign asks twenty people a question. A cascade asks one person a question, and asks the next one only because the first said no. Getting four acceptances for one shift is a worse outcome than getting none, because now a human has to un-invite three people.

When To Use

Use this skill for:

• filling a single open shift, slot, or appointment from a list of candidates
• on-call escalation where the next person is rung only if the previous one does not answer
• any "ring round until someone says yes" task
• shift-swap requests, cover requests, and last-minute no-show replacement

When Not To Use

Do not use this skill to:

• broadcast the same message to many people — that is a campaign, not a cascade, and this skill will refuse to run calls in parallel
• decide, on the agent's own authority, what an unclear answer meant
• fill several slots at once from one roster; run one cascade per slot, or the stop condition is ambiguous
• call anyone who is not on the roster the user supplied
• guess phone numbers, country codes, timezones, languages, or regions
• call a number the user has not confirmed the owner consented to receive calls on
• negotiate pay, hours, or terms on the call; the goal states the shift and asks yes or no
• retry a person who has already declined
• keep dialling after the shift has started

Required Inputs

Ask for any of these that is missing. Do not infer one from locale, phone number, UTC offset, or earlier unrelated context.

Optional: quiet hours, a cutoff before the shift, whether no-answers get a second sweep.

Core Workflow

1. Confirm the user wants one slot filled, and that the roster is a consented standby list.
2. Collect the required inputs above. Ask for anything missing; do not infer it.
3. Read references/cascade-rules.md — it is the source of truth for ordering, retries, callbacks, quiet hours and the stop condition. Do not re-derive these.
4. Check CALL-E auth status before the first call, so a token problem surfaces before anyone is rung.
5. Run the cascade (see Runtime Workflow). Report each outcome as it lands, not only at the end — the user is standing over this decision and may want to stop it.
6. When it ends, state the outcome in one line: who accepted and when they arrive, or that the list is exhausted and a human must decide.

Runtime Workflow

Repeat until the cascade ends:

1. Pick the next person. Callbacks that are now due first, then untried people in roster order, then the second sweep of people who did not answer. Never two at once.
2. Check before dialling. Skip anyone opted out, marked unavailable, or without a number, and say which — a silent skip is indistinguishable from a bug.
3. Check the clock. Inside quiet hours, do not dial unless the shift is imminent (see references/cascade-rules.md). Past the cutoff, stop entirely.
4. Plan exactly one call. Inspect the plan before running it: it must target the intended number and contain the intended shift details.
5. Run it, then read the result back.
6. Read the answer conservatively using references/reading-the-answer.md. Anything that is not a clear yes is not a yes, and anything that is not clear at all is not a no either.
7. On an answer you cannot read: stop and ask. Do not record it as a decline and move on — that passes over someone who may have been agreeing, and rings the next person about a shift that may already be taken. Report what was unreadable and wait. Place no further call until the user says what it meant, and record who said it.
8. On acceptance: stop. Do not dial anyone else. Record the arrival time, and if it is after the shift starts, say so in minutes rather than reporting a clean fill.

End conditions: someone accepted; the list is exhausted; the shift started; or the user stopped it. A call held for the user to resolve is not an end condition — the cascade is paused and resumes where it stopped.

Safety

• One call in flight. This is enforced, not advised. A second concurrent call is an error, not a slow path.
• An unreadable answer halts the cascade until a person says what it meant, and their name is recorded with the decision. It is never scored as a decline; a decline advances the list, and advancing on a call nobody could read is how a willing person gets passed over silently.
• Numbers come from the user. The skill never sources, guesses or completes a phone number. Numbers in examples and samples come only from ranges a regulator or network operator has permanently withheld from allocation — see references/safety.md.
• Nothing recorded from a real call is published. No transcript, recording, provider identifier or screenshot of one belongs in documentation or a demo, even with the number scrubbed.
• Opt-outs are honoured before dialling, and the reason is recorded.
• Every attempt is logged with its time, its outcome and its transcript, so a person can later ask why someone was or was not called and get an answer.
• Cancellation is immediate: because only one call is ever in flight, stopping the cascade stops everything except the call already ringing.

Reference Implementation

A runnable dashboard implementing this skill, with a fixture mode that replays authored calls — written, not recorded — so the whole cascade can be watched with no CALL-E account, is linked from references/reference-implementation.md.