your AI agent makes phone calls for you
homeexamplesinstall mcpblogsign up / sign inrules

blog > grok-bot-reusable-skills

Grok Bot skills: save a phone calling workflow you can reuse

Turn a restaurant inquiry into a reusable Call4Me skill that collects a fresh brief, caps the call and checks the transcript before answering.

Nick Khami · · 7 min read
[ 💬 0 ]
A Grok phone call becomes a saved calling method for a new restaurant inquiry

Save your Grok Bot phone calling method as a skill so the next call starts with a good brief and ends with a checked answer. The skill should collect fresh inputs, verify Call4Me access, set a duration cap and preserve unanswered questions. It should not inherit an old restaurant or permission to call.

This guide uses a restaurant availability inquiry as the example. Download the instruction file and the prompt to save it. Attach the file to your Bot and ask it to create a skill from the instructions. The file is readable Markdown, not an automatic Grok installer.

We have verified a real Call4Me connection and phone call in Grok Bot, documented in our Grok setup guide. We have not yet verified this new skill's save and reuse flow in the app. The steps below follow the current documentation and include checks for your own run.

Skill, routine or template?

Grok's skills and routines documentation describes a skill as reusable task instructions and a routine as the rule for when a Bot should run a workflow. Your private skill library is shared across your own Bots, but each Bot still needs appropriate access.

A Grok Bot template is what you prepare when another person needs their own copy of a Bot. A private skill appearing in your second Bot does not prove it is included in a template for someone else's account.

For the restaurant example, start with a skill you invoke deliberately. A recurring routine is usually unnecessary for a dinner plan whose date, party size and authorization change each time.

get new posts by email · 1 reader subscribed

Start from the result you actually obtained

Our existing restaurant call reached a recorded menu. It confirmed a general walk in policy, but did not confirm space for four people or a recommended arrival time. The result was partial.

That is useful material for a skill because it exposes a rule a simple happy path might miss: a completed call can leave the task unresolved. The skill should distinguish recorded policy from a live availability answer and keep unanswered questions in its final output.

Before saving the calling method, inspect the returned call record, outcome and transcript, and the recording when the summary is ambiguous. Correct unsupported conclusions before you teach the Bot to repeat them. Keep the instruction to follow the same call id, so a partial result does not silently become a second call.

Separate the reusable method from private facts

Write the method as if the next request came from a person you have never met.

Keep in the method Ask again for each task
Use the restaurant's own contact page Restaurant and published phone number
Distinguish recorded policy from live answers Date, party size and preferred time
Collect missing information before calling Time zone, flexibility and relevant needs
Ask for permission before a call Permission and duration cap for this particular call
Return evidence and unresolved questions Any account or reservation details

Keep keys, signed recording links and personal contact details out of a shareable method. A skill needs to describe a connector requirement; it does not need to contain a credential.

A complete instruction file you can adapt

The downloadable file contains this method. Its approval boundary is intentionally precise: preparation may proceed, but calling, booking and leaving a message require the permission named below.

Name: Restaurant availability inquiry

When to use
Use when someone wants to check restaurant availability or walk in
conditions for a particular party and date. This is an inquiry skill,
not permission to reserve a table.

Inputs
Restaurant, date, party size, preferred time, time zone, flexibility,
relevant seating needs, approved call duration and permission for this call.
Never infer a dietary or accessibility need.

Access
Public restaurant website and booking page. A working Call4Me connector
is required for the phone inquiry. Check access with call4me_get_balance
and confirm that the account belongs to the intended user.

Method
1. Gather missing inputs in one message.
2. Find the restaurant's own contact and booking pages. Record sources.
3. Check public availability. Keep general policy separate from slots.
4. Check call4me_get_requirements and collect any missing required facts.
5. Produce a call brief with the business, published number, questions,
   facts it may share and proposed duration. Wait for permission to call.
6. Place only the authorized call, setting call4me_place_call.max_minutes
   to the approved duration. Do not reserve, pay, request a callback
   or leave a message unless separately authorized.
7. Make only one call. Follow that returned id with call4me_get_call.
   If the call is still active, report that state rather than pretending
   to have a final answer.
8. Review the outcome and transcript. Retrieve recording metadata for
   the same id with call4me_get_recordings. If unavailable, say so.
   Inspect the recording when a summary's claim is ambiguous.
9. Report confirmed facts, source type, unresolved questions and next step.

Failure handling
Missing connector: give setup steps and stop before the call.
Missing facts: ask, do not fill them from an old task.
Menu or voicemail: report recorded policy and unanswered questions.
Tool error: report the actual error without exposing secrets. Do not
launch another call automatically; check the current call state first.
Business asks to book or pay: stop at the approval boundary.

Output
Restaurant and requested party/date/time.
Confirmed facts with source and date checked.
Whether a person answered or only a recording supplied information.
Unanswered questions.
Actual call id if one exists, and final or currently observed call state.
Transcript and recording references when available, without exposed keys.
Next action and any approval needed.

Changing the skill to perform bookings requires more than replacing “inquiry” with “booking.” Define the permitted times, what costs may be accepted, whether a deposit is allowed and what counts as reservation confirmation. Keep those authorizations specific to the current task.

Ask Grok to save the reviewed method

Attach the file, or paste the instructions, then use this prompt:

Create a skill called Restaurant availability inquiry from the attached method. Preserve its evidence checks, failure handling and approval boundaries. Do not copy the restaurant, dates, keys, recording links or personal details from our previous task. Show me the skill instructions before saving, then tell me how to invoke the saved skill. Do not create a routine or make a call.

Review the resulting instructions. Check for old task facts, vague permission such as “handle it,” and a completion rule that treats any ended call as a successful inquiry. If something is wrong, ask the Bot to edit that rule before saving.

The documentation says the desktop composer uses / to reference saved skills. If yours is missing, check Marketplace, Your plugins, Manage plugins and skills, then Private skills. These are documented controls; the saved skill still needs a test before you rely on it. Official skills instructions.

Check reuse with preparation only

Open another Bot under your account and invoke the saved skill. Give it a different restaurant and ask for preparation only:

Use Restaurant availability inquiry for [new restaurant], [date], [party size] and [time with time zone]. Check Call4Me access and required inputs, then show the call brief with a proposed [minutes] talk time cap. Do not place any call, book, leave a message or contact anyone.

Check that the output refers to the new request. If the Bot cannot access Call4Me, that is a connector setup issue; the method should explain the missing prerequisite rather than claim it made a call.

This second Bot check establishes reuse in your account when you run it successfully. It does not establish distribution to someone else's account. Use the template recipient checklist for that.

Try the cases that break a weak skill

Download the validation matrix. The expected behavior below is a requirement for your test, not an observed result from our app.

Input or situation Expected behavior
A complete request with preparation only Research and proposed questions, no call
No date or time zone Ask for those facts before contact
A different restaurant in a second Bot Use the new inputs and check that Bot's access
Missing Call4Me connector Explain the dependency and stop before a call
A recording says walk ins are welcome Report policy without asserting party availability
A supplied transcript ends without the requested answer Keep the question unresolved
A reservation would require a deposit Ask for the specific approval before commitment
A tool returns an error after a call was created Check the existing call before proposing another

For the transcript and error cases, provide a clearly labelled simulated example and keep external tools disabled. You can test the reasoning without calling a business.

If you later create a routine, inspect its owner, schedule, inputs and approval rules separately. Grok's documentation says a routine's Test run can perform real work, so a test is not automatically a simulation. Routine test instructions.

Keep the skill useful as tools change

Update the method when a connector, website or output format changes. Repeat the relevant validation cases after each edit. Preserve the evidence and approval rules even when the successful path becomes simpler.

You can use the same approach for service quote, cancellation inquiry and refund follow up calls: review a concrete call, correct the result, extract the method and check it with new inputs before automating it.

grok · skills · ai agents · ai phone assistant

Nick Khami @skeptrunebuilds call4me, the phone for your AI agent. software engineer; previously founded Trieve. email me@call4.me.

get new posts by email · 1 reader subscribed
no tracking, no spam; one email per post, unsubscribe in one click. or use the atom feed. posts marked paid need a supporter subscription (monthly, cancel any time).

0 comments

read next

Grok Bot and Meta Muse phone workflows compared by calling setup, call evidence and unanswered questions
Grok Bot vs Meta Muse for phone calls: setup, evidence and three inquiry briefs
Compare how each agent connects a calling service, prepares an approved inquiry and checks the answer. Includes three matching call briefs and a worksheet for recording actual results.
OCT 5 · Nick Khami
A shared Grok phone calling template needs the recipient's Call4Me access and call brief
Why a Grok Bot phone calling template fails after sharing
A recipient needs their own working Call4Me connection, call brief and permission. Find the missing prerequisite before asking the Bot to dial again.
OCT 5 · Nick Khami
Five Grok Bot phone calling workflows, from a clear call brief to a checked answer
5 Grok Bot templates for phone calls that get errands moving
Give Grok a phone calling workflow for appointments, restaurants, service quotes, cancellation questions and refunds, from the call brief to the actual answer.
OCT 5 · Nick Khami

newer: 5 Grok Bot templates for phone calls that get errands moving
older: Why a Grok Bot phone calling template fails after sharing
all posts · archive · atom feed