Invoking a skill
Skills are invoked with a slash command, and anything you type alongside the skill is added to it rather than substituted for it. Type/ as the first character of the message and select the skill, or continue typing to filter. A / anywhere else in a message is ordinary text. The composer shows Try Skill press / as a reminder.
A skill can be invoked on its own or with additional context in the same message, as in /ar-aging-digest for Acme Corp only. Everything after the skill name is passed through as free-form arguments.
When a skill and the message that invokes it disagree, the message wins. Copilot receives the skill body as reference material explicitly labelled as user-authored, not as system instructions, so it does not outrank what you type or the platform’s own rules. A skill cannot grant itself authority it was not given.
Skills work from every Copilot surface: the Agents panel composer, the Cmd+K command bar, and the copilot embedded in a record. Slash commands are resolved centrally rather than by each surface, so behavior is identical across all three.
The entity and accounting-basis selectors apply to a skill invocation exactly as they do to a typed question, because they scope the conversation rather than the individual message. Set them before invoking a skill that returns balances.
Managing skills
Select Skills in the Agents panel to view skills. Every skill is visible to your whole organization; there is no private or personal skill, and anyone with Copilot access can invoke any of them. Creating, editing, deleting, and rolling back a skill are restricted to organization admins. That split is deliberate: a skill is shared wording that everyone’s output depends on, so it changes through one set of hands rather than being edited by whoever ran it last.
A skill cannot pin an entity, an accounting basis, a connector, or an output format. Those come from the conversation it runs in, which is why a skill returning balances depends on the selectors being set correctly before it is invoked.
An organization can hold 100 skills. Editing a skill creates a new version rather than overwriting the old one, and previous versions remain viewable.
The built-in skills
Every organization starts with six skills that DualEntry ships and maintains. They are ordinary skills in every respect except that they arrive already written.
You can edit a built-in skill the same way as one your team wrote, but you cannot remove it: the delete option is disabled on built-in skills, so
/ar-aging-digest stays in the menu whether or not you use it. Rewriting its instructions is the way to make it yours. /ar-aging-digest is the usual starting point for collections work, since its output is the list a dunning pass runs against.
Instruction structure
Skill instructions carry the constraints that a typed prompt leaves to the person asking, which is what makes the output consistent across invocations and across people. Instructions state the records to query, the fields to return, the format, and the actions that are out of bounds. A dunning skill specifying “save as a draft, never send” applies that constraint on every invocation, including invocations by someone who does not know the policy. Instructions that depend on a value changing each time, such as a customer name or a period, name the value and leave it to the invoking message. A skill that hard-codes such a value returns the same answer to a different question. Instructions are also the durable, reviewable part of a skill, which is why customer-facing and auditor-facing language belongs in one rather than in a prompt that each person retypes. One copy of the wording stays under review instead of several.Skills, connectors, and scheduled agents
A skill only provides instructions. What it can actually do depends on the connectors the person invoking it has connected, and when it runs depends on whether a person or a schedule invokes it. A skill can reference connector actions, and Copilot calls them when the invoking user has that connector connected and authenticated. A skill that depends on a connector fails for a user who has not connected it, or whose token has expired. Skills do not carry credentials: connector permissions come from the connector, not from the skill. See how to connect an MCP connector. A scheduled agent can invoke a skill by starting its instructions with/skill-name, which keeps a recurring task and its wording in one place rather than duplicated between the skill and the schedule. The skill supplies the wording and the constraints, and the agent definition supplies the cadence, the entity scope, and the accounting basis.
An unattended agent invoking a skill has nobody to correct its output, so any constraint the output depends on belongs in the skill instructions rather than in the message that invokes it.
Permissions and logging
Skills do not change the permission model or the audit trail. They run inside both. A skill runs under the permissions of the person invoking it, not the permissions of the person who wrote it. Two people invoking the same skill can get different results if their roles differ in scope. A skill shared across the organization therefore returns each person’s own view of the ledger rather than the author’s. Skill invocations are recorded in the audit trail like any other Copilot interaction. The record keeps the compact/name args form you typed rather than the expanded instructions, and it identifies the exact version of the skill that ran, so an output can be traced to the wording in force at the time.
A skill does not widen what Copilot may do. It cannot post to the ledger on its own, and a skill referencing a connector still requires that connector to be connected by the person invoking it. Sharing a skill widens who can run the instructions, not what the instructions are allowed to reach.