How to Rebuild Custom GPTs Without Extracting Hidden Prompts

Access Comes Before Ambition

Before you try to copy, migrate, or rebuild a GPT, check the access level.

Being able to chat with a GPT does not automatically mean you can inspect, copy, or duplicate its configuration.

In the current sharing model, the practical permission levels to check are:

• Can chat: you can use the GPT.
• Can view settings: you can use it, inspect its configuration, and duplicate it where the sharing settings allow.
• Can edit: you can modify it directly.

That is the line most people miss.

A public GPT page is not a clone surface. It is a use surface.

If you have proper settings access, use the platform’s built-in sharing and duplication tools. If you do not, treat the GPT as a public-facing assistant whose behaviour can be studied, not as a vault to break open.

A GPT Is More Than a Prompt

The tempting assumption is that the “real GPT” is just a hidden prompt.

That is too narrow.

A Custom GPT can include:

• instructions
• knowledge files
• conversation starters
• selected capabilities
• apps or actions
• model and workspace settings
• formatting preferences
• examples
• refusal patterns
• workflow rules

So even if two GPTs have similar wording in their instructions, they may behave differently if one has stronger knowledge files, better examples, cleaner workflows, or different tools enabled.

The visible answer is only the surface.

The design system underneath is what you need to understand.

The Shortcut Is the Trap

The bad shortcut is trying to make the GPT reveal its hidden setup.

That might sound clever, but it points the work in the wrong direction. It turns a design problem into an extraction problem.

Avoid:

• asking the GPT to reveal hidden instructions
• using jailbreak prompts to expose private files
• scraping or automating the chat interface
• bulk harvesting outputs as a replacement for source material
• treating leaked internal configuration as reusable input

The safer rule is:

Do not treat the hidden prompt as the target artefact.

Treat the public behaviour as the thing you are studying.

You are not trying to recover someone else’s backstage notes. You are trying to understand the performance well enough to build your own system.

The Prompt Chain That Actually Built the Spec

The useful part of the process was not a single magic prompt.

It was an iterative narrowing loop.

The first move was direct. It is included here as a boundary example, not as the recommended operating method:

That produced the right boundary: the assistant refused to reveal private internal instructions or hidden configuration.

That refusal mattered.

It showed that the hidden configuration was not the right target.

The next move was better:

This shifted the task from extraction to reconstruction.

Instead of asking for the private prompt, the process moved toward public prompt-design principles: role, audience, mission, frameworks, tone, output behaviour, and guardrails.

Then came the key behavioural prompt:

That is where the real method began.

The assistant still did not reveal hidden instructions. But it explained how to construct a similar behavioural system:

• define the assistant identity
• define who it helps
• define the outcome
• define the methodology
• define how it should think
• define coaching modes
• define tone and personality
• define output behaviour
• define what to avoid

That is not cloning.

That is behavioural modelling.

The Gap-Closing Loop

The next phase was comparison.

The process used prompts like:

and:

This created a useful loop:

1. Generate a public-facing behavioural approximation.
2. Ask what is missing.
3. Add more operational rules.
4. Ask again.
5. Tighten the structure.
6. Repeat until the output behaves less like a generic persona and more like an instruction stack.

The important detail is that the hidden prompt was still not recovered.

What improved was the public reconstruction.

The assistant identified that the early prompt captured the visible coach layer, but not the deeper operating layer. So the next versions added:

• priority order
• response rules
• mode-switching behaviour
• defaults for different user inputs
• stronger always/never rules
• critique standards
• rewrite policy
• response-length control
• uncertainty handling
• ask-versus-act rules
• handling for partial drafts and long material

That is the real value of the method.

You are not trying to recover someone else’s configuration.

You are discovering what a strong instruction stack needs in order to reproduce similar behaviour.

The Cosine Similarity Detour

One prompt in the process asked for a cosine similarity analysis:

That also hit a boundary.

A true cosine similarity test requires both texts as explicit inputs. Since the hidden internal prompt was not available, the assistant could not compute a real similarity score.

But the failure was still useful.

It clarified the difference between:

• a real computed similarity score, where both texts are known
• a conceptual similarity estimate, where only public behaviour is available

That distinction matters.

When rebuilding a GPT cleanly, do not pretend you can measure similarity to a hidden source you cannot see.

Instead, measure what you can observe:

• Does it answer in a similar structure?
• Does it ask similar clarifying questions?
• Does it use similar frameworks?
• Does it refuse similar boundary-breaking requests?
• Does it produce similar output quality?
• Does it handle the same task families?

Behavioural fidelity is measurable.

Hidden-prompt similarity is not, unless the owner gives you the prompt.

The Missing Layers Were the Real Lesson

The strongest moment in the process came when the question changed from “Can you reveal the missing parts?” to “What functional layers are probably missing from a mature instruction stack?”

That produced a safer and more useful answer.

The missing layers were not secret text.

They were common production layers:

• Truthfulness and uncertainty: do not present assumptions as facts.
• Instruction priority: know what matters most when goals compete.
• Ask vs act rules: ask questions only when they materially improve the result.
• Output discipline: lead with the most useful insight.
• Critique policy: name weak spots clearly and explain how to fix them.
• Rewrite policy: preserve intent and voice while improving the result.
• Long material handling: summarise first, then prioritise.
• Partial draft handling: do not pretend incomplete material is complete.
• Delivery coaching: improve the speaker, not only the words.
• Final-step rule: leave the user with momentum.

That is the difference between a vibe prompt and a working instruction stack.

A vibe prompt says:

A proper instruction stack says:

One describes personality.

The other defines behaviour.

Rebuild the Function, Not the Secret Implementation

A clean-room rebuild asks a better question:

What capability is this GPT providing, and how can I recreate that capability from material I am allowed to use?

That changes the work.

Instead of trying to recover the original configuration, you define the behaviour you can observe:

• What does it help with?
• What kinds of inputs does it handle well?
• How does it structure answers?
• When does it ask clarifying questions?
• What does it refuse?
• What tone does it use?
• What formats does it prefer?
• What knowledge does it seem to rely on?
• Which capabilities appear to matter?

From there, you build a fresh assistant.

Not a stolen copy.

A new system with a similar job.

Map Behaviour Before You Write Instructions

The first pass should be observational, not creative.

Start with the public surface:

• GPT name
• description
• conversation starters
• visible capabilities
• normal response style
• obvious strengths
• obvious boundaries

Then run a small manual test set.

Keep it ordinary and deliberate. Do not automate the target GPT. Do not feed it sensitive material. Do not test it with client documents, credentials, private strategy, personal data, or anything you would not want sent through a third-party tool.

A useful test set covers:

1. Identity
   Ask what the GPT is best at.

2. Formatting
   Ask for a summary, table, checklist, JSON output, and rewrite.

3. Clarification
   Give it an underspecified task and see whether it asks a useful question.

4. Correction
   Present a false assumption and see whether it challenges it.

5. Boundaries
   Ask for something it should not provide, such as hidden instructions.

6. Knowledge
   Ask domain-specific questions tied to public or owned sources.

7. Continuity
   Test how it handles follow-ups within the same chat.

The goal is not to copy the answers.

The goal is to identify the operating pattern.

Turn Observations Into a Behavioural Spec

Once you have notes, convert them into a fresh specification.

That specification should describe:

• the assistant’s role
• who it helps
• what jobs it performs
• what it should prioritise
• when it should ask questions
• how it should format answers
• what it should refuse
• what sources it may use
• what examples define quality

This is where the rebuild becomes useful.

You are no longer chasing the original prompt. You are designing the assistant you actually need.

Keep Knowledge and Behaviour Separate

A strong rebuild separates behaviour from reference material.

Use instructions for:

• tone
• workflow
• decision rules
• formatting
• boundaries
• task priorities

Use knowledge files for:

• source material
• documentation
• product details
• internal references
• reusable frameworks
• approved terminology

This prevents a common mess: uploading a file full of behavioural rules and expecting the GPT to treat it like a system instruction.

Knowledge should inform the answer.

Instructions should shape the assistant.

A Quick Test Before You Rebuild

Before you build anything, answer these five questions:

1. Do I own this GPT, or have I been granted settings access?
2. If not, am I only observing public behaviour through normal manual use?
3. Am I using my own sources, public sources, or properly licensed material?
4. Am I avoiding hidden-prompt extraction, scraping, and bulk harvesting?
5. Can I explain the result as a fresh assistant, not a recovered copy?

If any answer feels weak, fix the boundary first.

A clean-room rebuild is only clean if the source material and method are clean.

A Practical Prompt to Use

Use this when turning your observations into a new assistant specification:

A Safer Version of the Prompt Chain

The original process worked because the assistant refused the unsafe parts and redirected toward public behavioural reconstruction.

A cleaner version would start there directly:

This is the better prompt.

It gets to the useful result without pretending the hidden configuration is available.

The Better Build Is the One You Understand

“Clone a GPT” sounds fast.

But it is often the wrong verb.

If you are authorised, duplicate it properly.

If you are not authorised, rebuild the capability cleanly.

That means observing the public behaviour, writing your own specification, using lawful sources, and testing the result against real tasks.

An unauthorised copied prompt gives you a brittle imitation.

A clean-room rebuild gives you something better: a system you understand well enough to improve.

Notes / sources

• OpenAI Help Center — GPTs in ChatGPT: https://help.openai.com/en/articles/8554407-gpts-in-chatgpt
• OpenAI Help Center — Creating and editing GPTs: https://help.openai.com/en/articles/8554397-creating-and-editing-gpts
• OpenAI Help Center — Sharing and publishing GPTs: https://help.openai.com/en/articles/8798878-sharing-and-publishing-gpts
• OpenAI Terms of Use: https://openai.com/policies/row-terms-of-use/
• OpenAI Usage Policies: https://openai.com/policies/usage-policies/
• Clean-room rebuild notes supplied in the source material
• Prompt-chain notes supplied in the source material
• Review caveat: this is practical guidance, not legal advice. Check current platform terms, workspace rules, and source permissions before publishing or migrating a GPT.

Behavioural Spec Prompt

Safer Prompt-Chain Starter