,

Build a simple GPT for a repeating task

14 min read
Featured image: Build a simple GPT

Every Monday at 8:40 a.m., Maya opens ChatGPT and types the same paragraph. Role, audience, hard rules, section order. She pastes last week’s bullet notes. She gets a one-page status draft. By week six the ritual still works, but she has forgotten a rule twice, and two teammates now keep their own slightly different versions in sticky notes. Nobody is “doing AI wrong.” They are paying a tax for a recipe that only lives in memory.

This is Part 1 of the Custom GPTs tutorial. A Custom GPT (OpenAI also just says “GPT”) is a saved ChatGPT setup for a specific job: name, instructions, optional knowledge files, optional tools. You open it, and the recipe is already loaded. If accounts, plans, memory, and first-week safety still feel fuzzy, start with Learn ChatGPT from scratch. If Chat vs Work vs Codex and “when is a GPT even the right door” still blur in standups, keep the ChatGPT product map open (especially the plain chat vs Custom GPT part). Everyday writing and planning without agent blast radius live in the ChatGPT everyday tutorial. Multi-step office deliverables live in the ChatGPT Work tutorial. Repo and coding agent work live in the ChatGPT Codex tutorial. Here we build one simple GPT for one repeating task, without actions, without secrets, without theater.

UI labels, plan packaging, and create rights still move. Treat names and rollout notes below as a July 2026 field guide. Re-check chatgpt.com/gpts, GPTs in ChatGPT, Creating and editing GPTs, and openai.com/chatgpt the week you write team policy or promise a department “we’ll all ship GPTs.”

What you’ll learn

  • A plain definition of a Custom GPT: saved name, instructions, optional knowledge, optional actions
  • How create rights usually work (paid create; Free often still uses GPTs others made)
  • How to pick one repeating job that earns a first GPT
  • What to skip on day one: actions, secret files, “superbrain” scope
  • A step-by-step first build on web ChatGPT, with Preview as your lab
  • A worked example: Monday status brief GPT with a short test set
  • Mistakes that waste seats or create unreviewed team noise
  • What Part 2 goes deep on: instructions, knowledge files, and actions (light)

Custom GPT in one sentence

A Custom GPT is a version of ChatGPT configured for a specific purpose: standing instructions, optional uploaded knowledge, and optional capabilities or connections, all saved under a name people can open again.

You still chat. The model can still be wrong. You still own the output when it hits a customer, a board packet, or a production system. What changes is setup cost. You stop retyping the same role every Monday. Teammates stop inventing five private variants of the same prompt. The recipe becomes a shared, editable object instead of folklore.

Rule of thumb: A GPT is a saved recipe inside ChatGPT, not a full software product with your own database, SLA, and audit trail. Treat it like a well-named template with brains, not like a shipped app.

OpenAI’s help docs say the same idea in product language: GPTs combine instructions, knowledge, and selected capabilities for a more tailored ChatGPT experience. Building is a web editor flow. Mobile can use GPTs; building stays on web for most people. Creating or editing needs a paid subscription on consumer plans (and workspace permission on managed plans). Using GPTs is broader: signed-in users can talk to GPTs they can access, including ones others shared or published, when product rules allow.

What a GPT is made of (day-one view)

You do not need every knob on the first build. Learn the layers so you know what to touch and what to leave alone.

PieceWhat it isDay-one advice
Name and descriptionHow people find and understand the GPTBoring and clear beats clever and vague
Conversation startersExample prompts shown on openThree realistic jobs, not marketing slogans
InstructionsStanding role, rules, format, refusalsThis is the spine; write them first
KnowledgeUploaded reference filesOptional; only stable, non-secret docs
CapabilitiesBuilt-ins such as web search, canvas, code tools (as product offers them)Enable only what the job needs
Actions / appsExternal connections you define or user-connected toolsSkip for first GPT; higher risk and setup cost

Part 2 of this series goes deep on instructions, knowledge, and a light tour of actions. Part 1’s job is narrower: ship one useful recipe for one repeating task, prove it on real inputs, and stop.

First Custom GPT build path: pick one repeating job, write instructions, optional non-secret knowledge, skip actions, test in Preview, then save with a clear name

Plan reality: create vs use

As of OpenAI’s public help pages around mid-2026, GPTs are available to signed-in ChatGPT users for conversation when they have access. Creating or editing GPTs requires a paid subscription. On managed Business, Enterprise, or Edu workspaces, create rights can also depend on admin settings and roles. Free users often can still open GPTs others made or shared, within product and workspace rules. Exact plan names (Go, Plus, Pro, and team plans) and create rights change by market and year. Confirm on your account before you promise “everyone will build one.”

QuestionPractical answer (hedge and re-check)
Can Free users chat in ChatGPT?Yes, within Free limits.
Can Free users create Custom GPTs?Usually no on consumer plans; paid create is the common rule.
Can Free users use someone else’s GPT?Often yes when shared or available under product rules.
Where do you build?Web ChatGPT GPT editor; mobile is mainly for use.
Do Business/Enterprise change the story?Yes: workspace controls, sharing, and data settings matter.
If you cancel paid create rights?Help notes: you may still use GPTs you made, but not create or edit until paid again (confirm current help).

If you are the only person with a paid seat, you can still create a GPT that teammates open when sharing allows. That is an ownership and budget question, not a free-for-all. Name who pays, who maintains, and who retires dead GPTs. Part 3 of this series covers team sharing without chaos.

Pick one repeating job (not a career)

The first GPT fails when the job sentence starts with “help with everything.” Successful first GPTs sound like a calendar entry:

  • “Turn weekly bullet notes into a one-page leadership status.”
  • “Rewrite support replies in our calm tone with no invented refunds.”
  • “Score a draft brief against our checklist and list missing sections.”
  • “Explain this metric definition pack in plain English for new analysts.”
  • “Turn meeting notes into action items with owners and open questions.”
Good first GPT jobs are narrow and weekly: status brief, support tone rewrite, brief checklist, glossary explainer; bad first jobs are everything bots, secret data bots, and action-heavy bots

Use this filter before you open the builder:

  1. Repeats. You (or the team) do this weekly or daily, not twice a year.
  2. Stable shape. Output format barely changes month to month.
  3. You can name hard rules. At least three constraints you refuse to drop.
  4. You have three real past inputs. Fake examples hide weak instructions.
  5. No external system required. Day one should not need custom API actions.
  6. No secret payload required. Public or already-approved internal reference only.

If the work is still exploratory, stay in plain chat. The product map series said it clearly: invent the recipe in chat, freeze it, then save it. Building first and learning later is how teams collect five half-broken bots with cute names.

What to leave out of your first GPT

Ambition is the enemy of a first useful recipe.

Skip actions on day one

Actions let a GPT call external APIs you define. That is powerful and higher risk: auth, third-party data handling, workspace domain allowlists, and failure modes that look like “the bot is smart” when the API returned garbage. OpenAI documents a full actions path. You will meet it lightly in Part 2. For Part 1, do not wire anything external. Prove the text recipe first.

Skip secret and live operational files

Knowledge is for reference material, not a vault. Do not upload customer exports, raw HR notes, unreleased forecasts, API keys, or “the whole shared drive as a zip.” Prefer public docs or internal docs you are already allowed to share in the way this GPT will be shared. Version file names with dates. If the file changes every day, you will maintain the GPT more than you use it.

Skip “replace Work or Codex” fantasies

A Custom GPT does not replace Work for multi-step office agent jobs that gather across files and produce decks or sheets. It does not replace Codex for repo work with diffs and tests. Those are different doors in the product map. A GPT is mostly a better way to start certain conversations with a fixed recipe. If your real pain is agentic office packages or code changes, go to those tutorials first.

Prep offline before you open the builder

Write these answers in a note. If you cannot fill them, you are not ready to create.

  • Job sentence: “This GPT helps ___ produce ___ for ___.”
  • Audience: who reads the output, and what they will do with it
  • Hard rules: three to seven constraints (no invented numbers, ask when grain is missing, max length, and so on)
  • Output shape: section order, tone, length limit
  • Refuse list: what it must decline (legal advice, credentials, confidential systems outside scope)
  • Knowledge list: zero to a few stable files, each with a purpose and date
  • Owner: human name for updates and retirement
  • Test set: three real past inputs and a one-line quality bar for each

A thin starter for instructions (Part 2 expands the skeleton) looks like this. Adapt it. Do not paste secrets into it.

You are a careful weekly status editor for a product team.

Audience: busy directors who skim.

Hard rules:
- Never invent metrics, dates, or customer names.
- If a number is missing, write UNKNOWN and ask one clarifying question.
- Prefer short sentences. Aim for one page equivalent.
- List assumptions in a final section.

Output sections in this order:
1) Headline (one line)
2) What shipped
3) What slipped
4) Risks
5) Asks
6) Assumptions and unknowns

If the user pastes messy notes, reorganize into those sections.
If the notes look like confidential HR data or raw credentials, refuse and say why.

Example of good behavior: if notes say "revenue was up" with no number, do not invent 12%. Write UNKNOWN and ask for the figure and grain.

Build path: create the GPT on web

Official create flow (confirm labels if the UI moved):

  1. Sign in to ChatGPT on the web with an account that can create GPTs.
  2. Open Explore GPTs in the sidebar, or go to chatgpt.com/gpts.
  3. Select Create.
  4. Choose conversational builder or configuration view. For learning, configuration view makes fields visible. Conversational builder is fine if you still paste your offline checklist into the chat.
  5. Fill name, description, and a few conversation starters.
  6. Paste your instructions. Prefer concrete steps and one short example over a novel of “don’ts.”
  7. Optional: upload knowledge files that are allowed and stable. Leave empty if unsure.
  8. Leave actions alone. Enable only built-in capabilities the job needs.
  9. Use Preview with your three real inputs. Fix instructions before you share.
  10. Save or create when Preview passes your quality bar. Keep share private until you trust it.

Help notes worth remembering: drafts save while you edit; use Preview before broad sharing; put rules and tone in instructions, not only in files; knowledge is for reference material; version history exists when you need to roll back (re-check auth if you later add actions and restore an old version).

Name it like a tool, not a mascot

Good: “Monday status brief,” “Support tone rewrite,” “Metric glossary coach.” Bad: “Ultimate Strategy Superbrain 9000.” Cute names hide stale bots. Future-you will search for the job, not the joke.

Conversation starters that teach usage

Write starters that match real work:

  • “Turn these messy notes into this week’s status sections.”
  • “Score this draft against the section checklist and list gaps.”
  • “Rewrite this reply in our calm support tone without promising refunds.”

Avoid starters that promise magic (“own the quarter,” “be my CEO”). Starters train habits. Vague starters train vague use.

Worked example: Monday status brief GPT

Setup: Maya’s team ships product features. Every Monday she turns Slack bullets and ticket titles into a one-page leadership status. She has three past note dumps saved as plain text. Leadership cares about shipped, slipped, risks, and asks. They hate invented metrics.

Job sentence

“This GPT helps product managers produce a one-page Monday status for directors from messy weekly notes.”

Build choices

FieldChoice
NameMonday status brief
DescriptionTurns weekly product notes into a one-page status with assumptions listed. Never invents metrics.
InstructionsRole, audience, section order, refuse invented numbers, refuse credentials
KnowledgeOptional: short public-style metric glossary file dated in the name, or none
ActionsNone
SharePrivate until Preview passes three real tests

Test set (do not skip)

Run all three in Preview before anyone else opens the GPT.

InputWhat good looks likeFail signal
Notes with clear shipped items and one missing numberSections filled; UNKNOWN for the number; one clarifying questionInvented “about 12%” or silent omission of unknowns
Notes that are pure venting with no factsThin shipped section; explicit unknowns; asks for factsConfident paragraph of empty leadership prose
Notes that include a password-looking string or raw personal dataRefuse or strip and warnEchoes secrets into a polished status

Maya’s first Preview fails test one: the model softens “revenue was up” into “solid growth.” She adds an explicit example in instructions: if no number, write UNKNOWN. Second Preview passes. She keeps the GPT private for one more Monday of solo use, then shares with two teammates who already know the format. Ownership stays with Maya. That is a complete first GPT story. No actions. No store launch. No avatar redesign marathon.

How first-week use should feel

Open the GPT. Paste real notes. Read the draft like a skeptical editor. Fix facts. Send the human version. If the draft saves you ten minutes of structure work, the GPT earned its seat. If you rewrote every sentence for truth, either the instructions are weak or the job still needs plain chat while you invent the recipe.

Help docs also note that GPTs do not use your saved memory, custom instructions, or previous conversations the way personal Chat settings might. Each conversation with the GPT starts from the GPT’s configuration plus what you put in that thread. That is a feature for consistency. It also means you should not assume “it remembers last Monday” unless you paste context or design for it.

GPTs vs other ChatGPT doors (quick map)

If your job is…PreferWhy
One-off exploration, still inventing the formatPlain ChatFlexible; no premature freeze
Same role and format every weekCustom GPTSaved recipe, shareable when ready
Multi-step office deliverable (deck, sheet, long doc package)WorkAgentic office loop, not only a chat recipe
Repo edits, tests, diffsCodexSoftware project surface
App embedded in your product with auditAPI / platform engineeringGPTs are not website embeds

OpenAI’s own FAQ is blunt on embeds: GPTs live in ChatGPT; if you need an assistant inside your product, use the API. Do not sell leadership on “we shipped a product” when you published a GPT with a friendly icon.

Common mistakes on the first build

Building before the recipe is stable

If section order changes every week, stay in chat. Freeze after a few real runs, then create.

Instructions that try to boil the ocean

Long conflicting rule piles make the model thrash. Prefer short sections: role, hard rules, steps, format, refuse, one example. Help’s troubleshooting advice is practical: shorten, remove conflicts, use “when X, do Y,” add one or two examples, test small changes in Preview.

Knowledge as a junk drawer

A 200-page PDF of everything is not a knowledge strategy. Short, purposeful, dated files beat archives. Put behavior rules in instructions, not only in files.

Actions as day-one theater

External calls multiply failure modes. Prove text quality first. Actions can wait until the recipe is boringly reliable.

Sharing before Preview

Private until three real inputs pass. Team trust is harder to rebuild than instructions.

No owner

Orphan GPTs become folklore. Assign a human. Write a simple retirement rule (Part 3 goes deeper on team process).

Practice this week

  1. Pick one job that already repeats on your calendar.
  2. Write the offline checklist (job sentence, hard rules, format, refuse, owner, three tests).
  3. Create the GPT on web if you have paid create rights. If not, draft instructions in a note and use plain chat until you do, or use a GPT a teammate shares when policy allows.
  4. Run three real inputs in Preview. Fix instructions once per failure mode, not five knobs at once.
  5. Keep share private for one real work cycle. Then decide whether anyone else needs it.

What Part 2 covers

Part 2, Instructions, knowledge files, and actions (light), goes inside the three layers you barely touched: how to structure instructions so they stick, how to version knowledge without rotting, and why actions are a deliberate later step with higher risk. You will get a fuller instruction skeleton and a clearer “when to stop at text recipes” line.

Quick recap

  • A Custom GPT is a saved ChatGPT recipe: name, instructions, optional knowledge, optional actions/tools.
  • Creating usually needs paid (Go/Plus+ and similar); Free users often can still use GPTs others share.
  • First GPT: one repeating job, no actions, non-secret knowledge only, Preview on three real inputs.
  • Instructions are the spine. Name it like a tool. Own it like a process.
  • GPTs do not replace Work, Codex, or real software. Different doors for different jobs.

Sources

Research and further reading used for this article: