System Prompts vs. Skills: What Goes Where?

A system prompt is a standing instruction that shapes how an AI assistant behaves across every session. A skill is a saved, named instruction for a specific kind of task, loaded when that task starts. Both are reusable, but they answer different questions. The system prompt answers "how should this AI always behave?" A skill answers "how should this AI handle this particular job?"

Confusing the two creates problems in both directions. System prompts stuffed with task procedures become unmanageable. Skills that try to define tone and persona end up repeated in every task and drift from each other over time. Keeping them separate and storing them in the right places solves both problems. fenbs keeps shared prompts, procedures, and decisions in one place that any connected AI app can read.

Quick comparison

What belongs in a system prompt

A system prompt should contain the things that are true of this AI regardless of the task. That means tone and voice ("always explain technical terms in plain language before using them"), hard constraints ("never give legal advice or quote legal authority"), persona ("you are a concise assistant for a US architecture firm"), and response format rules that apply across everything.

Standing decisions also belong here: "if the user asks about pricing, point them to the pricing page and do not quote a number." These are not task procedures; they are rules that apply in any context. The system prompt examples guide shows a range of working examples across different use cases.

Keep system prompts short enough to be maintained. A 2,000-word system prompt that nobody reviews is worse than a 200-word one that is correct. Add a rule when you have a reason; remove it when it no longer applies. The standing constraints are the ones you would be upset about the AI getting wrong in a random session.

What belongs in a skill

A skill should contain the things that are specific to one kind of task. That means the input specification ("a client email in plain text"), the steps the AI should follow ("first identify the main request, then list any constraints mentioned, then draft a reply"), the output format ("a reply under 200 words with a subject line suggestion"), and the edge cases ("if the email contains a complaint, acknowledge it before addressing the request").

Skills are the right place for procedures that repeat but vary in their input. A task that you always handle the same way is a good skill candidate. A task that you handle differently each time is better addressed with a direct prompt, possibly with the system prompt providing the context.

Claude skills work this way in practice: you define the instruction, name it and load it when the matching task starts. The claude skills examples guide shows what well-written skills look like. For the process of creating one from scratch, how to create a claude skill covers the steps.

When the line is unclear

Some instructions feel like they could go in either place. A tone rule ("be direct; avoid padding") feels like a system prompt rule, but if only one task type needs it, it belongs in that task's skill. A data format rule ("always output dates as YYYY-MM-DD") could be either, depending on whether it applies across all outputs or only in specific tasks.

The deciding question is scope. If the instruction is wrong to violate in any session, it belongs in the system prompt. If it only applies when a specific task starts, it belongs in a skill. When in doubt, put it in the skill. System prompts that grow too large become hard to maintain and easy to contradict.

Indirect prompt injection is one reason to keep system prompts minimal. If an attacker can insert text that your AI reads as an instruction, a large system prompt with many rules is harder to reason about. The indirect prompt injection guide explains this threat and how to limit it.

fenbs separates standing rules from task skills in a way that matches this distinction. Decisions and rules capture what every AI should always follow, appearing first in the AI context. Skills and prompts hold the task-specific instructions. Any connected AI app reads both, in the right order.

Storing both effectively

The most common storage mistake is mixing the two together in one file or one custom instructions field. When everything is in one place, a change to a task procedure requires reopening the whole system prompt, and it becomes easy to accidentally remove or overwrite a standing rule while editing a task description.

Store system prompts at the app or project level: custom instructions in ChatGPT, a project instruction in Claude, AGENTS.md or CLAUDE.md in a code project. Store skills in a named list you can add to and update independently. This separation lets you improve a skill without touching the standing behavior, and review the standing behavior without wading through every task procedure.

For practical guidance on the engineering side of prompts, the prompt engineering guide covers structure, clarity and testing. The chatgpt prompts for work guide shows the same ideas applied to specific work tasks.

Keeping both up to date

System prompts get stale when the work or the team changes and nobody updates them. A standing rule that was right six months ago may now contradict a more recent decision. Review the system prompt whenever a major decision changes how the AI should behave. Keep it short enough that the review takes minutes, not an hour.

Skills get stale when the task changes or when testing reveals a new edge case. The skill update process is the same as any iteration: find the failure, add the clarification, test again. Because skills are narrower than system prompts, updates are less likely to break anything else.

How to do this with fenbs

fenbs separates the two natively. Decisions and rules hold standing constraints; Skills and prompts hold task instructions. Connected AI apps read both, in the right order, at the start of each session.

1. Create a free account. Set up a project for the work you want to organize.
2. List the standing rules in Decisions and rules. Each rule says what it requires, who decided it, and why. These appear first in the AI context.
3. Save your task instructions as named Skills. Include the input specification, steps, output format and edge cases for each.
4. Connect your AI app over MCP at Integrations. The app reads the rules first, then the skills, before starting work.
5. When a rule changes, update it in Decisions and rules. When a skill improves after testing, update it in Skills. Each change applies to every connected app immediately.