Manifester

One prompt turns project data into a local app that grows as you use it.

Comment 2

Inspiration

Useful operational data often lives in CSV, JSON, and spreadsheet files. Turning it into software usually means defining requirements, choosing a framework, building screens and APIs, and maintaining another application.

Manifester explores a different model: describe the outcome once, then let the application grow from real usage.

What it does

Manifester is a Codex plugin that turns a project's files and data into a tailored local application.

A user opens a project in Codex and asks:

Create the most useful application for the data in this project.

Manifester discovers the project, understands its data and intended workflow, generates a useful starting application, imports supported data into local SQLite, starts the application, and opens it alongside a React management dashboard.

The initial application builds only the experience needed now. Deeper features remain deferred until the user chooses them. On first use, GPT-5.6 creates and reviews the requested route in staging. Later visits reuse the generated feature.

The manager shows applications as soon as generation begins, retains failures with an activity log, records lifecycle progress, links each completed application to its own Codex build task, and provides start, stop, restart, removal, deletion, and ChatGPT Sites publishing controls.

How it works

  • Project inventory excludes generated folders, secrets, unsupported large files, and source-control internals.
  • GPT-5.6 performs network-disabled, read-only discovery and returns a structured description of the domain, users, relationships, and most useful workflow.
  • If intent confidence is low, Codex asks up to three short questions through its native form.
  • A separate workspace-limited Codex task generates the home experience in an isolated staging directory.
  • Manifester validates the HTML, CSS, JavaScript, application registry, data access, and route structure before publishing it locally.
  • Deferred features repeat staging, review, and validation without changing existing routes.
  • Create, edit, and delete operations use a local SQLite copy, leaving the original files untouched.

CSV, JSON, XLSX, and XLSM data are supported. Source fingerprints prevent an application from silently continuing when its input files have changed.

How I used Codex and GPT-5.6

GPT-5.6 is the reasoning and generation engine inside Manifester. It interprets unfamiliar project data, selects an application shape, generates the initial experience, and builds deeper features from demonstrated user intent.

Codex provides the signed-in runtime, structured output, isolated tasks, native questions, plugin skills, MCP tools, and task continuity. No separate OpenAI API key is required.

I also used Codex throughout development to refactor the project into a focused PNPM monorepo, separate plugin, MCP, server, CLI, and runner concerns, diagnose lifecycle failures, review generated application contracts, exercise the React manager in a real browser, and repeat packaging and clean-install checks.

What judges can verify

The release includes prebuilt plugin artifacts, so the verified macOS installation path does not require PNPM or a source build. The demo shows a project containing a simple task management app that is built from a csv task table.

A judge can install the plugin, open the task-management sample, issue one prompt, and verify:

  • The application and manager open automatically.
  • Generation progress is visible immediately.
  • The generated workflow follows the supplied data rather than a fixed dashboard template.
  • A Task list app is generated
  • Going to a new route like /view/kanban / tasks/<task-id> generates a new page based of the entent of that URL.
  • Basic CRUD works.
  • Any edits survive an application restart.
  • The original CSV remains unchanged.
  • Publishing stays guarded until every deferred feature has been opened.

Key safety and design choices

  • Discovery is read-only and network-disabled.
  • Generation runs in a workspace-limited staging directory with network access disabled.
  • Generated output is validated before replacing the working application.
  • Deferred generation may use only the data authorized for that action.
  • Existing generated routes cannot be rewritten during just-in-time expansion.
  • Project edits remain in local SQLite instead of changing source files.
  • Changed source files block stale local data from being used.
  • ChatGPT Sites publishing is available only after deferred features are complete.
  • The publishing workflow uses only the prepared .manifester/site project. SQLite and Manifester working files stay local.

Challenges

The hardest challenge was balancing open-ended generation with a dependable application contract. The result needed to feel tailored to each dataset without allowing generated code to access arbitrary files, processes, networks, or unrelated data.

Long-running generation also had to fit a conversational plugin workflow. Manifester starts a progress application immediately and records lifecycle activity in the manager instead of leaving the user with an indefinite loading state.

Just-in-time features introduced another constraint: a new route must extend the application without silently altering routes that already work. Staging, route-source checks, resource scoping, structured registries, and a second GPT-5.6 review pass provide that boundary.

Accomplishments

  • One prompt turns included project data into a usable local application.
  • Applications grow from real user actions instead of predicting every screen upfront.
  • Local edits persist across application and manager restarts.
  • The dashboard exposes generation, failure, activity, lifecycle, and publishing state in one place.
  • The plugin runs through the user's signed-in Codex session without a separate API key.
  • Every production runtime is built and minified with Vite and packaged as a prebuilt Codex plugin.
  • Generated applications remain lightweight vanilla HTML, CSS, and JavaScript with no CDN or frontend build requirement.

What I learned

The most useful generation workflow is not one large prompt. Separating discovery, initial generation, intent-driven expansion, review, and deterministic validation produces a more focused application and clearer failure boundaries.

Generation progress is also part of the product. A visible lifecycle, persistent activity, and an inspectable failure are as important as the final screen when software is being built interactively.

What's next

Next steps include verifying additional operating systems, supporting more structured data sources and larger datasets, adding richer application history and export options, and exploring how a hosted application could preserve selected interactivity without exposing Manifester's private local state.

Built With

Share this project:

Updates