calle-ai/awesome-phone-call-agents/accesscall

AccessCall

#accesscall

Use this skill when a user wants to conduct an accessibility intake interview by phone instead of a web form, typically to support a Section 508 or WCAG conformance audit (VPAT 2.4).

Accessibility intake forms are themselves often inaccessible: screen reader fatigue, motor impairment, low vision, or cognitive load can all block someone from completing the exact form meant to capture their barrier report. AccessCall places a short phone call instead, conducts a structured verbal interview, and returns a result that maps onto standard VPAT 2.4 conformance report fields.

When To Use

#when-to-use

Use this skill for:

• accessibility intake for someone who cannot use a web-based audit form
• gathering verbal barrier reports to populate a VPAT 2.4 / Section 508 audit report
• "call and ask about accessibility issues" or similar one-off outbound intake requests

When Not To Use

#when-not-to-use

Do not use this skill to:

• place a call without the user explicitly confirming the recipient and their intent first
• guess a phone number's country code or region; ask if ambiguous
• call a third party who is not the requesting user without documented prior consent from that person
• auto-populate a VPAT row when the follow-up contact was never confirmed back to the caller (see Safety Rules)
• treat the auto-selected WCAG criterion row as final without human review; matching is done at the WCAG principle level (Perceivable / Operable / Understandable / Robust), not the specific success criterion

Setup

#setup

scripts/format-to-vpat.js depends on docx, jszip, and xml-js (declared in package.json). Run npm install inside skills/accesscall/ before using it — without this step it fails immediately with Cannot find module 'jszip'. scripts/parse-recap.js and scripts/phone-utils.js have no external dependencies and need no install step.

Core Workflow

#core-workflow

1. Confirm required inputs: recipient phone number, product or site name being audited, preferred language (default English, US). Ask for anything missing; do not fabricate a phone number or product name.
2. Validate the phone number against E.164 (scripts/phone-utils.js, isE164/assertE164) before calling plan_call. If it does not match E.164 format, reject it and ask the user to correct it — do not reformat, guess a country code, or silently pass a malformed number through to plan_call.
3. Call plan_call with the goal built from references/call-task-template.md, filling in recipient_name and product_or_site_name. Do not forward the user's full latest message verbatim via user_input by default — that field exists on plan_call for resolving an ambiguous/malformed phone number, not as a general passthrough. Only populate user_input when there's an actual number to disambiguate, and even then pass just the relevant phone-number text, not the user's entire message. The goal string alone carries recipient_name/product_or_site_name/language into the call.
4. Show the confirm_summary to the user and wait for explicit confirmation. Do not call run_call until the user confirms.
5. Immediately before calling run_call, acquire the dispatch lock (scripts/call-lock.js, acquireLock) keyed on the recipient's phone number, the purpose "accesscall-intake", and this specific plan_id — every lock is owned by the plan_id that acquired it. If a call to this recipient is already locked by a different plan_id — including on a retry after a crash or timeout, which will see the same lock a first attempt wrote — refuse to place another and ask the user to explicitly confirm an override before retrying. acquireLock also refuses unconditionally (even with override) if this exact plan_id was already dispatched before, per its durable dispatch history — a plan_id must never be replayed. The lock does not expire on a timer; it is only released in step 7, once a confirmed terminal status exists.

• Before ever passing `override`: run scripts/call-lock.js's checkLock first and show the human the current owning plan_id and generation — never override from memory or a stale earlier check. Overriding requires passing that exact generation as expectedGeneration; acquireLock re-verifies inside the same atomic critical section that the on-disk generation still matches before writing, and refuses with a clear "state has changed" error if it doesn't (e.g. a different override already went through in the meantime). This exists because the per-recipient mutex alone only serializes writes against each other — it does not stop two separately, legitimately approved overrides (each based on what looked like current state at approval time) from both eventually succeeding one after the other against state that changed in between. Never retry an override with the same expectedGeneration after a mismatch; re-check and decide again.

1. Call run_call with the confirm_token exactly as received. Never call it more than once for the same plan_id.
2. Poll get_call_run every 1-3 seconds while the run is active, then slow down, until a terminal status. As soon as one of COMPLETED/FAILED/NO_ANSWER/DECLINED/CANCELED/CANCELLED/VOICEMAIL/BUSY/EXPIRED is confirmed, call scripts/call-lock.js's releaseLock with that same plan_id and status to release the dispatch lock from step 5. releaseLock is compare-and-delete: it only releases if the plan_id given still matches the lock's current owner, so a delayed/late result for a plan_id that has since been overridden by a different dispatch is refused rather than freeing someone else's lock. Never release speculatively or because polling has taken a while — an unresolved status keeps the lock held until it either resolves or the user explicitly overrides.
3. This MCP server's plan_call has no schema-input parameter for structured extraction (verified against its inputSchema). Instead, the call goal (references/call-task-template.md) instructs the bot to recap its own answers in a fixed, labeled format at the end of the call. Parse that recap from the transcript using scripts/parse-recap.js, which only reads lines attributable to the bot's own final speaking turn (never anything the caller said) and validates the result against references/intake-result.schema.json before returning it.
4. If parsing/validation fails — including when the recap never happened because the crisis-safety override in references/call-task-template.md triggered, or because the recap couldn't be cleanly attributed to the bot — do not guess field values. Report the crisis disclosure (if that's what happened) as its own distinct, clearly flagged outcome. Otherwise, surface a redacted excerpt of the transcript via scripts/redact-transcript.js — never the raw, unredacted transcript, which may contain the caller's spoken phone number or email address.
5. If followup_contact is present, it must only be trusted when followup_contact_confirmed is true, meaning the bot spelled the contact back letter-by-letter and the caller explicitly confirmed it. If not confirmed, do not carry it into VPAT output; note "Contact unconfirmed, verify manually" instead.
6. Optionally run scripts/format-to-vpat.js to insert the validated result into a VPAT 2.4 template as a new row. Every auto-matched row (matched at the WCAG principle level, not the specific success criterion) gets an "AUTO-MATCHED AT PRINCIPLE LEVEL, HUMAN REVIEW REQUIRED BEFORE AUDIT USE" note in Remarks, so it can never be mistaken for a final placement.

Why a `plan_id` is never replayed, even with `override` (step 5): this is a permanent design choice, not a gap to eventually fix. run_call's own tool contract already forbids calling it twice for the same plan_id — this skill didn't invent that restriction, it's upstream. Every genuine reason to "retry" collapses into needing a brand-new plan_id anyway: if the recipient asks for a callback with a corrected detail, that's a different goal, which only plan_call can produce (there is no operation that patches an existing plan's parameters); if the process crashes between acquiring the lock and getting a response from run_call, you don't actually know whether the call was placed, and retrying the same plan_id risks a real duplicate dispatch at the API level, so the correct recovery is a fresh plan_id from a new plan_call, with the interrupted attempt's outcome flagged to the user as unknown rather than silently retried. override therefore only ever needs to resolve one kind of conflict — a different, newly-planned plan_id wanting to dispatch while the lock is still held by an unresolved other plan_id — never "let me reuse this one."

Safety Rules

#safety-rules