FoneClaw Tools, Plugins, Skills, Workflows, and Shortcuts Explained
Choose the right FoneClaw capability for an Android task, from one tool call to a saved workflow or shortcut, with a read-only example.
- Use a Tool for one supported action, a Plugin for an additional capability, and a Skill for reusable task guidance.
- A Workflow saves ordered tool steps; saving those steps does not schedule or run them.
- A Shortcut starts a confirmed prompt or a fully specified direct-tool task; saving it does not perform the task.
- Enabled tools, Android permissions, and configured approvals still govern each action, including actions started from workflows or shortcuts.
Choose the Smallest Capability That Fits
FoneClaw Tools, Plugins, Skills, Workflows, and Shortcuts answer different needs. Start with the result you want on the phone, then choose the layer that supplies it. A saved instruction or entry point still relies on supported actions, complete inputs, and the permissions needed when the task runs.
| Layer | What it does | Choose it when |
|---|---|---|
| Tool | Performs one supported action, such as reading battery status. | The needed Android action already exists. |
| Plugin | Adds an installable capability beyond the tools currently available. | The task needs a missing extension capability. |
| Skill | Provides reusable instructions for handling a kind of request. | You want consistent guidance or a reporting preference. |
| Workflow | Saves an ordered sequence of known tool steps. | You repeat the same checks or actions in the same order. |
| Shortcut | Starts a user-created prompt or a specified direct-tool task. | You want quick access to a familiar request. |
For example, one battery check calls for the battery-status Tool. A repeated battery and memory check is a good candidate for a Workflow. A preference for how those results should be explained belongs in Skill guidance. If a needed file operation is absent, search for an appropriate Plugin rather than assuming a Skill can add it. AI File Manager Agent Android Plugin: Safe File Operations With FoneClaw shows why file tasks need their own capability and scope checks.
A prompt Shortcut sends its saved wording to the agent, which interprets it when started. A direct-tool Shortcut is more specific: every requested action must map to a known tool with complete parameters. Neither type gains extra Android access by being saved.
Understand What Adding One Changes
When a capability is missing, FoneClaw can search official Plugin metadata. Search returns information to inspect; it does not install anything. A separate installation request creates a proposal for user review. Check what capability the Plugin declares and what dependencies or permissions it needs before accepting that proposal. The Phone-Agent Plugins and Skills Workspace: Install Android Capabilities Safely covers the operational installation and activation steps.
A user Skill follows a different path. Previewing a supplied Skill document parses and validates it without saving it. Saving creates a disabled draft; enabling a valid draft is another action. A Skill can guide the agent's choice and use of existing capabilities, but its instructions do not grant Android permissions or authorize a tool to run. The user can also review and roll back Skill changes separately from a phone task.
That distinction matters when a task crosses a sensitive surface. A Skill might describe how to prepare a file for review, while the actual file action still depends on an available Tool or Plugin, its enabled state, Android access, and the configured approval setting. AI Agent Skill Security Needs Phone Permission Checks examines that trust boundary in more depth.
Read a Small Workflow Example
Suppose you regularly check whether the phone is low on battery or memory before starting a long task. FoneClaw has separate read-only actions for battery and power-saving status and for current memory status. This illustrative stepsJson field value puts those checks in order:
stepsJson =
[
{
"toolName":
"device_battery_status",
"arguments": {}
},
{
"toolName":
"device_memory_status",
"arguments": {}
}
]Each array item names a supported Tool; {} leaves its parameters unspecified in this illustrative field value. Check each Tool's current input requirements before saving or running the Workflow. This shows the step format, not a complete workflow-save request or a report of results. Saving the Workflow creates a reusable sequence. Check that it appears among saved workflows, then inspect the actual battery and memory results when you run it. A saved sequence alone has no schedule. Scheduled Automations have their own trigger and missed-run handling.
A Shortcut can provide a separate entry point. For a prompt Shortcut, confirm its title, description, and the wording or behavior it should request before saving it. Starting it later asks the agent to interpret that prompt; it does not guarantee this exact two-step sequence. A direct-tool Shortcut could target known status actions only after each action and every required parameter are fully mapped. Saving either Shortcut does not execute it. Choose the Workflow when the order of checks is the important part; choose a Shortcut when a quick start is the important part.
Check Settings and Recover a Failed Step
Before using a saved path, check that its Tools are enabled, any Plugin it depends on is available, and Android has granted only the access the action needs. FoneClaw provides risk and default approval labels for Tools, plus per-tool enablement and approval overrides. The overall Tool Approval Mode and those settings determine what happens at execution; a Workflow or Shortcut does not bypass them. Our FoneClaw Features page describes the supported task surface.
If a step cannot find a Tool, check whether the capability is built in, supplied by an enabled Plugin, or merely mentioned by a Skill. If Android denies access, review the permission needed for that action rather than granting broad access for the whole routine. When a user declines an approval, leave that action unperformed. For an uncertain write, inspect the target app before retrying so a completed change is not duplicated.
Keep the result tied to each step: did battery status return, did memory status return, and did a later action change the expected app state? That check makes a short saved sequence useful without treating an instruction, installation proposal, or approval prompt as proof that the phone task completed.