Show Replit: I built a multi-stage prompt optimizer that catches logical flaws before your AI sees them

[ex-fallows]

Hey everyone,

​I didn’t have any previous coding experience, but I constantly found myself unable to tell AI exactly what I wanted. To solve my own problem, I started building Prompt Kaizen in my free time after work, coding the entire thing straight from my phone. I actually ended up building the optimization engine by using the engine itself to write the prompts! I want to give a huge thank you to Replit for providing such an incredible platform that allows someone without experience to just start building something real.

​Prompt Kaizen compiles vague inputs into production-grade specifications. It’s not a “make my prompt longer” tool. It’s a multi-stage pipeline that analyzes, enriches, stress-tests, and scores your prompts before you ever paste them into an AI.

​Here’s the live app: https://promptkaizen.com

​THE PROBLEM I KEPT HITTING

​Every AI coding session starts the same way: you type something lazy like “Create a React component,” the LLM fills in 47 assumptions you never made, and you spend the next hour unwinding hallucinated constraints.

​The issue isn’t the model — it’s that we’re feeding it ambiguous inputs and expecting precise outputs. That’s a signal processing problem, not an AI problem.

​WHAT THE PIPELINE ACTUALLY DOES (with real numbers)

​Your prompt goes through 5 stages — you can watch each one stream in real time via SSE:

1. ​Understand — Classifies your intent, detects domain, identifies what’s missing

2. ​Enrich — Expands the prompt with structure, constraints, edge cases, and domain knowledge

3. ​Stress-Test — A red-team pass that attacks the enriched prompt for logical flaws, contradictions, assumption injection, and prompt injection vulnerabilities

4. ​Refine — Reconciles the enrichment with every critique finding to produce the final prompt

5. ​Measure — Evaluates the output across 4 dimensions: clarity, structure, specificity, and redundancy

​Across 65+ completed production runs, the numbers look like this:

• ​Average output score: 84/100

• ​Average score lift: +43 points (input vs. output)

• ​Average expansion: 34x (word count)

• ​Max expansion: 509x (a single-sentence input became a 3,089-word specification)

​THE REAL DIFFERENTIATOR: THE STRESS-TEST CATCHES THINGS HUMANS MISS

​The stage I’m most proud of is the red-team critique. It doesn’t just check grammar — it attacks the enriched prompt for logical contradictions, scope explosion, assumption injection, and even prompt substitution.

​Here are three real catches from production runs:

​Example 1 — Input: “Create a React component” (4 words, scored 8/100)

The enrichment stage expanded it to 667 words with TypeScript interfaces, React 18+ hooks, accessibility requirements, and error boundary patterns. But the stress-test flagged it: the enriched prompt told the developer to include error boundaries while the rest of the prompt pushed functional-only patterns — and React error boundaries require class components. The pipeline caught the contradiction, forced a rewrite, and the final output scored 95/100.

​Example 2 — Input: “Write a python script” (19 words with context, scored 15/100 → final 94/100)

The enrichment expanded a vague automation request into a 610-word structured specification with TOCTOU race condition handling, path validation, symlink resolution, dry-run safety mode, and a blocklist for protected directories. The stress-test validated the expansion, the synthesis cleaned it up, and the final output scored 94/100 — a +79 point lift from a prompt that started as barely usable.

​Example 3 — Input: “Write me a prompt for 3rd game” (8 words, stress-test score 42/100)

This one is where the system earns its keep. The stress-test fired three [CRITICAL] alerts:

• ​Context Mismatch: “Assumes sequential game development learning path, but original provides no context about prior projects or skill level”

• ​Scope Explosion: “Expands 8-word request into ~2000+ word specification with 9 major sections never implied in original”

• ​Assumption Injection: “Unilaterally decides genre (2D platformer), tech stack (JavaScript/HTML5 Canvas), and complexity level without user consent”

​The system flagged it for review instead of blindly shipping an over-engineered spec. In another run, the stress-test even detected prompt substitution — where the enrichment stage generated a completely different prompt instead of optimizing the original. It fired [CRITICAL] “The optimized prompt is not an optimization of the original — it is a completely different prompt.” The system essentially caught itself fabricating, and flagged it before the user ever saw the output.

​5 PRISM MODES

​The pipeline adapts based on what you’re working on:

• ​General Logic — Clear, structured prompts for any AI task

• ​Software Engineering — Technical precision, error handling, implementation specs

• ​Creative Writing — Narrative flow, emotional resonance, world-building

• ​Business Strategy — Brand voice, compliance, professional communication

• ​Education — Socratic approach, learning objectives, reasoning steps

​HOW I BUILT IT ON REPLIT

​I wanted to push the native Replit stack as far as it goes. Here’s the full architecture:

• ​Frontend: React + TypeScript (Vite), Wouter routing, Tailwind CSS, shadcn/ui

• ​Backend: Express.js with SSE streaming for real-time pipeline visualization

• ​Database: PostgreSQL via Drizzle ORM

• ​Auth: Replit Auth (OIDC) — zero-config sign-in, no auth headaches

• ​AI: Replit AI Integrations — dynamically routes between a fast model for scoring/classification and a heavy reasoning model for expansion, critique, and synthesis

• ​Payments: Stripe integration for subscriptions

​The SSE implementation streams each pipeline stage to the UI in real time — you literally watch each stage think, then hand off to the next one. The state machine handles resume/rollback if any stage fails mid-run, so you never lose progress.

​PRICING (transparent, no hidden gotchas)

• ​Free: €0/month — 5 optimizations + 10 bonus credits on sign-up. All Prism Modes, quality scoring included.

• ​Entry: €29/month — 100 optimizations, full history, export/import, Concept Studio. Annual plan available (~20% off).

• ​Pro: €79/month — 350 optimizations + Integrity Engine, Forensic Analysis, Bulk Optimization, Prompt Memories. Annual plan available (~20% off).

​TRY TO BREAK IT

​I’d genuinely love for this community to stress-test the pipeline. Some things to try:

• ​Feed it a deliberately contradictory prompt and see if the red-team stage catches it

• ​Try a complex multi-step technical spec and check what the enrichment adds

• ​Submit something intentionally vague (like “make an app”) and see how it handles extreme ambiguity

• ​Run the same prompt through different Prism Modes and compare the outputs

​The app is live at https://promptkaizen.com — Free tier gives you enough runs to put it through its paces. If you find something the stress-test misses, or the SSE streaming breaks on your browser, I want to hear about it. That’s how this gets better.

​Built entirely on Replit. Source runs on the Replit stack (Express + Vite + PostgreSQL + Replit Auth + Replit AI Integrations).

[realfunnyeric]

Don’t forget the only part that matters: What’s your plan for getting users to the site?

[ex-fallows]

Will add some real results from optimization. Would like to know others opinion.

Input prompt:

Build a React login component Context: This React login component should integrate with OAuth providers like Google or GitHub for third-party authentication

Output prompt:

Context

You are building a React login component that serves as the authentication entry point for a web application. The component must support third-party OAuth 2.0 authentication via configurable providers, with Google and GitHub as the default/example implementations. The component should be extensible so additional OAuth providers can be added with minimal effort.

Scope note: This task focuses on the frontend React component and its OAuth redirect handling. Where backend involvement is required (e.g., token exchange), provide the expected API contract (request/response shapes) rather than a full backend implementation. Clearly label any backend-dependent logic.

Task

Build a React login component with the following requirements:

1. Component Architecture

• Create a functional React component using hooks (useState, useEffect, useCallback)
• Implement a composable component hierarchy:
  • LoginPage — parent container
  • OAuthButton — reusable, provider-agnostic button that accepts provider config
  • OAuthCallbackHandler — handles the redirect/callback URL parsing
• The component must be configurable via props:
  • providers: array of provider config objects ({ id, name, authorizationUrl, clientId, scopes, iconUrl })
  • onAuthSuccess: callback receiving { provider, accessToken, user } on successful auth
  • onAuthError: callback receiving { provider, error, errorDescription }
  • redirectUri: the OAuth callback URL
• Use JavaScript (ES2020+) by default. If the user’s project uses TypeScript, provide type definitions as a supplementary file

2. OAuth Integration

• Implement the Authorization Code Flow with PKCE (Proof Key for Code Exchange) as the default and recommended flow per current OAuth 2.1 best practices
• Use a redirect-based flow (not popup) as the primary approach for reliability and accessibility
• Handle the full client-side portion of the flow:
  1. User clicks an OAuth provider button
  2. Generate a cryptographically random state parameter (for CSRF protection) and a PKCE code_verifier/code_challenge pair; store both in sessionStorage
  3. Redirect to the provider’s authorization endpoint with client_id, redirect_uri, scope, state, code_challenge, and code_challenge_method=S256
  4. On callback, parse the URL for code and state parameters
  5. Validate the state parameter against the stored value (reject on mismatch)
  6. Send the code and code_verifier to your backend token exchange endpoint (documented below) — do not exchange tokens directly from the frontend unless using a BFF pattern
  7. Receive the auth result and call onAuthSuccess
• Provide provider configuration examples for Google and GitHub, including their specific authorization URLs, required scopes (openid profile email for Google; read:user user:email for GitHub), and any provider-specific quirks

Important: Never expose client_secret in frontend code. All secret-based token exchanges must happen server-side.

3. Backend API Contract

Since secure OAuth requires server-side token exchange, document the expected backend endpoint:

POST /api/auth/oauth/callback
Request body: { provider: string, code: string, codeVerifier: string, redirectUri: string }
Success response: { accessToken: string, user: { id, email, name, avatarUrl }, expiresIn: number }
Error response: { error: string, errorDescription: string }

Provide this contract clearly in the README. Optionally include a minimal Node.js/Express stub (< 50 lines) showing the token exchange call to the provider.

4. UI/UX Requirements

• Render branded OAuth buttons that follow each provider’s branding guidelines (reference the relevant docs: Google Identity branding guidelines, GitHub logo usage policy)
• Show a loading/spinner state after the user clicks a provider button and during the redirect flow
• Display clear error messages for these scenarios:
  • OAuth provider returns an error (e.g., access_denied, invalid_scope)
  • state parameter mismatch (possible CSRF — show a generic security error, not details)
  • Network failure during token exchange
  • Unknown or unexpected errors
• Ensure accessibility (a11y):
  • Semantic HTML (<button>, not <div onClick>)
  • aria-label on each OAuth button (e.g., "Sign in with Google")
  • Keyboard navigable (tab order, Enter/Space activation)
  • Visible focus indicators
  • Loading state announced to screen readers via aria-live region
• Responsive: must work on viewports from 320px to desktop widths

5. State & Error Handling

• Manage local component state with useState/useReducer for { isLoading, error, activeProvider }

• For app-wide auth state, provide a suggested AuthContext pattern as a separate, optional file with a recommended interface:

  { user: User | null, isAuthenticated: boolean, isLoading: boolean, login: (provider) => void, logout: () => void }
  

  Note: This is a suggested pattern. Adapt it to fit any existing auth state management in your application.

• Handle edge cases:

  • User navigates away during OAuth flow and returns later (stale state in sessionStorage)
  • Provider returns an error query parameter instead of a code
  • Backend token exchange returns a non-200 response

6. Security Checklist

• PKCE with S256 challenge method on all Authorization Code flows
• Cryptographic state parameter validated on every callback
• No client_secret in frontend code
• HTTPS enforced for all OAuth endpoints
• sessionStorage (not localStorage) for temporary OAuth state (cleared after use)
• All provider-returned data treated as untrusted and validated

Constraints

• React 16.8+ (hooks required). Note any usage of React 18+ features (e.g., useId) so users on older versions can substitute
• Functional components only — no class components or deprecated lifecycle methods
• Established OAuth libraries are encouraged where they improve security and reduce risk (e.g., @react-oauth/google for Google’s GSI integration). Justify each dependency with a one-line rationale
• Use generic environment variable names: GOOGLE_CLIENT_ID, GITHUB_CLIENT_ID, OAUTH_REDIRECT_URI. Include a note that the variable prefix depends on the build tool (REACT_APP_ for CRA, VITE_ for Vite, NEXT_PUBLIC_ for Next.js)
• Include inline comments explaining OAuth-specific logic (PKCE generation, state validation, redirect URL construction)

Output Format

1. File structure overview showing all files and their purpose
2. Complete source code for each component file
3. README section containing:
   • Environment variable setup with build-tool prefix guidance
   • Step-by-step OAuth app registration instructions for Google and GitHub
   • Usage example showing how to render the LoginPage component with provider config
   • The backend API contract (from Section 3)
4. Optional enhancements section listing clearly-labeled extensions:
   • Email/password form alongside OAuth
   • Token refresh logic
   • Additional providers (Microsoft, Apple, etc.)
   • Unit test examples (Jest + React Testing Library)

[ex-fallows]

Spot on distribution is next mountain to climb. But first wanted to get some feedback on actually output and UI from community first .