S Skillory

Guides / Prompting best practices

Field guide

Prompting best practices

Techniques that official Anthropic and OpenAI docs still recommend, plus when a repeated prompt should become a Skill.

Prompting advice ages quickly as models change. This guide sticks to techniques that official vendor docs still recommend as of November 2026, and flags a few things that used to work but are now discouraged.

In this guide
  1. What still works everywhere
  2. Claude-specific habits
  3. ChatGPT and Custom GPT instructions
  4. When a prompt should become a Skill
  5. Evaluate, then shorten

What still works everywhere

Whether you are writing a chat prompt, a Custom GPT instruction block, or a SKILL.md, the boring advice is still the highest leverage:

  • Be specific about the output. Name the sections, tone, length, and audience. “Write a weekly update” is weaker than “Write a weekly update for my engineering manager, under 12 bullets, with shipped / in progress / risks / asks.”
  • Explain why a rule exists when the why would change the model’s judgment. Anthropic’s prompting guide uses the example of forbidding ellipses because a text-to-speech engine cannot pronounce them — the motivation helps the model generalize.
  • Prefer positive instructions. “Write in complete paragraphs” beats a long list of “do not use bullets, do not use bold, do not…” OpenAI’s GPT-authoring help article makes the same point: tell the model what to do, not only what to avoid.
  • Show examples. Three to five input/output pairs, covering typical and slightly awkward cases, teach format better than another paragraph of prose. Make the examples diverse so the model does not copy an accidental pattern.
  • Put knowledge in knowledge, and behavior in instructions. Both vendors repeat this. Style, workflow, and refusals belong in instructions. Policies, schemas, and reference tables belong in files the model can open.
  • Test edge cases. A normal request, a vague request, an out-of-scope request, and a request that should trigger a tool or a file lookup will expose holes faster than another rewrite of the happy path.

Claude-specific habits

Anthropic’s current reference is Prompting best practices, plus per-model pages for the latest Opus, Sonnet, Haiku, and newer model lines. A few durable techniques:

  • Clear and direct. Treat Claude like a strong new employee who does not know your norms. If a colleague could not follow the prompt, neither can the model.
  • XML tags to separate parts of a complex prompt — instructions, example blocks, and documents each in their own tags, with consistent names. This is especially helpful when you mix a long policy with a user-supplied file.
  • Give a role in the system prompt when you want a stable tone or specialty: “You are a helpful coding assistant specializing in Python.”
  • Long context: put large documents near the top and the question near the end. Anthropic reports that queries at the end can improve quality substantially on multidocument tasks. Asking Claude to quote relevant passages before it answers also reduces wandering.
  • Be explicit when you want action. “Can you suggest changes?” may produce suggestions. “Change this function…” is more likely to produce an edit. If you want a default, say so: implement rather than only advise, or the reverse.
  • Match your prompt’s formatting to the output you want. A prompt full of bullets will often produce bullets. If you need prose, write the prompt in prose.

Model generations now differ in verbosity, tool eagerness, and thinking defaults. Anthropic’s current docs warn that instructions written to “poke” an older, shyer model — “CRITICAL: you MUST use this tool if in doubt” — can make newer models over-trigger. If you are migrating a prompt to a newer Claude, try softening those lines before you add more text. There are also model-specific notes (for example, some newer models no longer support prefilling the assistant’s last turn; structured outputs or a direct “respond with JSON” instruction replace that old trick).

For agentic coding, Anthropic recommends asking the model to read files before claiming anything about them, to avoid over-engineering, and to confirm before destructive or public actions. Those constraints belong in a Skill if you find yourself repeating them.

ChatGPT and Custom GPT instructions

OpenAI’s Creating and editing GPTs article still describes how GPT instructions should be written, and the same shape is useful for plugin skills and for custom instructions:

  • Use an explicit step structure for workflows: “When X happens → do Y.”
  • Separate sections with clear headings so priorities do not blur.
  • If the GPT must classify or follow a definition, include short acceptable and unacceptable examples.
  • Keep uploaded files for reference material, not hidden rules. If you want citations, say so and specify the citation format.
  • Prefer text-forward files. Complex layouts are harder to use reliably.
  • Tighten instructions and examples before you add more tools. Extra tools rarely fix a vague brief.

A durable instruction outline looks like this:

# Role and purpose
# Audience
# Workflow (numbered)
# Output format
# Tools and files (when to use each)
# Boundaries (what to refuse or escalate)
# Examples

If you maintain Custom GPTs, remember they are on a published retirement path (see Custom GPTs vs Claude Skills). Copy instructions out of the builder so you are not locked to a UI that may go away for your account.

When a prompt should become a Skill

If you have pasted the same paragraph more than twice, it is a candidate for a Skill or a saved instruction set. The conversion is mechanical:

  1. Lift the procedure into a folder with a name and a third-person description that includes trigger words.
  2. Keep only the rules the model does not already know.
  3. Move long reference material to references/ and point to it.
  4. Add two examples and one “do not invent X” line.
  5. Test a request that should trigger the Skill and one that should not.

That is also how you avoid prompt sprawl: the system prompt stays short, the Skill library grows, and each Skill stays focused. Anthropic’s authoring guide calls the context window a public good. Treat it that way.

Evaluate, then shorten

A useful evaluation set is small:

  • One typical task.
  • One messy or incomplete input.
  • One out-of-scope request (the Skill should decline or stay quiet).
  • One formatting-sensitive task (a table, a commit message, a JSON object).
  • One safety case, if relevant (destructive SQL, a request to cheat a live interview, a request to invent a citation).

Score whether the output followed the format, stayed within the facts, and used the right file or tool. When something fails, change the smallest section — often the description, one rule, or one example — and rerun the same set. Most Skills get worse when they only get longer.

Sources

More guides