A skill is a reusable instruction file your artificial intelligence (AI) client loads when a task matches it. Where a prompt is something you type once, a skill is your process written down — so the same work happens the same way whether you run it, someone on the regional operations team runs it, or it runs on a schedule at six in the morning.
Every prompt shown during the Fullcast MCP office hours ran without a skill behind it. That was deliberate. Open prompts show you what the model does on its own, which is how you find out what needs pinning down.
What a skill is for: Fullcast gives you more than one legitimate way to handle most situations. There are built-in workflows, automated policies, and planning tools, and several of them could reasonably apply to the same event. A skill is where you record which one is yours.
That framing matters because it tells you what not to write. The mechanics — the order of operations, the validation, what a workflow does once you pick it — are already built and documented. Writing those down again produces a second copy that drifts out of date while still being trusted. What is not written down anywhere is your organization's choice among the available paths.
Note
Not every client loads instructions on demand. Claude calls these Skills and Cursor calls them Rules; both load conditionally. ChatGPT has no direct equivalent — the closest is a project's instructions or a custom GPT, which are always on. Where conditional loading does not exist, the same content becomes either persistent instructions or a document you paste in at the start of a session, and the "keep it out of your instructions to save context" argument no longer applies.
Three places behavior can live
Built into Fullcast. Workflows, policies, validation, and the MCP's own domain knowledge. You do not write these; you check them.
Persistent instructions. Always on. Short, general, applies to everything — default plan, time zone, output format, review before write.
Skills. Load only when the work matches. Can be long, can contain decision trees, and encode judgment that would be absurd to keep in context permanently.
The test: if it applies to every conversation, it is an instruction. If it applies to one kind of work, it is a skill. If it is true of Fullcast rather than true of you, it is neither.
Tip
Resist building skills before executing a workflow using a prompt and discussion over multiple turns. A skill written before you have watched the model work is a guess about a problem you have not had yet.
When to turn a prompt into a skill
Start open-ended. Ask for the outcome in a sentence or two and see what comes back. Wide prompts expose gaps in your data and your assumptions faster than precise ones.
Notice what you keep correcting. The third time you tell it which plan to use, or that child accounts should follow parents, or that you want a table instead of prose, you have found something worth writing down.
Get specific in the prompt first. If a longer prompt fixes it, you may not need a skill.
Check whether Fullcast already has a path for it — and whether it has more than one.
Build the skill when the work is repeatable. Daily, weekly, or done by more than one person are all reasons. So is anything where the cost of doing it inconsistently is high.
Share it. A skill in one person's account is a personal shortcut. Shared across the team, it is your process.
Skills worth building
Five, each scoped to a decision the platform leaves open.
1. People-change decision table
What it does: Records which Fullcast path your team takes for each kind of people change, so the same event is handled the same way every time.
Why it matters: Nearly every people change has a documented workflow behind it. What varies is which workflow fits your policy — and for some situations, several fit. The table below is what exists and what it leaves you to decide.
Situation | What Fullcast provides | What it leaves you to decide |
|---|---|---|
Departure with a replacement ready | End Coverage with Permanent Coverage. The new person's start date defaults to the day after the outgoing person's end date, so coverage has no gap | Who takes each seat, and what happens to each target |
Departure with no replacement yet | End Coverage with Temporary Coverage plus a to-be-replaced (TBR) placeholder, so the open headcount stays visible while you recruit | Whether a manager holds the territory or it sits unassigned; when to convert the placeholder and end-date it |
Extended leave with a return date | Several paths, and no default. A temporary Smart Plan can redistribute the absent person's accounts across teammates for the leave window (Smart Plan for territory management). A single temporary assignment can hand the book to one person. A future-dated assignment can restore them on their return date | All of it. This is the clearest case in this table for writing your rule down — see the note below |
Role change in place | Change Employee Role ends the old role and starts the new one, resolving ramp | Whether the vacated role gets backfilled. Note that through the MCP a team move is a separate call, even though the UI wizard includes that step |
New hire into an open seat | End-date the placeholder, then create the assignment; ramp resolves from the role's profiles | Your start-date convention, and the hygiene step of end-dating the placeholder to match the start date |
Move between teams | Changes the person's place in the org chart. Territory coverage assignments are untouched — they keep covering the same territories until you change those separately | Whether targets move with the person, and whether to split a schedule mid-period |
Assignment created in error | Nothing, through the MCP. Deleting an assignment happens in the UI, and only when nothing actually happened — a future assignment for a rescinded offer, for example | Nothing. This one is a rule, not a choice: never swap a name on an existing assignment, because that overwrites history and interferes with Salesforce account team cleanup |
What else to encode:
Which workflow handles targets. Fullcast routes this by situation: if the person has a territory coverage assignment, use End Coverage; if they have no coverage and are leaving permanently, use Offboard Employee in the Teams module; if they are switching teams, move them there, where you can move, delete, or reassign targets. See Get started with targets.
The inventory-first rule. List every assignment and every target the person holds, present it as a table, and let a human decide seat by seat. Never let a splitting rule be inferred.
Targets default to untouched. Every one of these operations leaves targets alone unless you say otherwise, and a bulk team move cannot take per-target instructions at all.
Nothing reverts on a return date. Temporary coverage expires by date, but the seat does not hand itself back.
Whether a policy should do this instead. A Terminate Employee policy can detect a termination event and execute a predefined assignment plan automatically. See Smart Plan advanced strategies and automation.
Triggers on: someone is leaving, going on leave, transferring, being promoted, starting; backfill; reorg.
2. Change review convention
What it does: Records what has to be shown before a change is made, and what always waits for a person.
Why it matters: Commits are irreversible — there is no uncommit, and a committed ledger row is immutable. The platform gates the mechanics: irreversible actions require explicit confirmation, previews return scope and record counts, and moves default to proposed. It does not know your review process.
Note
This skill makes your convention consistent and visible. It does not enforce it — a skill is an instruction, not a control. What is enforced is RBAC: the MCP acts as you, and a change your Fullcast role cannot make fails at call time. Plan state is visible to the MCP but is not a guardrail; it will act in any plan you point it at. If a change must be impossible for someone, that belongs in their permissions.
What to encode:
Which plans are off limits, by name or by state (exporting vs draft).
What always waits for a confirmation regardless of who asked, for example: anything touching commissions, anything above a record threshold, anything in a plan that is exporting.
What you want shown before you confirm: scope, record count, and the affected records.
How a completed change gets reported, so there is a written trail outside the audit log.
Triggers on: commit, propose, approve, apply changes, bulk update, run comp.
3. Account move policy
What it does: Records what you do when a node's configured family treatment and your intent disagree.
Why it matters: The platform already reports each node's configured family treatment and flags when an account has been separated from its corporate parent unexpectedly. It cannot tell you what the treatment should be. The common real problem is a family split because keep-parent was never configured on the destination — the configuration is doing what it says, and what it says is wrong.
What to encode:
What to do when a node's family treatment is not what you intend: override it for this move, or fix the node.
When a split family is acceptable and when it is not.
Who may commit an account move, and any volume threshold that changes the answer.
Triggers on: move account, place account, put [account] in [territory], bulk account moves.
4. Analysis standards
What it does: Defines which metrics your organization judges territory balance, account priority, and opportunity on, so open-ended analysis returns a comparable shape every time.
Why it matters: Left to itself the model picks reasonable metrics. Reasonable is not the same as yours, and an analysis you cannot compare to last quarter is a one-time artifact.
What to encode:
Your two or three primary balance metrics, named exactly as they appear in Fullcast.
What counts as an outlier in your organization, numerically.
Segment and tier definitions, so comparisons mean the same thing across analyses.
What to exclude by default: test accounts, closed subsidiaries, specific nodes.
Triggers on: analyze, report on, balance, composition, where should we focus, whitespace.
5. Commission dispute response
What it does: Standardizes what a rep receives when they ask why they were paid what they were paid.
Why it matters: The investigation is handled — one call returns the full chronological story for a person on a deal, every component and adjustment in order, with committed and pending figures reported separately. What is not handled is the human half.
What to encode:
Your rep-facing template, and plain-language substitutes for system status values. Earned, committed, and paid are three different states; decide how you say that to someone who does not work in the system.
Which figures never go to a rep unqualified, and who reviews before anything is sent.
The difference between a derived and a calculated explanation. A derived explanation reconstructs the math from stored values and ties out, but it is not an engine trace, so it should not be presented as a full audit trail.
Who owns disputes, and what gets escalated.
Triggers on: why was I paid, commission dispute, explain this ledger entry, attainment tier.
6. Daily operations monitor
What it does: One scheduled run reporting on job health, proposed changes awaiting review, coverage gaps, and expiring temporary coverage.
Why it matters: Every one of these is something you find out about late. In the demo, a single question about export jobs surfaced failures nobody had gone looking for. Nothing schedules itself, so this one is entirely yours to define.
What to encode:
Exactly what to check, and the time window for each.
What silence looks like — a short "nothing to report" beats a page of green checkmarks.
Escalation thresholds: what warrants a message versus what waits for the weekly view.
Triggers on: scheduled run; also on demand as a status check.
Note
Two things people reach for as skills belong in your persistent instructions instead: your default output format, and your internal vocabulary. Both are short and apply to everything. Promote them to skills only if they grow past a paragraph.
A worked example: the account move policy skill
A skill is a plain text file with a short block of metadata at the top and instructions below it. Note how little of this is mechanics — the platform reports family treatment and pinned accounts on its own. What is left is the policy.
---
name: account-move-policy
description: Use when an account needs to move between territories in
Fullcast — single moves, bulk moves from a spreadsheet, family
consolidation, or correcting a placement. Triggers on "move account",
"place account", "put [account] in [territory]".
---
# Account move policy
Fullcast already proposes rather than commits, reports pinned accounts,
and tells you each node's configured family treatment. Do not restate
those checks — read what they tell you and apply the rules below.
## When family treatment is not what we intend
Check the destination node's configured treatment before moving. If it
would separate an account from its corporate parent and that is not what
we want:
- [REGION]: override for this move so children follow the parent.
- [REGION]: leave it — children are independent here by design.
- Anywhere else: stop and ask me. Do not pick one.
If a move would split a corporate family across territories, name the
territories involved and ask before continuing.
## Approval
- Propose only. Commit is [ROLE]'s decision, never yours.
- Never move accounts in a plan whose state is [STATE].
- Over [N] accounts in one operation goes to [PERSON] first.
## What I need to see before I confirm
- Current and destination territory, both with the full breadcrumb.
- Every child account affected, and the treatment applied to each.
- Whether the destination has coverage today, and who holds it.
## Never
- Never infer a family rule that is not written above.
- Never report a move as done without confirming it landed — a submitted
write is not a finished write.How to write a skill without starting from a blank page
Have the model interview you, then write the skill from your answers.
Interview me about how our team handles account moves. Ask one question at a time about family treatment, who approves what, which plans are off limits, and what you should never assume. Skip anything Fullcast already handles — tell me what those are instead of asking me. When you have enough, write it up as a skill.This works because the hard part is not writing the file. The hard part is that most of this policy has never been written down anywhere, and it surfaces more reliably in answers to specific questions than in a blank document.
Two more sources worth mining:
Your own corrections. Scroll back through a working session and collect everything you had to say twice. That list is the first draft of a skill.
Disagreements between regional teams. Where two operations teams do the same thing differently, one of them is about to be surprised. Writing the skill is how you find out which.
Sharing skills across your team
A skill is a file. Put it where your team already keeps shared configuration and treat changes to it the way you treat changes to a runbook.
Name the owner in the file. A skill nobody owns drifts out of date and keeps being trusted.
Date it and note what changed. When behavior shifts unexpectedly, the skill is the first place to look.
Do not encode anything sensitive. Skills describe process, not credentials.
Review after any platform release or plan restructure. A skill referencing a territory that no longer exists fails confusingly, and so does one describing a path the platform has since changed.
Tip
Start with two: the people-change decision table and the change review convention. Those cover the decisions Fullcast deliberately leaves to you, and they are the two that most benefit from being identical across regional teams.