SkillSpring Quantum

Turn AI conversation exports into searchable local archives, so you can find past answers without scrolling through chat history or uploading your data to another service.

Comment

Inspiration

AI conversations often contain useful answers, plans, and decisions, but they quickly disappear into long chat histories. I wanted a way to recover something I remember asking—without scrolling through hundreds of loosely titled threads or uploading personal exports to yet another service.

What it does

SkillSpring Quantum is a local-first Windows desktop app that turns supported AI conversation exports into readable archives, searchable history, and privacy-aware datasets.

A user checks an export, imports it locally, reviews readable conversation slices, and later searches for past material. The app supports a focused workflow: Imports → Readable Archive → Datasets → Find Imports.

How I built it

I built Quantum with TypeScript, React, Electron, and a deterministic import pipeline. It includes vendor-aware export detection, local archive generation, dataset creation, retrieval indexes, import activity history, reuse and resume handling, and a Windows installer.

Codex and GPT-5.6 were active engineering collaborators throughout the build. I used them to inspect and refactor the codebase, plan and implement recovery safeguards, add regression tests, debug packaged-runtime issues, improve documentation, and prepare the final submission workflow.

Challenges and lessons

The hardest challenge was trust: an import tool must not silently lose, duplicate, or misrepresent a user’s conversation history. I focused on deterministic processing, explicit preflight checks, activity visibility, safe reuse, checkpointed resume behaviour, atomic writes, and regression coverage.

I also learned that the product’s clearest value is memory recovery. People do not think in terms of datasets or indexes—they think, “I know I asked AI about this before.” That insight shaped the demo, documentation, and local-first design.

Built With

Share this project:

Updates

posted an update —

When I submitted SkillSpring Quantum to OpenAI Build Week, the main workflow was already working:

Imports -> Readable Archive -> Datasets -> Find Imports

The submitted 0.1.0-beta.1 Windows build could take the synthetic ChatGPT demo export, check it before processing, build a readable local archive and structured datasets, and make the imported history searchable again.

After submission, I moved from demo preparation into private-beta preparation. That meant using current exports from several AI platforms, trying less convenient paths, and paying attention to places where Quantum could technically continue but should instead stop and explain what was wrong.

Most of the changes since Build Week are small in isolation. Together, they make the product more honest and safer to test.

Better compatibility with real vendor exports

A current Microsoft Copilot activity export exposed a tiny format difference with a large practical effect: its CSV header began with a UTF-8 byte-order mark. Quantum's strict header check did not recognise the otherwise valid file.

The importer now handles that BOM explicitly, with regression coverage based on the real export shape. I then tested Copilot alongside ChatGPT, Claude, and Grok in one local workspace. Across that rehearsal, Find Imports showed four vendors, 1,000 conversations, and 27,017 messages together.

Refusing misleading Gemini imports

A Google Takeout package created a different kind of problem. It contained Gemini-related attachments but no usable Gemini conversation history. Auto Detect could previously fall through to generic document processing and make the package look more importable than it really was.

Quantum now recognises attachment-only Gemini Takeout folders and stops at Export Check. It explains that Gemini chat activity is missing and does not offer the Import action. This is an important product principle for Quantum: a clear refusal is better than producing output that misrepresents what was imported.

Protecting the original export folder

Testing also exposed a confusing source/output configuration. If the selected output workspace was the export folder itself—or a folder inside it—Quantum could write its own workspace files beside the raw source material.

The current candidate blocks that configuration in both the Imports screen and the underlying import runner. The user is asked to choose a separate sibling folder, the import actions stay hidden while the conflict exists, and Export Check no longer recommends importing while import is blocked.

Nothing is deleted or moved. The safeguard is about keeping original exports and generated Quantum workspaces clearly separated.

More honest ChatGPT package handling

Current ChatGPT exports can arrive as multiple conversation shards with additional companion files. Quantum now keeps the shard-first conversation path clear, identifies unsupported companions such as a separate codex.json history without treating them as failed conversations, and preserves local attachment references with readable labels where the package provides them.

The current sharded export remains the recommended ChatGPT path. Legacy chat.html support still exists as a compatibility route, but I am keeping its progress behaviour on the beta observation list rather than overstating it.

Testing the workflow, not just the parser

The post-submission work has included packaged walkthroughs as well as automated tests.

In the latest quick laptop test:

  • Activity History captured every action I observed
  • Readable Archive and Datasets became viewable after the first source file completed
  • both screens loaded within a minute on that laptop
  • Find Imports remained unavailable until the full import completed

Those timings are observations, not performance promises. I will repeat them with explicit machine and export-size evidence during the clean-machine rehearsal.

The repository's full regression gate currently covers vendor intake, import history and metadata, sharded imports, retrieval, archive and dataset readers, pipeline behaviour, the optional assistant boundary, and governance rules.

Keeping the Build Week submission frozen

The original Build Week artifact has not been replaced by this later work. The submitted source remains pinned to commit 465ebb5 with the annotated build-week-2026-submission tag and the v0.1.0-beta.1 release tag. The installer, checksum, synthetic demo, screenshots, and video remain recorded as the historical submission set.

The current repository identifies as 0.1.0-beta.6, but beta.6 is a private-beta candidate, not a new public release. Keeping that boundary explicit makes it possible to continue improving Quantum without rewriting what judges originally received.

What comes next

The next phase is evidence rather than feature expansion:

  • complete the beta.6 clean-machine rehearsal
  • gather smaller, current, privacy-safe test exports for each supported vendor
  • verify the vendor export guides against their live interfaces
  • rehearse the privacy-safe support and feedback process
  • run the first external user session without step-by-step developer guidance

Build Week helped me get Quantum into a coherent, demonstrable shape. The work afterward has been about something less visible but just as important: making sure the app tells the truth about what it sees, protects the user's source material, and fails safely when an export is not what it appears to be.

That is the version of Quantum I want to put in front of beta testers.

Log in or sign up for Devpost to join the conversation.