Using Custom GPTs and Claude Projects: Building Specialised Assistants

Most people use ChatGPT and Claude as fresh chat windows. Power users do something different — they build small, persistent assistants tuned for one job. Custom GPTs (OpenAI) and Projects (Anthropic) are the two main ways to do this, and the design patterns are remarkably similar across both.

Note: OpenAI and Anthropic update these features regularly. The patterns here are stable; specific menu options may move.

1. Introduction

Once you find yourself pasting the same long instructions into ChatGPT or Claude every Monday, you have outgrown raw chat. Custom GPTs and Claude Projects let you bake those instructions into a named assistant. You define a system prompt, attach reference files, set behaviour rules, and from then on every conversation starts with that context already in place.

This tutorial covers the design choices behind assistants that actually get reused — system prompts that hold up, knowledge files that genuinely help, conversation starters that nudge users toward good prompts, and the maintenance habits that keep an assistant useful past week three.

2. What Custom GPTs and Claude Projects Have in Common

Both products share the same underlying ingredients. Learning to design well in one means you can design well in the other.

• A system prompt. The hidden instructions that run before any user message. This is the single highest-leverage thing you write.
• Knowledge files. Documents the assistant can reference — style guides, product docs, examples, datasets.
• Tools / capabilities. Things the assistant can use beyond text: web search, file analysis, image generation, code execution (varies by platform and plan).
• Conversation starters / suggested prompts. Buttons that show up on the welcome screen to guide users toward the right kinds of requests.
• Sharing / access controls. Private, team-only, or public.

OpenAI calls the assistant a Custom GPT; Anthropic calls a workspace with these ingredients a Project. The design discipline is the same.

3. Writing the System Prompt

The system prompt is where 80% of assistant quality lives. A good one usually has the same five-section shape regardless of platform.

ROLE
You are the editorial assistant for an indie travel blog
that covers South and Southeast Asia.

AUDIENCE
Writers on the team. Most are non-native English speakers.
They want help, not lectures.

PRINCIPLES
- Friendly, encouraging, never condescending.
- UK English spelling.
- Prefer concrete examples over abstract advice.
- Cite the relevant style guide entry when fixing tone.

WHAT YOU DO WELL
- Critique drafts (3 strengths, 3 weaknesses, 1 priority fix).
- Suggest 5 alternative headlines for any article.
- Convert dense paragraphs into scannable web prose.
- Generate SEO-friendly meta descriptions under 155 chars.

REFUSE / REDIRECT
- Do not write entire articles from scratch — ask for an outline first.
- Do not invent statistics. If asked, request a source.
- Do not give legal or medical advice.

Notice the discipline. Each section answers a different question: who, for whom, how, what, and what not. Vague system prompts produce assistants that drift; this structure keeps them on the rails.

4. Knowledge Files: Less Is More

It is tempting to upload everything. Don't. A focused knowledge base produces a focused assistant; an overloaded one produces vague, lukewarm answers.

• Upload your style guide, not your archive. The assistant needs to know how you write, not every article you've ever written.
• Curate 3–10 gold-standard examples. Label them clearly in their filenames. The assistant will use them as templates.
• Use plain Markdown or text where possible. Models read those most reliably. PDFs work, but tables in PDFs sometimes parse oddly.
• Update on a schedule. Knowledge files go stale. A quarterly review is usually enough; weekly for fast-changing topics.

5. Conversation Starters and Default Format

Conversation starters do two jobs. They tell users what the assistant is good at, and they prime better prompts. Generic starters ("How can I help?") are wasted real estate.

1. "Critique a draft I'm about to paste."
2. "Suggest 5 alternative headlines for this article."
3. "Convert this dense paragraph into scannable web prose."
4. "Write a meta description under 155 characters."

Each is a complete prompt skeleton. Users tap the starter, paste their content, and get a useful answer on the first try. That is the user experience that gets your assistant reopened tomorrow.

6. Designing for Reuse

• One assistant, one job. The temptation is to build "a great all-rounder". Resist it. Five focused assistants (Editor, Researcher, Email Drafter, Coding Reviewer, Meeting Notes Cleaner) outperform one bloated one.
• Make it shareable. If the assistant is for a team, design the system prompt with team voice and rules — not your personal quirks. Document the intended use case in one paragraph at the top of the system prompt.
• Version your system prompt. Keep a copy in a doc with a date. When the assistant starts to drift, you can compare against the last known-good version.
• Test with adversarial prompts. Once built, try to break it. Ask things outside its scope, contradict its rules, paste irrelevant material. Tighten the system prompt where it stumbles.
• Watch for "lukewarm answer" syndrome. If your assistant starts giving safe, generic responses, your system prompt is probably too long or self-contradictory. Edit aggressively.

7. Practice Exercises

8. Key Takeaways