How to Build a Custom GPT for a Repeatable Task
Building a custom GPT that stays useful means defining the task clearly before touching the builder. Here are the steps from task definition through testing.
Updated 4 min read
Building a custom GPT for a repeatable task takes about thirty minutes if you know what the assistant needs to do and have your reference material ready. Most of that time is writing the instructions, not navigating the builder. The quality of the result depends almost entirely on how clearly you defined the task before you opened the editor.
Tools like fenbs let you store the approved procedure and the lessons from each test run outside ChatGPT, so the work survives if you switch models or rebuild the assistant later.
Define the task before you open the builder
A custom GPT is good at one specific job done consistently. Before you write a single instruction, write down the task in one sentence: "This assistant takes a draft blog post and rewrites it in our house style." If you cannot write it in one sentence, the scope is too wide.
Then write down what a good output looks like, and two or three examples of bad outputs the assistant should avoid. Those examples will become the core of your instruction set and your test cases.
Write clear instructions
Open the ChatGPT builder (chatgpt.com/gpts/editor on a supported plan) and go to the Configure tab. Give the GPT a name that describes the task, then write the instructions.
Structure the instructions in this order: (1) the main job in one sentence, (2) the rules the assistant must follow, (3) one worked example showing a realistic input and the correct output, (4) what the assistant should do when it cannot complete the task. Keep the total length short. Instructions that run to many paragraphs are harder to follow consistently.
- State the main job first and be specific: "You are a contract summarizer. Given a contract, you produce a plain-English summary of no more than five bullet points covering parties, obligations, term, payment, and termination."
- Write rules as commands, not suggestions. "Do not add information that is not in the contract" is clearer than "try to stay accurate."
- Include a worked example for any rule you expect to be tested. Show a short input and the exact output you want.
- Add a fallback: "If the input is not a contract, say so and stop."
Add suitable reference material
Upload knowledge files only when the assistant needs to search a specific body of text, not for general knowledge it already has. A style guide, a product catalog, a glossary, or a set of approved templates are all good fits. General web content the model already knows is not.
Plain text and PDF files work best. Before uploading, read each file for statements that conflict with your instructions. A knowledge file that contradicts an instruction creates unpredictable behavior. Check OpenAI's documentation (opens in a new tab) for current file format and size limits, as these can change.
Keep the work state outside the GPT
A custom GPT has no memory of what was decided in earlier sessions. In fenbs, record where each project stands, what decisions have been made, and what the next step is. An assistant connected to fenbs reads that context at the start of a new session without you retyping it.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Test with realistic inputs
Before publishing, use the Preview panel to run a quick check. Then save the GPT and open a fresh conversation to test properly. The preview can behave slightly differently from a real chat.
Run the five to ten test cases you wrote when you defined the task. For each one, note what the assistant did and whether it matched your instructions. When something breaks, change one thing at a time. Multiple simultaneous changes make it impossible to know what fixed the problem.
If the assistant fails a test more than once after you have revised the instructions, add a worked example that shows the correct answer for that specific case. Examples outperform abstract rules for edge cases.
Keep the work state outside the GPT
A custom GPT does not remember your project. Every conversation starts fresh. If your work spans multiple sessions, the project context, decisions made, and where you left off have to come from outside ChatGPT. This is the practical limit of what a custom GPT can do for ongoing project work.
For a comparison of custom GPTs with project memory tools, see Claude Projects vs. custom GPTs or how to build agent memory.
Keeping work state in a shared project record solves the problem for any assistant, not just custom GPTs. If your workflow moves between ChatGPT, Claude, and other tools, a tool like fenbs gives each one the same starting point. See /how-it-works for how that works in practice.
How to do this with fenbs
- Create a free account and add a project for the task this GPT supports.
- Add a Skill to fenbs with the full instruction text and a note on why each rule exists.
- Add a Decisions and rules entry for any choice that should not change between sessions.
- After each round of testing, add a Lessons learned entry noting what broke and what fixed it.
- When you rebuild or switch to a different assistant, pull the approved instructions and lessons from fenbs rather than starting over.
For a broader view of your options, see ChatGPT Projects vs. custom GPTs. If you are building something that takes actions rather than just generates text, how to build an AI agent covers the additional steps.