A system prompt and a Skill both shape how Claude behaves, and the overlap between them causes real confusion about where a specific house rule actually belongs. Get the split wrong and rules either apply too broadly, interfering with tasks they were never meant to affect, or too narrowly, missing the contexts where they were actually needed.
What each one is actually for
This is a genuinely small amount of discipline for a meaningfully more reliable, more consistent Claude setup across every task a business actually uses it for.
The same test applies whether you're a solo operator with one system prompt or a larger business managing several Skills across different departments: universal rules stay centralised, specific rules stay scoped, and the discipline of asking which category a new instruction belongs to before adding it anywhere is what actually keeps the whole setup manageable over time.
It's a small habit that costs almost nothing to maintain and saves a genuinely expensive cleanup project down the track.
A system prompt sets standing, account-wide or app-wide behaviour: tone, general constraints, things true regardless of what specific task is being worked on. A Skill packages task-specific knowledge and instructions that only activate when relevant, bundled reference material, step-by-step procedures, and domain expertise for a particular kind of work. The practical difference: system prompt rules apply to everything, all the time. Skill rules apply only when that Skill is relevant to the task at hand.
System prompt: always-on, applies to every interaction regardless of topic
Skill: activates only when relevant to the specific task
Put broad tone and constraints in the system prompt
Put task-specific procedures and reference material in a Skill
The common mistake: overloading the system prompt
Teams new to this often cram everything into the system prompt because it feels like the obvious single place to put house rules. The result is a system prompt bloated with instructions relevant to only one narrow task, which quietly degrades performance on every other task since the model has to weigh irrelevant instructions on every single interaction, not just the ones where they matter.
A worked example
A Sydney accounting practice initially put both a general tone instruction, formal, precise, no hedging language, and detailed BAS-preparation procedures into one long system prompt. Every unrelated conversation, drafting a client email, summarising a meeting, carried the full weight of BAS-specific instructions that had nothing to do with the task. Splitting it, tone and general constraints stayed in the system prompt, BAS procedures moved into a dedicated Skill that only activates for BAS-related work, made both faster and more consistently on-target, and it took under an hour to restructure once the distinction was clear.
A simple test for where a rule belongs
Ask: should this apply to literally everything this account or app does, or only to one specific kind of task. If it's genuinely universal, tone, formatting preferences, hard constraints, it belongs in the system prompt. If it's specific to a domain, a client type, or a recurring task, it belongs in a Skill. Most house rules, once actually examined, turn out to be Skill material, not system prompt material, which is the opposite of where most teams default to putting them first.
The cost of getting this wrong at scale
For a small team, an overloaded system prompt is an annoyance. For a business running Claude across dozens of use cases and staff, it becomes a measurable drag: slower responses, more irrelevant caveats showing up in unrelated tasks, and a system prompt that's grown so long nobody wants to touch it for fear of breaking something else buried in it. A Sydney firm that let this drift for a year estimated the restructuring project, splitting years of accumulated instructions into a proper system prompt plus a library of task-specific Skills, took a consultant about $2,800 to complete properly, work that would have cost a fraction of that if the split had been maintained from the start.
Getting this split right isn't a one-off setup task. Revisit it as new rules get added, since the same overloading problem creeps back in gradually if every new instruction gets bolted onto the system prompt by default rather than asked which category it actually belongs in.
A quarterly ten-minute review of what's actually in the system prompt, checking whether anything there is really Skill material that's drifted in over time, is cheap insurance against that kind of accumulated mess.
Get the split right early and it stays easy to manage for years.
That's the whole discipline, applied consistently.
Apply it the next time a new house rule comes up for discussion.
