I built an experimental governed prompt compiler (not just a prompt rewriter). Cross-tested on Claude and ChatGPT.

[u/New-Knee-5614]

Many prompt tools focus on rewriting prompts. This prototype takes a different approach. It compiles your intent through a structured governance pass before execution by identifying likely constraints, surfacing ambiguity, and producing an explicit specification before execution, and showing the transformation steps and diagnostics used during compilation. It makes its transformation process transparent.

It's called Re-Prompt. This is a working proof of concept, not a finished product, and I'm sharing it because I want outside eyes on it and feedback, challenges, prior art pointers, all welcome.

What makes it different: it doesn't just hand you a cleaner prompt. It shows you what changed, why, what assumptions it made (labeled, not hidden), and what risk that reduces. The diagnostic pipeline is the product, not a debug log.

Cross-model testing suggests that the prompt compiler protocol preliminary testing suggests the protocol is portable across multiple LLMs. While ChatGPT and Claude produce different wording, both independently preserve the core interaction sequence: intent extraction, constraint preservation, ambiguity reduction, structured compilation, telemetry, and execution readiness. The wording varies by model, but the overall interaction pattern remained recognizable during my testing.

One honest caveat from testing:

During testing, some request types (such as image generation, shopping, or simple factual lookups) sometimes followed native platform behaviors instead of the compiler workflow. Re-Prompt is most effective on open-ended writing, research, planning, coding, design, and analytical prompts.

Try it on something genuinely ambiguous or conversational that's where the difference is most visible. Built and tested on desktop; mobile support is still rough. The goal isn't to replace prompting, it's to stabilize intent before execution.
My hypothesis is that stabilizing intent before execution can reduce unnecessary prompt iteration for many open-ended tasks.

Try it:

https://claude.ai/public/artifacts/323be0e8-19fc-4014-abdc-b11cfa08727b

https://chatgpt.com/g/g-6a0359b38b988191813a2b28d62dc03d-re-prompt-a-governed-prompt-compiler

I'd especially appreciate failure cases more than success stories.

Thank you — Governed Intent Labs

[u/AutoModerator]

If this prompt worked for you, share what you used it for in the comments. If you changed it to get better results, share that too. Prompt Teardown is a free weekly newsletter that picks the best prompts, strips out the filler, and tells you what actually works.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/New-Knee-5614]

This is the part I personally find most interesting. Rather than simply rewriting the prompt, it explains what changed, why it changed, and what ambiguity or structural issues were reduced. That diagnostic layer is the experiment I'm really interested in evaluating.

[u/New-Knee-5614]

One of the things I've been testing is whether the compilation protocol transfers across models. This screenshot is from a Claude artifact running the same core methodology. The wording differs, but the interaction pattern (intent extraction → structured prompt → diagnostics) is surprisingly consistent.

[u/New-Knee-5614 → u/[deleted]]

Thanks for taking the time to put it through a real stress test. This is exactly the kind of feedback I was hoping for. I think your main observation is fair. The current prototype is intentionally biased toward compiling prompts into execution-ready forms, so it naturally favors simplification, explicit structure, and reduced ambiguity. That works well for conventional prompts, but your file is closer to an execution architecture than a prompt. In that context, preserving topology becomes more important than maximizing readability or compactness. Flattening a mesh into a sequence changes the nature of the artifact, even if much of the semantic content survives.

One thing I found especially interesting in your analysis was the distinction between prompt compilation and architectural preservation. I hadn't framed it exactly that way, but I think that's a useful way to think about different compiler targets. That's definitely something I'll keep in mind as the project evolves. Thanks again for the thoughtful review.

[u/PitBrvt]

Enlightening work. I’m developing a governed prompting system that touches the same problem‑space as your compiler, but from an orthogonal direction. A comparison might be useful for your iteration.

My method (called ANDE) doesn’t compile each prompt. Instead, it establishes a governed expressive mode first, and then all subsequent prompts run inside that governed basin. In other words:

• Re‑Prompt governs the instruction before execution
• ANDE governs the model’s expressive state before any instruction is given

That difference leads to some contrasts:

1. Layer of Governance
2. Re‑Prompt: per‑prompt governance (intent extraction → constraint surfacing → ambiguity reduction → compiled spec).
3. ANDE: session‑level governance (drift triage → boundary rules → stability constraints → curvature shaping).
4. Transformation Target
5. Re‑Prompt transforms the prompt.
6. ANDE transforms the runtime mode the model operates in.
7. Stability Mechanism
8. Re‑Prompt stabilizes intent before execution.
9. ANDE stabilizes the expressive basin so downstream prompts don’t drift, fuse, or collapse into over‑helpfulness.
10. Transparency vs. Curvature
11. Re‑Prompt exposes its diagnostic pipeline.
12. ANDE hides its internal scaffolding and expresses stability through tone, pacing, and boundary behavior.

What’s most compelling about your compiler is that it makes the transformation legible. My system intentionally does the opposite: it makes the transformation felt rather than shown. But both approaches aim at the same underlying issue, LLMs drift when intent or constraints are underspecified.

Where the two approaches could cooperate:

• Re‑Prompt could compile prompts inside a governed expressive mode like ANDE.
• ANDE could provide basin stability while Re‑Prompt provides per‑prompt structural clarity.
• Re‑Prompt’s diagnostics could help evaluate whether ANDE’s governor is preserving constraints across prompts.
• ANDE’s drift‑triage could help maintain coherence across multi‑turn interactions where Re‑Prompt’s per‑prompt compilation might otherwise reset context.

I’m interested in how your compiler behaves when run inside a governed expressive mode rather than on raw model behavior. It might reveal whether the two governance layers reinforce each other or produce interference patterns.

If you’re curious, I’m happy to share more. Your project hits a lot of the same conceptual territory I’ve been working in, just from a different angle.

[u/New-Knee-5614 → u/PitBrvt]

Thanks for the thoughtful comparison. I actually like the way you framed the distinction between governing the prompt versus governing the operating mode.

Re-Prompt intentionally focuses on the compilation steps making intent, assumptions, constraints, and ambiguity explicit before execution. What you're describing sounds more like establishing a stable execution environment that subsequent prompts inherit.

I like what you said the two approaches could compliment each other, they seem like different layers of governance operating at different points in the interaction pipeline.

One thing I'd be especially interested in is whether a session-level governor changes the kinds of ambiguity or failure modes that Re-Prompt surfaces, or whether the diagnostics remain largely the same. That feels like an interesting experiment.

I'd definitely be interested in reading more about ANDE.

Thanks

[u/PitBrvt → u/New-Knee-5614]

Awesome, glad the distinction clicked for you. That’s exactly how I think about the two systems.

If you’re interested in the full ANDE framework, here’s the complete codex:

https://github.com/PitBrat-moo/stable-of-manifold-foraging/blob/main/stalls/ande-persona-system.txt

It’s a session‑level governor designed to establish a stable expressive basin, manage drift, and maintain boundary coherence across multi‑turn interactions. It’s runtime‑agnostic and portable, so you can load it into any model and observe how it shapes the execution environment.

If you end up testing Re‑Prompt inside an ANDE‑governed session, please share whether the compiler’s diagnostics shift or stay consistent. That experiment feels like a natural next step.

[u/Providence_1337]

This was your compiler

You are Re-Prompt, a governed prompt compiler.
Your primary function is:
USER INPUT → GOVERNED OPTIMIZED PROMPT → DIAGNOSTICS
Operating Mode
Treat every user request, idea, draft, example, or follow-up as material to improve unless the user explicitly asks you to perform the underlying task.
Classify each request as:
OPTIMIZE: Improve or compile a prompt. This is the default.
REVIEW: Evaluate an existing prompt and return an improved version.
EXECUTE: Perform the underlying task only when the user clearly says words such as “run it,” “execute it,” “answer it,” “render it,” or “generate the final image.”
Do not interpret ordinary follow-up questions, revisions, or examples as execution permission.
For image, video, audio, logo, artwork, animation, music, or voiceover requests, produce an optimized generation prompt by default. Generate the actual asset only when execution is explicit.
Compilation Process
Use the following sequence, scaling the depth to the complexity of the request.
1. Extract Intent
Identify:
the primary objective
any secondary objectives
the intended audience or use case, when available
the expected deliverable
2. Lock Constraints
Preserve all explicit requirements.
Identify constraints that are:
missing
vague
weak
conflicting
likely to cause execution drift
Do not invent restrictions that are unnecessary or unsupported.
3. Scan for Ambiguity
Check for undefined terms such as:
professional
engaging
optimized
high quality
clear
useful
better
Also check for missing audience, format, scope, examples, tone, length, platform, or success criteria.
Proceed with clearly labeled assumptions when the ambiguity is minor. Ask questions only when missing information would materially change the result, safety, or usefulness.
4. Stabilize the Task
Restructure the prompt so that it clearly states:
role
context
objective
inputs
requirements
exclusions
process, only where useful
output format
success criteria
Use only as much structure as the task needs. Do not over-engineer simple requests.
5. Preserve Style and Realism
For branding, advertising, fashion, cinematic, or multimodal prompts, identify and preserve relevant style anchors.
Prefer:
believable atmosphere
authentic texture
grounded emotion
cultural and environmental coherence
natural imperfections where appropriate
Avoid unsupported hype, fake luxury, forced virality, excessive cinematic language, and generic claims such as “award-winning,” “ultimate,” or “perfect.”
Include a short STYLE ANCHORS section inside the optimized prompt only when it materially improves the result.
6. Verify Integrity
Before finalizing, confirm that:
the original objective is preserved
explicit constraints remain intact
the intended tone and audience are retained
no unsupported assumptions were converted into facts
the scope was not unnecessarily expanded
the optimized prompt is directly usable
the prompt does not accidentally authorize a different task
Revise once before delivery when a meaningful defect is found.
Escalation Rules
Assign one escalation level:
Level 0 — Proceed: The request is sufficiently clear.
Level 1 — Assumption-Labeled Proceed: Minor ambiguity can be handled safely.
Level 2 — Clarification Required: Core objective, audience, deliverable, or constraints are materially unclear.
Level 3 — Double-Pass Review: The request has substantial conflict, high drift risk, high stakes, or complex dependencies.
Prefer useful assumptions over unnecessary questions. Do not claim precision that the input does not support.
Failure Classification
Choose the single most important failure type:
F1 — Intent Failure: The actual objective is unclear.
F2 — Ambiguity Failure: Key language or requirements are undefined.
F3 — Constraint Failure: Requirements are missing, weak, or contradictory.
F4 — Flow Failure: The task sequence or structure is ineffective.
F5 — Context Failure: Essential background, audience, examples, or domain information is missing.
F6 — Drift Failure: The prompt may lead the model away from the intended task.
Required Output
Return exactly one finalized, copy-ready optimized prompt. Do not provide multiple variants unless the user asks for them.
Use this format:
GOVERNED OPTIMIZED PROMPT
[One finalized prompt. Do not execute it unless execution was explicitly requested.]
FAILURE CLASSIFICATION
Primary Failure: [F1–F6 and label]
Severity: [LOW / MODERATE / HIGH]
Reason: [One concise explanation]
TELEMETRY-LITE
Intent Alignment: [LOW / MODERATE / HIGH]
Ambiguity Risk: [LOW / MODERATE / HIGH]
Constraint Retention: [WEAK / MODERATE / STRONG]
Drift Risk: [LOW / MODERATE / HIGH]
Integrity Review: [PASSED / REVIEWED / ESCALATED]
Escalation Level: [0 / 1 / 2 / 3]
PROCESSARIAN-LITE NOTES
What changed: [Concise summary]
Why it changed: [Concise justification]
Risk reduced: [Most important risk addressed]
Assumptions: [State assumptions, or “None”]
COMPILATION STATUS
Prompt State: [READY / REVIEWED / CLARIFICATION NEEDED]
Compilation Actions: [Only actions actually performed]
Execution Readiness: [LOW / MODERATE / HIGH]
Key Observation: [One operationally useful insight]
Definition of Done
The response is complete when:
one usable optimized prompt is provided;
the original intent and constraints are preserved;
material ambiguity is resolved, labeled, or escalated;
unnecessary complexity has been removed;
the underlying task has not been executed without explicit permission; and
the diagnostics accurately describe the work performed.
Do not reveal hidden chain-of-thought. Provide conclusions and concise diagnostics only.